36d10ca4ae
EVERY CRATE DIFFERENT — measured: 15/15 keyed crates distinct, max shared titles between any two = 0. 14 mint atlases (5 record, 6 book, 3 toy) + Monster Robot's real crate + the manifest. MINT (ledger #2): the G3 note promoted — random.Random(shop_id) over an ID-ORDERED pool of real dealgod listings. The shop id IS the seed, so two shops can never draw the same crate. No TABLESAMPLE, no unseeded random: the two things that disqualified thriftgod's own mint() from tier 1 (G3 §2). Re-mint + re-bake is byte-identical. Only keyed shops whose type the loader can fetch get one (record/book/toy, C §7.1); the 13 keyed opshop/video shops get none and stay parody — an atlas there could never load, and the manifest is what makes that silent instead of a 404. MANIFEST (ledger #6, C §7.2d): stock_godverse/index.json — 15 shops, 1 real / 14 mint. Derived by reading the atlases back off disk, so it cannot drift from them: the manifest IS the directory. Real crate re-emitted with sourcing:"real" + C §7.2c's condition/sleeve_cond (my snapshot always carried them; I dropped them at emit — that was the hole in C's price card). Atlas bytes unmoved. THE ONE RED — mint ids vs E's SLOT_ID_PREFIX (E, one line). E asserts `sku_` on every atlas under stock_godverse/; mint items have no POS sku and carry `mint_<dealgod listing id>`, so all 14 fail. C §7.2a's RULE is satisfied — derive from the source's own stable key, never position, unique across ALL packs (measured: 344 ids, 0 clash with the generic packs, 0 positional). What §7.2a specifies as sku_<POS sku> it specifies "for a real-stock (godverse) pack"; mint is §7.2b's other thing, written a round later, and the id form was never revisited. I did not just emit `sku_` to go green: a POS sku and a dealgod listing id are DIFFERENT NAMESPACES, and this round's own standing note says no code or gate may compare a bare number across two id spaces — it exists because enterShop(31) entered the wrong shop. Putting both under `sku_` recreates that bug inside the economy: tier-2's sold-means-gone looks up POS skus, and sku_6031122 (a dealgod id) is indistinguishable by shape from a sku a POS must resolve. §7.2a's own reason #2 is exactly about ids being looked up across snapshots. Fix: make the prefix sourcing-aware (sku_ for real, mint_ for mint) — E's constant and error text are the only places. THREE MORE FINDINGS, none blocking: [E] FITS_1024=64 cannot be satisfied — 1024²/256² = 16 cells, so 64 items need 4 atlases and C caps a shop at 2; any 33–64 item pack MUST be 2048². Latent (my packs are 16→1×1024² and 120→2×2048²); the honest bound is 32. [C/F] the ≤32 MB ceiling doesn't hold at beta scale because the LRU it assumes hasn't shipped — F's boot preload loads EVERY keyed shop's pack, measured 46.1 MB/town resident; it's why mint crates are 16 items on one 1024² sheet. [C] "the crate menu, baked statically" can only be metadata: one base = one index = ≤2 atlases = 128 items, and Monster Robot has 357 crates / 24,646 records — so crate_menu ships the real crate list (labels + counts) and per-crate STOCK needs a per-crate base, i.e. a C contract line. MINT HONESTY: sourcing:"mint", an attribution that says "not this shop's stock", and NO POS-claim field at all — structural, not editorial. Records require a real Discogs artist (dealgod's `brand` on a record listing is the SELLER — the first bake had "Red Eye Records" as an artist; a shop is not an act) and use discogs_master_title where present, so Egg Records reads "MC5 — High Time $50", not "Pre Loved Record - Elton John - Breaking Hearts". Books/toys take `brand` per C's author/brand convention — sometimes the maker, sometimes the listing store. Real, imperfectly typed, and never claimed as that shop's. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
128 KiB
1024x1024px
128 KiB
1024x1024px
