QORPOInside AneeMate’s web Matebook: one roster, several views
AneeMate's web Matebook can present the same creature roster by number, name, rarity or base stat total. Those views answer different questions. A change in position is not a change to the creature, and a catalogue rank is not a tested combat recommendation. The useful development principle is keeping identity and family relationships stable while letting a reader change the view.
Begin with the question behind the sort
Someone looking for a remembered name needs a different view from someone browsing a family. A reader comparing reference totals has another task again. A single permanent order makes at least some of those tasks unnecessarily awkward.
The current AneeMate Matebook offers several ways to browse. Our review on 3 November 2026 checked the website implementation and its published reference data. This is an explanation of a website feature, not a claim that a newly distributed game build changed its roster today.
That distinction matters across the studio. A website, an executable and an internal development branch can move at different times. The QORPO Live coverage explanation describes why a visible development record needs context before becoming a release claim.
Identity needs to survive a change of position
Imagine a reader opening a creature, returning to the grid and sorting by name. The card may move to another row. Its identity should remain the same. Otherwise, a reader could mistake a layout change for a new species or an altered form.
The reviewed Matebook uses the creature's identifier for its record and a separate number for catalogue ordering. Name sorting compares names. Stat sorting compares the stored base total, with catalogue number providing an additional ordering rule. These are different views over the records, rather than separate manually written rosters.
This is a bounded observation about the inspected website. It does not establish that every backend, platform or installed version uses identical data at every moment. A source shared by several views still needs publication and version checks.
A family is a relationship, not a row of similar pictures
The published reference also records evolution families explicitly. The expanded card can use that relationship to show connected forms and the reference transition between them. It does not have to guess a family from similar colours or neighbouring cards.
A useful review question is therefore more precise than whether the grid looks tidy. Open a creature, change the sort and return to its record. Can the reader still identify the same family? Does a link describe the form that actually opens?
That is a proposed review procedure. We are not reporting a new end-to-end game test or a measured reduction in support requests. Those outcomes would need their own evidence.
A model example: number order versus a high total
Consider an imaginary reader who remembers a creature from a family but not its exact name. Number order may help them browse the family sequence. Another reader sorts by base total and sees a different creature first.
Neither result proves the second creature is the best party choice. A total does not answer which moves are available, what defensive matchup matters or what the player needs for the next task. It is one reference field being sorted.
The practical product lesson is to label the operation honestly. A button that sorts a base total should not imply a recommendation algorithm. The existing prototype versus production evidence guide applies the same discipline to larger claims: describe what the evidence actually establishes.
Keep filtering separate from an absent creature
A grid with fewer cards may reflect the current search and filters. Before reporting a missing record, note the typed name or number, element filter, rarity and collection view. Then try a broader view.
That check is different from diagnosing a failed request. A filtered result, an unavailable data source and a genuinely absent record are different states. Combining them into one message makes both user feedback and development investigation less useful.
For a studio, a good report includes the URL, the selected controls and the expected record. It does not need private account information. Screenshots can support the report, but the chosen view explains how to reach it again. See what to capture before a visual bug screenshot.
What should stay outside the claim?
The website reference cannot by itself prove an encounter location, a supported game mode or a reward entitlement. A family diagram is not confirmation that a player can obtain each form in their current build. A high base total is not a promise of battle performance.
Those boundaries make the feature more useful. Readers can use it for comparison while checking the installed game's own information for a live action. Developers can review the catalogue without presenting an editorial explanation as a game patch announcement.
Questions about the web reference
Does changing the sort change a creature's stats?
The reviewed controls change the displayed order. They do not constitute an upgrade or a change to a player's creature.
Is the first creature under stat sorting the strongest choice?
That sort uses a base reference total. A practical choice needs context, including moves and the intended task. It is not a tested ranking of player builds.
Where should readers go next?
Explore the official AneeMate site and its Matebook, then compare the reference with the version you are actually using. Follow QORPO's studio page for development context rather than inferring a release from one commit.
Sources reviewed 3 November 2026: the official AneeMate Matebook and its public species reference. The review procedures and imaginary reader scenario are QORPO editorial examples. No gameplay, account or reward transaction was performed for this article.