Skip to content

Historical Pokemon Numbering ​

The owner supplied 30 French 2026 and 25 French 2021 Classic Collection audit rows. The dedicated business-rules section keeps these Pokemon-domain rules separate from app feature and implementation documentation. The values are an owner-provided reference, not independently verified physical-card evidence.

The backend owns a bounded reference exposed through a read-only endpoint and adds printed_number / display_order to the audited print responses. Existing IDs, local catalogue keys, images and collection ownership are not rewritten. Celebi remains 30th-c-024, Palkia remains 30th-c-022, despite their different audit display order. Set pagination applies that order before slicing results. Historical fraction search finds distinct reprints rather than merging them.

The mobile app propagates the complete printed identifier across catalogue, search, detail, wishlist, holdings, binders and add-to-collection surfaces. The Wizards promo 24 never gets a current-set denominator; leading zeros remain intact. Public set cache v2 preserves both fields and invalidates old metadata. The owner approved a targeted exception to the usual ten-file mobile PR cap.

The admin adds a read-only rules page that reads the same backend reference, with edition selection, loading and retry states, and no write permissions. No audit table is duplicated in frontend code.

Verification ​

  • API suite: 1,158 passed; build and JavaScript typecheck passed.
  • Mobile: 2,480 passed, 11 pre-existing skipped; typecheck and lint passed.
  • Admin: 38 tests passed. Authenticated Playwright preview verified both tables, the promo 24 and no overflow at 1440/768/390px using mocked reference transport.
  • Documentation build passed.
  • A real-Postgres E2E covers list/detail/search, immutable identity and pagination. It passed in CI after adding canonical parent sets to the fixture. Local Docker is unavailable. All final backend, mobile and admin CI checks passed, including the PATCH projection and explicit printed-number sort follow-ups.

Rollout Status ​

After the owner's restart/activation request and green CI, backend #482, mobile #675 and admin #25 were merged to staging. Backend staging 8358166 and admin staging ae5984f were deployed with previous-image rollback overrides. No migration, catalogue rewrite or change to main was performed.

Snag's PostgreSQL, Redis, card/sealed/frame embedding services, legacy vision service, API, admin, image nginx and public/private gateways were restarted. Other projects and the observability stack were left running. The previously unhealthy private admin gateway became healthy. Database/model/admin health and public API readiness passed. Live checks verified all 55 printed identifiers, display orders and unchanged IDs; historical search returned both Dracaufeu reprints. The admin read all 55 rows through the real backend transport. The 70 One Piece sealed products remained available. Raw/private image restrictions remained intact.

A personal x86_64 emulator APK was built in the existing isolated worktree from mobile staging 402b80c, installed and launched. No generated build files or native configuration were committed. Installation initially hit Android's low storage reserve. The old APK was backed up, data was explicitly retained during package replacement, and the reserve percentage was temporarily reduced for installation then restored to its original unset value. Before/after credential- encrypted and device-encrypted data directory inodes matched. No factory reset, virtual disk enlargement or user data clear was performed. The nonblank home screen and running foreground activity were verified.

OCR/index matching is unchanged. Other print identities do not receive unreviewed numbering overrides. The emulator remains short of storage; a future disk expansion may still be useful but was not needed for this installation.