Dev Updates

Ascended Heroes is now available in the catalog as a modern set. Card pages show set numbering as card count out of 217 (e.g. 1/217) instead of total catalog items, so collectors see the correct denominator. Production ingestion supports running the full pipeline (cards plus product ID resolution) in the background to avoid timeouts, and image backfill runs only for cards missing images by default.

The Sales History section now supports an optional view of ungraded, condition-unknown sales for market context. A new checkbox "Include raw / ungraded sales" is off by default; when turned on, the page fetches and shows a separate block below the main sales tables. That block lists only sales without a stated condition, with columns for date, price, marketplace, and an informational proximity label (e.g. price near a condition median) plus a tooltip that clarifies we do not assign condition and this does not affect pricing. Raw sales are capped to five rows initially with a "Load more raw sales" control to expand in steps of five. Default behavior, pricing, charts, and conditioned tables are unchanged.

Liquidity confidence is now shown on the card page as a contextual market-health signal next to the JK Index score. When the API returns an optional liquidity_confidence value (high, medium, or low), a badge appears below the score with a tooltip that explains what the signal means and explicitly states that it does not assign condition and does not affect pricing. Display-only, no raw sales, no API or backend changes, and no change to default behavior when the field is absent.

When the JK Index score was served from cache, the optional liquidity_confidence field was missing from the API response, while fresh computations did include it. That meant the same card could return different response shapes depending on cache hit or miss. We fixed this so cached and recomputed responses both include the field when data is available. The field remains optional and is omitted when the lookup fails or data is absent.

The JK Index response can now include an optional liquidity confidence label (high, medium, or low) when we have enough sale-based data for that card. This is metadata only: it does not change the index score, band, or any pricing. It sets up future UI to show how confident we are in the liquidity signal without altering authoritative numbers. The signal is read-only and fail-closed: we never trigger recomputation or touch condition pricing; if data is missing or anything fails, the field is omitted. Existing clients are unchanged and the new field appears only when present.

We fixed a robustness issue in the liquidity confidence interpreter. When the aggregated summary had certain numeric fields explicitly set to None (rather than omitted), the interpreter could raise TypeError during arithmetic. It now validates those fields the same way it already validated the average confidence score: if any are None, it returns None (fail closed) instead of computing. No behavior change for valid inputs; invalid or incomplete data is now handled consistently.

We added a read-only interpretation step that turns aggregated proximity confidence into a single liquidity confidence label (high, medium, or low) for future market-health features. It consumes only pre-aggregated data, does not query the database or change any pricing or UI, and fails closed when data is missing or insufficient. The label is deterministic and safe to use later as an optional modifier for market health signals.

We added a read-only aggregation that summarizes raw-sale proximity confidence per card for use in liquidity and market health signals. It runs a single query per card, returns nothing when there is no cached data, and does not trigger recomputation or touch condition pricing or any existing market logic. This gives Phase 8.0 a safe way to use proximity as an internal confidence signal without surfacing raw sales in the UI.

A written product and UI analysis was produced to decide where and how Raw Sale Price Proximity should be surfaced before any frontend implementation. The doc maps the card page (authoritative vs contextual zones), condition and grade filtering behavior, and existing trust signals (tooltips, badges, muted text). It evaluates placement options (sales rows, filter context, secondary panel, hidden-by-default, off main page) and calls out where proximity must not appear (condition pricing blocks, Condition column, default-on, graded sales). The recommended Phase 8 entry point is an opt-in "Include raw/ungraded sales" control that shows raw sales in a dedicated block with proximity as an informational badge and tooltip, keeping default experience and condition pricing unchanged.

A centralized guard now decides whether each Gemini call runs immediately, is deferred, or (rarely) rejected. Soft limits are applied per purpose: scan identify is capped per user and per IP over a 10-minute window, scan retry is limited to one per session, enrichment uses a global hourly cap, UI preview is heavily throttled, and backfill is always deferred unless admin mode is on. Confidence rules gate retries: high confidence disallows retry, mid allows one, low defers. Budgets are tracked in-memory for now; every decision is logged with purpose, user, IP, and outcome. The listing enrichment hook consults the guard before calling Gemini and skips the call when the guard defers or disallows, so existing behavior stays unchanged under load.

Integration tests were added to prove that proximity recomputation never runs unless explicitly requested. Three tests hit the sales history API and mock recompute_raw_sale_proximity: when include_raw_sales is omitted or false, the mock is never called; when include_raw_sales=true, the mock is called once. Default API behavior stays cheap and unchanged; future refactors cannot accidentally trigger proximity recomputation. These tests fail loudly if recompute is triggered unintentionally, locking in the performance contract alongside Phase 7.1’s data-integrity guard.

The One Piece TCG set Pillars of Strength (OP-03, 341 cards) is now fully supported in the index. Set registration, API metadata, and release date (June 30, 2023) were added so the set appears correctly in set lists and set detail views. Card records are created and updated via the existing set ingestion pipeline; canonical IDs use the short set slug for consistency with other One Piece sets. Front images for cards are downloaded, processed to small and large variants, and stored on the CDN using the existing One Piece image pipeline. Ingestion is idempotent and safe to re-run.