Backend-defined grading scales

Backend PR #476 and mobile PR #663 replace the universal 1-10 grading grid with the owner's company-specific reference. Neither PR is merged or deployed by this delivery.

Ownership and UI

The backend owns ordered companies and allowed grade identities, not UI layout. GET /grading-reference returns version 1 and companies with id, label, and grades containing id, label, grade, qualifier. Single and batch M3 valuation routes validate these combinations before touching price watches. No database migration or dependency change is required.

The card-detail Graded checkbox reveals two inline selectors: company on the left, grade on the right. Selecting a company clears the selected grade. Options open in the existing scrollable centered dialog. The grade control is disabled until a company is selected. Unchecking returns to raw-card pricing. The grading price matrix uses the same reference. Existing theme tokens are retained.

The frontend validates the response and caches it in memory for one hour, scoped to the API base. Concurrent loads share a request, failures are retryable, and the request has a 15-second timeout. No hardcoded fallback scale is displayed.

REV-020: persistence and reopening

Confirming a graded addition stores a slab containing the exact company and grade reference. The backend validates companyId and gradeId, then retains the authoritative company label, grade label, grade and qualifier in the existing slab JSON. No new column or migration is needed. Numeric grades remain compatible; special labels have a null numeric grade rather than a fabricated score.

Local storage, cloud serialization and cloud parsing retain the reference. Collection badges and M3 price identities use it, including CCC, Collect'Aura, PCA 10+ and BGS Black Label. Selecting a collection copy passes its ownership ID to the card detail. Reopening restores that copy's choices. A catalogue detail with exactly one holding can restore it; multiple copies require an explicit choice and never inherit an arbitrarily selected grade.

The added regression tests reopen a new local repository instance, preserve four distinct graded copies, round-trip the cloud payload and assert special price identities. Restoration tests verify ownership ID targeting and ambiguous copies. Browsing a grade without confirming an addition does not mutate an existing lot.

Scales supplied by the owner

Company	Labels, in order
PSA	1, 1.5, 2, 3, 4, 5, 6, 7, 8, 9, 10
PCA	1, 2, 3, 4, 5, 6, 7, 8, 9, 9.5, 10, 10+
CCC	1, 2, 3, 4, 5, 6, 7, 8, 8.5, 9, 9.5, 10, Gold Label, Black Label
Collect'Aura (CA)	1, 2, 3, 4, 5, 6, 7, 8, 9, 9.5, 10
BGS	1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 7.5, 8, 8.5, 9, 9.5, 10 Pristine, 10 Black Label

PCA 10+ and CCC labels remain literal, distinct grade strings. No numeric equivalence or external provider mapping is asserted. BGS uses grade 10 plus the explicit qualifier. Missing exact evidence remains unavailable, never a substitute ordinary-10 quote. Legacy unqualified BGS 10 and existing condition qualifiers remain accepted for compatibility, but are not new UI choices.

Verification and delivery

• Backend API: 1,141 tests passed; JavaScript/TypeScript checking passed.
• Mobile: lint and typecheck passed; 2,457 tests passed, 11 pre-existing skips.
• TDD evidence: reference route returned 404 before implementation; PCA 10+ returned 400 before the shared validator update; missing frontend modules and old screen wiring failed before their implementations. Focused tests subsequently passed. Additional malformed-input/cache cases are regressions.
• Maestro flow card-grading-reference.yaml added, not executed: CLI unavailable.
• No native APK rebuild, visual verification, merge or VPS deployment.
• Deploy backend first, then mobile. Against an old backend, the new UI exposes reference retry rather than invented grading options.
• The follow-up extends graded additions and saved slabs for REV-020. No existing holding is rewritten automatically; saved numeric slabs remain compatible.