BACKEND, SAVE & ANTI-CHEAT

Traffic blocks — the rate limiter's second layer

Every authenticated /api/* request is sorted into a rate class and spends a token from a per-account bucket for that class. The classes and their buckets (src/worker.js, RATE): battle 24 / 4 per min, floor 30 / 8, save 20 / 12, save_read 60 / 60, me 60 / 60, name 3 / 0.05, auth 10 / 10, db 80 / 40, mm 60 / 45 (/api/pvp/mm/), pvpm 120 / 90 (/api/db/m/), wallet 24 / 40, roll 300 / 240 (/api/roll, /api/hatch, /api/breed/claim), other 40 / 24, plus a blanket ip_all of 600 / 360 per address, checked after the session gate and the per-account bucket (see system-networking). An empty bucket answers 429 {error:'rate'}.

A refusal also escalates. reportBreach posts the (account, class) pair to the WorldDO at most once per RATE_FLAG_MS (default 60s); once TRAFFIC_BLOCK_N reports (50 in the deployed wrangler.jsonc vars; code default 3 where the var is unset) land inside a rolling 10 minutes, traffic_status is set blocked=1 for that pair and an anomalies row is written. A blocked pair is refused at the gate with 403 {error:'soft_block'} before any Durable Object wakes. The worker caches the block set per isolate for SB_TTL_MS (default 60s), so a change takes up to a minute to be felt.

Reads are exempt (2026-08-02). Classes listed in RATE_READ_ONLY — currently save_read (GET /api/save) and, since 2026-08-06, me (/api/me) — are never soft-blocked and never escalate. Reading your own save grants nothing, so blocking it prevents no abuse; and because the shell RETRIES that read when it fails, escalation on it meant the retry loop fed the counter that produced the block. Nothing may join that set which can mutate state or mint a value.

Blocks expire (2026-08-02). /api/_internal/softblocks clears blocked=1 rows older than SB_EXPIRE_MS (default 1 hour) each time the set is read. The row survives with blocked=0, so /api/admin/traffic history and the traffic audit table are unaffected, and a genuine abuser is re-blocked by the next 10-minute window. SB_EXPIRE_MS=0 restores permanent blocks. Before this, blocks were permanent and cleared only by hand — the flag detail said “queued for review” and there was no queue.

Failure mode this class of block produces, and how to recognise it. A soft block is per (account, class), so the account keeps working everywhere else. With save blocked, GET /api/me still answers 200 (class other) while GET /api/save answers 403 forever. The shell reads that as a failed sync and falls back to the sign-in gate, so the player sees “Could not load your save — retry N…” under a Steam button and reports it as “I cannot log in”. It is not a login failure and re-authenticating cannot help. Diagnose with the account's own cookie: curl -i https://playdfmc.com/api/save -H 'cookie: ht_session=…' — 403 is a block, 429 is the bucket, 500 is the object.

Dismantle yield — the shared table

src/dismantle.js is a pure module carrying the dismantle yield: dismYield, breedRates, gradeNum, buildDismantleDb, dismTotals. Same contract as src/power.js — no fetch, no timers, no Durable Object state, safe to import from the Worker and from node, with CSV fetching left to the caller Worker-side and never inside a DO.

Why it had to exist. POST /api/backup/dismantle used to remove rows and credit nothing, because the yield lived only in play/app.js, which made the ops door unusable on a real player: it would delete a pile and pay for none of it. Since #A4 (D 2026-09-28, on dev): the Worker prices every removed row with dismYield (forwarded to the object, which never fetches the CSV) and the object credits it through dismCreditRow — the same priced-credit step /api/dismantle uses, on the same ledger keys, so a uid paid by one door can never be paid again by the other. The door fails closed on a pricing outage, refuses socketed or equipped uids (held-in-socket), still spares Mutants, and replays a retried apply by its idem instead of crediting twice. Separately — corrected 2026-08-20, this sentence had gone stale — foodCeil now carries a priced dismantle allowance: the worker prices each declared row and the player’s object verifies it against its own previous save or the item’s grant record before a point of allowance is spent (system-networking owns the mechanics; the accepted grant origins were widened to every stamp the server writes on 2026-08-20).

Admin grants are sourced from birth (D ruling 2026-08-20, RELEASED IN 0.56). mintGrant assigns server uids to the payload, books each item into items with origin grant, and every fresh grant writes a permanent acct_log entry through the audited kind admin_grant — gid, reason and item list. A granted item is checkable and dismantles like anything else; a merely claimed grant reads unsourced and stays refused. Replays log nothing; the original entry is the record.

The yield is AUTHORED, not computed. dismantle.csv carries one row per (Category, Grade, Tier) and the module only looks it up; the gear rows keep a fourth key field fixed at +0 (a legacy refinement slot — the mechanic does not exist, and the 1,000 +1…+10 rows were removed 2026-08-25). The ladders are deliberately not smooth; there is no formula to derive and none should be written.

Mutants (D order 2026-08-21, LIVE on release since 2026-08-21 (0.58)). The CLIENT’s dismYield refuses a Mutant creature — mutants are never dismantled — and /api/_internal/bulk_dismantle carries its own copy of the refusal: with scope 'all' it now leaves any Monster with mut:true untouched, because it was the one dismantle running server-side without the client’s gate. This module deliberately does not copy the refusal: the pricing copy must keep verifying and paying a stale release client’s Mutant claim (additive-only backend rule), and refusing here would protect nothing — the destruction is client-side. The parity gate pins the asymmetry (B4) so it cannot be “fixed” by porting the refusal in.

null is not zero. Class souls, anything flagged dismantleable:false, an unknown category and a missing CSV row all return null. A caller that reads null as zero would silently confirm a zero-yield dismantle, which is how a player loses a pile for nothing.

The parity gate. A transcription is worthless unless something proves it has not drifted, so tools/probe_dismantle_parity.py boots the real client and compares against it: the rebuilt table key-for-key and value-for-value, then dismYield on a fixture generated from every authored row plus every creature grade plus the null cases, then the aggregate. Fixtures come from the CSV, so a newly authored row is covered the day it lands. Currently 10/10 over 1,541 fixtures from 1,515 rows, including gate B4, which asserts the one deliberate divergence: the client refuses a Mutant and this module keeps paying it.

Not yet enforcing. The module exists and is proven; nothing validates against it yet. The design (D): the player dismantles, the client credits immediately — safe, because a dismantle carries no RNG — the save rides the next sync, and the server recomputes and validates by diffing the previous save against the new one. Items gone from the bag are what was dismantled. A client receipt is never trusted, because a receipt is precisely what an attacker writes.

Server: src/dismantle.js. Gate: tools/probe_dismantle_parity.py. Client source of truth transcribed from play/app.js dismYield/breedRates/gradeNum/dismantleDb.

Why no automatic report ever arrived — and how one does now

Status: LIVE on release since 2026-08-13 (0.48). Superseded in part by the 2026-08-17 batch below, which is on release. Between 2026-08-04 and 2026-08-12 the automatic reporter filed zero readable rows. D noticed it before any tool did (report #124: “I haven't seen one of them yet which is odd”). There were two independent causes and either one alone was fatal, which is why neither showed up as an error: nothing failed, the rows were written exactly as instructed, and the instructions were wrong.

1. The status word. The row was written status='open'. Every reader filters status='new' — /api/feedback/export defaults to it and /api/admin/feedback hardcodes it. Worse, 'open' is not in the accepted set of the mark endpoints (['new','processed','wontfix','fixed']), so the row could neither be listed nor closed. It was unreachable in both directions.
2. The object. This is the load-bearing one, and it is the same defect class as the PvP queue door's 401. src/worker.js defines ONE class: PlayerDO and WorldDO both extends MainDO with empty bodies, so every table exists in both objects and which one holds the truth is decided by routing, not by schema. WORLD_PATHS sends /api/feedback and /api/admin/ to the WorldDO, so the inbox everyone reads is the WorldDO's feedback table. But every REPORTABLE kind fires on a save, battle or roll path, and those are not world paths — so flag() → flagReport() ran inside the player's own object and inserted into that object's feedback table. Same schema. Different object. Read by nothing.

The proof was in the live data, not in the reasoning. The export's counts (GROUP BY kind, status) carried no auto kind at any status after weeks of guards firing, and /api/admin/save-history returned [] for an account on save version 3,525 — because that door reads the WorldDO's save_hist too.

The relay — how the row crosses objects without a fetch

The raising object must never call fetch(): an outbound subrequest is one of the lifecycle facts that stops a Durable Object hibernating, and a non-hibernateable object bills at full wall-clock rate — a ~1000× cost difference. So the row is carried out the way ANTICHEAT 2 already carries a leaderboard write:

1. flagReport() queues onto this._autoQ instead of inserting. The per-account-per-kind-per-day dedup row stays where it is raised, because that is where the account's own history lives.
2. MainDO.fetch is now a thin wrapper over fetchInner that attaches the queue to the response as the x-ht-autorept header. A wrapper, not a body annotation, because a flag can be raised from any of ~180 return sites and a header needs none of them changed — and a header carries a streamed or non-JSON response unaltered.
3. autoRelay() in the Worker strips the header (it never reaches the browser: it names accounts and internal guard kinds) and POSTs to /api/_internal/autorept on the WorldDO under ctx.waitUntil. The player's save is never delayed by a bug report, and a lost relay costs the report rather than the request it rode on. Applied at the Worker's own fetch, one place, because a flag can be raised on any route — world or player.
4. The world door writes the row with status='new' and enforces the forty-a-day inbox ceiling there, because the budget is a property of the inbox: forty accounts each filing their own one-a-day would otherwise bury every real report between them.

Still true after this change: raw anomalies rows are still written into the raising object and /api/admin/flags still reads only the WorldDO's, so it still shows only world-path events. The row behind a report stays per-account and is read through GET /api/backup/flags?key=&sid=. The “first detail of the day” wording above is superseded by the 2026-08-17 batch — a report now carries the day's running count and the latest detail, updated in place.

Every guard reports itself — and admin actions leave the inbox (2026-08-17)

Status: LIVE on release since 2026-08-21 (0.58). The reporter above shipped with an allowlist of 19 kinds. The worker raises 74. The other 55 wrote an anomalies row and stopped there, so “show me the bug reports” showed roughly a quarter of what the server had caught — and the missing three quarters included every kind that matters most for trust: wins_over_ledger, kills_over_ledger, lb_power_over, maxfloor_over, floornum_over, battle_floor_over, boss_overdraft, inv_illegal, breed_claim_bad, unlock_sequence, wallet_drift, wallet_rate, wraithgold_seed and pvp_commit_mismatch. The same list also carried wraithgold_over_grant, which nothing has ever raised — the same disease pointing the other way, unnoticed for exactly as long.

D's ruling, 2026-08-17: “That noise is not normal. Those are bugs.” So there is no allowlist, no routine class and no exclusion list. The four kinds a previous session excluded on purpose — grow_only, dead_slot, rate_cap and the save-size pair — report like everything else, because a guard firing 237 times on one honest account is a defect to be explained, not background. The sequence is deliberate and it is the whole design: report everything → watch live accounts → only a kind that never fires honestly becomes enforcement. Nothing here gates anything today.

• A map can no longer suppress a detection. FLAG_WHY is a courtesy: a kind with no description still files, and its body says so. FLAG_CLASS is a sort order: an unclassified kind is system. Neither is a gate. This is the property the allowlist lacked, and it is why the batch is worth more than the 55 kinds it switched on.
• Class is a sort order, never a verdict. suspect — the claim pays more than the ledger can account for, past any in-flight envelope. sync — two devices, two windows, or a reply that never landed. system — the build is wrong; the default. A real bug looks exactly like suspect, which is why the watching comes first.
• One row per account per kind per UTC day, updated in place with the day's running count. The shape the Auto PVP verify report already proved: “237 occurrences” in one row is readable where 237 rows are not. Relayed on a widening ladder (1, 2, 5, 10, 25, 50, 100…) because a relay is a written row and written rows bill at a thousand reads. anomalies is not the counter it looks like — flag() collapses repeats to one row a minute — so the count is kept in memory and seeded on a cold isolate from the count at the last relay, which is on disk. A restart can make the number read low, never high.
• Status is never rewritten by an update. If a report has been closed and the guard keeps firing, the next UTC day files a fresh row. Rewriting a closed row back to new would hide that it was ever closed.
• Budgets are per class (suspect 400, sync 300, system 300 a day) and an update in place costs nothing against them. The old ceiling was 40 rows a day for the whole inbox, dropped silently — survivable at 12 reporting kinds, fatal at 64, because the drops are first-come-first-served and the routine kinds fire first. A refused report is now itself reported, one row a day counting up: a reporter that loses reports quietly is the disease this batch exists to cure.
• Two silent-loss paths in the carrier closed. It took the first 8 queued rows and cut the encoded header at 6,000 characters — a cut landing mid-JSON makes autoRelay's parse throw, which discarded the whole batch with no trace. Rows are now added while they fit, the remainder stays queued for the next response, and audit rows ride ahead of reports.

The permanent account action log (2026-08-17)

Status: LIVE on release since 2026-08-21 (0.58). D's ruling: admin and ops actions “are legal actions and they need to be permanently recorded on each account when they are taken”, and “Ops only” — players never see these entries.

They were not being recorded permanently, and some history is already gone. Every one of them wrote an anomalies row and nothing else, and maybeMaintain deletes anomalies at 30 days. Every wipe, rollback, bulk dismantle and restore older than a month had already expired before this was written.

• The table lives in the WorldDO, and that is the design rather than a convenience: an account wipe destroys the player object's tables, and a wipe is precisely the action that must survive being wiped. Central, keyed by account, never pruned — deliberately absent from maybeMaintain and it must stay absent.
• The eight call sites did not change. flagReport() diverts any kind in AUDIT_KINDS to auditLog() before it can reach the inbox, so a one-line this.flag(...) cannot forget to log. Covered: admin_grant, admin_wipe, admin_rollback, admin_bulk_dismantle, admin_lock, admin_unlock, ops_restore, trade, global_wipe, save_retry, chain_resync, grants_revoked, admin_traffic_block, admin_traffic_clear. (The bare traffic_block kind is the automatic threshold's anomaly and stays a report, not an audit row.) Written straight to the log through auditLog() rather than a flag: admin_rename, sock_migrated, mon_migrated, birth_migrated, birth_recorded.
• World-side actions write straight through (WorldDO now sets _isWorld); player-side actions ride the same carrier the reports do, ahead of them.
• Ops-only read: GET /api/admin/acctlog?sid=&limit=, behind the same steamid allowlist as every other admin door. There is deliberately no player-facing route to it anywhere in the build, and the probe asserts that there is not.

Worker: AUDIT_KINDS/FLAG_CLASS/FLAG_WHY, flagReport(), auditLog(), ensureAcctLog(), ensureAutoIdx(), budgetDrop(), MainDO.fetch, /api/_internal/autorept, /api/admin/acctlog in src/worker.js. Probe: tools/probe_flagrept.mjs — BEFORE 12/12 on the build it replaces, AFTER 25/25, methods lifted verbatim and run against real SQLite. That probe had been crashing since 2026-08-12: it asserted flagReport() inserted a row, and the relay above moved the insert to the world door, so every run since threw on rows()[0].status and nothing ran it. It is the fourth gate in this repo found retired the same way (probe_savefacade 14/17, probe_floorclock_boon 2/9, probe_spawnshare crashing). A lift list is a dependency list.

Worker: flagReport(), MainDO.fetch/fetchInner, /api/_internal/autorept, autoRelay() in src/worker.js. Probe: tools/probe_autorept.mjs 18/18 — 7/18 against the build it replaces. The probe drives the real worker under wrangler dev --local and asserts against the same export door the feedback pull uses; it re-implements none of the logic it tests.

Changelog

• 2026-11-03 — the Steam market farm view is BUILT, off (board S1, server half; D 2026-11-03 “I don’t see anything about steam marketplace for mons … Build those too”; dfmc-client lane marketsrv). On dev. New section “The farm view”: GET /api/ops/market/exports?steamid=&day= (ops key, in KEY_GATED) reads the World’s market_world mirror — rows newest first and farm counts per (steamid, day). The per-account daily cap, the account-age gate and the kill-switch flag are vars (MARKET_EXPORTS_PER_DAY 5, MARKET_MIN_SESSION_DAYS 7, MARKET_ENABLED off). Runbook dfmc-client steam/MARKET.md; gate tools/probe_market.py 5/34 → 34/34.
• 2026-11-02 — the restore door counts the payload against the server slot caps, and the roster reads wdel (Tower rulings card T68, D: “WHY WOULD THE PLAYER EVER GO OVER CAP IF ALL OF THIS IS SERVER AUTHORITATIVE? REVIEW THE IMPLEMENTATION”; dfmc-client lane soulcap). On dev. The review of every server path that puts a soul or an item in a bag: the save door strips souls past max(cap, what the account held), the breed egg refuses on a full stored bag, the breedfix regrant defers past room, hatch is egg→creature one for one, devour and dismantle only remove, a merge moves Wraithgold and identities only, an admin grant mints an offer the save door bounds — and /api/backup/restore stored the payload as given. That was the hole: an ops restore of a 34/30 bag was then “what the account held” and the save door kept it for good. The door now counts souls and items (soulCountOfSave / itemCountOfSave: non-soul rows in bag+bagAdd) against the cap the server owns — the slot_caps row when one exists, else what capsOf will adopt from that payload at first contact — and answers 409 over_cap with both counts listed unless force=1, which stores as given and flags ops_restore_over_cap. The client is never the cap. Handoff 2026-10-30 Step 1.2 rides it: GET /api/backup/accounts carries wdel {n, due24h} (?now= as del_due takes it), so the age-purge nightly re-mark is verifiable from an ops read door. Gate tools/probe_t68_soulcap.py.
• 2026-10-23 — the hourly sliced retention no longer errors on a fresh account’s items tombstones (dfmc-client lane probe-triage-6). On dev. The maintenance prune slices items on its gone column, which only the items schema upgrade adds; an account whose items table had never been upgraded logged errs 1 / items -2 on its MAINT line. Maintenance now runs that upgrade before the slice. No retention window changed.
• 2026-10-23 — the auto-report budget is counted when a new row needs it, not on every relay (A14, the 1,000-CCU pass; dfmc-client lane a14-ccu, docs/ccu-1000-2026-10.md). On dev. /api/_internal/autorept on the WorldDO rides most battles and saves, and it counted the three per-class budgets (suspect 400, sync 300, system 300 a day) with three COUNT(*) scans of the unindexed feedback table — the whole inbox — on every relay, audit-only and update-only relays included; once a cap is full every refused flag arrives new again, so the scan stayed on the hot path at peak. Now an audit row or an in-place update reads nothing for the budget; a new row reads the day’s auto rows once, buckets them by class, and the counts are kept on the World object for 60 s, raised with every insert. The caps, the per-class split and the reporting budget hit refusal row are unchanged; a row filed by another writer is counted at the next pass (≤ 60 s). No index was added (one on ts would write a row on every in-place update). Every WRCOST line now also names its object (do: W/P) and flags the first request after a wake (wake). Gate: tools/probe_a14_autorept.py 2/4 → 4/4 (relay reads 2,706 → 2 at an 899-row inbox).
• 2026-10-23 — the per-account ops follow a merged account to its winner (A13 finding, dfmc-client lane merge-follow). On dev. After a merge the loser’s id is a husk no login reaches, but lock, save-history and rollback (adminPlayerOp, GM and Steam admin) and the ops /api/backup/history / /api/backup/rollback acted on the id they were given: a lock or rollback aimed at it wrote the loser’s object and left the winner untouched. Each now resolves the target through the World ledger’s account row first (mergedWinner; the loser’s own merged-to hops before the backfill is done), acts on the winner and never writes the merged-away id. The answer carries both ids (steamid/sid = the winner, asked, merged_into; an unmerged id answers as before) and the admin_lock / ops_rollback audit row, on the winner, names the asked id. Gate: tools/probe_merge_follow_ops.py 2/7 → 7/7 on a local worker.
• 2026-10-23 — the release ritual has one written source, and the Discord notice a script (INDEX D1/D2, dfmc-client lane ops-docs). Ops tooling, nothing ships to players. The ritual lived in four places that disagreed (HANDOFF, an OPS 0.80 entry still saying “push from rel-0.80”, the backlog, a session memory). It is now docs/release-ritual.md in dfmc-client, and the others point at it: dev fast-forwards main, no rel-* branch; a non-empty git log origin/main..dev -- play/ makes any push a release; the build is live + 0.01 exactly; GATES_STRICT is on for any non-empty value; wrangler only through tools/cf_wrangler.sh; Worker secrets go on after the deploy (the worker answers 503 until they do); CSVs come from the worker’s codex door since A4, art is still jsDelivr at the pin, so the “do not advance DATA_PIN” warning stands for art. tools/discord_post.py posts release_gate’s notice to the channel webhook kept in local-only/secrets/discord.env (never printed, mentions off, split under Discord’s 2000 characters, --dry-run; silent hotfixes post nothing); the post stays D’s to send. The missing OPS entries for 0.84, 0.85 and 0.86 were rebuilt from the repo history and Workers Builds check-runs.
• 2026-10-23 — an ops write answers POST only (SEC-11, dfmc-client lane security-2). On dev; release with the next release. The ops doors that write - apply=1 on breedfix, sockmig, monmig, keymig, birthmig, reparts, rollback and wallet_credit, breedfix revert=1, the PvP force-end pvpq?end= - wrote on any method. A write sent as anything but POST now answers 405 method_not_allowed; the dry runs stay GETs. The key goes in the x-ops-key header (SEC-02); the URL form is refused once OPS_KEY_QUERY is 0, a 0.90 release-checklist step. The door table above says which method each one takes. Details: docs/security-review-2026-10.md in dfmc-client.
• 2026-10-23 — the feedback status door matches the report, not the number (A20; D3 rides it). On dev. POST /api/feedback/export ran UPDATE feedback SET status=? WHERE id=? and pull_feedback.py --set kind:id=status threw the kind away, so a --set naming the wrong kind for an id re-statused a different report with a 200. The door now takes items:[{kind,id}] (or kind + ids), answers 400 kind_required for an id without a kind, checks every pair before any write and answers 404 with the missing pairs while writing nothing, then updates WHERE kind=? AND id=?. closed joins the accepted statuses and an optional note is appended to the report body; the tool gains --note and --close-before KIND ISO (D3: the pre-wipe auto rows close as “pre-wipe (T37)”). The GM panel’s /api/admin/feedback/mark is unchanged. Gate: tools/probe_a20_kindid.py.
• 2026-10-22 — the four Worker secrets leave wrangler.jsonc (T19 part 4; Tower rulings card T19, D 2026-10-18: “Close all, after the wipe”). LIVE on release since 2026-10-23 (0.89); the release worker gets its secrets in the release ritual. SESSION_SECRET, SPAWN_SECRET, GM_SECRET and FEEDBACK_KEY sat as plain vars in wrangler.jsonc and wrangler.keyprobe.jsonc — in the repository, in every clone, in the dry-run log until de97f81 redacted it. They are Cloudflare Worker Secrets now (wrangler secret put, new values, 32 random bytes base64url). The worker reads each from env.<NAME> exactly as before (a var and a secret are the same binding) and refuses every request with a 503 and one ops line naming what is missing (names, never values) when any of the four is absent, at the top of fetch() before maintenance and before any Durable Object — a deploy that lost one used to run open (an empty SESSION_SECRET signs every token with an empty key; SPAWN_SECRET fell to 'dev'). A var and a secret cannot share a name (API 10053), so the order is deploy-without-vars first, then the puts: the dev worker answers 503 between the merge’s deploy and python tools/put_secrets.py --name dfmc-client-dev; release the same in the ritual (wipe runbook § 5, docs/secrets-runbook-2026-10.md). Rotating SESSION_SECRET signs every player out once; GM_SECRET ends every GM session. Locally, wrangler dev reads the ignored .dev.vars (wrangler’s own mechanism; it wins over any vars in a generated probe config), and every probe and ops tool asks tools/_devvars.py / _devvars.mjs instead of regexing a config (137 files rewritten). The live keys for the ops tools (gm_login, pull_feedback, pull_advlog) come from the environment or a local-only record per worker; dev and release keys differ now. Gate: tools/check_secret_vars.py in gates.sh refuses any of the four under vars, a tracked .dev.vars, or a retired value in any tracked source. Probe tools/probe_t19e.py 3/7 → 7/7.
• 2026-10-22 — The material wallets are the ledger’s from the wipe (T19a; Tower rulings card T19, D 2026-10-18: “Investigate and fix it this round. We are wiping now”; WALLET AUTHORITY D 2026-08-02). SHIPPED IN 0.90, flips with WIPE_EPOCH 2. Scrap/Ink/Dust/Essence had server-booked earns (the dismantle doors) and spends (roll, slot, shop) in wallet_ledger since BOOK, but the class door and the Shadow Trader judged the stored save’s wallet, a single roll attempt judged nothing (ruling #3), and the save door only rate-watched the claim - the client’s number was the money. Now: (1) every door books the ledger at every epoch - the class door (source class, ref <realm>:class:<line>), the trade door (one trade spend row per paid line, one earn row for the target), the ops credit door (/api/backup/wallet_credit takes cur Scrap/Ink/Dust/Essence beside food); (2) post-wipe (the account has claimed epoch ≥ 2 - the same line as the grade freeze) the class, trade and roll doors check SUM(delta) and refuse insufficient (402; the all-in bound is the ledger), write the ledger’s balance into the stored wallet and answer it (wallet on the roll answer, adopted by the client); (3) the save door clamps a claim above ledger + grace (ledger_grace.food) to the ledger - silently when the spends booked since the previous accepted save explain it (a save built before a door’s spend landed), flagged wallet_over_ledger otherwise - and hands the clamp back in srv.wallet; a claim is never raised. Pre-wipe nothing refuses or clamps (PROVENANCE ENFORCEMENT IS WIPE-GATED, D 2026-08-18). Ichor keeps its ledger.food_total ceiling, Wraithgold its entitlement ledger. No source of the four is client-minted: the dismantle doors, the save door’s own dismantle verification, the trader and the ops credit are the only mints; battles pay Ichor only. Gate: dfmc-client tools/probe_t19a.py 8/22 -> 22/22 on a local worker at both epochs.
• 2026-10-22 — Dismantle yield rebalanced (REC2; T5, D 2026-10-18, Tower rulings form: “rebalance the income”; Bug Run 0.89-4 board Q14). LIVE on release since 2026-10-23 (0.89), landed with the wipe. Real saves + battle telemetry at 109 battles/h: Ichor 1,398 / 2,019 / 3,697 / 4,596 per hour by band (1-49 / 50-89 / 90-109 / 110-119), 61% of endgame Ichor from dismantled eggs; Scrap 6,573/h at 119 (the Apex grades, 4.3× floor 105’s). The shared table changes in the authored CSVs both sides read: breeding.csv Egg_Dismantle_Ichor ×0.4 for Epic and above (115/180/270/410/610/860 → 46/72/108/164/244/344); dismantle.csv Gear and Tag Scrap ×0.75, tier 10 ×0.5 (200 rows; Gem, Rune, Scroll, Key, Material untouched). After: Ichor 1,398 / 2,004 / 2,888 / 3,007 per hour (early unchanged, endgame −35%), Scrap at 119 3,287/h (halved); one T10 piece Epic→Void 6.8 h → 13.5 h. Nothing in src/dismantle.js or the doors changed — the data is the fix; it reaches the live Worker and client when DATA_PIN advances and the bake runs. The trader half is on system-shadow-trader. Gate: dfmc-client tools/probe_econ_bands.mjs 10/12 → 12/12 (in gates.sh); the table is tools/sim_econ.mjs.
• 2026-10-01 — legacy boss keys get their server rows: /api/backup/keymig (F131, dfmc-client review lane KM, 3034ef9). LIVE on release since 2026-10-23 (0.89); run at the 0.88 deploy. Since F081 / F6-041 a credited boss battle spends one server key row and refuses without one (boss_nokey); saves older than server-minted keys hold Key items the server never recorded (3 of 21 live accounts on 2026-10-01). GET /api/backup/keymig?sid=<steamid>&realm=standard[&apply=1], ops key, dry by default like sockmig/monmig: it reads the STORED save (bag + bagAdd), resolves each key’s zone (keyId, else name, else keyFloor), counts per zone what the save holds against the rows the battle door would accept (its own predicate), and mints the difference, never more — reusing the save item’s uid first (no row: inserted; an unsourced row: flipped), then fresh uids the way the key lane mints. Origin grandfather; a spent row is never revived; one keys_grandfathered audit row per apply. A pure item-row mint: the save is not rewritten, so no ver bump, snapshot or session-epoch rotation. Idempotent. tools/keymig_all.py walks /api/backup/accounts, dry by default, --apply to write. Gate: tools/probe_keymig.py 16/16 (3/16 before); probe_bosskey.mjs 9/9, probe_lanem_doors.py 17/17.
• 2026-09-30 — an unread request body no longer drops the next request (dfmc-client review lane Z, 556c455). On dev. Lane V's x-dfmc-env stamp rebuilt every /api request as new Request(req, {headers}), which took the incoming body stream; a door that answers without reading its body (POST /api/backup/sweep, /api/lb/backfill) left it live past the reply, the runtime read it afterwards (“Can’t read from request stream after response has been sent”) and the next request on that connection died with an empty 500 — probe_backup’s second forced sweep, about two runs in three. The stamp now reads the body to the end before any route answers and the rebuilt request carries the bytes. Gate: tools/probe_lane_z_bodydrain.py 4/4 (1/4 before); tools/probe_backup.py green 5 runs of 5.
• 2026-09-30 — a retried relay writes each audit row once (dfmc-client review lane W, the F239 follow-up). On dev. Lane R gave autoRelay() three tries for the audit rows it carries to acct_log; a first attempt that landed but lost its reply was re-sent and appended a second copy of the same legal action. Every audit row now carries a stable aid minted where auditLog() creates it (kept across every retry and every queue carry-over; a row from an object still on the old build gets one derived from the relay header and its position, before the first attempt). acct_log gained an aid column with a unique index and both inserts are INSERT OR IGNORE, so a repeat is a no-op while a second real action is still its own row. Rows written before this have no aid and are untouched. The lost reply is simulated by AUTOREPT_REPLAY_TEST=1, a test-harness var set only in the probe’s own config copy (never in production, like RATE_OFF). Gate: tools/probe_lanew_relay.py 8/8 (5/8 on the tree before); tools/probe_laner_ops.py 12/12.
• 2026-09-30 — the battle-telemetry ops tools read one environment (dfmc-client review lane Y, F6-061, dev 67c38ce). tools/balance_queries.py and tools/replay_keylane.mjs still read dfmc_battles across dev and release. Both now filter on blob7: release by default (every point not stamped dev, so release points written before the stamp reaches main still count), with --env / ENV dev or all. Dev points older than the stamp are unmarked and age out with the 90-day window.
• 2026-09-30 — the battles and write-cost panels count their own environment (dfmc-client review lane V, the F252 follow-up). On dev. Lane N stamped the environment on dfmc_activity; dfmc_battles and dfmc_wrcost still mixed dev and probe traffic into the release console. Both points are written inside the objects, whose isolate may never have served a Worker request, so the Worker now stamps every /api request it forwards with x-dfmc-env (overwriting any client value) and the object reads it (falling back to the isolate’s own knowledge for internal calls). Battles carry it as blob7, write cost as blob6; the two panels filter on it. Points written before this carry no environment and drop out of the filtered panels. Gate: tools/probe_lane_v.mjs 16/16 (4/16 on the tree before).
• 2026-09-30 — the ops doors leave their permanent record (dfmc-client review lane R: F256, F257, F259, F239, F238, F236, F241, F264, F265, F220). On dev. F239: every key-gated edge that forwards to a player object rebuilt the reply with content-type alone, so the header carrying auditLog rows (ops_restore, admin_wipe, the rollback) never reached the relay and acct_log stayed empty; the header is now kept (and still stripped before anything leaves the edge), and the relay retries three times, then writes one AUTOREPT_LOST log line carrying the audit rows in full. F256/F257: ops_rollback (the working /api/backup/rollback), ops_breedfix and ops_breedfix_revert are audit kinds (acct_log, never pruned) instead of bug reports + 30-day anomalies; the grandfather stamp writes a grandfathered row per account it flips. F259: the ops_restore row records the ratchet actually written (max(1, maxFloor)), not the old dev-seed 9. F238: the housekeeping sweep is hourly again, gated on a persisted last-run time: one point read per save, a write only when it runs (it was a counter written on every save, sweeping every 100 saves). F236: the 30-day prune of item tombstones moved from every changed save into that sweep's shared, sliced budget. F241: the two 2026-07-24 one-off wipes that every new object ran for nothing are removed. F264/F265/F220: the GM save-history panel says “no history” on an empty result; dead realm read in /api/admin/wipe removed; the rate-limit comments state the sizes in force. Probe tools/probe_laner_ops.py.
• 2026-09-30 — the GM console counts what it says (dfmc-client review lane N: F244, F251, F252, F254, F248). On dev. F244: /api/usage reports the cap spend() enforces (an admin override in wmeta beats the constant; the constant rides along as default when they differ). F251: the activity panel’s rate is labelled for its real denominator: errors among the requests the counter writes (the classed route families plus every error), not all requests. F252: release and dev bind the same Analytics Engine dataset, so each activity point now carries its environment (blob5) and the panels read their own; dev and probe traffic no longer count as release players. Points written before this carry no blob5 and drop out of the one-hour / one-day windows. F254: the entitlement R2 mirror is counted in the PLAYER object’s own usage table, not the world budget /api/usage reads; the code comment no longer claims otherwise. F248: the ops bulk dismantle (/api/backup/dismantle) refuses a locked item, like the mutant and the held-in-socket refusals.
• 2026-09-30 — the ops key rides a header (review P6 F6-022). On dev. FEEDBACK_KEY, the one secret behind /api/backup/*, /api/usage, /api/ledger/reconcile, /api/lb/*, /api/gm/bootstrap, /api/admin/wipe/rename, /api/account/resolve and /api/feedback/export, was read only off the URL query (?key= / ?k=), which Workers Logs, Logpush, the request sampler, proxies and shell history record verbatim. Every door now reads the X-Ops-Key request header first (one helper, opsKeyIn; the object-side compares are the constant-time opsKeyOk). The query forms are still accepted for now, so an old tool keeps working; the live ops tools (pull_feedback, backup_saves, pull_advlog, gm_login, promote_lvl90, replay_keylane) already send the header. Local probes still use the query against wrangler dev with the probe-only key. Probe tools/probe_opskeyhdr.py 12/16 → 16/16.
• 2026-09-30 — the roll door’s rate ceiling stops scanning the table (review P6, lane H finding, fixed in lane M). On dev. The 120-draws-a-minute ceiling on /api/roll ran SELECT COUNT(*) FROM rolls WHERE ts > now-60s on every roll; rolls has no ts index, so it read the whole 7-day table each time - the last per-roll scan after F6-023. The count is now an in-memory list of the object’s draw times, seeded from the table once per wake (so a restarted isolate still sees the last minute) and appended on every recorded draw. Same window, same limit, no row written. probe_rollsweep rowsRead growth per roll: 1.0 → 0.0.
• 2026-09-30 — the roll door's retention sweep runs once an hour, not on every roll (review P6 F6-023). On dev. /api/roll ended every request with DELETE FROM rolls / roll_att WHERE ts < now-7d; neither table has a ts index, so each roll scanned both tables' whole 7-day window. The sweep now runs when the player object's in-memory stamp is over an hour old (a woken object sweeps on its first roll); same 7-day horizon, zero rows to keep the stamp. No ts index was added: an index is one more billed row written on every roll. Measured over 40 enchant rolls (tools/probe_rollsweep.py, WRCOST): rows read 1,722 → 864, rows written 87 → 87.
• 2026-09-30 — the worker's table readers parse quoted line breaks (review P6 F6-021). On dev. The chance tables (every CHANCE_CSVS file, floors.csv included), the item bases / legality index (items.csv) and the species set (creatures.csv) split the file on newlines before parsing, so a quoted cell holding a line break (classes.csv already authors them) would have shifted that row's cells. All three now use the worker's one quote-aware parser, which also now treats a bare quote mid-field as a literal (as move_icons.csv authors one). No change on today's pinned data. Probe tools/probe_csvreaders.mjs 46/49 → 49/49 against Python's csv.
• 2026-09-30 — review drift fixes: F385 (project review, codex fix lane). Text only; no code changed. “The write breaker” now states what wrBreaker runs: layer 3 compares the closed hour to 10× the p90 of the retained active hours and needs at least 12 of them (since 2026-09-02, not the first request against the median); layer 2’s 70/90/100 wr_budget flags and the diagnostic anomalies shed at the ceiling are named.

• 2026-09-30 — GM Lock, Save history and Rollback reach the player’s own object (project review F225, D decision “fix”). On dev. Since Stage 2 a player’s saves, save_hist and the lock check live in that player’s PlayerDO, but /api/gm/admin/* and Steam-admin /api/admin/* sent lock, save-history and rollback to the single WorldDO: a GM lock wrote a row no player object reads (the player kept saving), Save history was always empty and Rollback answered 404. The Worker now routes the three to the target account’s PlayerDO (adminPlayerOp: _internal/save_hist, _internal/rollback, new _internal/lock), the same hop /api/backup/history and /api/backup/rollback make. Lock also keeps its WorldDO row. The GM-session and ADMIN_STEAMIDS gates are unchanged; a malformed steamid is refused 400. Gate: tools/probe_f225_adminplayer.py 5/14 → 14/14 on a local worker.

• 2026-09-30 — review drift fixes: F126, F212, F213, F214, F215, F229, F230, F231, F250, F260, F261, F262, F263 (project review, codex fix lane). Text only; no code changed. The page body now states what the build does: the ops bulk dismantle prices and credits through dismCreditRow since #A4 (dev); GM login is password only and bootstrap mints no TOTP (#TOTP-removal, 2026-09-28); the rate classes carry today's buckets (ip_all 600/360, plus me, mm, pvpm, roll) and TRAFFIC_BLOCK_N is 50 as deployed; RATE_READ_ONLY holds save_read and me; adventure-log uploads are capped at 1.25 MiB, keyed per device, and a round closes itself after 3 days (advlog_until); the ops door list is complete, split into read and write doors; the GM activity panel (dfmc_activity, /api/gm/analytics) is documented; restore writes the save parts through writeSave; the audited kinds list matches AUDIT_KINDS (admin_traffic_block/admin_traffic_clear) plus the direct auditLog kinds; /api/admin/flags takes sid/kind/limit and answers {ok, rows, counts24h}.

• 2026-09-30 — GM enrollment holds its own lock (project review F210, D decision “fix”). On dev. The ops-key check on GM enrollment no longer depends on the generic request gate, which stands down during maintenance: the enrollment handler and the world object each check the ops key themselves (constant-time), maintenance or not, the same way the backup doors already did. GM usernames containing a dot now keep a working session after login.
• 2026-08-28 — one game mode (D order). On release. The GM console's realm selector and snapshot report the one realm; the account-reset door resets it alone; the removed death pipeline's section left this page because the pipeline itself left the build. Build record on Realms.

• 2026-08-26 — birth records on the items row, and two doors (on release). items.birth holds each creature's and egg's birth record (see system-networking); /api/backup/inv now shows it per row; /api/backup/birthmig?k=&sid=&realm= reports what a STORED copy would record, strip and keep, and &apply=1 does it through the save facade (ver bumps by one, so it is for accounts that are not playing — a playing account migrates itself on its next save). One audit line per save that moved records (birth_recorded) and per migration (birth_migrated).
• 2026-08-26 — two detectors say what they saw (on release). wr_rate_anomaly names the request, the object class and the account (three rows — 174/195/228 rows — had reached the operator as “rows this hour” with no object, and could not be attributed); breed_claim_bad's elapsed row says by how many seconds of the pen's authored wait the claim was early (the reason word in the answer stays elapsed). Why: twelve elapsed rows on one account in the day after the pen-anchor fix reached release, all on pens that were running before it — a verified claim advances started by one wait from the OLD anchor, so a pen anchored late stays late for as long as the pair runs. The delta is the number a re-anchor tolerance would need; measured first.
• 2026-08-25 — refinement purged from this page's text (D order: the mechanic does not exist). The spend list, the roll ladders, the cost tables and the two diagram labels no longer name it; the dismantle key's third field is documented as the constant +0 it has always been, and dismantle.csv lost its 1,000 dead +1…+10 gear rows (the lookup key never asked for them).
• 2026-08-25 — LEVEL-90 PROMOTION (D orders: “Promote everyone who is wearing gear above their level to lvl 90” / “Creatures too”), done through the audited ops restore door (LIVE — these are release saves). Ahead of the level-requirement rule reaching release, every account wearing character gear above its account level, and every party creature wearing tags above its own level, had its XP raised to XPCurve.csv cumulative for level 90 (3,963,264) — only that field, verified by re-read, one ops_restore audit row per write, idle accounts only. Done: accounts …5081 (85), …7635 (88), …0634 (87); creatures Ingot and Drakeling (60, 60), Nosferatu (83), Omnichimera and Crestmantis (85, 85), Ferrodrake (80), Colony (5), and D's own Typhon and Charybdis (87, 87) once his tab went idle. Still owed at the time of writing (mid-session at every retry): account …3878 (85 → 90). tools/promote_lvl90.py is the repeatable form: dry by default, --apply writes only accounts idle 10+ minutes, re-reads and reports; running it when nothing is owed changes nothing.
• 2026-08-23 — the GM console: password+TOTP operator login at /gm, cached world snapshot, adventure-log extraction (built by Jeff, PREP_GM_CONSOLE.md §8–§9d; LIVE on release since 2026-08-23 (0.61)). New “GM console” section above carries the mechanics: ops-key-gated enrollment (inert until the first bootstrap), PBKDF2+TOTP login with per-account lockout and a permanent gm_audit trail, a 12-hour HMAC session with no v1 revocation, gm:<user> identities holding the full /api/admin/* surface, a snapshot data plane that accumulates on the existing nightly backup cycle and serves one cached value, and metadata-only adventure-log rounds into the private backup bucket (turnsLog stripped server-side, 256 KiB cap, budgeted R2 writes). Three new ops-key doors joined the table: gmsnap, advlog/list, advlog/get. Gates: tools/probe_gmconsole.py, tools/probe_gmadmin.py, tools/probe_gmsnapshot.py, tools/probe_advlog.py; live smoke on /dev/gm (page 200, unauthenticated doors 401, bootstrap without the key 403).
• 2026-08-22 — the Worn-pen repair door, /api/backup/breedfix (D order “fix both”). LIVE on release since 2026-08-22 (0.59). Companion to the breeding fix on Breeding: between the 08-21 server batch and 0.59 every breeding pair the ledger could verify was recorded as Worn and laid eggs off the Worn row. GET /api/backup/breedfix?k=&sid=&realm= is a dry run: it lists every stored egg draw whose recorded pair was Worn and which the ledger verified, with the real pair grade recomputed from the pen's recorded parents' ledger grades, the grade the draw's own keyed lane gives on that row, what would be done, and the Ichor owed (pair price minus the Worn price booked). &apply=1 does it: held unhatched eggs are re-graded in place (save and ledger row), hatched or dismantled ones are regranted as a fresh egg of the same line at the pair grade (ledger origin breed, save origin marked repair), the Ichor difference is booked once (source breedfix, keyed on the draw), every running pen's recorded grade is re-derived, the save is written one version up with a fresh timestamp, and the account is flagged ops_breedfix. Each repaired draw is marked in place, so a re-run changes nothing. Skipped and named, never guessed: an honest Worn pair, a pen whose pair changed since the draw, a parent without a legal grade, or a lane that no longer reproduces the stored Worn draw. A player online at apply time can overwrite the written save with their next flush — apply while the account is idle and re-read the live save afterwards. Gate: tools/probe_breedfix.mjs.
• 2026-08-21 — retention leaves the battle loop: sliced, budgeted, hourly (report #458, D order). LIVE on release since 2026-08-21 (0.58). The battle credit loop ran the events_seen (7d) and drops_granted (30d) prunes per event, ungated; ~7 days after a heavy day one battle inherited the whole day's expiry in one statement — 2,193 rows on the write breaker's first live morning, filed as auto report #458. Both prunes moved into maybeMaintain beside the three already there; all five now drain through a shared budget of billed rows per hourly run, announced by a MAINT console line. Replay protection can only run longer during a drain, never shorter. New section “The write breaker and the sliced retention” above. Gate tools/probe_battleprune.py 6/6, red 3/6 first; six adjacent suites re-run green.
• 2026-08-21 — the ops bulk dismantle spares Mutants, and the shared yield module deliberately does not copy the refusal (D order: “all types of dismantle for creatures are ignoring mutants”). LIVE on release since 2026-08-21 (0.58). /api/_internal/bulk_dismantle with scope 'all' now leaves any Monster with mut:true untouched — it was the one dismantle running server-side without the client’s gate. src/dismantle.js keeps paying a Mutant claim on purpose, so a stale release client loses nothing; probe_dismantle_parity.py gate B4 pins that divergence. Ops probe tools/probe_dismmutant_ops.py 4/4, red 2/4 against the build it replaces.
• 2026-08-17 — every guard now reports itself, reports carry counts, and admin/ops actions became a permanent per-account log (LIVE on release since 2026-08-21 (0.58)). D’s order after reading a bug-report pull: “Make sure all these flags are being stored as auto bug reports… Once we are sure they are not catching only bugs they will become our anticheat”, then “That noise is not normal. Those are bugs” and “Admin and ops actions are legal actions and they need to be permanently recorded on each account… Ops only.” The allowlist of 19 is gone — all 74 raised kinds report, 64 of them into the inbox and 10 diverted to the new never-pruned acct_log in the WorldDO, read only through GET /api/admin/acctlog. Reports are one row per account per kind per UTC day updated in place with the day’s running count, tagged suspect/sync/system as a sort order rather than a verdict. Budgets are per class and a refused report is itself reported; the carrier no longer cuts its own payload mid-JSON, which used to discard whole batches silently. Nothing gates anything yet — enforcement waits on a week of live accounts. Probe tools/probe_flagrept.mjs AFTER 25/25, BEFORE 12/12, and the probe of that name had itself been crashing since 2026-08-12.
• 2026-08-12 — the automatic bug reporter had never filed a readable row; both causes fixed (on release). Report #124. Rows were written status='open', which no reader lists and no mark endpoint accepts, and inserted into the raising player's own object while the inbox lives in the WorldDO — either alone was fatal and neither raised an error. Status is now 'new'; the row is queued in the raising object, carried out on the x-ht-autorept response header, and relayed to the WorldDO by the Worker under waitUntil, so no Durable Object gains an outbound fetch and hibernation is unaffected. The forty-a-day ceiling moved to the world door where the table it counts lives; the per-account-per-kind-per-day dedup stayed where the account's history is. New section “Why no automatic report ever arrived” above records both causes, the live evidence for each, and the relay. This is why report #122 had to be noticed by D rather than caught by looking — every save-path detection since 2026-08-04 was written somewhere no door can read. Probe tools/probe_autorept.mjs 18/18, and 7/18 against the build it replaces.
• 2026-08-08 — per-invocation CPU ceiling set to 500 ms on both branches (silent fix, no version bump, D's order). The account is on Workers Paid, so no daily cap and no platform spend cap applied and every invocation could burn the 30,000 ms default. Measured before setting, not guessed: 7 days and 293,918 requests gave P50 0.8 ms, P99 15 ms, P999 59 ms — but the true max over 169 hours is 156 ms, because the every-minute cron and the nightly R2 mirror sit below the P999 cut and a quantile cannot see them. Headroom is 3.2×, not the 8× the percentile suggested. Applied first to dfmc-client-dev through the settings API and smoke-tested, then to release; the settings API refused the release worker with error 10214 (latest uploaded version was not the deployed one), which is why it belongs in wrangler.jsonc rather than the dashboard in the first place. New “Denial-of-wallet” section above records the measurement method and the standing re-measure trigger.
• 2026-08-05 — reports anchored to open time, not send time (LIVE on release since 2026-08-08 (0.42)). ctx was read when the player pressed send, which with autoplay running is several battles after the moment being reported — the cause of report #29 arriving stamped screen: resolving. openFeedback() now snapshots the context, and the payload carries openedAt, typedMs and an atSend map holding only the fields that drifted while the report was written.
• 2026-08-05 — screenshots removed from bug reports entirely (D order; LIVE on release since 2026-08-08 (0.42)). All 33 stored reports were decoded and inspected first: 24 usable frames, 3 flat texture, 6 absent, and the frame taken when the report was written rather than when the bug happened. The payload drops from 63 KB to 13.1 KB and logs become 96% of it. b.shot is ignored rather than rejected so release clients do not lose reports during the rollout; purgeShots() blanks the stored images once behind a wmeta flag, on the ops door. The new “What a bug report actually carries” section above is the first time the payload has been written down.
• 2026-08-04 — new wallet rate class (LIVE on release since 2026-08-08 (0.42)). Currency spends no longer share the generic other bucket, where normal play left too few tokens for a couple of clicks on the inventory + and produced a 429 that was both shown as PURCHASE FAILED and filed as a traffic breach.
• 2026-08-04 — restore does not write history or save parts. Recorded against a live account: a restore created ver 65 in saves while the history ring still topped out at ver 64 and no save_parts row existed. Harmless while saves is authoritative; a silent data-loss bug the moment reads cut over to parts. Also: the first sweep of these doors was run unpaced and dropped responses were swallowed into empty results by the tooling, which read as missing data on accounts that had answered correctly minutes earlier — pace the requests and print the status.
• 2026-08-04 — the PvP queue door answered 401 on release; root cause was route placement, and the full ops-door set is now documented (LIVE on release since 2026-08-08 (0.42)). /api/_internal/pvpq had been written among the PvP routes, roughly 1,150 lines below the blanket session gate in MainDO.fetch, while all thirty-odd sibling internal routes sit above it. The Worker forwards internal calls with no session cookie, so the object refused the request before the handler ran and the ops key was never the problem. Moved above the gate with the invariant recorded at the call site. No logic changed — the diff is the move plus a comment. Also fixed on this page: the “Ops reads” section had been appended after </body></html>, so the page had been shipping malformed since it was added.
• 2026-08-03 — dismantle yield extracted to a shared, parity-gated module (ON DEV, not enforcing yet). The yield lived only in the client, which is why the ops dismantle door deletes rows and credits nothing, and why dismantle Ichor is client-minted against a battle-only ceiling. src/dismantle.js now carries it on the src/power.js pattern, proven 9/9 against the live client over all 1,515 authored rows. Server-side validation by save-diff is the next batch.
• 2026-08-02 — traffic blocks documented; reads exempted; blocks now expire. An alpha account was soft-blocked on the save class for seven hours and the symptom was indistinguishable from a broken login; two more accounts had been silently blocked on floor and db for three days. GET /api/save moved to its own save_read class which is never blocked and never escalates, and blocked=1 now ages out after SB_EXPIRE_MS.
• 2026-07-31 — key-gated reads of a player’s save history and of the server’s own ratchet and ledger. Added for the rollback repair, because the admin console’s equivalents are routed to the WorldDO and are blind to player data.
• Backfilled 2026-08-01 — this page had no changelog section, and the commit that should have added the entry above skipped it silently instead of failing.

Ops reads — the account's own record

Both are key-gated with the ops key and are read-only: they select, they never write. They exist because /api/admin/* is dispatched to the WorldDO while saves, anomalies and progress live in the player's own object, so the admin console's save-history and flags views have always answered empty for player data. These doors are what made the 2026-07-31 rollback repair possible. Since 2026-09-30 (F225, dev) the three per-account admin ops are routed to the target account's own object: lock, save-history and rollback — through the GM console (/api/gm/admin/*) or a Steam admin session (/api/admin/*) — reach the player's PlayerDO via adminPlayerOp (_internal/save_hist, _internal/rollback, _internal/lock). Lock also keeps its WorldDO row, so world-routed writes stay refused and the admin_lock audit row keeps the actor. Since 2026-10-23 (merge-follow, dev) every one of these doors resolves a merged-away id to its winner through the World ledger first and answers both ids.

What a bug report actually carries

Status: LIVE on release since 2026-08-05 (0.33). A report is one row in the feedback table of the shared object — the same SQLite as every save, capped at 10 GB. Measured across all 33 stored reports on 2026-08-05, the payload was:

With the screenshot gone a report is 13.1 KB instead of 63 KB, and logs are 96% of what remains — they are now the report. Guards unchanged: 20 reports per account per hour, 300 globally per hour, and a same-account/same-wording/same-hour dedupe that hands back the existing id.

The report is anchored to the moment it was OPENED

Status: LIVE on release since 2026-08-05 (0.33). ctx used to be read at send time — after the player had typed. With autoplay running that is several battles and possibly a floor or two later, so the stamp described a moment the report was not about. Report #29 names the floor-map key count and arrives stamped screen: resolving for exactly this reason.

• openFeedback() snapshots feedbackCtx() and a timestamp. That snapshot is what ships as ctx.
• openedAt — ISO timestamp of the moment the reporter was opened.
• typedMs — how long the report took to write. A large value is the warning that the run moved underneath it.
• atSend — present only when something drifted, and carrying only the fields that did: floor, phase, screen. Drift is recorded rather than silently overwriting the anchor.
• Falls back to the live ctx when the open snapshot is missing, so a restored or forced state still reports.

The reporter deliberately does not close the inventory or equipment window behind it, so the open-time screen is the one the player was actually looking at when they decided to file. Verified by tools/probe_noshot.py (7/7), which moves the run to floor 77 and opens the inventory underneath an open reporter, then asserts ctx.floor still reads the open-time floor and that atSend records the drift — the #29 condition, reproduced deliberately.

Still not perfect, and worth knowing: opening the reporter goes through the menu, so the anchor is the moment the player decided to report, not the moment the bug happened. The activity log timestamps in logs remain the only thing that ties a report to the event itself.

Why the screenshot went (D order, 2026-08-05)

All 33 stored reports were decoded and inspected before the removal, not sampled. 24 carried a usable frame, 3 were flat repeating texture with no information (one of them 152 KB, filed against a report titled “font too small”), and 6 had nothing at all. A first pass using luminance-histogram spread scored the texture images as fine; averaging each frame down to 32×32 so high-frequency pattern cancels is the test that catches them, and that correction is recorded here because the first answer given to D was wrong.

• The frame is of the wrong moment. It is captured when the report is written, not when the bug happened, and filing goes through the menu — so the camera usually pointed at the menu the player opened to file. Report #29, about the key count reading zero on the floor map, carries a photograph of the Autoplay Options panel while its own ctx.screen says resolving.
• html2canvas re-renders the DOM, it does not photograph it. Letter-spacing collapses (“AutoAdvanceFloors”, “OptimizFor”) and description text compresses to mush. At a 2560 px viewport the frame is scaled to 900 px and is illegible.
• Failure and opt-out were indistinguishable. Every failure path returned an empty string, and so did a player unchecking the box, so nothing could be diagnosed from an absent shot.
• It was fetched from a third party mid-report. html2canvas came from cdnjs at the moment of the click; blocked or slow meant no image, silently.

What changed in the build. Client: captureShot() and the cdnjs fetch are gone, the “Include a screenshot of this screen” toggle is gone, and the panel no longer hides itself before sending. Worker: b.shot is ignored, not rejected — release clients keep sending one until the next release and a 413 would lose their whole report; the export and the admin summary no longer select the column; and purgeShots() blanks every stored image once, guarded by a wmeta flag and hung on the key-gated export door so no player request pays for it. The column itself stays, because dropping a column in SQLite is a table rebuild.

Not a cost fix. The whole stored payload was 1.65 MB — about $0.0003 a month. It was removed because it was not earning its place, and the storage argument that was first offered for it was wrong.

Client: openFeedback(), sendFeedback(), feedbackLogs(), feedbackCtx() in play/app.js. Worker: the /api/feedback POST handler, /api/feedback/export, purgeShots() in src/worker.js. Probe: tools/probe_noshot.py 5/5.

GM console — the operator surface at /gm

LIVE on release since 2026-08-23 (0.61). A browser console for operators, served inline by the Worker at /gm (deliberately not under play/), reachable even under maintenance mode. Its auth is fully independent of player sessions.

• Enrollment — POST /api/gm/bootstrap, ops-key-gated in its own handler (maintenance or not). Creates or re-enrolls a named operator account and sets its password; every enrollment is audited. Since 2026-09-28 (#TOTP-removal, Jeff's order) bootstrap mints no TOTP secret and answers {ok, user}; a re-enrolled account keeps whatever totp_secret row it already had, unused. Until the first bootstrap the account table is empty and login is impossible — the console ships inert.
• Login — password only (PBKDF2-SHA256, 100,000 iterations, per-account salt). The TOTP second factor was removed 2026-09-28 (#TOTP-removal): no code is asked for or checked. A per-account fail counter applies a lockout window (the brute-force defense, since /api/gm/* skips the per-steamid rate limiter); every attempt — unknown user, locked, bad password, success — lands in the permanent gm_audit table with timestamp, actor, action and IP.
• Session — ht_gm_session cookie, HMAC-signed with GM_SECRET, 12 hours, HttpOnly/Secure/SameSite=Lax. v1 has no server-side revocation list — expiry is the only thing that takes a token away, which is why it is short.
• Power — /api/gm/admin/<action> verifies the GM session, then forwards internally to /api/admin/<action> under the identity gm:<user>; the admin allowlist accepts gm:* alongside ADMIN_STEAMIDS. A GM session therefore holds the full admin surface, and every admin door’s own permanent per-account recording applies to it.
• Snapshot data plane — population, floor and power summaries per realm, accumulated during the existing nightly backup cycle (never a new per-account call) and published to one cached value at cycle wrap. GET /api/gm/snapshot (GM session) and GET /api/backup/gmsnap (ops key) both serve the cache, so reading it fifty times a day costs the same as once. Until the first full cycle completes it reports that no snapshot exists yet.
• Adventure-log extraction — an operator starts a round (POST /api/admin/advlog/start, audited). The round closes itself: start stamps advlog_until = now + 3 days and answers {round, until}; after that the active round reads as none and uploads stop (D2, D ruling 2026-09-04). Clients poll the active round id at most hourly and upload once per round per device: chapters and battle metadata only — the round-by-round combat text (turnsLog) is stripped server-side regardless of what the client sent, uploads are capped at 2,000 battles and 1.25 MiB (1,310,720 chars; raised by D2 to carry advArc, the gzip+base64 archive blocks holding older history), and each R2 write passes the shared spend budget first. Files land in the private backup bucket under advlog/<round>/<steamid>/<device>.json, one per device so no device overwrites another's; /api/backup/advlog/list also returns devices (sid → device count); a receipt row per account per round records time and size, and the status door reports the count and the last five check-ins.
• Activity panel (backlog 12.2, Jeff's order 2026-09-28) — the Worker writes one Analytics Engine point (binding ACTIVITY_AE, dataset dfmc_activity) per /api/* request that falls in a console class (hatch, roll, battle, save writes, login) or answers an error status; other requests write nothing. The point carries the class, a hashed session cookie (first 8 bytes of SHA-256, never the steamid or raw cookie), the status and the path; the write is fire-and-forget and a missing binding just stops emission. GET /api/gm/analytics (GM session) reads it, plus dfmc_battles and dfmc_wrcost, through the AE SQL API using the Worker secrets CF_ACCOUNT_ID / CF_AE_TOKEN: active players over 5 m/1 h/24 h, requests per class and error rate over the last hour, battles and write cost per system. Every point in all three datasets carries its environment (dev / rel: dfmc_activity blob5, dfmc_battles blob7, dfmc_wrcost blob6) and every panel counts only the environment it is served from, because release and dev bind the same datasets. Cached 60 s per isolate; with the secrets unset it answers {ok, note:'Analytics token not set', panels:null}.

Ops doors — the complete set

Every /api/backup/* door is gated on the ops key at the Worker's session gate, which matches on the stripped path so /dev/api/backup/* is gated identically. A wrong key answers 403 forbidden and never wakes an object. Note /api/feedback/export takes k, not key. Per-account doors act on realm standard whatever realm is passed (one game mode). The first table is the read doors; the write doors follow it.

Write doors. Each of these changes stored state; the migration and repair doors are dry by default and write only with apply=1.