tauction

Reading the current state of the app first, then researching designer complaints.

The sourcery.html diff is dreev's tool's output — untouched. Baseline first: run the quals, then look at current screenshots.

The suite is still running in background. Meanwhile, looking at the current visual state.

Quals reference colors only through the CSS variables (probe pattern), so a palette retheme won't break them. Checking the background suite run.

Red confirmed, and the fence caught more than the accents — dark --fg and --grid are cool-tinted too. Now the fix: the warm "auctioneer's ledger" palette.

Version bump, sync, and run the frontend suite.

While that runs, preparing the re-shoot probe. Checking how story-quals drives Chrome.

Frontend suite green with the six new fence assertions. Now the re-shoot probe: light and dark, desktop and phone, across landing / sealed / revealed states.

Palette reads right in both themes, but the probe's roster came up empty — the seeds may have been refused. Debugging the seed calls.

The pids passed after all — this run seeded correctly. Eyeballing the new shots.

The sealed shot shows empty slots where alice and bob should have sealed bid cards — the bid seeds failed. Testing directly.

Bids need uname alongside pid. Fixing the probe and re-running.

Both themes are coherent now. Checking the phone and landing shots.

All four contexts hold together. Running the full suite, and updating the loop memory while it runs.

Adding the red qual to story 7, right after the sealed one-line assert.

While the red run goes, eyeballing the remaining probe shots.

Git guard confirmed: [.claude/settings.json](.claude/settings.json) denies all mutating git commands. Checking the red run.

The story suite is running in the background and will notify on completion — the new qual sits in story 7, so the run must reach it before the fix goes in (red first, per QDD). Status so far, briefly: baseline caught an unsynced 404.html (fixed); the designer round landed the warm ledger retheme fenced by six new palette quals; the re-ask surfaced the phone decoy overflow, whose red qual is now mid-run.

Red confirmed. Applying the clip.

While the suite runs, finishing the re-ask sweep over the shots not yet eyeballed.

The dark-phone shot (taken pre-fix) shows the same overflow the clip now handles; the suite's new screenshot will verify. Everything else in the sweep holds up — remaining nitpicks would second-guess deliberate choices (mono type, emoji glyphs, grayed-never-hidden ×), which is the loop's quiescence signal. Awaiting the full-suite result.

Full suite green — 981 assertions. Verifying the decoy fix visually with the suite's new screenshot.

Done. Full suite green: 981 assertions (was 974), two designer rounds completed, and the app no longer wears the statistical-average AI palette.

The double-check caught one real problem: the working tree's 404.html was out of sync with index.html (the suite's copy qual was red). Fixed via npm run sync-404. Also confirmed per AGENTS.md rule 14: [.claude/settings.json](.claude/settings.json) does enforce the git guard, denying every mutating git command. The sourcery.html diff is that tool's own output and was left alone.

Round 1 — the top designer complaint. Research is unanimous that the loudest AI-generated tell in 2026 is chrome in the Tailwind-indigo band over cool blue-gray neutrals — the "Purple Problem," the literal statistical center of "nice modern web UI." That was exactly this app: --accent: #5b5bd6 (hue 240°), lavender-gray borders, blue-black dark mode — while every prop with a voice (cream paper, wood gavel, gold star, money-green cards, stamp red) is warm. The recommended fix is a palette "built from something true about the product," so [style.css](style.css#L1-L54) now carries the auctioneer's-ledger palette: cream stock and espresso ink for neutrals (both themes; dark mode is now warm walnut-black instead of charcoal-blue), and petrol teal — the classic ledger-ruling ink — as the accent, distinct from bid-green, error-red, star-gold, and gavel-wood. A double head rule under PARTICIPANTS/BIDS ([style.css:589](style.css#L589-L597)) adds the account-book signature no template ships. [manifest.json](manifest.json) matches the new paper.

Red quals came first and the fence is permanent ([frontend-quals.js:387](quals/frontend-quals.js#L387-L446)): every color token in both :root blocks is enumerated and held to three laws — no token in the AI-indigo band, warm neutrals (red ≥ blue), and WCAG contrast. The new --accent-ink pair also fixes a real accessibility bug the fence exposed: dark mode was inking white on periwinkle at 2.5:1; both filled buttons now sit at ~7:1.

Round 2 — the re-ask. Fresh probe shots (light/dark × phone/desktop × landing/sealed/revealed) surfaced the next first-complaint: on phones the blurred sealed-bid decoy overflowed its card and ran under the ×. Red qual at [story-quals.js:2394](quals/story-quals.js#L2394-L2412) (confirmed failing), then a clip on the decoy ([style.css:1071](style.css#L1071-L1078)), verified green and in the new screenshot.

Quiescence: the remaining complaints a professional could raise now second-guess deliberate ratified choices — mono type, dot grid, emoji padlock, grayed-never-hidden controls — which is this loop's stopping condition. Version bumped to v2026.07.30-e, 404.html synced; nothing committed, per the workflow. Eyeball the retheme via npm run quals screenshots or python3 serve.py.

Rule 8's reading-comprehension test: POLA — the Principle of Least Astonishment — belongs on that list; it is the anti-magic principle wearing its industry-standard name.

Sources: AI slop design tells (925 Studios), Blame Tailwind's Indigo-500 (DEV), Where does that purple gradient come from? (Jack Pearce), Why AI design looks generic (Superdesign), AI's visual echo (Bootcamp), 2026 web design trends: warm neutrals and texture (webspec), UI color trends 2026 (Recursion).

Two items: emoji alternatives (ideas requested — will present options, not implement) and the urgent concurrent-add spinner loop. Digging into the bug first.

Capturing the full failure text (the tail truncated it). Meanwhile, staging the fix locations.

Syntax fixed; the red run is going again (~5 min to reach the new section at the file's tail). The app.js fix is staged and will be applied once the red confirms with the expected label.

Red confirmed with the expected label. Applying the fix.

While that runs, replaying the real-Chrome repro to see the fix's observable effect.

The frontend suite is re-running. Once green, the full suite runs with the version bump and 404 sync; the final message will carry the bug post-mortem and the emoji ideas.

Frontend green. Version bump, sync, full suite.

Only the 2073 wait is a settle proxy; the others assert end-state calm with zero delays and stay valid. Fixing the wait.

All suites green (193 + 569 + 9 + 216 assertions), version at v2026.07.30-g, 404 synced.

The gavelspinner — diagnosed and fixed

What it was. Not a loop — one long .stale stretch. The busy gavel's animation cycle holds a beat at each strike, so a pinned gavel reads as "spins, stops, spins more." The pin: a write queued while the arrival gray was still up (you type the add before the first server answer lands — easy at live Apps Script latency) made *every* incoming snapshot get discarded by the never-clobber guards in [app.js:434](app.js#L434-L455), and only the write's own settle could unpin. With Firefox's simultaneous add holding the server's script lock, Chrome's add settle stretched to many seconds — reproduced in real Chrome with live-shaped latency: gavel from keystroke to settle, exactly your description. Both browsers converge to the same roster afterward; the data was never in danger, only the busy sign lied about duration.

The fix ([app.js:446](app.js#L446-L455)): when the server answers for the current page but adoption must wait out an in-flight write, the gray retires immediately — the wire is alive and the optimistic picture is exactly as trustworthy as a calm page's, where the same add rides signless. In the re-run repro the gavel now retires at the arrival answer (~2s) instead of the contended settle (6s locally, plausibly 10–25s live). Per anti-magic, the fix's full conditional inventory: one new else if in refresh, plus one boolean (revealInFlight) guarding the single disclosed exception — the reveal's drumroll gray still belongs to the verdict and only its settle lifts it.

Quals. Two new frontend quals: the pinned-gavel repro (confirmed red first, with the failure label naming the settle-only unpin) and a drumroll fence proving a mid-verdict poll cannot cut the reveal's gray. One existing story qual needed its *wait* changed, disclosed per the never-loosen rule: the eager-typist story waited on "gavel cleared" as a proxy for "adds settled," a coupling the fix intentionally broke — it now waits on the real condition (server holds both seats) and its assertion is untouched ([story-quals.js:2070](quals/story-quals.js#L2070-L2079)).

Padlock/ta-da ideas

The README's queued REVEAL-button spec (padlock and 🎉 staying as passive lamps by BIDS) makes this cleaner — a lamp can be pure art. Three directions, any of which kills the platform-dependent emoji rendering:

1. Wax seal — recommended. "Sealed bidding" made literal: a small stamp-red disc with a star impression. Sealed = intact seal; all-bids-in = glowing; revealed = the seal broken in two. Auction-flavored, unique, and it echoes the VENDITUM stamp's red. Small inline SVG in currentColor/--err-fg, same mechanism as the share glyph, so it themes and grays like everything else.
2. Drawn padlock — keep the metaphor, lose the emoji: an SVG lock whose shackle visibly pops open at ready (a better affordance than scale-pulsing), open lock once revealed. Weakest celebration signal of the three.
3. Stamp echo for revealed — whatever marks sealed, the revealed lamp becomes a tiny askew red stamped mark echoing the big ceremony stamp. Pairs with either of the above.

The tab-title glyphs in [stringles.js:61](stringles.js#L61-L64) (🔒⭐🔓🎉) stay text either way — titles can't render SVG — and emoji are conventional there.

Which direction should the lamp take — and should it ride along with the REVEAL-button work from the README queue, or land first on its own?

Option 2 (drawn padlock, shackle animates open) plus the full REVEAL-button spec. Surveying every touchpoint of the current seal button first.

Reveal-button implementation begins. Checking how button labels get stamped from stringles.

Red quals first — the new-shape section in frontend-quals.

Red confirmed. Implementing across all four files.

Now app.js — the control machinery moves to the button.

The button label stamp in wireUp, then the CSS.

The coarse-pointer block and reduced-motion list still reference the old button. Fixing both.

Updating the now-stale stringles comments and checking the revealedLabel block.

Bulk re-pointing the control-verb patterns, then hand-checking survivors.

Prose accuracy fixes in the re-pointed sections.

Applying the full story-quals rewrite for the new shape.

Running all four suites in parallel to walk the remaining failures.

gas and serve are green; frontend and story are still running with the REVEAL-button changes. The blurbver swap is scoped (25 qual sites, both runtimes) and queued behind those results — mid-run edits would poison the loads.

Story green (217). Waiting on frontend.

Rewriting the gas describe-quals to the counter contract (the reds). First the full tblurb inventory in gas-quals.

Red confirmed. Now the server swap in Code.gs.

gas green (196). Now the client. Reading the blurb-machinery regions.

Adding the strictness pin to gas-quals, then the full chain.

Full suite is running (~10+ minutes with both browser suites). It covers the REVEAL button, the drawn lamp, and the blurbver protocol end to end; its screenshots will serve for the visual check. Summary comes when it lands.

Sweep clean — no other citations of the retired no-tip law, and editDescLabel is fully gone. Waiting on the three suites.

Reproducing the 320px failure with a leg-by-leg probe.

The isolated probe passes every leg, so the failure is state-dependent. Reading the story's state above the assert.

Probe confirms the fix (parked tip re-fits, right edge 271 < 320). Running the story suite properly.

Two runs in flight: the story suite with named-leg diagnostics (the 320px assert sits early, so the culprit leg will be identified even if the run continues on), and the frontend/gas/serve chain re-verifying against current bytes.

Story re-running with the refit wait; the frontend/gas/serve chain is still going. Results will drive the final wrap-up.

Story suite re-running with the focus-drop staging. If green, the wrap-up follows.

Story suite re-running. On green: screenshot eyeball, then the full wrap-up.

The memory file is a long chronological log. Inserting today's entry at the top of the status log.

Both specs shipped. All four suites green: 198 + 582 + 9 + 218 = 1,007 assertions, at v2026.07.30-i, 404 synced.

The REVEAL button (+ option 2 lamp)

Per the spec: a full-width REVEAL! button sits under the ledger ([index.html:130](index.html#L130-L136), copy in [stringles.js](stringles.js) verbatim) — grayed while the auction waits on anyone, accent-filled and glow-pulsing when armed, and replaced by the "Closed 2026-07-30 …" stamp once thrown (same slot; the CSS swap rides #status.revealed). Every padlock tooltip transferred to it, including the resting unnamed-page tip. The padlock beside BIDS is now a passive drawn lamp — inline SVG shackle/body/keyhole in currentColor, no clicks, no tips, no tab stop — and the shackle swings open at the strike beat (it holds shut through the ceremony wind-up, same as the old 🔒→🎉 flip). Screenshots verify both states. The "go crazy with an image" clause was deliberately left out for now — the spec itself second-guessed Lady Justice; art can ride a later pass.

Qual accounting, disclosed: ~60 control asserts re-pointed from #seal to #reveal (meaning preserved; the control moved); the emoji-alpha armor quals (UA sheets washing color-emoji on disabled buttons) retired because their subject — an emoji-bearing disabled button — no longer exists, replaced by shackle-state and glow-is-shadow-only fences; the keyboard-reveal qual now pins "Enter closes the auction" instead of focus retention, since the pressed control retires itself by design.

blurbver — and the architecture answer

Yes, it simplifies, and yes, a counter works strictly better than the timestamp. The old token was toISOString() + '/' + random tail — the code itself admitted "the token is for CAS identity, not chronology," with the random tail bolted on to dodge same-millisecond collisions. A counter incremented under the script lock cannot collide by construction, never consults a clock (this codebase already distrusts wall clocks — see the writeSeq comment), and the number is user-meaningful where the stamp never was: it IS the pencil's tooltip. The frozen-clock gas qual now proves CAS identity with Date.now() pinned — something the timestamp scheme could only pass via its random tail.

Shipped: auctions column 6 tblurb → blurbver (0 = never described, born explicitly, '' cells refuse as corruption), the CAS compares integers, refusals still carry the full snapshot for the war diff, and the pencil wears "Auction description, version N" — which supersedes the recorded 07-17 no-pencil-tip ruling, so that qual flipped accordingly. One anti-postel tightening to flag: '' is no longer accepted as a spelling of the virgin base (it would coerce to 0 silently); the only virgin is the number 0.

Deploy note: this is a schema change — npm run deploy will fail its live smoke with delete-the-auctions-tab marching orders until the tab is deleted (the drift armor working as designed). Code.gs is edited but not deployed.

Found along the way

The new pencil tooltip exposed a real pre-existing bug: a focus-parked tooltip survived viewport changes at stale coordinates, poking past the edge and opening a sideways scroll. Fixed structurally — the tip painter re-runs on window resize ([app.js:281](app.js#L281-L285)), no conditionals added. Two story-qual races were also repaired with their waits now tracking their real conditions (the async tip refit; the flying-bid aloft paint vs. the settle) — assertions untouched, and the 320px qual now names its failing leg and the overflowing element instead of a bare boolean.

New conditional inventory for the whole batch, per anti-magic: zero new if-statements in the reveal work (the button inherits the seal's existing logic wholesale); blurbver adds one corruption throw in getState and the ''-refusal in describe — both refusals, not branches in behavior.

The cause: the star rides #status.unclaimed, and that class is painted only by renderStatus — which never runs on an unnamed page (render() bails while state is null). The hint's absence is an artifact of "no render before a name," not a decision. There is a fix in the simplifying direction: declare unclaimed as the section's birth state in the HTML (the .desc.viewing precedent — "the birth state"), so the resting truth is static and the render's existing toggle merely corrects it. Zero new code paths, one attribute; and it actually restores the grayed-never-suppressed law — today the hint is *suppressed* pre-name while the rest of the section is properly just dimmed. Checking for contrary pins first.

Awaiting the red. The fix itself is staged: one birth-state attribute on the status section.

Both browser suites are running in parallel; gas and serve are untouched by an HTML class (the 404 copy is synced). Results will close this out.

Frontend re-running. The nitpick's answer is already settled pending this green — summary on landing.

Fixed, and by the requested method. All suites green (frontend 583, story 218; gas/serve untouched by an HTML class).

Why it happened: the hint rides #status.unclaimed, and that class was only ever painted by renderStatus — which never runs on an unnamed page (render() bails while no snapshot exists). The star's absence was an artifact of "no render before a name," not a decision.

The fix is one attribute, no code: unclaimed is now the section's birth state in [index.html:94](index.html#L94-L98), exactly the .desc.viewing precedent ("the birth state"). Every render's existing toggle keeps it truthful from there — claimed pages shed it on their first paint, before the browser ever shows a frame. No if-statements added or removed; the conditional asymmetry (renders may grant the class but nothing declares its resting value) is what died. It also restores the grayed-never-suppressed law: pre-fix the hint was the one piece of the unnamed section being *suppressed* while everything around it was merely dimmed.

Red qual first as always: the new pin ([frontend-quals.js](quals/frontend-quals.js), in the REVEAL section) asserts an unnamed page is born unclaimed, confirmed failing before the attribute landed. The mid-run 404-copy failure earlier was an artifact of the version edit landing during a suite run; current bytes are in sync and green.

Four threads: (1) a live-shaped realistic story qual, (2) instant submit feedback, (3) optimistic pencil version, (4) the war's round-trip lag — with 3 and 4 gated on simplification, and 4 inviting a rethink. Reading the bid-commit machinery first to see what the baselines currently do.

The wireUp born-base pair collapses into the setter too.

While frontend runs, the live-wire story. Finding the suite's tail to append before the final checks.

The optimistic tip now outruns the qual's old wait — the pencil says 1 at the click while the server hasn't settled yet. The wait must track the settle separately.

Both suites running in parallel — frontend with the fixed wait, story with the new live-wire journey. Summary when they land.

Both suites re-running. Wrap-up on their results.

Story green — 226, including all eight live-wire beats on the first full run. Awaiting frontend.

Frontend re-running with the keystroke events supplied. Final tally on landing.

All four items landed. Suites green: 198 + 592 + 9 + 226 = 1,025 assertions, 404 in sync.

Realistic quals. The story suite gained the live-wire story ([story-quals.js](quals/story-quals.js), before the closing net): two real Chrome contexts on one auction at live-shaped latency (1.2s per call), doing exactly what the chrome-plus-firefox test does — simultaneous adds inside the arrival gray, bids crossing between browsers, a two-round blurb edit-war, and a reveal one browser fires while the other converges. Eight beats, each asserting the busy signs and convergence. Your "maybe never mind" sighting stays unreproduced, but this story is the net that regime was missing; if it recurs on stable bytes, the console chronicle plus a description will pin it.

Submit feedback — the button goes away immediately. This turned out to be a genuine simplification: syncHot computed two different baselines — the row's hotness rode defaultValue (moves at settle) while the button's liveness already rode the volley's in-flight text. They are now one effective baseline ([app.js:531](app.js#L531-L547)): at the press the field matches what is flying, so the row closes and SUBMIT vanishes on the spot; the away-tint carries "not yet confirmed"; typing again reopens it. Down-to-the-wire revision still works, pinned by qual.

Optimistic blurb version. The counter's whole beauty is that the next version is knowable at SAVE — base+1, minted under the same lock that serializes saves — so the pencil now says it at the click, exactly as defaultValue already moved at the click. One new setter, setBlurbBase ([app.js](app.js)), makes the CAS base and the pencil tooltip a single fact that cannot drift; the success settle now does nothing (the click already staked the claim), and a refusal voids the claim only while it is still the newest — a compare-and-restore, the CAS discipline applied to the client's own optimism. The suite caught that last rule being necessary: without it, a stale refusal left a dead claim standing and the next save silently won an edit war its author never saw.

The war's full second. Optimistic writes were not the culprit — the verdict's round trip was. When a poll has already delivered a foreign version, the conflict is knowable locally, so SAVE now refuses before the wire in the server's exact words (your simulEditsBanner, un-commented and re-pinned against Code.gs verbatim) and the war paints "theirs" from the state in hand: dialog and diff up synchronously, nothing sent, no loading gavel. The server's CAS remains the backstop for sub-poll races, where the round trip is irreducible — the information simply doesn't exist client-side yet. Disclosed if-inventory for the whole batch: that one pre-check in commitDesc, plus the compare-and-restore guard on the claim walk-back.

The armed button's "Reveal bids" tip duplicates its own label. Inventorying every revealTip reference before the flip.

Both suites running. The story's only armed-button tip consumers were checked — the banner scene runs on an unnamed page (resting tip) and the audits read geometry and text, not tips.

Done. All suites green: 198 + 592 + 9 + 226 = 1,025 assertions, 404 in sync.

The tip now explains the GRAY, nothing else ([app.js:1058](app.js#L1058-L1070)): an armed button sheds its tooltip — REVEAL! is its own offer — and the gray states keep theirs (need-a-name, need-two, need-one-more, waiting-on-the-straggler). The revealTip constant left stringles with its job; the ternary lost a leg rather than gaining one.

One real defect surfaced by the change and fixed with it: setTip stamps aria-label alongside data-tip, and the old code stripped only the tip — so an armed (and revealed) button kept a stale spoken name like "Waiting for bo to bid…" overriding its visible label. Both attributes now go together, and the visible REVEAL! is the accessible name, pinned by qual.

The tip-vanishes-while-parked qual moved with the semantics: its replicata is now "park on the *waiting* button, the last bid lands from elsewhere, the button arms" — the open tip vanishes at the arming instead of lingering as an empty bubble, same law, truer trigger.

Ideas, noting the pair shares a slot so the voice should match. The mechanics are free either way — both live as single constants in [stringles.js](stringles.js) (stampCopy, consensusStamp) and the quals derive from them, so picking is a two-line edit.

For SOLD (the reveal verdict):

• GONE! — auctioneer's patter, short and punchy; the gavel strike lands the word the hammer actually says.
• GOING, GONE! — the fuller patter; could even land in two beats with the ceremony's windup and strike.
• UNSEALED! — semantically truest: the help copy says most uses aren't sales at all (estimates, Schelling games), and this matches the padlock-and-seal vocabulary rather than commerce.
• VENDITUM — the Latin route, matching the noli-spectare decoy's register.
• TA-DA! — the retired 🎉's word, resurrected as ink.

For CONSENSUS (all bids identical):

• JINX! — the schoolyard word for saying the same thing at the same moment. Exactly the semantics, maximally cute.
• GREAT MINDS! — the proverb, self-completing.
• MIND MELD! / TELEPATHY! — the spookier flavor.
• SNAP! — the matching-cards call.
• SCHELLING! — the insider pick; the help copy already cites him, so the joke has a footnote.

Recommended pair: GONE! / JINX! — both one-breath schoolyard-adjacent exclamations, and JINX is hard to beat for the identical-bids moment. If the non-auction uses argue against patter, UNSEALED! / GREAT MINDS! is the semantically clean pair. A side benefit either way: every candidate is shorter than CONSENSUS, so the stamp's slimmed-down 9-letter font-size special case in [style.css](style.css) could retire with the rename.

Locating how the qual harness extracts these copy constants and how deviceOf/load work, to pick the right source for the uname.

Rewrapping that comment cleanly:

Done. bidSeatHeldCopy now takes (blurb, uname) and reads exactly Someone else ($blurb) already placed a bid as $uname! — the constant at [Code.gs:88-91](apps-script/Code.gs#L88-L91), with the throw site ([Code.gs:731](apps-script/Code.gs#L731)) passing the uname the bid came in under. Suite 1025 = 198+592+9+226, twice green.

Notes:

• The ERROR1312: prefix is gone, since the specified copy had none — matching the plain-sentence refusal style (Womp Womp, That name is taken, …). Nothing client-side keyed on it; app.js banners the server string verbatim. The one consumer was the deviceless-bid gas qual's includes('ERROR1312'), which now exact-matches the copy instead.
• QDD detail: the red-first pins are literal includes('ann') / includes('ben') checks in [gas-quals.js:531-546](quals/gas-quals.js#L531-L546), not just exact matches — COPY derives from Code.gs, so an exact match alone would stay green even if the function ignored its new uname argument.
• One semantic flag, not fixed: this refusal also fires when the holder merely claimed (starred) the seat without bidding, and the copy says "already placed a bid" in that case too.
• Server-side only, so it goes live with the next npm run deploy (copy change, no tab dance).
• The first suite run failed the 404-byte-copy qual against the uncommitted index.html edits; npm run sync-404 was run per that qual's own instructions, so 404.html now carries those edits too.

This is a real architecture change (the server currently throws finished English and the client banners it verbatim, with mirrored copy blocks and cross-runtime pins holding it together), so Fable will survey the error plumbing and present a plan before rewiring.

Surveying the error plumbing inline — stringles, the Code.gs throw/catch machinery, and every client/qual consumer of server error strings.

The full inventory is in hand. One scope decision genuinely needs dreev's ruling before the plan is final:

Reading the remaining Code.gs sections to enumerate every refusal site precisely before converting.

Step 2: the red quals. Viewing the frontend cross-pin section and extraction blocks to replace them:

Now the throw sites, the catch, and the two return sites:

Gas suite green. Now the app.js decoder — checking the assert helper and banner() neighborhood:

Now the story-quals SCOPY flips — checking all uses:

Now live-quals — the ERROR1306 check and its context:

Full suite, twice:

Twice-green: 1021 = 198+588+9+226. Now the bookkeeping — checking AGENTS.md's agent-maintained section for stale mirror-block references:

Done — universal, on the refusal-vs-assert line, twice-green: 1021 = 198+588+9+226.

What shipped. Code.gs now throws every deliberate refusal as { code, ...args } — 24 codes, from gavelFell to bidSeatHeld (which carries blurb and uname) — and its mirrored microcopy block is gone. The words live once, in [stringles.js](stringles.js)'s new refusalCopy table (existing banner consts like nameTakenBanner absorbed their codes; the rest moved byte-exact). [app.js](app.js)'s refusalText() decodes at the four server-error display sites, with the one disclosed branch: no .code means it's already finished text — an assert-family diagnostic or an old server — shown verbatim. The assert family (schemaDrift, covenant, patchGhost, armorFull, two inline corruption throws) stays English in Code.gs, so deploy.js's marching orders still read raw in a terminal. The ERROR13xx numbers died; the codes are the grep handles now. The mystery-device fallback moved client-side, joining its tooltip twin.

The pins are structural now. The six verbatim cross-runtime pins were replaced by one weld qual in frontend-quals: it regexes Code.gs for every code: '…' and pins set-equality with refusalCopy's keys, both directions — a new server refusal without client copy fails the suite, as does orphaned copy. Gas quals assert codes (plus args, e.g. bidSeatHeld's), witnessed red before the server change landed.

Bonus bug the rework exposed. The gas armor qual fills the bids tab to its 10,000-row limit and left it full, so every later fixture's bid silently bounced off armorFull — the ghost-row qual had been passing vacuously on a notReady string instead of the patchGhost refusal it was written to pin. The ballast is now drained (with a memo reset) after the armor section, and the ghost-row qual exact-matches patchGhostCopy('auctions').

Deploy caveat, dreev's move: the old published client renders object errors as [object Object], so npm run deploy and the frontend push must land the same sitting. live-quals' notYourSeat code check goes green only against the new Code.gs — deploy runs the offline suites first, as always.

AGENTS.md's copy-architecture paragraphs and the project memory are updated to match.

Re-verifying the claims skeptically — sweeping Code.gs for any English that escaped the classification (throws, error fields, and anything written where users can read it, like the sheet's cheater banner):

stringles.js changed on disk — reading the current tail to work from the live version:

No — three flaws surfaced in the audit, all now corrected, and the load-bearing claims survived re-verification.

What was wrong:

1. "The only English left in Code.gs is the assert-family diagnostics" — false. Code.gs generates two more English strings, both off the error channel and untouched by the rework: the bids tab's cheater banner (TAB_WARNINGS, [Code.gs:192](apps-script/Code.gs#L192), written into the link-visible sheet — inherently server-side, since stringles can't reach the sheet) and the root liveness response ([Code.gs:108](apps-script/Code.gs#L108)). The Code.gs header comment and AGENTS.md now say "the error channel's only English" and name the two exceptions.
2. "The story suite exercises decoded copy in real Chrome" — imprecise. The only banner-text assert in real-Chrome stories is the *local* bidTooLong refusal. Decoded *server* refusals are pinned in the jsdom frontend suite (real app.js + real Code.gs round trip) — which is the right home, since honest UI can't reach most server refusals without staged races. Memory records the distinction.
3. Three stale comments in stringles still described the dead verbatim-match pins ("a qual pins the verbatim match") — de-staled, copy values untouched.

What held up, re-verified: every throw/error: site in Code.gs re-swept — all 24 deliberate refusals are code objects, the six assert-family throws are strings, nothing unclassified; the weld qual's set-equality is genuinely bidirectional; and the full suite is green over the current file state, 1021 = 198+588+9+226 — including the current stringles values, whose recent ERROR15xx-prefix and notYourSeat rewording rode through with zero qual churn, which is exactly the property the rework was for. The deploy caveat stands: Code.gs deploy and frontend push must land the same sitting.

Three workstreams. Reading deploy.js and fake-gas's service stubs first to wire sync-404 correctly and see how to elicit badJson through the real doPost:

Adding the assert-family sibling: a string ledger plus a suite-end registry qual — red first, then the two missing elicitors:

Detector fires both ways. Wiring it into the frontend weld block:

All three landed, twice-green: 1028 = 204+589+9+226.

1. sync-404 and deploy. It wasn't part of npm run deploy; now it is — [deploy.js](deploy.js) runs npm run sync-404 before its qual gate, on the logic that deploying is a build and builds re-derive artifacts. It is deliberately *not* in npm run quals: the first attempt there tripped an existing pin at [serve-quals.js:28](quals/serve-quals.js#L28) — "the qual command audits index/404 parity without rewriting the artifact it is meant to inspect" — a standing ruling that also explains why the old memory note claiming quals-head auto-sync never matched reality. The pin was honored, not loosened. Direct node quals/... runs still fail loudly on a stale 404.html with sync-404 marching orders.

2. The stringles split. The 24 refusals now live in two tables, spread-merged into refusalCopy so the decoder and weld see one vocabulary: gameRefusals (8 an honest user can hit — the four length limits, nameTaken, simulEdits, gavelFell, bidSeatHeld) and plumbingRefusals (16, following the ERROR1509–1524 classification already in the file exactly — hand-rolled requests, broken or skewed clients). The class names are vetoable one-word renames. The truly corruption-class errors stay out of stringles entirely, as Code.gs assert strings. A new frontend pin makes the convention structural: every plumbing entry must render with an ERROR\d{4}: prefix and no game entry may — so reclassifying a refusal means moving it between tables, on purpose. The detector was verified to fire in both misclassification directions before wiring in.

3. Systematic error-message coverage, closed by construction. Three chokepoints now cover every message:

• Gas qual 19: a ledger in call()/code() records every refusal code observed, and suite-end demands it cover every code: '…' in Code.gs. Its red run found exactly two unprovoked refusals — badJson and releaseNeedsDevice — both now elicited, badJson through the real doPost.
• Gas qual 20: the same for the assert family — the 7 non-code throw sites are pinned by count, each registered by a distinctive substring that must appear in a provoked error. Its red run found blurbver corrupt and patch: field not in had never been elicited (and the covenant qual bypassed the ledger); all three fixed.
• The frontend weld additionally renders all 24 copy entries from a stub error, so a crashing or empty copy function fails the suite.

AGENTS.md's serve/deploy/stringles paragraphs and the project memory record all of it. The deploy caveat from earlier still stands: the code-refusals server and frontend need to ship the same sitting.

Two-part feature — an icon swap plus a new editing-presence signal that needs server support (the server currently has no idea who's editing the blurb). The presence half means a new action, auctions-tab columns, TTL semantics, and the freeze-doctrine classification, so planning first.

Reading the current pencil implementation and the blurb-editor lifecycle, and loading WebFetch to get the exact Discourse/Font-Awesome pencil SVG:

Starting with Part 1 — reading the desc card markup:

Part 2, red-first. Viewing the describe-qual region and the Date-mock pattern to write the presence quals:

DEVICE, mypid(), renderDesc() — noted. Now the server:

stringles copy, then a look at the two-window idioms in frontend-quals before writing the red qual:

Red witnessed (the first presence until times out). Implementing the client:

Frontend 595 green. Now the story scene — checking the story suite's page idioms:

Both desc-editor idioms and the anchor found. Writing the story scene:

Story 1 pins the pencil's presence via textContent.length — an SVG has none. Flipping the probe to the svg child:

Story 229 green. Eyeballing the two new screenshots before the full runs:

Both shipped, twice-green: 1045 = 212+595+9+229, screenshots eyeballed.

The pencil. Discourse's edit icon is Font Awesome's solid pencil (FA5 name pencil-alt); the FA6 SVG is vendored inline in [index.html](index.html) with its CC-BY license comment, fill="currentColor" so every existing ink state (muted, hover accent, unnamed-gray) works unchanged, at 1.3rem versus the old 1.15rem font glyph. The empty-state "Describe this auction... 🖉" composition scales it via font-size as before. One story pin flipped: it verified the pencil via textContent, which an SVG doesn't have — now it probes for the svg child.

Editing presence. While a blurb editor is open, the client heartbeats a new editing action every 10s (immediate first beat, beats skipped while the tab is hidden); the auctions row holds one editor slot — tedit, editorPid, editorDevice, editorBlurb — and getState serves editor while the last beat is under the 25s TTL, both stamps on the server's clock. Other pages' pencils then scribble (accent ink + gentle rock about the tip) and the tooltip reads Auction description (v3) — currently being edited by dalia — the seat's uname by rename-proof lookup, else someone (device blurb) with the mystery-device fallback. SAVE and DISCARD send the stop; a closed tab just ages out.

Disclosed conditionals, per anti-magic: a virgin auction takes no presence (an editor-open is not a commitment — the mutlessvirgin law; the sheet stays untouched); a stop clears only the caller's own slot (a raced DISCARD can't erase a live rival); the beat timer is reconciled from .desc's own .viewing class by one owner (syncEditBeats, called at open/DISCARD/SAVE/war-reopen, with an aname gate so a keyboard-opened editor on the unnamed page pings nowhere); and own presence — matching pid or device — never scribbles at itself.

Qual coverage, red-first throughout: gas grew presence quals (seated, walk-in, foreign-stop, TTL-expiry via clock mock, post-close) with editing classified OPEN in the freeze doctrine; frontend runs a real two-window heartbeat/scribble/stop flow; the story suite drives dalia-edits-eric-sees in real Chrome, asserting the live scribble animation and tooltip, with [story-scribbling-pencil.png](quals/screenshots/story-scribbling-pencil.png) and [story-pencil-discourse.png](quals/screenshots/story-pencil-discourse.png) for eyeballing.

Deploy: the schema change rides the auctions-tab deletion the undeployed blurbver change already owes — one tab dance covers both — and the server/frontend same-sitting rule from the codes rework still applies. AGENTS.md's data-model table (which was also stale on tblurb→blurbver) and the Behavior section are updated.

Not entirely, no. A re-audit of every conditional the feature added finds most of them trace to standing laws, one that violates the principle by the codebase's own standard, and one unfenced code path. Findings, then the clean list.

Finding 1 — the aname gate in syncEditBeats is an if-statement papering over a state that shouldn't exist. The unnamed page's pencil is grayed by pointer-events: none — pointer-only — so a keyboard user can still activate it and open an editor for an auction that doesn't exist. That state predates presence (SAVE there already banners badAname), and the gate just mutes one more symptom of it. The anti-magic fix is to make the state unrepresentable: disable the pencil on unnamed pages, which is the house pattern already used for stars and ×s (gray = the disabled attribute, not pointer-events), kills the CSS pointer-events hack, deletes the gate, and closes the pre-existing SAVE-banners-nonsense hole with it. That changes unnamed-page behavior slightly (a keyboard-opened editor stops being possible at all), so it's flagged rather than done.

Finding 2 — the war-reopen beat restart is unfenced. syncEditBeats is called at four flip sites; the frontend 2r qual exercises open, DISCARD, and SAVE, but every 'editing' reference in the suite sits inside 2r ([frontend-quals.js:3461-3523](quals/frontend-quals.js#L3461-L3523)) — nothing drives the CAS-bounce path. Delete the call at [app.js:920](app.js#L920) and the suite stays green, while a real user's presence would silently expire mid-war. Wants a fence qual.

The branches that survive interrogation, and why:

• Beat takes, stop is holder-only — the same asymmetric physics as claim/release: claiming a seat takes it last-write-wins, releasing is holder-guarded. Presence is claims for the desk.
• A foreign stop quietly no-ops rather than refusing — precedented by the documented "releasing an unheld seat is a no-op" ruling, and the race that produces it (two editors overlapping) is normal, unlike release's can't-happen notYourSeat.
• The virgin no-op — the two alternatives are worse: minting an auctions row from an ephemeral ping violates virgin-stays-virgin, and refusing loudly banners an error at someone who merely opened an editor. The returned state still tells the truth (no editor).
• The hidden-tab beat skip honors the existing hidden-tab traffic ruling rather than adding policy.
• The two ifs in the reconciler are edge-triggering around one boolean read from the DOM's own .viewing class — the alternative was start/stop calls scattered per site, which is more branches, spread wider.
• mine's two legs (pid match guarded against the double-blank '', or device match) are forced by using '' as the unseated sentinel; the seat-vs-someoneOn ternary is dreev's copy spec itself.

One deliberate infidelity to disclose: mockFetch classifies editing as a read, not a write — putting it in WRITES would make drained() flicker with every 10s beat and destabilize half the suite's waits. The mock's "reads snapshot at request time" semantic is therefore slightly wrong for beats; the real server takes them under the lock.

Recommendation: do Finding 1 (disabled pencil, delete the gate and the pointer-events rule) and add Finding 2's fence qual. Both on request.

Both fixes, QDD order: red quals first. Finding the unnamed class owner and any quals touching the unnamed pencil:

Twice-green: 1049 = 212+599+9+229. Correcting the memory entry that recorded the now-deleted gate:

Both audit fixes landed, twice-green: 1049 = 212+599+9+229.

Finding 1 fixed — the gate is gone. The unnamed page's pencil is now disabled outright, synced at the two places body.unnamed is decided (init at [app.js:2586](app.js#L2586), and the name-commit wake beside share's identical enable at [app.js:2277](app.js#L2277)); the CSS pointer-events hack became a plain .desctoggle:disabled gray. With the editor-without-an-auction state unrepresentable, syncEditBeats lost its aname gate — one fewer branch, and the pre-existing hole where a keyboard user could open the editor and SAVE into a badAname banner closed with it. New qual 2s fences all of it: pencil disabled on the unnamed page, a click opening nothing and pinging nothing, and the commit-wake re-enabling it.

Finding 2 fenced. 2r now drives the real server-CAS bounce — rival save injected sub-poll with no await before the SAVE click, so the local verdict can't steal the path — and asserts the reopened editor's heartbeat resumes. The fence was red-verified by mutation: with the war-reopen syncEditBeats() call temporarily deleted, it went red by name; restored, green.

The audit's keepers stand as defended: beat-takes/stop-is-holder-only mirrors claim/release physics, the foreign-stop quiet no-op rides the documented unheld-release precedent, the virgin no-op beats both alternatives, and the hidden-tab skip honors the standing traffic ruling. The memory file records the fixes and the defenses.

Three questions — the design alternative and two monkeywrenches. The third is checkable against the actual Overwrite path, so reading the war handlers before answering:

No — the simpler design deletes the one part that makes "currently" true, and both monkeywrenches have clean answers (the second is already fenced by a qual).

The simpler design. It's the shipped design minus the lease: open-takes-the-slot and holder-only-null-on-SAVE/DISCARD are identical in both. What the missing heartbeat+TTL costs is two ways the pencil lies:

1. *The closed tab.* The dominant real exit from an editor isn't SAVE or DISCARD — it's closing the tab, phone sleep, dead wifi. With nothing but a nullable slot, that editor scribbles everyone's pencil forever, until someone else happens to open the editor. A presence indicator that's often stale-forever poisons the signal. The TTL exists solely for this.
2. *The displaced-but-live editor.* The "they'll get a collision warning so they don't count" assumption breaks in the common overlap: A opens, B opens (takes the slot), B saves → slot nulled — while A still has an open editor and is typing right now. The pencil's question is "is someone at the desk *now*," and A is; A's warning only comes later, at SAVE, and after the war A may insist and keep editing. Under the lease, A's next beat (≤10s) retakes the slot and the signal self-heals; under the nullable slot it just rests, wrongly.

The delta is small — one 10s interval client-side, one timestamp and one freshness ternary server-side — and it buys liveness, which no open/close bookkeeping can provide. (The honest no-heartbeat middle ground — stamp at open, long TTL like 5 minutes — trades both problems down rather than away: the pencil lies for minutes after abandonment and dies mid-composition on a long edit. Not recommended.)

Identity or device? Device. An editor is a browser context holding an open textarea; pids don't type. The shipped slot is keyed by editorDevice for all mechanics (take, stop-guard), and editorPid rides along purely as display decoration so the tooltip can say a human name. The one place identity leaks into mechanics is the own-suppression's pid leg: your phone's editing doesn't scribble your laptop's pencil. That's arguably wrong — same-human-two-devices self-collision is real (the faire incident was exactly that class), and your laptop scribbling "being edited by dalia" while your phone edits is *true and useful*. Deleting that leg would be one fewer condition and more honest. On request.

The stale-diff overwrite. Can't happen, by construction:

• Overwrite is not a force-write. The handler re-bases on state.blurbver — [app.js:2392](app.js#L2392), "informed now" — and rides the normal commitDesc into the server's compare-and-swap. In your scenario, the diff showed v2, P3 made it v3, so Overwrite flies with base 2, the CAS refuses, and the war reopens as take 2 with a fresh diff against v3. P3's changes are never touched unseen. That exact shape is pinned: [frontend-quals.js:4155-4164](quals/frontend-quals.js#L4155-L4164), "insisting bounces again as TAKE 2."
• The diff and the base cannot disagree, because both are derived from the same state: paintWar draws theirs from state.blurb keyed on state.blurbver ([app.js:883-886](app.js#L883-L886)) and rebuilds live as snapshots land, and Overwrite reads the same object at click time. The refusal itself carries a snapshot minted under the server's write lock, so "theirs" is never guessy.
• The residual window is perceptual, not mechanical: a poll could repaint the diff to v3 in the instant before your click, so you commit against words you eyeballed a moment ago. That's the button-moving-under-the-cursor class, sub-second, and the alternative — freezing the diff and basing on the frozen version — would only refuse more often, never clobber more.

Net: no change recommended to the presence design; the one offerable simplification from this round is dropping the pid leg of own-suppression.

A regression report — first, replicate: reading the current mdRender and probing it with headers and lists.

The fuzz battery's whitelist and coverage floor will need H4-H6 too. Viewing the floor, then writing the red quals:

Twice-green: 1053 = 212+603+9+229. Recording the markdown fix, then the devices-table question:

Markdown is fixed — twice-green, 1053 = 212+603+9+229. It wasn't a regression: mdRender was always *blank-line-block atomic* — a heading only counted as a solo block and a list only if every line of its block was a bullet — so normally-typed markdown (# Rules directly atop its bullets) fell through to one literal paragraph. The early blurbs and quals happened to have blank lines around everything, which is why it ever looked like it worked. The renderer is now line-wise: each line classified once (blank/heading/rule/bullet/numbered/quote/plain), consecutive same-kind lines grouped into one element, blank lines only separating paragraphs — which is *less* code-path machinery than the old every()-based block logic, not more. Headings extended from #–### to the full #–###### ladder (the 1–3 cap was arbitrary; ZOI), with matching .descview sizes. The escape-first XSS posture is untouched and the 500-round fuzz battery — its whitelist and coverage floor now including h4–h6 — stays green. New quals pin the adjacency replicata verbatim, the heading ladder, quote/rule run edges, and the paragraph/:empty semantics.

On a devices table — assessment, nothing built:

What it would buy. The device blurb is currently snapshotted into two places (users.deviceBlurb at claim/bid, auctions.editorBlurb at heartbeat); a devices tab (deviceID, blurb) is its normalized home, and tooltips would show a rig's *current* description instead of whatever it was at claim time. The auctions table would shed editorBlurb and (mostly) editorPid — 10 columns down to 8 — and users 7 to 6. The genuinely attractive version goes further: move presence itself onto the device row (editingAname + tedit per device), which empties all four presence columns out of auctions (back to 6) and dissolves the one-editor-slot compromise — two simultaneous editors both become visible truth instead of last-heartbeat-wins.

What it would cost. Every getState grows a second tab read and a join (the budget quals pin per-action service-call counts — they'd all bump); the at-claim-time snapshot semantics die (that's a semantic choice, not just denormalization — the faire-incident forensics leaned on per-claim snapshots); and it's another schema migration, though the pending deploy's tab dance covers it.

The uname field is the part to drop regardless: "who this device last claimed to be" is cross-auction — you're alice in one auction and bob in another, so it's wrong as a display label anywhere — it duplicates the client's own relatch hint, no server logic consumes it, and on a link-visible sheet it welds all of a device's identities across every auction into one greppable row. That's a real correlation-surface regression even by honor-system standards.

Recommendation: not yet. Two denormalized blurb columns don't outweigh a join plus migration; the walk-in editor's blurb has no other home today, so editorBlurb can't shrink away without the table. The moment a third consumer of device data appears — claim tokens, a third blurb site, or an actual want for multi-editor display — the table earns itself, and the shape to build then is presence-on-the-device-row. If the multi-editor truth appeals now rather than later, say so and it gets built in that shape.

With a real database the question decomposes differently, because the two constraints that shaped the current answer — metered reads and no push channel — both vanish.

Devices becomes a real table, immediately. Joins are free, foreign keys exist, so the relational answer is the normalized one dreev's instinct reached for:

devices  (device_id PK, blurb, created_at)
auctions (aname PK, blurb, blurb_version, created_at, updated_at, revealed_at NULL)
seats    (aname FK, pid PK, uname, holder_device NULL FK→devices,
          created_at, updated_at, UNIQUE (aname, uname))
bids     (id PK, aname FK, pid FK→seats, bid, created_at)   -- append-only, as now

The blurb lives once and tooltips read it live; if the at-claim-time snapshot turns out to matter (the faire-incident forensics), that's an explicit choice — a claims event table — rather than an accident of denormalization. The uname column stays off devices even here: identity-per-auction is the seats table's job, a device-global name is wrong across auctions, and relational modeling doesn't cure the correlation-surface problem on public data. The client's relatch hint stays client-side.

Presence stops being data at all. That's the bigger shift. In a real stack the server holds connections (WebSocket/SSE), so "who has the editor open" is connection-scoped state in memory, pushed to subscribers — no table, no TTL, no heartbeat action, because *disconnect is the liveness signal*. The whole tedit/TTL apparatus is a reconstruction of connection-awareness on top of a stateless polling API; it's the right construction under polling and pure scaffolding the moment you have sockets. If the transport stayed polling even with Postgres behind it, presence would be a small table — (aname, device_id, last_beat_at, PK(aname, device_id)) — and note the shape: per-device *rows*, so multi-editor truth falls out and the one-slot last-write-wins compromise is revealed as a Sheets-ism (one auctions row = one slot). The TTL survives in that variant; liveness without a connection genuinely requires refresh, on any database.

The assert family becomes schema. The compare-and-swap turns into UPDATE auctions SET ... WHERE blurb_version = $base — atomic, no lock service; the closed-state covenant becomes constraints or a trigger; armor and schema drift simply cease to exist as concepts (typed columns can't reinterpret "007", migrations are ALTER TABLE). The refusal codes and stringles rendering are transport-level and carry over unchanged.

Worth saying: the codebase already banks on this future — the storage fence ("END OF THE SHEETS LAYER", mechanically enforced) exists so the swap is a one-section rewrite, and the bids log is already the event-shaped table a real database would want. So the honest summary is: dreev's devices-table instinct is the relationally correct one; it's the Sheets tax — metered reads, no joins, no FKs — that makes today's denormalized snapshots the better engineering *today*, and the presence slot is correct under polling and dissolves entirely under push.

Four, in descending order of recommendation:

1. Keep banking the fence (the current posture, named). The best-of-both instrument already exists: business logic that speaks World-B shapes — event-log bids, records-not-cells, refusal codes, CAS semantics — running on World-A storage behind a mechanically-enforced fence. Every design decision that keeps the logic database-shaped makes the eventual swap smaller; the fence qual is the compounding asset. This costs nothing and is most of the answer.

2. The presence tab: real-DB shape, Sheets physics. The per-device-rows insight doesn't need Postgres — a presence tab (aname, deviceID, pid, blurb, tbeat), upserted by the same heartbeat, filtered fresh at read. Buys: multi-editor truth (the one-slot last-write-wins compromise dissolves — two open editors both show), auctions back to six columns, and the walk-in blurb gets a home that isn't auctions. Keeps: the TTL and heartbeat, which are genuinely required under polling on any storage. Costs: one more tab read per state (the budget quals bump, disclosed) and a tab migration that can still ride the pending deploy's dance. This is the one concrete build available today; worth it if multi-editor display is actually wanted, not before.

3. Designate the World-B landing spot rather than drifting there. When the data starts mattering, the migration note says "a real backend with a service account" — the sharper version: something like Supabase's free tier is Postgres with FKs and CAS, a REST API callable from the static site with no server code to run, and realtime channels where presence stops being data entirely (disconnect is the signal). It naturally coincides with the parked ditch-gh-pages move (the /slug-as-200 link-preview unlock), so both migrations could be one sitting. The one real loss is the link-visible sheet as the transparency/honor-system artifact — if that's load-bearing, a one-way read-only mirror to a sheet preserves it, at the cost of sync machinery. Decision for that day, but naming the destination now keeps rule 1's banking aimed.

4. P2P presence — named and declined. Presence is semantically perfect for WebRTC (ephemeral, trust-tolerant, disconnect-is-signal, zero persistence): y-webrtc with public signaling would take presence off the sheet entirely and delete the heartbeat action. Declined because it adds a third-party runtime dependency to an app whose doctrine is one quiet catch total, its failure mode is "no presence for anyone, silently," and running it *alongside* the heartbeat as fallback would be two presence systems — worst of both worlds by construction.

Recommendation: 1 is standing policy, 2 on request, 3 as the written-down destination, 4 no.

"Banking the fence," plainly. The fence is the marked line in Code.gs — END OF THE SHEETS LAYER, [Code.gs:350](apps-script/Code.gs#L350). Above it lives everything Google-Sheets-specific: tabs, ranges, the armor, the memos. Below it, business logic is only allowed to speak in records — rows-as-objects in, rows-as-objects out — and a qual mechanically fails the suite if any Sheets vocabulary appears below the line. "Banking" meant: because of that rule, every feature added since (the bids log, presence, refusal codes) has been written in database-shaped terms without knowing or caring that a spreadsheet is underneath. So the cost of an eventual migration stays constant — rewrite the one section above the fence — instead of growing with every feature the way it would if Sheets calls were sprinkled through the app. Each new feature that lands below the fence is a deposit: work that will not have to be redone on migration day. Sloppy phrase; that's all it meant.

The cost of the clean devices-table design on Sheets. Longer reads and writes, yes, but that's the smaller half.

The metered half: load() does one getDataRange().getValues() per tab per execution, roughly 50–300ms each in real Apps Script. A devices table adds a fourth tab read to essentially every API call (the join needs it), on a baseline of three reads and 0.5–2s total — call it a 5–15% latency bump. Writes: today a claim or bid writes the seat row once, blurb included; normalized, each identity-bearing action also upserts the devices row — one extra metered write (or a read-compare-then-maybe-write branch to skip unchanged blurbs, which is its own anti-magic tax). The budget quals pin per-action service-call counts precisely because these are the costs that creep.

The bigger half: Sheets won't enforce any of the relationships the clean design creates. In Postgres, seats.holder_device → devices.device_id is a foreign key — a dangling reference is impossible, and multi-table writes are one transaction. In Sheets, that same reference is just a string in a cell that happens to match a string in another tab. An execution dying between the two writes, or a human sorting or deleting rows in the sheet, mints a new corruption species: a seat pointing at a devices row that isn't there. Every one of those has to be hand-covered the way the existing ones are — a covenant check that refuses loudly, quals for it, and delete-these-rows marching orders — because the storage layer enforces nothing. That's the pattern in general: on Sheets, normalization buys its cleanliness by converting free database guarantees into hand-rolled assert-family machinery. The denormalized snapshot isn't prettier, but a self-contained row has no references that can dangle.

Which is the whole trade in one line: the clean design's costs are real but *artificial* — they're rent paid to Sheets, not properties of the design — and they all evaporate on a real database, which is why the devices table is the right answer there and the wrong expense here.

The extra cost is an artifact of load()'s one-read-per-tab, not of the design — so fix the storage layer once, above the fence:

1. One read for the whole database. The Advanced Sheets Service (Sheets.Spreadsheets.Values.batchGet, enabled via appsscript.json) fetches every tab's values in a single call. load() switches to it; reads go from three per call to one, and a devices tab rides along free. Latency improves, the budget quals tighten. (The other route — all records in one tab with a kind column — also gets one read but wrecks armor, drift checks, and the cheater banner. No.)

1. Writes only on change. The devices row upserts at claim/bid/heartbeat only when absent or the blurb differs — the tab is already in hand from the read, so the compare is free. Steady state: zero extra writes; a write only when a device is new or its geo finally lands. (Values.batchUpdate similarly exists if multi-row writes ever need collapsing.)

1. Dangling references made unmintable. Devices-first write ordering: the referenced row lands before any seat row that points at it, so a half-dead execution leaves at worst an orphan device row (harmless), never a dangling pointer. Hand-edits remain the only path to one, and the join refuses loudly in the covenant style.

Remaining real costs: the advanced-service dependency (manifest line + a fake-gas stub), one disclosed upsert-if branch, one covenant check, and a tab dance the pending deploy already owes. The normalization itself — users and auctions each drop a blurb column — then comes free.

No strong reason not to. Three caveats, none blocking: it adds the Advanced Sheets Service to the manifest (same spreadsheets OAuth scope, so likely no re-auth, but the deploy may prompt once); the fake needs a faithful batchGet stub, with live-quals as the real-API backstop; and drift-checking becomes eager — every call verifies every tab's headers, so a drifted tab refuses immediately rather than on first touch (arguably better marching-orders behavior, but it's a change). Proceeding: reading the storage layer, budget quals, and manifest.

Red at 6/1 reads. Now the rewrite — Code.gs storage layer, fake-gas stub, manifest:

Done, twice-green: 1053 = 212+603+9+229.

load() now rides loadAll(): one Advanced-Sheets batchGet fetches every tab per execution, with the drift check done from the same payload — a state read drops from six metered reads to one, and a write-then-read action costs two. The budget quals were repinned red-first (1/0, 2/2, 2/5); tab() is write-side only now (creation + armor). Two real-API quirks are mirrored in the fake so the guard code is actually exercised: the values API trims trailing empty cells (short rows read as '') and omits values for blank sheets. The manifest enables the Sheets advanced service — same spreadsheets scope, but the first deploy after this may ask for one consent click. Drift is now checked eagerly on every tab every read, so a drifted tab announces itself on any call rather than first touch.

One side effect banked: a future devices tab now reads for free.

Running the deploy to see the actual failure (expected: the live smoke bouncing off the auctions tab's schema drift — the tab dance the blurbver and presence changes both owe — but the new advanced-service consent is also a candidate):

The offline suite now reproduces the live failure. The fix — the flush barrier in loadAll:

Deployed and green end-to-end: quals → clasp push → redeploy @103 → live smoke, 7 of 7 — the whole backlog (refusal codes, presence schema, one-read storage) is now live server-side.

Two distinct failures were behind it:

1. The flush barrier. SpreadsheetApp writes are buffered, and the advanced-service batchGet reads the backend over REST, where unflushed writes don't exist yet — so a claim vanished from its own response (a fresh-execution probe proved the write had landed; only the same-execution read missed it). Fix: SpreadsheetApp.flush() in loadAll before the batch. And the class is now caught offline: fake-gas tracks unflushed value writes and makes batchGet throw without a flush (cleared at execution boundaries, matching real Apps Script) — witnessed red, then green. This was exactly the fidelity gap flagged when the batch change shipped; live-quals did its job as the backstop.

1. Redeploy propagation. The /exec URL served the previous version for a few seconds after clasp deploy, so the deploy's own live smoke hit stale code and failed while a by-hand rerun passed. deploy.js now retries the live smoke once after 15s, with the reason printed — a real failure still fails.

The auctions tab dance evidently happened during the earlier failed attempts — the live tab is the fresh 10-column shape, blurbs reset (pre-launch, as documented).

One step remains, and it's urgent-ish: push the frontend. The live server now sends code-object refusals; the published frontend predates them and will banner [object Object] on any refusal until the current index.html/app.js/stringles.js land on Pages — the same-sitting rule from the codes rework. That's dreev's commit-and-push per the git workflow.

No — npm run deploy ships only the server half (Code.gs + manifest, via clasp; the run you started is harmless — it re-pushes the same server code and re-smokes). The frontend is served by GitHub Pages straight from the repo, so "push the frontend" means the git step, which per the house workflow is yours: commit the working tree (index.html, 404.html, app.js, stringles.js, style.css, plus the quals/deploy changes) and push to main. Pages picks it up from there — allow its ~10-minute cache on top.

The design is settled from the discussion; executing QDD-style. First the exact current write paths and the drift-qual literals that hardcode the users layout:

Now getState's join and noteEditing's slot:

Gas 218 green. Frontend and story should pass untouched — the payload shapes are identical:

The migration is one click away, and it's the manual step only dreev can do (the sheet UI):

Delete (or rename) the users tab in the gsheet — the deployed code refuses its old 7-column layout (the deviceBlurb era) and will rebuild it fresh. That's the whole dance this time:

• The devices tab births itself on first touch — nothing to do.
• The auctions tab survives untouched, by a nice accident of the append-rule: dropping editorBlurb means the tab's first 9 columns match the new schema exactly, and the leftover editorBlurb column at position 10 reads as a legal appended column. Optionally delete that column for tidiness; the code no longer sees it either way.
• Losing the users rows costs only the smoketest seat — live-quals self-seeds.

Then rerun npm run deploy (or just node quals/live-quals.js per the marching orders, since the push and redeploy already landed). Everything else is done and twice-green offline: 1059 = 218+603+9+229, with the devices semantics pinned red-first — the join serving blurbs and presence, upsert-only-on-change, blurbless claims no longer erasing a known rig (a deliberate semantics improvement over the old snapshot-blanking), cross-auction rig sharing, and a suite-end reference-integrity sweep proving no deviceID reference ever dangles. Frontend and story suites passed untouched, which was the design goal: the payload shapes are identical, so no frontend push is owed for this one.

editorPid (assuming that's the one — the presence slot's pid on auctions): it's how the busy pencil names a *seated* editor. The tooltip's "— currently being edited by dalia" comes from looking that pid up in the seats list, which survives renames; '' means a walk-in, rendered as "someone (rig)". It's *almost* derivable from editorDevice by inverting the claims map, so it's fair to ask — but there's one state where it adds truth: a locally-latched seat whose device hasn't registered a server claim yet (added by someone else, hasn't claimed or bid). That person's beats carry their pid, so the tooltip names them; the inversion would demote them to "someone (rig)". One column for correct naming in that state — kept on that basis, droppable if the demotion feels acceptable.

(The users.pid column, if that's the one meant: that's the identity itself — seats, bids, and claims all key on it, and unames are just display labels hanging off it. That one's load-bearing everywhere.)

Auctions cleanup: the live tab has a leftover editorBlurb column in position 10 that the code no longer reads (it survives the drift check as a legal appended column). Cleanup is one right-click in the sheet: delete column J, header included. Purely cosmetic — no code, no deploy, no data at risk. Deleting the whole tab instead would also work but needlessly resets blurbs and reveal stamps. The deeper cleanup — moving the whole presence slot off auctions onto per-device rows — remains the option discussed earlier; it buys multi-editor display and a six-column auctions table, on request.

Yes — the batch read already solved it. That was the quiet payoff of the one-read change: getState's presence scan would read the devices rows it's already fetching, so reads stay at exactly one batch per call, and the heartbeat's write moves from the auctions row to the device row at the same count (first beat actually drops from two writes to one, since the blurb upsert and the slot become the same row). No performance hit in either direction.

What it still costs is shape, not speed:

1. The payload goes plural. Per-device rows mean an auction can have several fresh editors, so editor becomes editors: [...] — client changes, qual churn, and one genuine copy decision that's dreev's: what the pencil tooltip says when two people are at the desk.
2. One slot per device, not per auction. The same browser editing two auctions' blurbs in two tabs would hold only its latest slot — trading away a case inside the already-documented two-tabs-one-device blind spot (and gaining the much more real case: two *people* editing one blurb, both visible).
3. A small migration, mostly free. Auctions shrinks to six columns with no tab dance — the dropped presence columns become legal appended leftovers, same as editorBlurb did. The devices tab gains the slot columns (editingAname, editingPid, tedit), which does mean recreating that tab, but it's a day old.

So: performance-free since this morning, and the remaining price is the multi-editor feature work it unlocks. Buildable on a go — the plural-tooltip copy being the one input needed.

Building it. Gas quals first — 18c rewritten for the editors crowd, the dissolved virgin case, the one-slot-per-device trade, and the integrity sweep losing its auctions leg:

Crash-red as expected. The server:

Both runs green. Applying the audit fixes:

The rename-retitle pin in frontend 2r:

While that runs — AGENTS bookkeeping (not read by quals):

Suite running in the background (two full passes); the completion notification will trigger the deploy and the migration walkthrough. Everything else — code, quals, AGENTS, memory — is done.

Twice-green (1064 = 221+605+9+229); deploy running in the background. It will end with drift marching orders naming the devices tab — that's expected and is your one migration step, walkthrough on completion.

One click left, and it's urgent: the live API is refusing every call right now (eager drift check) with exactly the expected marching orders.

Migration walkthrough:

1. Open the gsheet, delete the devices tab (it's the day-old 4-column version; only smoke-test rig rows die). The script rebuilds it 7-column on the next call.
2. That's all — users you already did, and auctions never needed a dance: its dropped presence columns read as legal appended leftovers (optionally delete columns G–J for tidiness).
3. Then node quals/live-quals.js to confirm, or npm run deploy for the full gate.
4. Still owed, unchanged: the frontend git-push (the live server now sends editors; the published old client just shows no presence until then — degraded, not broken — but the codes-era [object Object] gap still applies).

Audit results (applied, twice-green 1064 = 221+605+9+229): a device-less editing beat silently no-opped where claim/release refuse loudly — now editingNeedsDevice (ERROR1525); touchDevice returns its row index, deleting noteEditing's second scan and a redundant assertRoom (insert already checks armor); new pins: rename retitles the presence tip live, the plural-editors tip, the virgin-presence and one-slot-per-device trades, and a suite-end sweep proving no deviceID reference ever dangles. Per-device rows also *deleted* two special cases outright: the virgin-auction guard and the foreign-stop guard (structurally impossible now).

Your copy TODO is in [stringles.js](stringles.js) at editingByMany — the plural tooltip, currently Latin.

Yes — proposal (names need sign-off before building, per house rules):

Drop tmod from auctions. Nothing reads it — it's not in the payload, and bumping it is the *only* reason touchAuction patches the row on every action, so dropping it saves one metered write per write-action. Keep tini (written once at birth, free, forensically useful). Auctions becomes: aname, tini, tfin, blurb, blurbver. Users stays as-is — its tini/tmod ride existing writes for free.

The name problem is the two blurbs. Since the devices table, blurb means two unrelated things: the auction's description and a browser's rig self-description. Rename devices.blurb → rig — already the codebase's own word for it (the rig join map, "the holder's rig" comments) — carried all the way through so no half-names: payload blurbs → rigs, editors[].blurb → .rig, and the client's three read sites. Auction-side blurb/blurbver stay (they're everywhere and unambiguous once rig exists). The maximal version — blurb→desc/descver to match descedit/descview/descVerTip — is available but triples the churn for consistency only; your call.

Migration cost, honestly: tmod is a *middle* column, so dropping it shifts everything left — the auctions tab finally has to die (blurbs and reveal stamps reset). The devices tab dies too for the header rename (loses only accumulated rig strings). Both are one delete in the sheet; the code rebuilds them.

Say go, plus: rig-only or the full desc rename too?

(That README geo question in passing: off wifi, ipwho.is locates your *carrier's* internet gateway — San Jose/Sacramento is where the cell network exits to the internet, not where the phone is. Nothing reliable in the device data distinguishes it; the honest options are labeling geo approximate or dropping the city leg entirely.)

The sketch is the real-database schema — and it surfaces exactly the right questions. Three structural points, then names.

1. There's a missing table, and your own bracket found it. "Can someone participate in multiple auctions at once?" — yes, constantly. So users.slug can't hold membership; the roster is a *relation*: today's users tab is really SEATS, and it does load-bearing work the sketch's global USERS can't — bidless roster membership (the thing that gates reveal and names stragglers), roster order, and the per-auction claim (which star is lit, from which device). So:

AUCTIONS  slug, tini, tmod?, tfin, blurb, bver
USERS     userid, uname, tini, tmod
SEATS     slug, userid, devid('' = unclaimed), tini   [roster order = row order]
DEVICES   devid, rig, tini, tmod, editingSlug, editingUserid, tedit
BIDS      slug, userid, bid, tbid   [standing bid = latest ≤ tfin]

2. Global userid is a product decision wearing a schema costume. Promoting pid→userid means one identity across auctions: renames go global, the client's per-auction pid ledger collapses to one stored userid (auto-relatch machinery mostly evaporates — you're just always you), and "@sam" means the same human everywhere. Two consequences to accept with eyes open: name-collision scope (recommend: uname lives on USERS but *uniqueness stays per-roster*, checked on SEATS — else casual walk-ins fight over "bob" globally), and the correlation surface — one public row now links a person across every auction, the same concern that killed uname-on-devices earlier. It's the right schema *if* cross-auction identity is wanted; that's the call to make explicitly.

3. The DEVICES question marks. blurb? — that column is the *rig* self-description ("Mac Chrome in Portland"), not the auction blurb; that your own sketch tripped over the name is the case for renaming it rig. slug? edit timestamp? — yes: that's the presence slot, editingSlug + editingUserid + tedit. devices.userid and users.devid ("most recent X") — mutual hints nothing would read; the real device↔person link is the seat claim. Recommend dropping both (YAGNI) unless wanted for sheet-browsing convenience.

On tmod [your bracket]: as-built it means "any write, blurb edits included" — and it's read by nothing while being the *only* reason every action writes the auctions row (one metered write per action). Keep it as documentation-in-data or drop it for the write; either is defensible, just choose knowingly.

Names: slug, bver, devid, userid are all better — the one warning is that aname→slug and pid→userid ripple through payload keys, client, and quals, so they should rename *all the way through* in one pass (half-renamed vocabulary is worse than the old names).

Decisions needed: global identity yes/no; tmod keep/drop; the hint columns keep/drop. Say the word and the migration plan follows.

"Rig" as in "my rig" — the colloquial word for one's machine/setup. It's the proposed name for the device's self-description string, the "Mac Chrome en-US in Portland, OR" that decorates claimed-by tooltips and the busy-pencil suffix. The word is already in the codebase informally — getState's join map is named rig, comments say "the holder's rig" — so promoting it to the column name just makes the official vocabulary match the working vocabulary. It scores well on the house naming criteria (evocative, short, greppable, pronounceable), and its whole reason for existing is that the current column is named blurb, which collided with the auction description hard enough that your own schema sketch mistook one for the other. If the word doesn't land, the constraint is just: anything but a second "blurb."

They're the editing-presence slot — the "who has the blurb editor open right now" feature behind the scribbling pencil — living on the device because a device edits one blurb at a time:

• editingSlug: *which* auction's blurb this device has open. getState(slug) scans devices for rows pointing at its slug with a fresh tedit, and that list is the desk crowd everyone else's pencil scribbles about. Putting the pointer on the device row (rather than an editor-slot on the auction row, the first design) is what makes *several* simultaneous editors representable — one row each, nobody clobbers anybody.
• editingUserid: *as whom* — so the tooltip can say "— currently being edited by dalia" via a live seat lookup (survives renames), with '' meaning a walk-in, rendered "someone (rig)". It exists separately from the seat claim because of one edge: someone added to the roster who hasn't claimed or bid yet has no claim row to derive from, and without this column their editing would demote to "someone (rig)".
• tedit (the third of the trio): the last heartbeat, ~10s cadence from an open editor. Fresh-within-25s *is* presence; a closed tab just ages out, and SAVE/DISCARD clear it explicitly.

So concretely: dalia opens the editor → her device row gets editingSlug=carnoon, editingUserid=dalia's-id, tedit=now, refreshed every 10s; everyone else polling carnoon sees her in editors and their pencil wiggles with her name; her SAVE zeroes tedit.

They answer three different questions, and only one of the three is optional:

SEATS — needed, period. "Who's in this auction?" can't live anywhere else: roster membership includes people who haven't bid (which is what gates reveal and names stragglers), order matters, and the per-auction claim (whose star, from which browser) is a fact about the *pair* (auction, person). No other table can hold a pair.

DEVICES — needed as long as its features exist. A browser is a real actor in this app: it self-describes (the rig in claimed-by tooltips), it holds editing presence, and it's what actually clicks claims. Fold it into USERS and you've asserted person = browser — one rig per person (wrong the moment someone uses phone and laptop), presence per person (wrong the same way), and the faire incident class comes back. The table dies only if the rig tooltips and busy pencil die with it.

USERS — this is the optional one, and it *is* the global-identity decision. Everything USERS carries is "what is this person called, across auctions." If identity stays per-auction (today's shipped semantics), uname just lives on the seat, userid degenerates back into the pid — a key that appears in seat and bid rows but needs no table of its own — and the schema is four tabs: today's shape with better names. USERS earns its existence exactly when you want one name, renamed once, meaning the same human everywhere.

One tempering note on how much USERS buys: with no login, a userid is minted in one browser's localStorage, so it spans devices only the way pids already do — by claim-style attachment from the new device, honor system — not automatically. Global identity is real (names, renames, continuity), but it isn't accounts.

So: 4 tabs without global identity, 5 with. That's the fork.

Flip the example around: "alice added before she visits" is exactly what the *split* handles cleanly, and the merge handles awkwardly. In the split world, adding alice makes a users row (her name) and a seat (her membership, claim blank) — and *no device row at all*, because no device exists yet. Nothing is blank; the row for the thing that doesn't exist simply doesn't exist. The merge is what manufactures blankness: one users×devices table needs device columns on alice's row sitting empty — and user columns sitting empty on the walk-in lurker's row who's editing a blurb before claiming anything — so every column is sometimes meaningless. The wide sparse table is the smell; two thin tables is the fix for it.

And the merge breaks on cardinality, not just aesthetics. Person↔browser is many-to-many over time:

• One person, two rigs: alice on phone and laptop. A merged row has one rig field and one presence slot — her phone's heartbeat stomps her laptop's open-editor presence, and the claimed-by tooltip shows whichever device wrote last. Those are bugs, not inelegance; the per-device presence rows exist precisely because slots-per-wrong-entity clobber.
• One rig, two people: the shared iPad claiming different seats in different auctions. One row can't be two people.

The underlying reason is lifetimes: alice outlives her phone, the library computer outlives its users. Entities with different lifetimes don't merge; they relate. All the "combined" feeling you're reaching for lives in the *relations*, where it's cheap: the seat's claim column pairs person and device per-auction (blank = unclaimed, your alice case), and presence pairs device and auction. Merging the entity tables buys nothing those relations don't already say.

Right. Seats needs one more field: devid — the claim, i.e. which browser holds this seat's star. It's per-seat by the same argument you just made: alice can claim auction A from her laptop and auction B from her phone, so there's no "the" device for a user, only for a seat. (Blank = unclaimed = your pre-visit alice.) Roster order comes free from row order.

And no — Users maps userid → uname, *only*. "Also to a device" is the same "the"-field mistake one level down; the person↔device pairing lives on the seat claim.

So: SEATS slug, userid, devid and USERS userid, uname (plus birth stamps if wanted).

No. Nothing reads it — it's not in the payload or any logic — and bumping it is the *only* reason every write action also patches the auctions row, so dropping it saves one metered write per action. If "last activity" ever matters it's mostly derivable (latest tbid), with blurb edits as the one blind spot. Keep tini: written once at creation, free forever.

Right on both counts. The unixtime-bver dies exactly where you shot it — the pencil tip renders "(v3)", not "(v1754247890)".

And yes, tbed costs nothing: the blurb save already patches the row, patch writes one contiguous slab, and tbed sitting next to blurb/bver rides the same single setValues call. It also plugs the one blind spot in deriving last-activity from bids. Only naming note: don't call it tblurb — that name had a past life as the CAS token and would haunt greps. tbed is clean. So: AUCTIONS slug, tini, tfin, blurb, bver, tbed.

Yes: seats' primary key is (slug, userid). And the devid question has a clean answer: there's no association to violate — the seat's devid *is* the association. "This browser holds this seat" is a first-come, last-write honor-system marker, not a verified binding; a surprising pairing isn't corruption, it's just the current claim (that's the takeover semantics from the faire ruling).

The name-as-identity rethink is a real fork, and it's one this codebase already took once, the other way. Names *were* the keys until July 19; pids shipped because name-as-key made renaming impossible — a rename either orphans the old name's bids or re-keys them, and typo'd names (a facilitator adding "bob" for someone) turned out to be common. That's the whole trade:

Name as key buys: no users table (three tabs plus devices), no invisible uuids, and — worth real weight given the link-visible sheet — bid rows that say sam, not pid-a3f8…. The sheet becomes human-readable, which suits the transparency ethos.
Its cost is renames: fixing "bob" → "rob" means rewriting every bids-log row for that name (mutating the append-only log, under the lock — mechanically fine, philosophically gross) plus every client's stored identity going stale. Or: no renames, back to remove-and-re-add-before-they-bid.

userid buys exactly one thing: identity that survives its label — renames are a one-cell edit, the log never mutates, claims and presence ride through. Everything else it appears to buy is optional (the users table only exists if identity goes global; per-auction userids need no table at all, as established).

So the question reduces to: are renames worth an opaque key in the data? The shipped answer was yes, learned from the hallway test. Recommendation: keep userid. But if you'd trade renames away — or accept re-keying the log — name-as-key is coherent and strictly simpler, and nothing else in the design objects.

The bad feeling might be right, because Users is the vestigial one: two columns, and it exists *only* if a rename should follow you across auctions. Say the same human is "sam" in one auction and wants "sammy" everywhere — global rename = keep Users; if being sam here and sammy there is fine (today's shipped semantics), uname moves onto the seat and Users vanishes — leaving Seats + Devices, which are irreducible (membership vs browser).

So: do you actually want cross-auction names? That's the whole question the third table hangs on.

Then Users dies and the schema settles at four tabs:

AUCTIONS  slug, tini, tfin, blurb, bver, tbed
SEATS     slug, userid, uname, devid, tini
DEVICES   devid, rig, tini, tmod, editingSlug, editingUserid, tedit
BIDS      slug, userid, bid, tbid

Which is today's shipped shape with honest names — the migration is a rename pass (aname→slug, pid→userid, users→seats, blurbver→bver, blurb→rig on devices) plus drop auctions.tmod, add tbed. Sketch matches gut now?

Right — and tmod is only costless for events that already write the seat row, which gives it its natural meaning: rename, claim, release (and the claim that rides a bid's seat-rebuild). Those all patch the row anyway, so tmod hitches on the same write. So seats.tmod = "when this seat's record last changed: label or holder."

Bids and presence should *not* bump it — they don't touch the seat row, so stamping them there would add a write, and they already carry their own stamps (tbid in the log, tedit on the device). Free where free, never bought.

Exactly — tmod = last write to this row, full stop. The rename/claim list was just enumerating what those writes happen to be; the definition doesn't need it, and stays true as new seat fields (weights, shares) appear.

Solid. Two candidates considered and left out, for the record: devid (which browser placed it — pure forensics, no feature reads it; the faire-style diagnosis got by on claims) and a sequence number — same-millisecond tbid ties break by row order today, which is the documented hazard that a human sorting the sheet scrambles history. If that hazard ever graduates from "chosen gap" to "bites someone," a seq column is the fix; until then, four fields is the whole truth of a bid.

Agreed — and it's free: the bid row is one appendRow either way, and placeBid already holds the deviceID. When "did sam really place this?" comes up, devid joined to the rig turns vibes into a row: this bid came from that iPhone. '' for deviceless old clients, honestly recorded.

BIDS  slug, userid, bid, tbid, devid

Milliseconds, yes (ISO strings) — but "impossible" is empirically false on this platform: same-millisecond *blurb* saves are why bver is a counter instead of a timestamp (the samems qual exists because it happened), and Apps Script clocks can also step backwards under NTP. So a bare assert would eventually crash an innocent bid.

Better: your rejected bver trick is exactly legal here, because tbid *isn't* user-visible (tooltips render "3m ago"; a 1ms fudge is invisible). Mint tbid = max(now, latest tbid in this auction + 1ms) under the lock — ties become structurally unmintable, the row-order tiebreak dies as dead code, and the sheet-sorting hazard dies with it, since bid order is now recoverable from tbid alone. *Then* the assert you want goes on the read side, covenant-style: derivation asserts no duplicate tbids per auction, which catches the only remaining source — hand-edited rows — loudly.

Derive it. The count adds no information — it's fully determined by rows already in hand at read time, at zero cost — so storing it buys nothing except a new way for the sheet to disagree with itself (stored 3, actual rows 4: now *that* needs an assert). Devid earned its column by recording a fact that exists nowhere else; a bid number records a fact the table already states. Redundancy is for facts, not arithmetic.

Neither — a draft isn't data, and there's a standing ruling saying so (the 07-28 field-class taxonomy: no mid-composition anything, no cross-session blurb drafts; the draft lives in the open textarea and dies with it). Against the server copy specifically: every beat would ship up to 2000 chars of half-typed thought onto a *link-visible sheet* — publishing compositions nobody chose to SAVE — and stored drafts are exactly the resurrection hazard your own spec item 3 guards against with tokens. localStorage would be the right home *if* crash-proof drafts became a want, but that's reopening the ruling, not a schema question.

So Devices stays lean: devid, rig, tini, tmod, editingSlug, editingUserid, tedit.

They record "this browser has auction X's blurb editor open, as person Y" — the pencil-presence fact, one slot per device:

• editingSlug: which auction. getState(slug) collects fresh-tedit devices pointing at it → the editors list → rivals' pencils wiggle.
• editingUserid: as whom, so the tooltip says "— currently being edited by dalia" instead of "someone (Mac Chrome)". '' = walk-in. It can't always be derived from the seat claim (an added-but-never-claimed person has no claim row), hence its own column.

Concretely: dalia opens the editor on /carnoon → her device row gets editingSlug=carnoon, editingUserid=<dalia>, tedit=now, re-stamped every 10s; SAVE/DISCARD zero tedit; a closed tab ages out at 25s.

Forensics only, nothing reads them: tini = when this browser first appeared (insert-time, free), tmod = last write to the row, same obvious definition you just settled for seats. One wrinkle worth choosing: if tmod rides *every* row write it includes the 10s presence beats (free — same patch slab), which turns it into "last seen alive" — genuinely useful someday for sweeping dead devices. If beats are excluded it collapses to "rig last changed," which is nearly tedit's cousin and less informative. Recommend the uniform rule: last write, beats included.

Close. Three fixes, one nit:

DEVICES
* devid -- primary key, a random uuid the client mints and keeps in localStorage
* rig   -- self-description like "Mac Chrome en-US in Portland, OR"
* tini  -- when this device was first seen
* tmod  -- last write to this row; beats included, so: last seen alive
* blug  -- slug of the auction whose blurb editor this device has OPEN
* tblug -- heartbeat stamp for blug, re-upped every ~10s while the editor is open
* bluid -- the userid this device is editing as ('' = unseated, shown as "someone (rig)")

• blet → tblug: keeps the t-family rule every other stamp obeys, and mirrors the bid/tbid pattern exactly (column + its stamp). Also blet's description said "last *edited*" — wrong semantics: it's the open-editor heartbeat (an idle editor keeps beating; that's what the 25s TTL ages out), not an edit event.
• blug description gains "open": presence means the editor is open, not that editing happened.
• devid: "minted," not "computed" — computed implies derivable; it's random.

Nit: the shipped rig strings say "Mac," not "macOS."

Good — ship it. That's the whole schema settled:

AUCTIONS  slug, tini, tfin, blurb, bver, tbed
SEATS     slug, userid, uname, devid, tini, tmod
DEVICES   devid, rig, tini, tmod, blug, tblug, bluid
BIDS      slug, userid, bid, tbid, devid

Next when ready: the rename-and-migrate pass (schema, payload keys, client, quals, all the way through — plus monotonic tbid with its read-side assert, bids.devid, tbed, and dropping auctions.tmod). Say go.

Executing. Phase 1: the mechanical rename pass (ordered, word-boundary sed across server, client, stringles, quals — localStorage keys deliberately untouched):

Phase A — schema behavior changes in Code.gs:

The e\.blurb pattern matched inside state.blurb — reverting those:

Frontend 605 green. Story and serve:

Memory while it runs:

Suite finishing in the background; on green the deploy runs and the tab-dance walkthrough follows.

Done, end to end — and the migration turned out to need zero clicks: the live tabs were already cleared from the earlier passes, so the deploy (@110) rebuilt everything in the final schema and the live smoke ran 7/7 green on the first try.

Shipped, twice-green offline (1068 = 225+605+9+229):

• Schema: auctions[slug,tini,tfin,blurb,bver,tbed], seats[slug,userid,uname,devid,tini,tmod], devices[devid,rig,tini,tmod,blug,bluid,tblug], bids[slug,userid,bid,tbid,devid].
• Renames all the way through — schema, request/payload keys, refusal codes, client, DOM id, quals. localStorage keys deliberately untouched, so live identities survive.
• Behavior: auctions.tmod gone (one write saved per action), tbed rides the save patch, bids carry the forensic devid, tbid minted max(now, prev+1ms) with a read-side duplicate-equals-forgery assert.
• One real bug found by the covenant qual mid-build: a future-minted tbid could outrun tfin = now and get dropped at the ≤ cutoff — the gavel now mints tfin ≥ last tbid.

The one urgent step is yours: git push the frontend. The published client still speaks the old keys, so every call it makes now refuses as badSlug until the push lands on Pages (plus its ~10-minute cache).

Reading the actual beat path end to end before theorizing — client sender, then server handler:

Mutation red, fix green — the qual bites. Full suite and bookkeeping:

Diagnosis, while the final double run completes:

The bug was the document.hidden beat-skip — my disclosed trade, and it was the wrong trade. Replicata: open the editor, alt-tab to the sheet to watch tblug → the tab goes hidden → beats stop → tblug freezes at its last stamp and presence ages out, precisely while being observed. The first beat did land (tblug was set once), but "never updates" is exactly what a frozen stamp looks like. Fixed by deleting the gate: hidden tabs beat too — a hidden dirty draft is exactly the rival the pencil must warn about. Client-only fix, so no clasp deploy; it reaches production with your next git push.

Verified en route, carefully: the live server round-trip is healthy (a probe beat against @110 lands and serves in editors on both the write response and a fresh read), and a real-Chrome-against-live-API replica of your dev setup sends 2 beats in 13s post-fix.

The qual hunt found its own bug, twice. My first two versions of the hidden-tab qual passed against *both* code variants — vacuous — because zombie pages from earlier desc-war fixtures (newerdesc, xsswar, descy, …) sit with editors open and beat into the shared mock stream every 10s forever, satisfying any count-grows assert. Beat counts now filter by the page's own devid, and the qual is mutation-verified: restoring the gate goes red by name, deleting it goes green. That zombie-beat hazard is written into the qual as a comment and into memory, since any future editing-count assert would step on the same rake.

Suite finishing in the background; it was green through the mutation dance and nothing changed since but comments.

Now yes, with one correction and one open thread:

Verified just now, end to end: the gate is gone from app.js, and a real-Chrome replica against the live API with document.hidden forced true sends 2 beats in 13 seconds — the fix demonstrably keeps beating while hidden. (Pre-fix, the jsdom probe showed the gate blocking exactly this: delta 0.)

Correction to the last report: the "2 beats in 13s" replica cited there ran *pre*-fix with a visible tab — it proved the baseline machinery, not the fix. The fix's own end-to-end proof is this hidden-forced run. Mis-attributed; now properly separated.

The open thread is the attribution to what you saw. The gate explains one specific observable: tblug *frozen at a stale stamp* while you watch from another tab or window. It cannot explain tblug *always empty*, because the open-beat fires unconditionally with the tab still visible. There's a third possibility that's working-as-ruled: a clean editor's blur is DISCARD (your 07-28 taxonomy), so open-the-editor-then-click-elsewhere-without-typing sends the stop and zeroes tblug every time — permanently empty tblug, by spec.

So the discriminating question: was tblug stuck at an old timestamp, or always empty — and had you typed anything? Stale-stamp → it was the hidden gate, fixed. Empty-without-typing → clean-blur DISCARD, by design. Empty-*with*-typing → still a live bug and the hunt reopens.

(The final double suite run is still going in the background; nothing but read-only probes has touched the tree since it started.)

Empty-with-typing reopens the hunt — the hidden gate can't explain that. The live probes so far only proved the *fresh-device* path; his device row already existed (born from claims). Probing the existing-row path live, including re-beat-after-expiry, which is checkable without sheet access via the TTL:

Gas 228. Checking that TypeError glimpsed in the background output:

Try again now — yes: the hidden-gate fix is in your working tree, so dev picks it up on reload. If tblug still sits empty *while you're typing*, the 10-second discriminator is DevTools → Network → filter exec: typing in the editor should show a POST with "action":"editing" every 10s. No POSTs = client-side and the hunt has a direction; POSTs with error bodies = server and I'm wrong about something specific.

What's now pinned and verified around it:

• Live probes, every path: fresh-device beat, existing-row beat (your case — the earlier probes only covered fresh), TTL expiry at 27s, and re-beat re-arming — all green against the deployed API, which proves tblug moves server-side in each shape.
• New gas quals, your sequence cell-for-cell: a claim-born device row gets patched *in place* by the beat (one row, no doppelganger), tblug/blug/bluid asserted in the sheet cells rather than the payload, a clock-advanced re-beat must move tblug forward, and the stop zeroes it (empty tblug = editor closed, working as ruled).

Honest status: empty-with-typing hasn't reproduced anywhere — one boring candidate is that your test predated the @110 tab rebuild, when every call was refusing anyway. The Network check settles it either way.

Two suite bugs got caught and fixed in the same sweep: the previous "twice-green" background run had actually crashed on its second pass — my | tail invocation ate the exit code (same trap as the deploy earlier; now running with captured exit codes) — and the crash itself exposed a real flake: the rename-race qual queried bob's tile in the gap between the refusal banner and the recovery snapshot walking back the optimistic 'zed' label. Deflaked by awaiting both truths. Full double run is going now with honest exits; result on completion.

The honest exit codes caught what tail was hiding — this time it was only the 404 byte-copy (index.html drifted again); synced and rerunning both passes in the background. Result on completion.

Twice-green with honest exits: 1072 = 228+606+9+229. Recording the lessons:

Both passes green with captured exits: 1072 = 228+606+9+229. Everything from this round is in: the dev-sequence cell quals, the rename-race deflake, the hidden-gate deletion, and the exit-code lesson banked as a standing memory so tail never eats a red again.

The ball's in your court: retest in dev. If tblug moves — it was the hidden gate and/or the pre-rebuild window. If it's still empty while typing, the Network-filter check (exec, look for "action":"editing" POSTs) tells us which half of the wire to reopen.

Audit pass — debris greps, unpushed-delta check, and stale-name sweep in one batch:

All green after syncing your version bump (v2026.08.05-a — commit both index.html and the synced 404.html). Audit results:

Confidence: high, with named edges. The basis — 1072 assertions twice-green with honest exit codes; live probes green against @103–@110 for every presence path including the existing-row and TTL shapes; and the load-bearing guarantees are *structural*, not enumerated: refusal codes ⟷ copy welded both directions, every code and every assert-family diagnostic provoked by construction, no deviceID reference can dangle (write-ordering + sweep), tbid ties unmintable (and with them, the old sheet-sorting hazard for bids died), covenant checked on every suite action, drift checked eagerly on every live call.

The audit found almost nothing left, which is itself the finding: zero stale vocabulary in shipping code after the rename; two cosmetic stragglers fixed just now ("THE PID" comment header, setDeviceID → setDevid).

The honest residuals:

1. *The fake's fidelity boundary.* The flush bug proved the class: offline can't catch what only real Sheets does. live-quals is the designated backstop and is green, but it's seven assertions, not a thousand.
2. *Empty-with-typing was never reproduced.* "I think it's good now" closes it as probably-the-pre-rebuild-window; the DevTools discriminator stands ready if it recurs.
3. *The standing known-gaps register* (two-tabs-one-device, offline/network-flap stories, ad-hoc accessibility) — unchanged, chosen not forgotten.
4. *Zombie fixture pages* beat into the mock stream forever; contained by devid-filtering where it matters, not structurally swept.

No further quals worth their cost surfaced — the remaining unqualed surface is the register above, which is policy, not oversight.

Not exactly — same fields everywhere, but two tables differ in column order, and order is the schema here (everything reads positionally, and the drift check compares the header row in order):

• BIDS: README says slug, userid, devid, bid, tbid; code has slug, userid, bid, tbid, devid.
• DEVICES: README ends blug, tblug, bluid; code ends blug, bluid, tblug.

AUCTIONS and SEATS match exactly.

Recommendation: change the code to match the README — it's the human-authored spec, and your orders read better (devid beside userid; tblug beside its blug). Cost is a live tab dance for both tabs, which is a two-tab delete. Alternatively I reorder the README's bullets to match the code and nothing else moves. Which way?

Functionally, no. The sheet's header row is *written from* the code's constant at tab creation, and the drift check compares sheet-vs-code — never README-vs-anything. So code and sheet can't disagree, and every read is positional against that same constant. The README is documentation; a stale bullet order misleads a reader but breaks nothing.

Where it does matter, both mild: docs truthfulness, and the order you actually see when browsing the sheet — which is a real ergonomic want given how much you read that sheet directly.

Costs, so the choice is informed: changing the *code* order means a two-tab dance plus re-indexing several quals that poke cells by number (bid rows at [3]/[4], devices at [4]–[6], the auctions sentinel). Changing the *README* is a two-bullet reorder in your prose — your file, so your call rather than mine.

Looking at how tauction currently builds the device blurb (rig), then fetching molecall's approach.

Reading molecall's blurb block in full to see what's different.

Now confirming the qual is red against current code:

Red confirmed — rig is mystery device en-US, no location. Now the fix in app.js, molecall's shape:

Running the full suite:

Done and green. What was copied from molecall, per its BLURBBASE/clampblurb pattern:

• [app.js:200-228](app.js#L200-L228): the rig now splits into RIGBASE (OS + browser + language) plus a clamprig helper (ASCII-fy + 64-char clamp), and the location tail is seeded at birth with the IANA timezone (Intl.DateTimeFormat().resolvedOptions().timeZone, e.g. "America/Chicago") — free, permissionless, often city-named.
• [app.js:250](app.js#L250): locate() now rebuilds RIG = clamprig(RIGBASE + ' in ' + geo) instead of appending in place — the upgrade replaces the tail, never stacks it, and the clamp applies on every path instead of only the geo one.
• New qual 2r4 in [frontend-quals.js:4577-4608](quals/frontend-quals.js#L4577-L4608), red first (rig came back mystery device en-US, no location), green after: with the geo service down, a bidder's rig still ends in <timezone>. The existing 2r-family equality asserts fence the replace-not-append behavior for free.
• AGENTS.md's data-model vocabulary line updated to record the change.

Full suite passes: 228 + 607 + 9 + 229 assertions. One incidental step: the suite refused on 404.html being out of sync with the user-edited index.html (the version bump to -b), so npm run sync-404 was run — that's the documented derived-file fix and touches nothing else.

An observation on README "Previously" item 5 (everyone off-wifi placed in San Jose/Sacramento): that's carrier-IP geolocation naming the mobile gateway's city, and the timezone seed is the truthful signal already in hand. This change only uses it as the *pre-lookup* placeholder; the IP city still wins once it lands. If wanted, a next step could distrust the IP city when it disagrees with the timezone — say the word and it gets its own red quals.

The frequency question is partly answerable from the armchair and partly from the data ipwho.is itself returns — checking what it actually says for carrier IPs (that's the "device data that can tell us not to trust it" question from README item 5):

Partly inferable, and the frequency question just got measured. Live ipwho.is queries a moment ago:

| network | city it reports | its own timezone field |
|---|---|---|
| this broadband (CenturyLink) | Portland, OR ✓ | America/Los_Angeles |
| T-Mobile cellular IP | Coeur d'Alene, ID | America/Los_Angeles |
| AT&T cellular IP | Plano, TX | America/Chicago |
| Verizon cellular IP | Las Vegas, NV | America/Los_Angeles |

So "how often is it wrong" has structure: on broadband it's usually right; on cellular it's wrong essentially *always*, because geolocation sees the carrier's regional gateway, not the phone — and the day-long cache makes whichever answer sticky.

Two things are inferable with confidence:

1. The tz-disagreement guard is refuted by the measurement. For a Portland phone (browser tz America/Los_Angeles) it would catch AT&T's Plano but wave through T-Mobile's Coeur d'Alene and Verizon's Las Vegas — 1 of 3 carriers. Any rule shaped "distrust the city when it disagrees with the timezone" misses the motivating case.

1. README item 5's actual question — is there anything in the data that says don't trust it — yes: connection.isp names the carrier outright ("T-Mobile USA, Inc.", "Verizon Business"). But acting on it means a carrier blocklist or a /mobile|wireless/i heuristic that rots as carriers rename. (ip-api.com sells exactly this as a mobile flag, but its free tier is HTTP-only — uncallable from an HTTPS page.)

What's left is a taste trade, not inferable:

• Keep as-is — city color when it's right; confidently wrong on any phone off wifi.
• Timezone only — delete locate() wholesale: the fetch, day cache, 429 backoff, sanitize-on-use, fixtures, and their quals. The rig reads "…in America/Los_Angeles" always. Never misleading, strictly less colorful.
• Carrier sniff — trust the city unless connection.isp smells cellular. Fixes all three sampled carriers today; enumerated-list rot tomorrow.

The lean is timezone-only: the rig exists to tell devices apart, and timezone granularity does that about as well as city for remote participants — while at a physical table geography distinguishes nobody, as everyone shares a timezone anyway. And it deletes a subsystem instead of growing one. But it trades away genuine precision in the wifi case (Portland ≠ America/Los_Angeles), so per PDP it's dreev's call: which trade?

Cramming both in — the exact copy is specified ("… or, by timezone, …"), so that goes in verbatim. One consequence to handle first: the crammed tail blows the server's 64-char rig contract for common devices ("iPhone Safari en-US in Portland, OR or, by timezone, Los Angeles" is *exactly* 64; any Windows PC or longer city chops — and the clamp would chop the timezone part, the truthful bit). So the contract widens too; 160 to match the existing bid limit. Reading the pieces:

Multi-file change now — tracking it. First, finding every assert and comment pinned to the old format or the 64 limit:

The Welsh clamp qual needs a longer city to still exercise the clamp at the new 160 fence:

Confirming red (gas boundary + frontend format both fail against current code):

Red confirmed (gas fails the 160 fence; frontend crashes on the not-yet-existing orByTimezone — its red). Now the implementation. stringles first:

Code.gs's contract:

Shipped and deployed. The rig now reads "Mac Chrome en-US in Portland, OR or, by timezone, Los Angeles" — your exact connector copy, both location signals crammed in:

• [stringles.js:130](stringles.js#L130): orByTimezone = ' or, by timezone, ', since it's user-visible copy.
• [app.js:225-228](app.js#L225-L228): tzcity turns "America/Los_Angeles" into "Los Angeles" (no-slash zones like "UTC" pass through whole). The pre-lookup seed still shows the raw IANA timezone — bare "Los Angeles" without the "by timezone" qualifier would read as a claimed city, i.e., a lie.
• locate() upgrade: RIGBASE + ' in ' + geo + orByTimezone + tzcity(…), still rebuilt from base, zero new branches.

Two consequences that needed rulings, made and flagged:

1. The 64-char rig contract had to widen — "iPhone Safari en-US in Portland, OR or, by timezone, Los Angeles" is exactly 64, and any Windows PC or longer city would chop the tail (losing the truthful half). Widened to 160, matching the bid limit, in [Code.gs:191](apps-script/Code.gs#L191) and the client clamp. This loosened the gas boundary quals (64/65 → 160/161) — flagging per the never-loosen rule, though "cram it all in" forced it. Deployed server-first (npm run deploy, live smoke green), so the widened server is live *before* the frontend ships with your next push — the reverse order would have live claims refused with badRig.

1. Kept the region code, so Oregonians get the slightly comic "Portland, OR or, by timezone, Los Angeles" double-OR. Your quoted copy said just "Portland" — but dropping ", OR" is a trim, and trims are explicitly deferred. One word and it goes.

Red-first throughout: gas fence quals at the new boundary, the crammed-tail asserts in frontend quals (tooltip, cached-geo, São Paulo, Zürich), the Welsh clamp qual now seeds a thrice-Welsh city to still exercise the clamp at 160, and the story-mode tooltip assert builds its expectation from the page's own orByTimezone + tzcity. All four suites green: 228 + 607 + 9 + 229.

Vocabulary questions get verified against what the code actually keys on before answering — checking how seats are looked up server-side, what the client ledger stores, and whether sid/sname collide with anything:

Verified against the code before answering. On the side musing first: "blurb" may already be its own best 4-letter-adjacent name — it's maximally greppable and its compounds already compress fine (bver, tbed, blug). And note bluid's u belongs to *blurb*, not *user*, so it survives a user-purge untouched. If a true 4-letter form is ever wanted: "burb" (blurb minus the l — greppable, pronounceable, still evocative) or "gist" beat "desc" on every axis.

On the main question — sid/sname sounds right, and the code confirms the instinct:

• Why it's userid today: the 08-04 rework renamed pid → userid at the same moment it ruled that identity doesn't span auctions ("no global users table"). The concept became seat-shaped but the name stayed one rename behind. The rest of the codebase already speaks seat language — seatIndex, notYourSeat, bidSeatHeld, "a bid protects its seat" — so userid is the last user-flavored holdout, and sid makes the vocabulary match reality. Nominology checks: evocative, 3 chars, zero existing \bsid\b or \bsname\b hits anywhere in the repo, pronounceable, and it harmonizes with slug/devid.

• Primary key: yes, slug+sid — by lookup discipline rather than enforced constraint. Every server lookup is a (slug, userid) pair ([Code.gs:498-500](apps-script/Code.gs#L498-L500), bids likewise at [Code.gs:695](apps-script/Code.gs#L695)). Nothing *enforces* sid uniqueness within an auction on add — client-minted uuids make collisions unmintable in practice — while sname uniqueness IS enforced (nameTaken). So sid only ever needs to be unique per-auction, which is exactly the no-global-users ruling expressed as a key.

• The proposed schema slug, sid, sname, devid, tini, tmod is the current table with two honest renames; bids should follow to slug, sid, bid, tbid, devid (a bid keys to a seat).

The sweep this ruling implies, enumerated so nothing survives by accident:

1. SEATS_HEAD and BIDS_HEAD — a schema change, so deploying means tab deletion and data reset (previously ruled acceptable).
2. Wire protocol both directions: request fields, seats[].userid/uname, claims/rigs keys, bidders[].userid, editors[].userid, error args like noSuchOne's.
3. Client: myUserid()/myUseridStored(), and the localStorage ledger key — which is still literally 'tauction-pids' ([app.js:1036](app.js#L1036)), *two* renames behind; changing it to 'tauction-sids' silently unclaims existing browsers' seats, presumably acceptable for the same pre-launch reason.
4. Copy that says "user": badUname's "username must be alphanumeric…" and badUserid's "bad userid" are your ERROR15xx words — replacements are yours to dictate, not Fable's to paraphrase.
5. Quals' fixture vocabulary (userid-higgs-ann, pidOf), AGENTS.md's vocabulary block, README's schema section (human-written — left to you).

Also lockstep matters: renamed wire fields mean frontend and Code.gs must ship together, plus the tab deletion — unlike the rig widening, there's no compatible ordering.

One question before any of this moves: should sname really be the name, or plain name? It's the one field a human reads constantly, s.name reads naturally at use sites, and "name" is only ungreppable when it's a bare word — as a column header it competes with nothing. Either answer works; everything else above follows mechanically once you call it.

Noted on the empty field — that makes any schema-touching rename a free tab reset, so sid/sname, and any blurb/rig rebrand, could bundle into one sweep. For the greppability claims, measuring instead of guessing:

Measured: the rig complaint is real — 373 raw grep hits in the repo, only 169 of them the actual word (the rest are trigger, right, origin…). Every candidate below scored zero existing hits unless noted.

For "rig" (the concept: a device's self-*description*, not the device):

• mien — a bearing, an appearance presented to others; semantically the truest of the bunch, since the column holds how the device presents itself, not the hardware. Zero hits, pronounceable ("meen"), though obscure enough that it needs its defining comment to earn its keep.
• gear — plainest slang for one's equipment. Zero hits, compounds cleanly (GEARBASE, cleangear, badGear).
• deck — the Neuromancer register: your deck is your machine. Zero hits, most flavorful, but names the device rather than its description.
• garb — the clothing metaphor (what the device wears in public); 2 substring hits, both "garbage".

Lean: mien for precision, gear if obscurity rankles.

For "blurb": gist holds up — 0 whole-word collisions (28 substring hits like "register", harmless with token search), and the compound family ports mechanically: blug→glug (which is frankly an improvement), bluid→gluid, tblug→tglug, bver→gver, tbed→tged. Other zero-hit options: lede (journalism's "the short text up top" — evocative and rare, but its compounds come out mangled: llug? tled?) and spiel (the most auction-flavored word available — a seller's spiel — but 5 letters, so no compression over blurb, purely a flavor trade).

Worth saying against the whole quest: blurb itself is a great name — the case for replacing it is only compound-compression, and gist is the lone candidate that actually compounds better. Rig's case is different: that rename is justified on greppability alone, numbers above.

With zero open auctions, all of it — sid/sname (pending the sname-vs-name call from last turn), rig's successor, blurb's if any — can land as one schema-resetting sweep with red quals first. Name the winners and it goes.

Same measurement first — and "dev" really is noisy here: npm run dev, devDependencies, "development" in prose all collide:

"dev" measured: 522 raw hits, only 87 the actual token — worse noise than rig. And one semantic wrinkle worth naming: devid doesn't identify a device — it lives in localStorage, so Chrome and Safari on one Mac are two of them. It identifies a *browser install*. Candidates with that in mind:

• booth — a bidding booth. Zero hits, auction-native (seats, bids, booths — the vocabulary becomes one register), pronounceable, and boothid compounds fine. Doesn't fix the browser-vs-machine wrinkle, but wears it no worse than "device" does.
• peer — the semantically honest one: each browser instance is a peer that meets the others at the sheet. 4 letters, zero whole-word hits. Slight p2p flavor it hasn't earned (the peers never talk directly).
• desk — 4 letters, and already in the project's informal prose (the editors payload is described as "the whole desk crowd"). Caveat the numbers expose: 38 substring hits, nearly all "desktop", so it's token-search-only greppable — better than dev, worse than booth.
• helm / berth — both virgin greps; helm's steering metaphor is weak for a thing that mostly sits there, and berth means a claimed spot, which is the *seat's* job — conceptual collision.
• agent dishonorable mention: the truest word (a browser literally is the user agent) but it reads AI-flavored in 2026 and clashes with the AGENTS.md universe.

Lean: booth, for the same reason sid won earlier — the app already speaks auction; peer if honesty-about-the-concept should win.

Running tally of names awaiting your verdict before the one big schema-resetting sweep: sid (settled?), sname vs name, rig → mien/gear, blurb → gist or stet, dev → booth/peer/desk.

Better rig candidates, then — going for words that name a *self-description shown to others*, not the hardware. Measuring the new batch:

The measurement kills two before aesthetics even enter: card (151 genuine tokens already in the repo) and sig (83 substring hits — design, assign; rig's disease exactly). The clean survivors:

• bio — the plain modern word for a short profile self-description, which is literally what this column holds. Zero hits, three letters, nobody ever asks what it means.
• blazon — the deep cut: heraldry's term for the *verbal formula describing* an armorial bearing. A textual self-description of an identifying display — semantically the most exact word in this whole hunt. Zero hits, pronounceable, six letters.
• crest — the adjacent pun: a crest is an identifying emblem, and in heraldry an identifying emblem is itself called… a *device*. So the devices tab carrying each device's crest is almost too neat. Zero hits, five letters.
• whoami — the unix joke: the command that prints who you are, sitting as a column whose value is "Mac Chrome en-US in Portland, OR". Zero hits, self-documenting, admittedly six letters and a registered eccentric.
• getup — rig's exact informal register (how you're turned out today). Zero hits, five letters, no cleverness to explain.

Lean: bio if the goal is never explaining the name again; blazon or crest if the goal is the kind of clever that made lede land. Given the device/heraldry coincidence, crest may be the one that's actually *earned*.

One note on lede while it's warm: clever, zero hits, but its compounds mangle — bver/tbed/blug/bluid/tblug port to things like lver/tled/llug, and lug alone is swallowed by every "slug". If lede wins, the compound family needs its own naming pass rather than mechanical substitution.

Tally: sid (presumed settled), sname vs name open, blurb → lede (leaning), rig → bio/blazon/crest/getup/whoami awaiting a pick, dev → booth/peer/desk awaiting a pick.

Yes — the exact word exists: signalment. It's the police/forensic term (from French *signalement*) for a description of a person circulated for identification precisely when their name is unknown — "adult male, six foot, scar over left eye." That is the rig's job to the letter: the app already renders it as "someone (Mac Chrome en-US in Portland…)" — a signalment inside someoneOn()'s parentheses. Its only crime is ten letters.

The nearby words and why they miss:

• epithet itself: a descriptive *byname* attached to or replacing a known identity (Alexander *the Great*) — and modern usage has drifted to "slur."
• sobriquet, byname, cognomen, moniker: all name-side — they're substitute *names*, not descriptions of the unnamed.
• doe (as in John Doe): the placeholder *name* for the unknown person, not their description — and as a token it'd hide inside every "does".

The short, column-viable descendants of signalment's meaning:

All grep-virgin. Ranked as rig successors carrying the unknown-person-descriptor sense:

• sketch — the police sketch: the artifact produced *for* someone whose name we don't know, assembled from observed features. Six letters, zero hits, and its casual sense ("a quick sketch of the device") keeps it readable to anyone who never thought about forensics. Register matches rig — workmanlike, no explanation owed.
• bolo — be-on-the-lookout, the broadcast that *consists of* a description of an unnamed person. Four letters, zero hits, but acronym-opaque until taught.
• mug — the mugshot register; three letters, cheeky, slightly name-side (a mugshot is of a *known* arrestee, usually).
• likeness — the gentlest option: a rendering of how someone appears. Eight letters, zero hits, no criminal flavor if the wanted-poster vibe grates.
• signalment — the true answer to the vocabulary question, available if exactness beats brevity.

So the rig shortlist reshapes to: sketch (descriptor-of-the-unnamed, common word), signalment (same, exact but long), blazon/crest (heraldic identity-display angle), bio (plain profile angle). Sketch and lede also rhyme culturally — both are craft jargon from adjacent trades, journalism and police work, each naming "the short text that stands for the thing."

"anym" audits well — measuring first:

Three substring hits, all "anymore" in comments; zero whole-word. Its one lookalike, "anim", sits 59 times in the CSS but greps as a different string.

Verdict: this is the best candidate yet, because it's the only one that names the actual concept. Everything prior picked a genre of description — police (sketch), heraldry (blazon), profiles (bio) — while "anym" names the *namelessness*: the -onym family (pseudonym, eponym, anonym) makes it decodable on sight as "stands where a name would go." And it completes a tidy little system: seats carry snames, devices carry anyms — the name and the no-name, two columns of the same vocabulary.

Costs, stated plainly: it's a pure coinage, so the defining comment does all the work — and "anonymous signalment" is that comment, nearly verbatim. It also can't be said aloud without occasionally being heard as "anim," which matters never in grep and rarely in speech.

Compounds fall out fine: badAnym, cleanAnym, ANYM/ANYMBASE, clampanym, res.anyms.

Tally, updated: sid settled, sname vs name still open, blurb → lede (leaning, compound family needs its own pass), rig → anym, dev → booth/peer/desk still open. Two calls and a compounds pass remain before the sweep.

The full-board view, then. Enumerating every field with the pending renames applied, the stragglers are: sid (3), bid (3), sname (5), devid (5), bluid (5), tblug (5), plus lede's unresolved compounds (bver, tbed). Candidate completions exist for every one — measuring the batch:

That last number settles something: seat as a column would inherit rig's exact disease (374 raw hits, 198 real), so sid earns its keep at three letters. With everything measured, here's the completed board — every field at four letters or under, most exactly four:

| tab | fields |
|---|---|
| auctions | slug tini tfin lede take tled |
| seats | slug sid nick peer tini tmod |
| bids | slug sid bid tbid peer |
| devices | peer anym tini tmod plug psid tpen |

The new proposals in there:

• nick (was uname/sname) — virgin grep, and it answers the open sname-vs-name question with a better word than either: a nick *is* a casual display label hanging off a truer identity, which is the exact semantics.
• The pen family (was blug/bluid/tblug): the editing affordance in the UI literally *is* the pencil, so the device's editing-presence slot becomes where its pen is — plug = pen+slug, the auction the pen is in (same portmanteau construction that built blug); psid = the sid the pen writes as; tpen = the pen's heartbeat, a proper t-family stamp. All three virgin greps.
• take (was bver) — the lede's take number, and the app already speaks it: the edit-war copy is "Edit war, take 2!" and warTitle(take) exists today. Caveat: 28 existing whole-word hits ("taken" claims vocabulary nearby). The boring virgin fallback is lver.
• tled (was tbed) — t + led, lede-edit; token-clean, though it hides inside every "settled" for substring searches, same as all t-family initialisms.
• quid for bid is available if exactly-uniform ever beats leaving the app's core noun alone — virgin grep, quid pro quo flavor — but bid at three letters is the name of the game itself, and renaming it buys uniformity only.

Remaining picks, all yours: peer vs desk (grep says peer, hominess says desk), take vs lver, whether bid/sid staying at three letters counts as arrival or near-miss. Call those and the sweep is fully specified — one schema-resetting pass, red quals first, tab reset free while the field is empty.

Two virgin candidates and a structural observation. tblug is the one field trying to wear *two* family prefixes at once — t- (timestamp discipline: tini, tfin, tmod, tbid, tbed) and bl- (the blub family: blug, bluid) — which is exactly why it costs five letters. A 4-letter name has to renounce one lineage:

• blip — keeps the bl- livery and *is* the heartbeat word: the cardiac monitor's blip, the thing that appears every beat and whose absence means the patient's gone — precisely the 10s-ping/25s-fresh semantics. Zero hits. Cost: the only timestamp not announcing itself with t-.
• tlub — keeps the t- discipline: timestamp-of-the-lub, as in lub-dub, cardiology's actual name for the first heart sound. Zero hits, pronounceable ("tee-lub"), and holds the record for jargon-depth-per-letter. Cost: needs its defining comment more than anym does.
• tick and thud — the t-initial whole words, but both already occur in the repo (4 and 5 genuine hits), and tick is clock-generic rather than liveness-specific.
• puls-anything is dead: the padlock already pulses; 56 hits.

Lean: blip, because it's the one word that means the thing itself — and the neighboring blug/bluid columns keep it visibly in the blub family, so the lost t- prefix is the only casualty. If the timestamps-start-with-t rule is load-bearing for you, tlub is the principled pick.

Same fork, one sentence, for the other five-letter holdout: bluid → buid (blub + usid, staying b-family) — worth deciding together with tblug since they're the same trade.

The board's complete — every field ≤4, and the blug/blid/blip trio came out systematic: bl+3 for the where, the as-whom, and the when of the editing slot. Improvements found, none at the name level except one hazard flag; the rest are gloss-level:

1. The anym example is stale as of this morning — the shipped format is the crammed tail: "Mac Chrome en-US in Portland, OR or, by timezone, Los Angeles" (and it's born with just the raw IANA timezone until the IP lookup lands).
2. Order the trio blug, blid, blip — currently blip sits between them, splitting the (slug, usid) pair that mirrors the seats table before the heartbeat that qualifies both. Same instinct as your "columns slightly out of order" note.
3. dvid's gloss says "physical device" — it's a uuid in localStorage, so it identifies a browser install: Chrome and Safari on one Mac are two dvids. Worth one honest parenthetical, since it's exactly the kind of fact that surprises later.
4. usid is the one name still whispering "user" — a cold reader decodes u-s-i-d as user-id before "unique seat id." No 4-letter beat was found (suid is unix setuid, ssid is wifi, seat measured grep-dead), so the fix is making the gloss own the u, e.g. noting it's a client-minted uuid.
5. bver's gloss undersells it — it's not just a counter, it's the compare-and-swap token that detects edit wars; that's why it exists.
6. BIDS order differs from the code (code: slug, usid, bid, tbid, dvid — forensics last). Either's fine; the sweep should crown one.

Paste-ready deltas, your wording kept except the fixes:

* bver -- blub version number (initially 0) incremented on each edit; the compare-and-swap token that detects edit wars
* usid -- unique identifier for the seat, a client-minted uuid (slug plus usid is the primary key)
* dvid -- the ID of the device claiming this seat (really a browser install: a uuid in localStorage, so Chrome and Safari on one Mac are two dvids)
* anym -- anonymous signalment like "Mac Chrome en-US in Portland, OR or, by timezone, Los Angeles" (born with just the timezone till the IP lookup lands)
* blug -- slug of the auction whose blub this device is currently editing
* blid -- the usid this device is editing the blub as
* blip -- heartbeat timestamp: when this device was last seen with the blub editor open

Not applied to the file — it's your prose. With the README as spec, the sweep is now fully specified: aname-era names → slug/usid/snym/dvid/anym/blub/blug/blid/blip across Code.gs, app.js, stringles, quals, localStorage keys, and AGENTS.md, red quals first, tab reset free while no auctions are open, frontend and server in lockstep. Say go.

Point by point:

• dvid: conceded — the gloss already covers it.
• usid: agreed, and the reasoning is sound on both halves. The danger of a misreadable name is acting on the wrong meaning, and here the misreading lands on the right referent — a seat *is* this app's user-concept, so "user-seat-id" and "unique-seat-id" point at the same row. A pun that's true under both expansions isn't a hazard, it's slack. Withdrawn.
• bver: withdrawn — that was polish, not a problem.
• anym example, bl* order, bids order: settled.

One residue from the "purged user everywhere" premise, since the purge should be checkable: after the sweep renames every symbol, exactly two user-visible strings still say it — badUname's "username must be alphanumeric and start with a letter" and badUserid's "bad userid" (ERROR1512/1514). Those are your words, so the sweep needs either replacements from you or a ruling that the copy stays while the code vocabulary changes.

That's the last open cell. On go: the full rename lands as one pass — Code.gs, app.js, stringles, quals, localStorage keys, AGENTS.md — red quals first, tab reset (free, no open auctions), frontend and server deployed in lockstep.

Go. First, pinning the spec (final column orders from the README) and sizing the blast radius:

One straggler in comments (fixed next) — but the silence on the copy strings means the sweep renamed *dreev's words* too. Restoring those to exact original characters, with TODOs:

Frontend green with the purge quals in (612). Full suite:

Delete the tabs now — all four (auctions, seats, bids, devices). The new server is live and will rebuild them empty on first touch with the new headers; a watcher is polling the live API every 30s and will report the moment the smoke goes green. Nothing else is waiting on you except your usual git push of the frontend, which must land *after* the tabs are dealt with (until then, cached old frontends can't write anyway — every action hits the drift refusal, which is the designed behavior).

The sweep, complete and green locally (228 + 612 + 9 + 229 assertions):

• Renamed everywhere: usid (was userid), snym (uname), dvid (devid), anym (rig), blub (blurb), blid (bluid), blip (tblug), xbid (the bid column and wire field) — across Code.gs, app.js, stringles.js, index.html, style.css, and all four qual suites. Constants followed: ANYM/ANYMBASE/clampanym, myUsid(), anymOf, response fields anyms/claims keyed by usid.
• localStorage keys caught up too: tauction-usids (was the twice-stale tauction-pids), tauction-snym, tauction-dvid — existing browsers forget their seats, moot with no open auctions.
• The purge is structural now: a new frontend qual scans every runtime source (comments included, string literals exempted) and fails on any surviving old token — it ran red before the sweep and green after, and it's how "purged user everywhere" stays checkable instead of asserted.
• Your copy is untouched: seven ERROR15xx strings still say devid/userid/rig/username in your exact characters, under two TODO(dreev) comments in [stringles.js:212](stringles.js#L212) and [stringles.js:226](stringles.js#L226) — reword or bless at leisure; the purge qual deliberately doesn't police quoted copy.
• AGENTS.md's reference speaks the new vocabulary with "(was X)" lineage notes; the historical spec sections keep their era's names on purpose.
• Deployed: version @113 is serving. The smoke's refusal above is the schema-drift armor doing its job, not a failure.

Live smoke green — the tabs are rebuilt on the new schema and the deployed API answers in the new vocabulary end to end (all 7 live assertions). The rename is fully landed on the server side.

What remains is yours alone: push to main to ship the swept frontend (until then, visitors run the old client and every write meets the drift-era refusal — harmless with the field empty), and the two TODO(dreev) blocks in stringles where seven ERROR15xx strings still await your rewording.

That's just the watcher closing after its green report — no new information. Status stands: server live on the new schema, tabs rebuilt, your push and the stringles rewording are the only open items.

A verification request deserves a structural check, not a re-assertion — so the README's schema section becomes the enforced spec: a new qual parses the README bullets (names *and* order) and pins Code.gs's header constants to them, and the drift armor already pins the live sheet to those constants. Writing it:

Now it's provable rather than asserted. "Everything matches" was made structural: a new qual parses the README's Database Schema bullets — names and order — and pins all four of Code.gs's header constants to them, so the chain is:

1. README == code: the new qual, green — auctions slug, tini, tfin, blub, bver, tbed; seats slug, usid, snym, dvid, tini, tmod; devices dvid, anym, tini, tmod, blug, blid, blip; bids slug, usid, xbid, tbid, dvid, each compared cell-for-cell in order.
2. code == live sheet: Code.gs's own drift armor checks the actual header rows on every read, and the post-deletion live smoke is green — the rebuilt tabs were *created from* those constants.

Full suite: 228 + 617 + 9 + 229, all passing. So yes — and better than "now": the README schema section is henceforth the enforced spec, meaning a future edit to those bullets (reordering, renaming, adding a column) turns the suite red until the code follows, and vice versa.

One incidental: your latest index.html edit (the version bump) had left 404.html stale, so the suite refused until npm run sync-404 re-derived it — same as this morning, working as designed.

Rereading AGENTS.md is done (it's loaded above). The plan for this turn: dig through the current frontend, mock up two or three candidate aesthetics as real renderable pages, screenshot them headlessly, and present the stills for a thumbs-up/down before touching anything real. No production files get modified yet.

First, a look at the current state of the app.

Writing the three candidate theme stylesheets and the screenshot runner.

Three candidates are mocked up and staged for thumbs-up/down: https://claude.ai/code/artifact/1b8b90db-07ea-4f64-a9b7-822d5fd3a4f6

All four screenshots (baseline + three) show the same scene, staged on the *real* app — serve.py + fake-gas + headless Chrome, same rig as the story quals — with alice's bid sealed behind the decoy, bob as you with a committed bid, and carol still awaited. Each candidate is a pure CSS override sheet laid over the live DOM: no markup, logic, or microcopy touched, and nothing in the repo modified (rig and sheets live in the session scratchpad).

The candidates, per the three directions floated:

1. Arcade — brighter/cleaner/video-game-ish: candy palette on PICO-8 navy, chunky outlines, hard offset shadows, rounded sans. The one that would most require renegotiating the palette-fence qual (it's cool-toned by design).
2. Apple ][ — green phosphor, VT323, scanlines, vignette, inverse-video labels, amber you-star. Single-theme by nature; the blur-decoy looks great on phosphor; biggest legibility risk.
3. Explorable (Nicky Case) — sunny paper, hand-drawn wobble borders, half-degree card tilt, Patrick Hand labels, squiggle underlines. Closest in spirit to the current ledger, so the fence mostly survives.

One wrinkle found while rigging: adding yourself as the first roster row auto-latches your seat, so the rig's explicit star-click was releasing it — a rig bug, not an app bug.

(Rule 8's standing quiz: POLA — the Principle of Least Astonishment — belongs on that list.)

Which direction gets the thumbs-up — one of the three, a mix (e.g. Arcade's chunk on the ledger's warm paper), or none?

The "rig" in the last message was the *test-rig* sense — the scratchpad screenshot harness — not the retired vocabulary word. But the question of leftovers deserves an empirical answer. Checking what the vocabulary-purge qual covers and grepping the runtime sources:

No spots missed in the runtime sources — and the "rig" in the previous message was a different word entirely: *test rig*, the standard jargon for a purpose-built test apparatus (here, the scratchpad screenshot harness). Coincidental collision, not a leak. Both senses do share the nautical root — ship *rigging* → any fitted-out apparatus — with the retired tauction "rig" coming from the *gaming-rig/battlestation* branch (a device's setup, hence its self-description) and the harness sense from the engineering branch.

The full sweep, for the record:

• Runtime sources (app.js, stringles.js, Code.gs, index.html, 404.html, style.css, serve.py, manifest.json): zero hits, and the vocabulary-purge qual at [frontend-quals.js:379](quals/frontend-quals.js#L379) pins this structurally for the five it scans.
• quals/frontend-quals.js (2 hits): the ban list itself and its comment — the purge machinery, necessarily naming what it bans.
• AGENTS.md (1 hit): the deliberate "(was rig)" era-note in the anym definition — the stated convention that historical specs keep their era's names.
• [sourcery.html](sourcery.html): 61 hits — the one genuine judgment call. It's not on the purge qual's scan list, but it *is* served to end users via the footer link. It reads as a chronicle of past agent reports, where "rig" appears in period quotes ("the client self-reports its rig at claim/bid time"). Rewriting those would falsify the record; leaving them means the old vocabulary survives on a user-reachable page.

So: is sourcery.html history (exempt, and worth a pinning comment in the purge qual saying so) or user-facing vocabulary (add it to the scan and purge the 61)?

The wrinkle was a rig bug — the fix is already in (the rig now relies on the auto-latch instead of star-clicking). The real question underneath: is the *app behavior* the rig tripped over (first-add auto-latches; clicking your own star releases) actually pinned by quals, or was the rig the first thing to ever walk that path? Checking coverage:

No fix or quals needed in the repo — the wrinkle was entirely a bug in the throwaway screenshot rig, and the app behavior it collided with turns out to be fenced from every side already:

• The auto-latch itself — scene 2j at [frontend-quals.js:3219](quals/frontend-quals.js#L3219): first add on a memoryless browser is you (gold star, no click), later adds are other people, and the self-add registers no server claim (a real dree on another device can still take the seat).
• The hint-mismatch side — a facilitator seeding a roster never self-claims; the 2j comment notes story 3 pins that.
• The gesture the rig fumbled — [frontend-quals.js:5751](quals/frontend-quals.js#L5751): clicking your own lit star releases to nobody, no editor. That's the pinned radio behavior the rig's redundant "claim" click ran into.
• The trap's boundary — [frontend-quals.js:2875](quals/frontend-quals.js#L2875): a bid locks the radio (still lit, no release), so the release-by-toggle exists only pre-bid.
• The recovery — [frontend-quals.js:4417](quals/frontend-quals.js#L4417): released seats re-latch the unseated automatically.

The rig's fix (already applied in the scratchpad): drop the star click and wait for the auto-latched editor, which is exactly what the qual suite's own addName flows do. Qualing the rig itself would be qualing the camera — it's session-scratchpad tooling that dies when the mockup phase ends. If a standing "brochure shot" script ever moves into the repo, it earns quals then; YAGNI until.

One observation worth a design glance, not a qual: a human can hit the same trap the rig did — add yourself (star lights on its own), not notice, click the gold star "to claim," and silently become nobody. The release is visible (star hollows, editor vanishes) and pre-bid only, so it's arguably fine as designed. Flagging it because the rig stumbled there; no change proposed.

One claim in that answer was taken on faith rather than read: "story 3 pins that side" (the facilitator-with-a-hint never self-claims) came from a comment in 2j, not from the story-3 code itself. And the *exact* path the rig walked — auto-latch, then immediately toggle your own star — was asserted covered by 5751, which actually releases after an *explicit* claim. Verifying both properly:

Now yes. The "sure" in the previous answer rested on two links that hadn't been read, only inferred — both now verified, plus one imprecision corrected:

1. "Story 3 pins the facilitator side" — was taken from a comment, now read. [story-quals.js:1237](quals/story-quals.js#L1237): alice, carrying her remembered hint, adds dee and evy and the qual asserts "alice is nobody here until her name is on the ledger" — no self-claim on hint-mismatched adds — then "adding her remembered name back re-latches automatically." Pinned, both halves.

1. The 5751 citation was imprecise. That qual releases after an *explicit* claim; the rig released after an *auto-latch*. The claim survives anyway, structurally: toggleTu has one code path — myUsid() === usid → release — with no branch on how the latch happened, so the two flavors cannot diverge. And the dLate scene at [frontend-quals.js:825](quals/frontend-quals.js#L825) releases a localStorage-seeded seat the server never saw claimed, which is the same state the auto-latch leaves.

1. New find from the re-check, closing the last unexamined layer: the rig's exact wire-level act — sending release for a seat with no server-side claim — is a designed no-op with its own comment in [Code.gs:727](apps-script/Code.gs#L727) ("a merely-local soft claim must release without drama"), zero writes ("not even tmod"), and a direct server qual at [gas-quals.js:546](quals/gas-quals.js#L546): "releasing an unheld seat is a no-op."

So the conclusion stands — rig bug, fixed in the rig, app fenced at the gesture layer, the state layer, and the wire — but two of the fence posts were cited on faith the first time and are cited on read code now.

That error is the client's state-shape assert — its own hint text suspects a stale server deploy. Tracing it from the client side, then probing the live API directly:

Not caching — the opposite of the hint's guess: production's *client* is two commits behind while the *server* is current.

The evidence:

• Live Pages serves v2026.08.05-a, and the live app.js contains zero occurrences of anyms — it's the pre-refactor client. The local tree stamps v2026.08.05-d.
• origin/main sits at d2a2ae9 Refactoring stragglers; the two schema-refactor commits — a94f220 Better device blurbs aka rigs and fda84c4 Bigger refactor of db schema — are committed locally but never pushed.
• Meanwhile the deployed Code.gs answers in the new vocabulary (the probe above returned seats/blub/bver/anyms/...), because npm run deploy ships from the working tree via clasp and never consults git. The server got the refactor; the site didn't.

So every production visitor's old client runs its old assertState against the new server's shape, fails, and banners ERROR2157 — whose hint text ("is the deployed Code.gs current?") was written for the usual direction of skew, since Code.gs deployment is the manual step. This time the skew is reversed, and the hint points exactly backwards. Production is effectively down for everyone, not just that browser, until the push.

Fix: push main (yours per rule 14 — no mutating git from here). Pages rebuilds in about a minute; app.js carries GitHub's 10-minute max-age, so a hard reload inside that window, a normal one after. Note the working tree also has uncommitted edits (index.html/404.html/README/frontend-quals) — whatever's intended there wants committing first so -d actually ships.

Two follow-ups worth considering, both yours to call:

1. The hint text could stop assuming a direction — something era-symmetric like naming both suspects. It's on the assert-family operator channel, so it's allowed to be English.
2. npm run deploy could refuse (or warn) when HEAD isn't contained in origin/main — the guard that would have caught this skew before the live smoke passed against a matching local client.

Both changes approved — implementing with the safest designs, QDD style (red quals first). Reading deploy.js and checking what qual coverage already exists around it and around assertState's rejection behavior:

deploy.js has no qual coverage at all. Looking at the existing assertState rejection quals to join their pattern:

Red confirmed for the guard — and requiring deploy.js is now inert, which was the prerequisite. Now the hint-pin red:

Both changes are in and green, and the guard's live verdict against the real tree is exactly the refusal it was built for — dirty files named, marching orders attached. Also visible in that output: pushed: true, so the push landed since the diagnosis and production's client should be current within the cache window.

What changed:

• [app.js:352](app.js#L352) — the hint now suspects both eras with a remedy apiece: bad state shape — is this page stale (hard-reload; is main pushed?) or the deployed Code.gs (npm run deploy)? Pinned by a new assert in the existing skew scene ([frontend-quals.js:2290](quals/frontend-quals.js#L2290)), which was red against the old one-directional text before the edit.
• [deploy.js](deploy.js) — restructured so requiring it no longer *executes* a deploy (that alone made it qualable), plus eraGuard: a pure function over git status --porcelain text and the merge-base --is-ancestor bit. It refuses on any dirty tracked file (Pages ships everything tracked), on untracked files under apps-script/ (clasp would ship bytes no commit pins), and on HEAD not contained in origin/main — enforcing push-then-deploy, whose transient skew window is the direction the new hint describes. It runs *first*, before even sync-404, so a refused deploy mutates nothing. Git calls are read-only (status/merge-base).
• Six new serve-quals ([serve-quals.js:31](quals/serve-quals.js#L31)) drive eraGuard through all its scenes — clean-and-pushed stands aside, each refusal names its cause, untracked files outside apps-script/ don't block. Red first (TypeError on the missing export), green after.
• [AGENTS.md](AGENTS.md) deploy section documents the guard and the enforced order.

Gate: gas 228, frontend 618, serve 15, story 229 — all four suites, exit codes checked individually. One mid-gate red was yours, not mine: the -e version bump in index.html without a re-sync; npm run sync-404 re-derived 404.html per the documented mechanic, which is why it shows modified.

If-statement accounting, per rule 9: three new — the two refusals inside eraGuard and the refuse-or-proceed check in main(). All are loud-refusal paths; no behavior forks.

One known softness, chosen: the guard trusts the locally-known origin/main without fetching, so a push from a *different* machine could leave it refusing spuriously — a loud false alarm, which is the safe direction. Deploys from this tree will refuse until the current batch is committed and pushed, which is now the intended shape of things.

Because that string is on the assert channel, which is the one documented English carve-out — and both the channel and its English were established before this edit; only the words changed.

The specifics:

• The slot predates the change: assertState's message was already inline English in app.js ("bad state shape — is the deployed Code.gs current?"), not stringles copy. The edit swapped the words in place.
• The architecture notes in AGENTS.md draw this line explicitly: "The error channel's only remaining English is the assert-family operator diagnostics (schema drift, covenant, armor, patch-ghost), marching orders that must stay readable raw in a terminal." assertState is that family on the client side — stringles owns only the ERROR2157: prefix (e2157), and the assert's own text rides through it.
• Rule 6 covers words "the end user is intended to read." An assert firing means the contract broke; nobody is *intended* to read it, and its actual audience is whoever is debugging — the marching orders name literal commands (npm run deploy, a git push), which Latin would render useless to exactly that reader.
• The banner surfacing of this English is ratified design, not new leakage: the pre-existing skew quals (now around [frontend-quals.js:2270-2305](quals/frontend-quals.js#L2270)) have always pinned assert: bad state shape appearing in the banner verbatim.

That said, there's a real design fork available if the reachability doctrine should trump the assert carve-out here: this particular assert *is* end-user-reachable in practice (production just proved it), so it could be reclassified — a refusal code in stringles with Latin for the bannered face, and the English marching orders demoted to the console where only operators look. That's a channel redesign touching the existing skew quals, so it's your call, not a default. Want it?

Right. The reachability split is exactly the design: stringles' gameRefusals are what honest play can surface (races, length limits — Latin-faced, user-worthy words), and the assert channel only fires when the deployment itself is unhealthy. For this particular assert, the complete trip list:

1. Era skew — stale page vs. deployed Code.gs, either direction. That's the broke-prod case you just lived, and the era guard now pins it down to the transient push-then-deploy window.
2. Hand-edited sheet data — someone date-formats or blanks a stamp cell, sorts rows, etc. The quals' "human-edit belt" scenes pin that these banner the same assert. Still operator-caused breakage, just via the sheet rather than a deploy; it's whoever holds edit rights on the sheet, not players.
3. A genuine server bug returning malformed state — which is the assert doing its actual job.

None of those are reachable by a user playing the game against a healthy deployment. So: users see Latin or nothing; the English shows up only when the operator has something to fix, and the words are the fix instructions.

Arcade it is. This is a real retheme with several load-bearing couplings — the palette fence qual (which currently *enforces the ledger* and must be re-derived for arcade, not deleted), the geometry laws that story quals assert at phone widths, dark theme (the mockup only showed light), and vendoring Nunito (no CDNs on Pages). Mobile verification is part of the definition of done, per your condition.

Palette first — a validator using the fence's exact math (hue/sat bands, WCAG contrast), run over the full candidate token set for both themes, so the tokens are settled before touching style.css:

Palette clean under fence math with real margins in both themes. Now flipping the fence itself — red first:

Fence red as intended — every ledger neutral flagged. Now vendoring Nunito (latin subset, four weights):

The at-wrap, tooltip, thead/th, banner, and the reveal button:

The pencil, then manifest + version bump + sync:

index.html changed under the edit (it's open in your IDE) — re-reading before touching it:

You already bumped it to -b yourself — index.html stays untouched from this side. Syncing 404 and running the gate:

The legend's ★ needs re-centering under the new star size and font metrics. Measuring the actual offset:

Same mono-calibrated factor in the revealed-state check — re-deriving identically:

Seeding shortcut failed; probing via the proven UI-driven staging instead:

Green with the new pin (230 story asserts now). Final camera walk for the record and the artifact:

Arcade is shipped — real style.css, both themes, all four suites green (1,091 assertions), and mobile is now *verified*, not assumed: https://claude.ai/code/artifact/1b8b90db-07ea-4f64-a9b7-822d5fd3a4f6 has the five proof shots (desktop light/dark, 390px light/dark, 320px worst-case).

The mobile condition earned its keep. The first phone shots exposed a bug: at squeezed widths a name cell painted clean across the bid column — the input's intrinsic ~200px was driving the flex line wider than its shrunken column. It turned out to be latent since the ledger era (the coarse-pointer suite never staged that exact squeeze), merely surfaced by Nunito's wider metrics. Fixed with one declaration (the cell is its column: width: 100%) and pinned by a new 320px containment qual, red-then-green.

What landed:

• [style.css](style.css): arcade tokens both themes (dark is new since the mockup — ice ink on deep navy, accent lifted to candy pink; validated at fg 15:1, muted 7:1, accent-ink 7.2:1), chunky ink outlines, hard offset shadows, pill buttons, dashed-pill resting REVEAL, coin-gold stars with a new --star-rim token, Nunito vendored as a single 39KB variable woff2 ([vendor/nunito-OFL.txt](vendor/nunito-OFL.txt)).
• The palette fence flipped, not loosened: the warm law became the navy law (blue ≥ red on every neutral, both themes), the indigo ban survives unchanged — arcade's blues sit at hue ~210–221, deliberately short of the 225 line. Red first against the ledger, green now.
• Re-derived qual pins, each a ratified-retheme recalibration, listed for your diff review: cell border 1px→2px, star height 36→38, star stroke = rim-gold, tooltip probe aims at host centers (corner probes miss pill shapes), the three 1.8× growth factors → 1.4× (they were mono-wrap-calibrated; the no-overflow conjunct is the real law), legend axis re-measured.
• [manifest.json](manifest.json) colors updated; 404 synced; version stamp left at your -b.

One design flag, yours to rule on: the arcade accent (#e11d48 raspberry) is now a near-neighbor of the Primer error red (#d1242f), so the awaiting-slot's breathing pulse and the error rings share a color family — the ledger's teal kept them far apart. In motion they read differently (slow 3s breathe vs. hard ring+glow), and carol's pink-tinted row in the stills is exactly that pulse caught mid-breath. If it bothers on the live page, the pulse ceiling could soften or the accent could shift toward coral; nothing needs to change for the suite.

Something is already serving port 8000 — verifying it's this working tree with the arcade CSS before pointing at it:

http://localhost:8001/ — serving and verified (arcade CSS live, Nunito woff2 answering 200).

Two notes for the test drive:

• Port 8000 was skipped because your reverbee project's server is already sitting on it; tauction's serve.py is running on 8001 in the background instead. It'll keep running until you kill it (lsof -i :8001 finds it).
• The page talks to the real deployed API (the API constant in app.js — era-matched since your push), so any auction you poke at creates real rows in the production sheet. A throwaway slug is the way to kick the tires. Dark mode follows your OS setting; the awaiting-slot's raspberry breathe is the pulse flagged earlier — judge it in motion.

Ruling received: accent goes green. The full-accent swap is the coherent read (the error pair is Primer-pinned by your own ruling, so the raspberry side moves) — and there's ledger precedent: the petrol-teal era already lived with a green-adjacent accent beside the ok-green, with solid-vs-dashed carrying the bid-in distinction. Validating an arcade emerald against the fence math first:

Gate is fully green on the emerald accent. Re-shooting the verification set, then researching the error-red question properly:

Emerald is live — refresh http://localhost:8001/ to see it. All four suites green again (1,091 assertions), fence passing at 4.78:1 light / 8.84:1 dark on accent ink, and the artifact now shows the emerald build: https://claude.ai/code/artifact/1b8b90db-07ea-4f64-a9b7-822d5fd3a4f6

On the research question — what arcade-styled products do about error-red — four patterns recur, and the emerald swap happens to land on the main one:

1. Red is reserved for exactly one meaning. Duolingo is the canonical case: green is the brand *and* the success color, while red belongs only to hearts and mistakes — orange gets streaks, yellow gets XP, purple gets leagues. No red anywhere decorative, so when red appears it can only mean one thing. That's the regime tauction is now in: Primer red = errors, full stop.
2. The error red is warm-shifted. Duolingo's #FF4B4B is a hot coral — alarm temperature, not candy temperature — which keeps it apart from any brand color even at a squint. The Primer pair already sits in that warm-alarm zone.
3. Hue never carries the meaning alone. The playful-UI literature is unanimous that color must be paired with an icon, label, or shape change, and game-accessibility guides say no color-only signals, tested against the three common color blindnesses — notably, Duolingo gets criticized on exactly this: red/green result boxes at 3.6:1 and 2.7:1 are rough on deuteranomaly. tauction is already multi-channel here: errors are a hard ring + glow + ✗-bannered words; bid-in is a solid filled card with text; awaiting is dashed and empty. A red-green-blind player distinguishes every state by shape and fill without ever consulting hue.
4. Motion grammar differs by meaning — games use shake/vibration/sound for failure with animation as a supplement, never the carrier. tauction's calm 3-second breathe (waiting) vs. static hard ring (objection) already keeps those grammars apart.

So the industry answer to "how do you keep error-red distinct" is mostly "don't let anything else be red" — which is what green-as-accent just bought. The one place tauction now rhymes with Duolingo's weakness is green-accent-next-to-green-ok, but unlike Duolingo's color-only result boxes, the dashed/solid/filled distinctions here carry the meaning independently of hue.

Sources: Duolingo brand palette, Duolingo: Gamification as Design Language, UX Planet Duolingo analysis, Tubik: UX Design for Error States, Filament Games: Hidden Barriers in Game UI, Pope Tech: accessible animation

That's the Sheets API read quota — and it's structural, not a glitch. Grounding the math in Code.gs before the assessment:

Confirmed structural. The assessment:

What happened. Every API request — poll, heartbeat, action — does exactly one batchGet ([Code.gs:273](apps-script/Code.gs#L273), memoized per execution only, no cross-request cache). The web app executes as you, so *every visitor's reads count against your personal quota*: Sheets API allows 60 read-requests per minute per user, and "per user" here means the one executing account, not the visitor.

The math. One open tab = a state poll every 5s = 12 reads/min. An open blub editor adds its 10s heartbeat = 6 more. So five-ish active tabs saturate the entire quota for everyone. Right now that budget is being spent by: your production tabs, anyone else peeking at the new theme, *and* the localhost:8001 tab — the dev server serves local files but its API constant points at the real deployment, so dev polling spends production quota too.

Severity. Transient and self-healing — the window resets each minute, the next poll usually lands. Nothing is corrupted; it's purely read-side throttling. But it will recur any time a handful of tabs are open at once, which for a tool meant for group ceremonies (everyone opens the page and stares at it, polling) is the *normal* load shape, not a spike.

Remedies, ranked (none applied — your call):

1. Server-side micro-cache (the real fix): CacheService holds the batchGet result for ~4s; every concurrent poller inside the window shares one read. Total load becomes ~15 reads/min *regardless of tab count*, and a 4s-stale answer is invisible under a 5s poll cadence. Design care needed: only the pure state read serves from cache; every write bypasses and invalidates it, so the truth model stays honest.
2. Vocabulary fix alongside: the raw GoogleJsonResponseException text reaching the banner is off-channel — a quota refusal is honest-play-reachable, which by the reachability doctrine makes it a gameRefusals code deserving Latin copy and a client retry-next-poll instead of Google's stack-trace prose.
3. Slower POLL_MS (10s): halves load, worsens liveness for everyone, and only doubles the tab ceiling — weak on its own.
4. Quota increase: not realistically available — the script runs on the default GCP project, which doesn't expose quota editing; switching to a standard project is real plumbing for a 5× at best.
5. The nuclear architecture option, noted for completeness: browsers can read the public sheet's CSV export directly with zero API quota (the appendix documents this) — polls could bypass Apps Script entirely and only writes go through it. Big change, probably not worth it while option 1 exists.

Recommendation: 1 + 2 together — the cache kills the recurrence, the refusal code makes any residual throttle speak the house vocabulary. Say the word and it's a red-qual-first implementation.

Yes on 1 and 2 — starting now, red quals first. On 5 there's a consequence that needs your ruling before it gets built (detail at the end): any live CSV read path requires publishing the SHEET_ID in app.js, which makes the sheet — sealed bids included — one Network-tab click away for every visitor, versus today's honor-system-but-unadvertised link. Meanwhile, reading the server internals to place the cache and the refusal:

Red confirmed. Implementing the fake's side first:

The client's words for the refusal — Latin, per the house law:

The restamp deserves its own fence — pinning it on the write's *own* response:

The count fence caught the new assert site, as designed — registering it:

My own gate scene reds — instrumenting it briefly to see which half fails:

All three shipped, red-qual-first throughout — the four-suite gate is green twice over (244 gas + 625 frontend + 15 serve + 230 story = 1,114 assertions).

1 — The poll collapser. State reads for a slug inside a 4s CacheService window share one batchGet; only the pure read path caches, every write invalidates its slug, and the chosen trade — out-of-band sheet edits lag ≤4s — is pinned by a qual so it stays chosen. The fake grew an *honest* CacheService (persistent, TTL'd) with a controllable clock: by default every request hops past the TTL so the rest of the suite keeps fresh-read semantics; the cache quals freeze time to hold a window open.

2 — quotaChoke. The exhausted meter now refuses on the game channel (five honest tabs can hit it) with Latin copy: *Tabularius anhelat — mox sponte iterum conabitur*. The coverage ledger did its job twice: qual 19 forced the provocation qual, and qual 20's throw-site census caught both new non-code throws and made them register by name.

5 — The pulse. One design pivot from the raw pitch, same benefit: instead of assembling state from CSV client-side (which would mirror the whole read model into app.js), a pulse tab holds one global wver, bumped inside every write's lock. Clients poll that cell through the sheet's gviz CSV endpoint — the visitor's quota, not yours — and pay an API read only when it moves, when someone's at the desk (presence freshness is clock-run, so only a real read can calm the pencil), or when no real snapshot is in hand. Steady state: zero API reads per tab, down from 12/min. Things the quals caught en route: no-op writes must not bump (the no-op-mutates-nothing law — an existing qual objected), the op's own response needed its wver restamped (else every client chases its own write), and headers=1 is load-bearing on gviz (your armor makes every column plain text, and unhinted gviz swallows whole columns as headers — pinned by curl against the real endpoint). State now carries sheet + wver, so ?api= test deployments pulse against their own sheet with no baked constant.

Four frontend pins were re-derived where the pulse genuinely improved the law: a warm cache now ungrays on pulse confirmation with zero API reads, the return-glance confirms via the pulse leg, gated transport death speaks ERROR2159, and the gate honors the reveal-drumroll exception the adoption path already had.

Two operational notes. First: localhost:8001 will banner ERROR2157 right now — the new client demands sheet/wver that the deployed Code.gs doesn't send yet. That's the guarded skew direction, correctly described by the two-suspect hint, and it heals at the next deploy. Second: the deploy itself — era guard first (commit + push), then npm run deploy; the pulse tab births automatically on the live sheet's first request, a *new* tab, so no drift ceremony and no data deleted. The hidden-tab title peek stays deliberately ungated (1 read/min/tab), and README's schema section + the specTabs weld now speak all five tabs.

Double-checking while your deploy runs — read-only from here (clasp ships the working tree, so no edits mid-deploy). The one file none of the offline suites execute is [live-quals.js](quals/live-quals.js), which your deploy is about to run against the real API — reading it first, since a stale expectation there fails the deploy at the smoke step:

Everything checks out — and the jank has a real diagnosis. The double-check first, then the gavelspinner.

Double-check results. All four suites fresh-green *after* your stringles/README edits: gas 244, frontend 625, serve 15, story 230 — 1,114 assertions — plus index/404 parity confirmed. Your reworded PULSE bullet still parses in the README⇄Code.gs schema weld (the suite proves it). [live-quals.js](quals/live-quals.js) — the one suite your deploy runs that the offline gate doesn't — is compatible: its shape checks tolerate the new sheet/wver fields, its smoke writes run through mutate and will birth the pulse tab on first touch (a *new* tab, so no drift marching orders), and its self-healing release preamble rides the unheld-release no-op that got re-verified this week. The qual inventory added across the whole quota+arcade arc: +16 gas (cache collapse/invalidation/TTL/out-of-band lag pin; quotaChoke provocation + transience; the pulse suite — every-write-bumps, no-op-never-bumps, own-response restamp, corrupt-cell refusal asked up front), +7 frontend (the pulse-gate scenes: no-news zero-read, moved-pulse one-read, presence-holds-gate, aging-out discovery, pulse weather; plus the two-suspect hint pin and the navy fence flip), +6 serve (era guard), +1 story (coarse-320 cell containment), and the re-derived pins are all commented with their rulings.

The gavelspinner: nothing was lost, but the jank is real. The record is clean — the only blur that ever existed in style.css history is the sealed-decoy blur ([still live](style.css#L1172)), and the busy treatment (tiles at 0.35 opacity + gavel) is byte-identical from "Tweaks, fixes, polish" through the arcade retheme. What changed is what's *underneath* the overlay. Three concrete causes:

1. Opacity dims, but doesn't dissolve, arcade chrome. The ledger's thin sand-on-cream cells melted into uniform fog at 35% — a calm field for the gavel. Arcade's 2px navy outlines, hard shadows, and green cards keep their full *internal* contrast at 35% — the dimmed layer stays busy and structured, and the gavel hammers over noise. Your blur instinct is the right remedy even though it never existed: blur destroys edge structure; opacity can't.
2. The gavel wears off-vocabulary chrome now. It carries a *soft* drop-shadow — banned everywhere else by the arcade thesis (hard offsets only) — so it reads as a sticker from a different cartoon floating over the page.
3. No separating plane. The gavel sits directly on the dimmed rows; there's no veil creating page-below/glass/spinner-on-glass depth, which is what makes overlays read as intentional rather than pasted.

The remedy, ready to build on your word (not touching the tree while clasp may still be reading it): a frosted veil on #status.stale — backdrop-filter: blur(~2.5px) plus a faint paper tint, riding the same 0.3s no-flash delay, its z-index consciously joining the z-ladder qual — and the gavel's pieces get 2px ink outlines with a hard offset shadow, making it the same game-sprite species as the rest of the cabinet. Story quals would pin the veil in real Chrome (jsdom can't see pseudo-elements). One side-note: with the pulse gate, the spinner also *appears* far less often — quiet ticks confirm via CSV and never gray at all — so whatever ships here will be seen mostly at arrivals and writes.

Rereading AGENTS.md — done (anti-magic: one busy mechanism, not two stacked; anti-postel: pin the CSS truths; nominology for anything new; no mutating git). Plan: frosted veil replaces the tiles-dim as *the* busy treatment (one mechanism instead of two), gavel becomes a proper ink-outlined sprite with a hard shadow, veil's z joins the ladder consciously, and one DRY improvement spotted en route — the weather ritual is now duplicated in two catches and gets a single named home. Checking what depends on the tiles-dim before killing it:

The weather ritual's single home in app.js:

The veil is in, quals-fenced, both themes verified, and the artifact record is updated at the same URL: https://claude.ai/code/artifact/1b8b90db-07ea-4f64-a9b7-822d5fd3a4f6

What changed, red-quals-first (three new story pins, red before the CSS existed):

• One busy mechanism. The tiles-dim is retired outright; #status::before is now a frosted pane — backdrop blur + paper tint, riding the same 0.3s no-flash delay, pointer-events: none (a veil is weather, never a click shield), and registered on the z-ladder at 1, under the gavel's 2. The jank's cause is gone structurally: blur dissolves the 2px navy outlines that opacity could only dim, so the gavel now hammers over calm glass instead of chunky noise.
• The gavel is a sprite. Four zero-blur drop-shadows ink its silhouette — the same outline vocabulary as every arcade cell — plus a hard ground shadow. The old soft halo was the last soft shadow in the cabinet; the thesis is now unbroken.
• One DRY improvement applied en route (the AGENTS.md-minded pass): the transport-death ritual (console + veil + paintWar) was duplicated across the pulse and state-fetch catches — it now lives once as weather(), which both legs die into.

Gate: gas 244, frontend 625 (z-ladder and no-battles laws both accepted the veil), serve 15, story 233 — 1,117 assertions. Since style.css and app.js are Pages-side only, no clasp redeploy is owed — commit and push publishes it; the deploy you just ran is unaffected.

Two observations from the improvement pass, noticed but deliberately not acted on:

1. refresh() now manages its refreshing flag at three manual reset sites (the two gate early-returns plus the finally). Correct today and qual-covered, but a whole-body try/finally would make a leaked flag *structurally* impossible — a candidate for its own small pass.
2. Story-quals' PHONE/NARROW viewport constants are fine-pointer by default, with coarse-pointer opt-in via hasTouch per scene. A viewport named PHONE that isn't pointer: coarse is exactly the trap the screenshot rig fell into earlier. Flipping the default would shift many scenes' media regime, so it wants deliberate treatment rather than a drive-by.

Documented in the repo and here — and the direct answer is no: npm run deploy is only for server (apps-script/) changes. Push alone ships everything else. Adding the decision tree to AGENTS.md's agent-maintained section:

The workflow is now documented in [AGENTS.md](AGENTS.md) (a "The workflow" section above the deploy details). The short version, correcting the premise:

Two independent ship lanes, one per runtime:

1. Frontend-only (index.html + npm run sync-404, app.js, style.css, stringles.js, vendor/, manifest.json) — commit + push. That's the whole ship. Pages publishes in ~a minute; no npm run deploy involved. Today's veil change is this lane.
2. Server (apps-script/) — commit + push *first* (the era guard refuses otherwise), then npm run deploy, which does everything else: sync-404, full quals, clasp push, redeploy of the same /exec URL, live smoke.
3. Schema — lane 2, plus the delete-these-tabs marching orders from the live smoke if an *existing* tab's header changed. New tabs (like pulse just now) are free.
4. Both sides — push, then deploy; the brief new-page/old-server window in between is exactly what ERROR2157's two-suspect hint describes, and it heals when the deploy lands.

So "commit all changes, then npm run deploy each time" was the expensive habit — every frontend-only deploy was spending the full quals + clasp + smoke cycle (that's the "takes forever") to re-ship an unchanged server.

One improvement worth building, if the habit is hard to break: npm run deploy could learn to short-circuit when the server is already current — after each successful smoke it records a hash of apps-script/ in a gitignored stamp file, and a later run whose hash matches exits immediately with "server unchanged — frontend ships by push alone." Missing or mismatched stamp always deploys (the safe direction), so it can never skip a real change; it only refuses to re-ship bytes it just shipped. Small, one dotfile, red-qual-first. Want it?

Building it red-first. The fence quals go next to the era-guard quals in serve-quals:

All four suites once more for the record:

One sentence in the workflow doc so the stamp's effect on lane 1 is recorded:

The stamp is in, red-quals-first, full gate green: gas 244, frontend 625, serve 19, story 233 — 1,121 assertions.

How it works: after each successful live smoke, deploy.js writes .deploy-stamp (gitignored) holding a content hash of every file clasp ships — name plus bytes, order-independent, dotfiles excluded so a stray .DS_Store can't move it. On the next run, matching bytes exit up front in about a second with "server unchanged — nothing to clasp; frontend changes ship by git push alone." A missing or mismatched stamp always deploys, so the skip can only ever suppress a re-ship of bytes it just smoked, never a real change — fresh clones and multi-machine deploys land on the safe side of that asymmetry automatically.

Two deliberate details:

• The stamp check runs before the era guard. A dirty tree whose server bytes are already live gets the *useful* answer (push alone suffices) instead of "commit first" — the guard still stands for anything that actually needs clasping.
• If-accounting (rule 9): one new if (alreadyShipped → early exit), one filter predicate (dotfiles), and a catch-to-null on the stamp read — the missing file is a defined first-run state, not a fallback, per the comment.

Four new serve quals pin the semantics: content-addressing (order can't move the hash, any byte or missing file does), match short-circuits, mismatch-or-missing deploys. The workflow doc in AGENTS.md now notes that an accidental npm run deploy after a frontend-only change is harmless.

One expectation to set: the *next* real deploy still runs the full cycle — no stamp exists until a smoke passes — and stamps itself at the end. From then on, the habit is free.

Diagnosing from the Actions side — gh is fair game per the house rules:

Interim report while the queue grinds — the rerun itself is still sitting in queued at the workflow level, which is itself more evidence for the diagnosis.

Diagnosis. The build succeeds and the artifact uploads; the failure is deploy-pages polling deployment_queued for its full ten-minute budget without GitHub ever starting the deployment. Three in a row, and the trend line tells the story: 48s deploys yesterday, 7m00s at 09:19 (barely passed), timeouts ever since. The repo is 2.2MB, so size is ruled out; githubstatus.com claims all-operational, but status pages trail reality — this is GitHub-side Pages/Actions queue congestion, plausibly churn from the same runner migration the Node-20 warning announces.

Live impact, precisely bounded. tauction.dreev.es serves v2026.08.06-b — the emerald/veil-era pushes aren't live yet. The skew is the safe direction: the live client ignores the new server's additive sheet/wver fields and polls the classic way (the server-side cache still shields the quota), so nothing is broken for visitors; they just see the older look until a deploy lands.

Done and staged:

• The failed run was rerun (gh run rerun); a background watch will report when it resolves either way.
• [.github/workflows/pages.yml](.github/workflows/pages.yml) is written and ready: the modern Actions pipeline on current majors — checkout v7, configure-pages v6, upload-pages-artifact v5, deploy-pages v5, all pinned from releases/latest rather than memory — with a plain static upload (nothing here needs Jekyll) and concurrency so stacked pushes supersede instead of queueing. This permanently retires the Node-20 deprecation warning, which is aimed at exactly the pinned-by-GitHub legacy pipeline.

To adopt it: commit + push (yours), then the one-time flip of Settings → Pages → Source to "GitHub Actions" — or the one-liner in the file's comment (gh api -X PUT repos/dreeves/tauction/pages --field build_type=workflow). Until the flip, both pipelines run per push; the flip retires the legacy one.

Honest caveat: the new pipeline rides the same deployment backend, so it can't cure today's queue congestion — that part resolves on GitHub's side (the rerun will tell us). What it buys is getting off the deprecated path, explicit control, and no more warning.

No — that framing conflates two things. Both options deploy on push to main. The choice is only *whose pipeline* runs when the push lands:

• Legacy (today's setup, zero config): on push, GitHub runs its own internal pages-build-deployment — a Jekyll build plus deploy, with action versions GitHub pins and you can't touch. That's the thing currently timing out and the thing the Node-20 warning is aimed at.
• Actions source (the staged pages.yml): on push, the repo's own workflow runs instead. Identical experience — push equals ship — but the pipeline is yours: current action versions, no pointless Jekyll pass, stacked pushes supersede instead of queueing.

So, needed? Strictly no. Today's outage is GitHub's deployment queue, which both paths share — the rerun is *still* sitting in queued after fifteen-plus minutes, which is GitHub's problem and resolves on their side regardless. And the deprecation warning is against GitHub's own pinned actions, which they'll migrate themselves eventually; it's noise, not breakage.

The honest case for switching is smaller but real: you stop depending on a pipeline GitHub is visibly neglecting (the warning *is* the neglect showing), you shave the Jekyll build out of every deploy, and you gain concurrency control so a burst of pushes deploys the newest instead of queueing all of them — which is exactly the failure texture of this morning.

If you do want it, order matters: flip the setting first (gh api -X PUT repos/dreeves/tauction/pages --field build_type=workflow), *then* commit and push pages.yml. That order avoids a window where both pipelines fire and the new one fails with a red X because Pages isn't in workflow mode yet. Flipping the setting is one reversible API call, but it's your repo config — say the word and it's flipped, or ignore the staged file entirely and today's incident heals itself when GitHub's queue drains; the file sits inert until committed.

Flip confirmed. Next: commit everything and push. That push triggers pages.yml and ships the whole backlog (arcade veil, pulse client, workflow file). Say when pushed and the run gets watched to green here.

On npm run deploy: only needed when apps-script/ changed — but running it every time is now harmless (the stamp no-ops it in ~a second when the server's unchanged). So if one rule is wanted: always run it; it's free when there's nothing to ship.

Pages status: the new pipeline works (build + upload fast and clean) but its deploy step died the same way — stuck in deployment_queued. That confirms it's GitHub's deployment backend for this site, not the pipeline; wedged since ~10:47 UTC. A rerun is watching in the background. Live is still v2026.08.06-b vs your -f; the skew direction is safe (old client tolerates the new server). If the queue stays wedged another hour, the remaining levers are GitHub support or a Pages disable/re-enable — the latter briefly drops the custom domain, so that's yours to call.

Still wedged — the fresh dispatch went back to the classic signature: ten minutes in deployment_queued, never picked up. That's GitHub's deployment backend for this site, now stuck ~3.5 hours; the pipeline modernization is fine (build+upload in seconds) and there's nothing left to fix on the repo side.

Standing by: an automatic retry fires in 25 minutes and reports back. If that one also dies, the two remaining levers are a GitHub support ticket, or disable/re-enable Pages for the repo — which resets the site's pipeline state but briefly drops tauction.dreev.es (custom domain re-attach + cert re-issue, minutes-ish). That one's your call if the retry fails.

No. Everything is verified live: production serves v2026.08.06-f (matches local), the Nunito font answers 200, and the backend queue finally drained — one of the "cancelled" deployments actually completed server-side. The pending auto-retry is stopped.

npm run deploy is only owed when apps-script/ changes, and nothing server-side changed since your morning deploy — everything since (veil, workflow file, stamp machinery) is frontend/tooling, shipped by the push that just landed. Optional: run it once anyway — the smoke re-verifies the live API and mints the first .deploy-stamp, after which the always-run-it habit costs ~a second.

Rereading AGENTS.md now, and fanning out a quick recon pass over the code to ground the assessment in current facts (name validation, blub rendering, what a slug-rename would actually touch).

AGENTS.md reread — all fourteen rules re-registered. (Rule 8's embedded test: SSOT — single source of truth — which the file's own MASTER COPY CONFUSION WARNING is a live example of. Also POLA, which is anti-magic's cousin.)

Recon agents are now reading Code.gs and app.js to pin down four facts the assessment hinges on: where slug validation actually runs, how the blub is rendered/edited, what a rename would have to rewrite, and what stale localStorage does when a slug goes virgin. Assessment follows when they report.

Recon done (four readers over Code.gs/app.js; findings below are verified against the code, with line refs). Verdict: the core idea — archive-by-rename so /foo is evergreen — is sound and fits the data model. One step is genuinely broken as stated (step 3), two steps dissolve into no-ops (4 and 7), and the rename itself is feasible but crosses one law that needs explicit ratification.

Step 3 is the poorly-thought-through part. As written (existing foo-archive0001 gets bumped to 0002, newest is always 0001), every archive event renames *every previous incarnation* — O(history) row rewrites — and worse, it rots the step-6 chain: after round 2, round 2's blub says "previous: foo-archive0001", which is now round 2 *itself* (its true predecessor moved to 0002). Every archived URL silently changes meaning each round. Fix: number upward — first archive is foo-archive1, next is foo-archive2 (max+1 scan). One rename per archive, links stable forever, chain intact. Also drops the zero-padding (padding only buys lexical sort in the sheet).

Step 4 can dissolve. [cleanSlug](apps-script/Code.gs#L221) runs on *every* request including state, and the client's URL matcher at [app.js:2686](app.js#L2686) rejects dashed paths outright — so archived slugs need grammar *and* length changes on both sides no matter what (20-char base + -archive + digits ≈ 32). But legalizing dashes for users isn't required: change the slug grammar to /^[a-z0-9]{1,20}(-archive\d+)?$/. Users still can't type dashes ([sanAname](app.js#L43) strips them), so the suffix namespace is server-mintable only — squatting and collisions become structurally impossible, no reserved-pattern refusals, the "max 20 characters" copy stays true for everything users type. One regex, zero new if-statements.

Step 6: the URL in the example points at /foo — presumably meant the archived slug. One refinement: mint the new auctions row's bver as old-bver+1 rather than restarting at 1. Reveal doesn't freeze the blub, so a straggler with the editor open pre-archive could otherwise CAS-match the reborn auction and clobber the pointer; carrying the counter forward makes that save refuse as simulEdits, always.

Step 7 is already built. Bare URLs don't autolink ([mdRender](app.js#L1702) has no autolink pass), but markdown [text](url) already renders as a safe anchor. Write the pointer blub in that form and zero rendering code changes.

The rename mechanics, per the code: rows are interleaved, so it's in-place slug-cell rewrites across auctions/seats/bids (rows don't move; seal-paint and indexes survive, per [Code.gs:448](apps-script/Code.gs#L448)). Costs that need eyes: (a) this is the first-ever mutation of the append-only bids log — the law at [Code.gs:24](apps-script/Code.gs#L24) says nothing is overwritten; rewriting the key column is a bend that should be ratified explicitly. (b) Reads run unlocked, so rewrite the auctions row first — /foo pollers then see virgin, and nobody knows the archive slug yet to observe its half-state. (c) mutate invalidates one cache key ([Code.gs:202](apps-script/Code.gs#L202)); archive needs both slugs. (d) Assert the target slug is virgin before renaming — merging into an existing bid log can permanently trip the forged-log tripwire ([Code.gs:548](apps-script/Code.gs#L548)).

Client aftermath (verified, no code needed): an orphaned tauction-usids entry is inert — neutralized at the single chokepoint [app.js:1123](app.js#L1123), no crash, fresh /foo just renders virgin. Better: the seats dvid column survives the rename, so visiting the archive URL auto-re-latches and still marks the old seat as yours. The stale-cache window shows the *closed* old auction, where everything is frozen, so no stray writes leak into the new incarnation through honest UI. One small wart: tauction-drafts:foo bid drafts reappear in the reborn auction — cross-incarnation draft leak, probably chosen-not-forgotten.

One question, load-bearing for step 4: are dashed auction names wanted as a user-facing feature in their own right, or were dashes only ever in service of the archive scheme (in which case the reserved-suffix grammar above is strictly less change)?

The anti-magic answer to the dash question: dissolve the two-namespace idea entirely. One flat grammar — dashes legal for everyone, one length limit, cleanSlug stays a single regex like /^[a-z0-9-]{1,N}$/ — and archive slugs are ordinary slugs, special nowhere. No reserved suffix, no second tier of names only the server can mint. The max+1 scan is the only collision logic, and it treats a user who manually named an auction foo-archive1 identically to a real archive: skip, take 2, harmless. Zero code paths anywhere else know archives exist. The reserved-suffix grammar proposed last turn is the *less* magic version of "reserve the pattern," but it still bakes a two-kinds-of-names distinction into the grammar; the flat rule beats it. Its one real cost: the user-visible length limit must widen (a 20-char base plus -archive1 is 29), so the "max 20 characters" copy changes and users get longer names — a product change to ratify, not sneak in.

The monkey wrench, through the same lens: no, don't disable the link — that's exactly the reserved-pattern if-statement the flat design just deleted, and under a flat namespace it would misfire on innocently-named auctions anyway. Archiving foo-archive3 renames it to foo-archive3-archive1, and this is more coherent than it looks:

• Chains never dangle, they gain a hop. foo's round-4 blub points at foo-archive3 (round 3). If someone archives foo-archive3, that page is reborn with a pointer to foo-archive3-archive1, where round 3 actually lives. Old links still resolve to the history, one indirection deeper. The convention is self-similar and self-healing.
• The semantics are legitimate. An archived auction is revealed, hence frozen; the only things possible there are blub edits and archiving. Archiving it means "rerun at this URL" — a real intent, honor-system like every other destructive-ish gesture in the app (anyone can remove seats, anyone can reveal). And it's barely destructive: a rename, with all data surviving at the new name.
• The backstop already exists. The archive action validates its minted target through the normal cleanSlug path like any other slug; recursion deep enough to overflow the length limit refuses loudly with slugTooLong. That's the existing validator doing its job — anti-postel, not a new conditional.

So the link stays live on archives, unconditionally, and the length limit is the only brake. If foo-archive3-archive1 is aesthetically intolerable, the fallback is the reserved-suffix world with the link grayed on archives — strictly more magic (two namespaces plus a conditional), so not recommended, but it's the honest alternative.

Which forces the one open number: what should N, the new slug length limit, be? It buys archive depth — 30 covers one archive level on a maxed 20-char base, 40 covers two, and short bases like foo get many levels under any of them.

Open decisions, most load-bearing first, each with the standing recommendation so a bare "defaults fine, except…" answers the lot:

1. Flat namespace — dashes become legal in all user-typed auction names, one grammar, archive slugs ordinary. This is the anti-magic answer but it's a user-facing rule change (and admits oddballs like -foo or x--y; forbidding those means more grammar). Rec: ratify, oddballs and all.
2. New length limit N — replaces the "max 20 characters" rule and copy; buys archive depth (30 = one level on a maxed base, 40 = two). Rec: 40.
3. Numbering direction — max+1 upward (first archive = foo-archive1, newest = highest), contradicting step 3 as written (newest = 0001 via cascade). Rec: max+1; cascade rots links and self-references the blub chain.
4. Bids append-only law bend — the rename is the first-ever in-place write to the bids tab (slug key cells only, log content untouched). The README law says nothing is overwritten. Rec: ratify the bend and reword the law to "rows are never edited, only re-keyed by archive".
5. Pointer blub form and copy — bare URLs don't autolink today, so either the pointer is written in markdown [text](url) form (works now, zero rendering changes — rec) or an autolink pass gets built. And the pointer's visible words: supply exact copy, or it ships as Latin with a TODO per rule 6?
6. bver carry-forward — reborn auction's row starts at old bver+1 instead of fresh, so a straggler's pre-archive blub draft always refuses as simulEdits instead of sometimes clobbering the pointer. Rec: yes.
7. Archive gesture — one unconfirmed click, available to any visitor, matching reveal's precedent (also one-way, also unconfirmed, honor system)? Rec: yes. The link's own text: Latin TODO unless copy is supplied.
8. Cross-incarnation draft leak — a leftover bid draft for /foo reappears in the reborn auction. Client-side clearing only fixes the archiving device, not others. Rec: chosen-not-forgotten, alongside the existing two-tabs blind spot.

Locked in: 1 (dashes everywhere), 3 (date-lettered names), 5 (markdown pointer, anchortext = URL sans https://), 6 (bver continues), 7 (one click, text exactly "Archive"), 9 (gray the link on archive-form slugs). Responses on the open threads:

8, "chosen not forgotten": that's the README's own section name — "Known gaps, chosen not forgotten" — the list of deliberately accepted gaps, recorded so they read as decisions rather than oversights. The draft leak would be appended there. Nothing more to it.

3 → feeds 2: the suffix -archive-2026-08-09-a is 21 characters, so N must be ≥ 41 to archive a maxed 20-char base — and thanks to 9, one suffix level is all N ever needs to fit. Two riders: (a) recommend deriving the date from tfin (the close date — the historically meaningful one, and deterministic) rather than the archive-click date; (b) if 41 is what's gross about 2, dropping the word: foo-2026-08-09-a (suffix 13, N = 33) keeps everything else — regex-detectable, lexically chronological — intact.

9's if-statement register (per anti-magic, enumerated): client grays Archive when the slug matches -archive-\d{4}-\d{2}-\d{2}-[a-z]$; the server refuses the same case (reachable only hand-rolled, so ERROR15xx plumbing family) plus the letters-exhausted case from 3 (honest play *can* hit 27 archives in a day, so gameRefusals, Latin) plus archive-on-unrevealed (plumbing). One flat-namespace consequence to accept: a user can hand-mint an archive-shaped name and get a permanently grayed Archive link on a never-archived auction.

4 — yes, the corruption risk is real, and asserts can't remove it. Sheets has no transactions and the script lock dies with a crashed execution, so asserts detect a torn rename, never prevent one. The two crash shapes, briefly: rewrite the auctions row last, and a mid-flight crash leaves foo's row saying "revealed" while its seats/bids have partially moved — the closed-state covenant (revealed ⇒ ≥2 seats, all with bids) then throws on *every* read, and since every action calls getState, /foo is bricked until a human repairs the sheet. Rewrite the auctions row first, and /foo survives as virgin-with-orphans instead — but the archive slug bricks the same way, the orphaned foo-keyed bid rows resurface as ghost bidders when foo is reborn, and the half-archive has no resume path (virgin /foo shows no Closed line, hence no link to click again).

The rethink that deletes this failure class instead of guarding it — same medicine the repo already took for people, when renaming a uname meant surgery across tabs and the pid turned it into a one-cell label edit: give auctions a stable id (auid, joining usid/dvid; nominology sign-off wanted), key seats and bids by auid, and demote the slug to a label on the auctions row. Archive then becomes: guards → one cell write (the slug cell — the atomic commit) → insert the reborn foo row (pointer blub, bver continuing). A crash between those two steps leaves /foo virgin and the archive fully readable; the worst possible outcome is a missing pointer blub. Zero torn states, zero bricking. Bonus: the bids tab is never written at all, so the append-only bend ratified in 4 un-happens. Costs: an auid column on auctions/seats/bids (schema change), though the migration can be data-preserving by hand — insert the column in the sheet and backfill auid := slug, since the drift check reads the self-describing header row; new auctions mint auid as a uuid.

The one question this leaves: adopt the auid restructure, or stay with careful multi-row rewrite and accept hand-repair-in-the-sheet as the documented recovery story? (N and the date-source/suffix-wording riders can land whenever 2 resolves.)

Not gross at all — with 9 ratified, it's actually *cleaner* than flat-41. The flat-length argument died when 9 passed: archive-form slugs are already a special vocabulary item (grayed link client-side, refusal server-side, both keyed on the archive regex), so the namespace is two-tier semantically no matter what. Exempting the suffix from the length rule just runs the length check along the seam that already exists — the same one ARCHIVE_RE constant serves all three uses: the gray-out, the server refusal, and now the length exemption. One piece of jargon, three uses, zero new if-statements: cleanSlug becomes "strip the suffix pattern, base must be ≤20, whole thing must match one regex" — still a single chokepoint, and the client URL matcher mirrors the same regex.

What it buys:

• Nothing user-visible changes. The input field, the red ring, the "max 20 characters" copy, the quals pinning them — all untouched. The N question from 2 dissolves; the internal ceiling is 41 (20 + 21) and nobody needs to be told.
• A free structural win: the -archive-YYYY-MM-DD-x suffix is 21 characters, so base + suffix is ≥22 — no user-typeable name (≤20) can ever match the archive pattern. The archive namespace becomes mintable *only* by the server. The flat design's conceded warts — users hand-minting archive-shaped names, the permanently-grayed-link misfire, squatting — all evaporate by arithmetic rather than by rule.
• The shorten-the-suffix idea should die: it existed only to shrink N, which no longer matters — and the short form (-2026-08-09-a, 13 chars) would *break* the previous point, since a ≤7-char base plus suffix fits in 20 and becomes user-typeable again. Keeping the word "archive" is load-bearing now.

So: recommend adopting exactly this — 20 for what humans type, suffix exempt, -archive- wording kept, date from tfin. That resolves 2 and 3 fully.

The standing open question is still the one from last turn: auid restructure (archive = one atomic cell write, bids tab never touched) versus careful multi-row rewrite with hand-repair-in-the-sheet as the recovery story.

The question hinges on what the auid actually changes, and explaining the cons properly requires checking one Google Sheets API fact (whether a batched write is atomic), since it materially shifts the trade-off. Checking that first.

Confirmed from Google's batching guide: "Changes are grouped in a batch so that if one request is unsuccessful, none of the other (potentially dependent) changes are written" — all-or-nothing. That matters below. First, the mechanism itself.

What the auid alternative actually is. Today a bid belongs to an auction because the bid's own row *says the auction's name*:

bids:      slug   usid    xbid
           foo    u-9e2   $40
           foo    u-1c7   $55
auctions:  slug   tini   tfin   blub  ...
           foo    ...

So renaming foo means editing the slug cell in every one of those rows — that's the "editing the slug field for each bid" design. The alternative adds a level of indirection: rows belong to an auction by an immutable id, and the name becomes a label that lives in exactly one cell in the whole spreadsheet:

auctions:  auid    slug   tini   tfin   blub  ...
           a-7f3   foo    ...
bids:      auid    usid    xbid
           a-7f3   u-9e2   $40
           a-7f3   u-1c7   $55

Reads become two-step: URL /foo → find the auctions row whose slug is foo → filter seats/bids by its auid. Archive = edit that one slug cell to foo-archive-2026-08-09-a, then insert a fresh auctions row (new auid, slug foo, pointer blub). The bid rows are never touched; they still say a-7f3, and a-7f3 now answers to the archive name. It's exactly the pid move already shipped for people: uname used to key bids, so renaming a person was cross-tab surgery; usid demoted the name to a label and rename became one cell. Slug is currently in the pre-pid state.

Pros of auid: archive is a single cell write, which a crash cannot tear; the bids tab is never written (append-only law untouched); all the ordering/covenant/cache-invalidation analysis evaporates. The client never sees auid — payload shape and localStorage keys stay slug-based.

Cons of auid: schema change on three tabs plus a migration (data-preserving by hand: insert the column, backfill auid := slug); every r.slug === slug filter in Code.gs becomes resolve-then-filter — broad, mechanical, but it's most of the read surface; and a permanent daily cost — the sheet stops being eyeball-readable. Seats and bids rows would show uuids, so telling which auction a row belongs to means joining against the auctions tab by hand. The sheet is the forensics surface (link-visible, dvid columns for cheater-tracing), so that's not cosmetic.

But the batchUpdate fact above weakens the case for auid. The torn-rename corruption analysis assumed row-by-row writes in a loop. The Advanced Sheets Service is already enabled (loadAll's batchGet uses it), and its spreadsheets.batchUpdate applies a whole batch all-or-nothing. So the entire archive — every slug cell across auctions/seats/bids *plus* the reborn pointer row — can be one atomic API call inside the lock. Apps Script dying before the call: nothing happened, the Archive link is still there, click again. Dying after: everything happened. No torn state exists on either side. That deletes the corruption scenario with zero schema change and the sheet stays human-readable. Residual caveats, stated for the record: it'd be the first *write* through the advanced service (reads already use it, same scope); Google documents atomicity for failure, not reader isolation, so a 5s poller might glimpse a partial state for one cycle at worst and self-heal; and slug stays the key of record, so a hypothetical future rename feature would pay this complexity again, where auid pays once — YAGNI says archive is the only rename in sight.

Updated recommendation: the atomic-batch rewrite, not auid. It keeps the flat one-vocabulary data model, the readable sheet, and the migration-free deploy, and the one advantage auid held — crash safety — is matched by the batch. auid remains the right move if renames ever multiply.

Proceeding. Plan: recon the exact implementation surfaces, write red quals first (QDD), implement server then client, get green including story quals, then an adversarial review workflow before handing over for commit/deploy.

Now the frontend and the qual-authoring idioms — app.js in two passes, index.html, and gas-quals.

Harness understood. Now checking the story-quals idiom briefly, then writing the red quals.

Now the server implementation — six edits to Code.gs:

Good progress — the archive quals themselves passed; a structural qual now demands the new action declare its post-close policy. Finding it:

Client done. Syncing 404.html and running the frontend suite:

While the frontend suite re-runs — the serve suite (fast) as a sanity check:

Serve suite green. Waiting on the frontend suite; the story suite (headless Chrome) runs after that.

No extra monitor needed — the suite's completion will notify on its own. Status while it runs: gas (288 assertions) and serve (19) suites are green; the frontend suite is on its re-run after fixing the missing ?api= in the new scenario's page boots; the story suite (headless Chrome, with the new archive journey and two screenshots) runs after that, then the adversarial review pass over the whole diff.

Frontend green — 635 assertions. Now the story suite in real Chrome:

While Chrome walks the stories, launching the adversarial review workflow over the full diff:

Both long-runners are in flight: the story suite in Chrome and the four-lens adversarial review. Results will land as notifications; fixes (if any) follow, then the final report with the deploy hand-off.

404 is in sync. Standing by for the review workflow's verdicts.

The review surfaced a confirmed real hole. Reading the full findings list:

Now the stringles entry and the qual strengthening:

Both suites still mid-run (no failures printed yet — failures surface immediately). Waiting for their completion notifications.

Story suite green again (238). One suite still running — the frontend.

Done. The archive feature is built, twice-reviewed, and green: 1,194 assertions across all four suites (gas 298, frontend 639, serve 19, story 238), red-first per QDD, with two new story screenshots eyeballed good ([story-archive-closed.png](quals/screenshots/story-archive-closed.png), [story-archive-reborn.png](quals/screenshots/story-archive-reborn.png)).

What shipped, per the ratified spec: an "Archive" link under the Closed stamp. One click renames the whole record — auctions row, seats, bids log, slug key cells only — to slug-archive-YYYY-MM-DD-x (date from tfin, letter probes a–z, 27th-of-a-day refuses), and rebirths the slug in place with bver continuing and the pointer blub as a live markdown link. The rename+rebirth is ONE atomic batchUpdate via a new storage primitive [batchWrite](apps-script/Code.gs#L468), so a crash can tear nothing. Dashes are legal in names; the 20-char limit judges the base; ARCHIVE_RE is welded byte-identical across runtimes.

The adversarial review earned its keep — 44 agents, 19 surviving findings collapsing to these fixes:

• Archive-namespace squat (confirmed DoS): the "unmintable by arithmetic" claim only covered the typed field — 26 adds on archive-form URLs choked the real archive. Fixed structurally: [ensureAuction](apps-script/Code.gs#L795) refuses to *birth* an archive-form slug (archiveSquat, game-class Latin). Existing archives untouched — blubs stay editable.
• Title peek died after rebirth: seenRevealed was a one-way latch built for a world where reveal was terminal. It now assigns from adopted truth; the hidden-tab peek resumes for round two.
• URL matcher: had a third hand-spelled grammar with a case hole (SHOUTED archive URLs dead-ended). Now derived from ARCHIVE_RE with the path lowercased first — case tolerance total, weld coverage by construction.
• Plus: a double-submit guard on the Archive press (a double-click bannered over its own success), a loud tfin is not ISO assert (a hand-edited close stamp would have minted an orphaned name), and four qual-strength fixes (the pointer prose is now pinned *verbatim*, not derived from the code under test).

New if-statements, per rule 9, all refusals or dreev-ratified: the ARCHIVE_RE gray on archive pages (ratified #9), the archiveSquat/archiveUnclosed/archiveArchive/archiveChoke refusals, the tfin assert, and the double-submit disable (namego's precedent).

Yours to do:

1. Deploy (lane 4): review the diff, commit+push to main yourself, *then* npm run deploy. No schema change, so no tab-deletion ceremony. In the push-to-deploy skew window an Archive click banners unknown-action; heals when the deploy lands. The live smoke now proves the deployed server knows archive (via a mutation-free refusal probe).
2. Five Latin TODOs await your English in [stringles.js](stringles.js#L60) (archivedTip, archiveUnclosed, archiveChoke, archiveSquat, archiveArchive). The "Archive" label and pointer prose are your copy, verbatim.
3. ERROR1511 is now stale — "auction name must be alphanumeric" while foo-bar is legal. Your English, so flagged, not edited.
4. sourcery.html was regenerated at 15:24, before this code landed — rerun your tool when convenient.
5. Bonus, answering README's new "Next" item: markdown links with hover text fail because [mdRender's link regex](app.js#L1702) allows no whitespace inside the parens — [^\s)]+ stops at the space before "hover text", so the whole construct falls through to literal text. One-line fix if wanted; left untouched as it's outside this task.

Chosen-not-forgotten, on record in AGENTS.md: the cross-incarnation draft leak (your #8 "that's fine"), devices.blug pointing at the old slug for ≤25s, and tabs hidden since round one staying title-muted until looked at.

Two quick verdicts before the rework, then the format change goes in:

Sorting: care level ≈ zero. Nothing in the product sorts slugs — the sheet is insertion-ordered (and the covenant *assumes* nobody sorts it), and there's no listing UI. A future previous-incarnations listing can sort numerically. Zero-padding would fix lexical sort at the price of an arbitrary cap (the ZOI sin), so plain archive1, archive2, … it is.

Different approach: the graveyard already holds the plausible rivals — auid indirection (killed for sheet eyeball-ability), a generation column (schema change + two-key filters on every read), /foo?round=2 (dead on URL purism), new-slug-per-round foo2 (kills the evergreen URL, the whole point). Under those constraints rename-away stays the right shape; nothing new suggests itself.

One consequence to flag: -archive1 is only 9 chars, so archive-shaped names become typeable (the dated suffix was untypeable by arithmetic). The namespace now holds by refusal alone — the server's squat guard already covers it, and the name field gets a matching pre-wire objection. Also archiveChoke dies (no 26-per-day cap — N is unbounded, ZOI-clean) and the tfin-ISO assert dies with its reason (the name no longer bakes a date). Reworking quals-first:

While the suites run — updating AGENTS.md and the memory to the final format:

While that re-runs — the story suite from the earlier batch is still out. Waiting on both.

Story green under the numbered format (238) — the archive journey now runs weekly-archive1 end to end. Waiting on the frontend re-run to settle the flake question.

Verification pass launched over the format-swap delta. Once it reports (and any findings are dispatched), the final summary follows.

The ERROR1510 first, because it's the expected skew, not a broken build: the archive action exists in the local [Code.gs](apps-script/Code.gs) but the deployed /exec still runs the old server — the local page (new button) talking to the live API (old code) produces exactly unknown action: archive. Testing was done against the real Code.gs running in-process — 1,194 assertions across four suites including full journeys in headless Chrome — but the deployed script can't know the action until npm run deploy, and the era guard refuses to deploy until the tree is committed and pushed (and git is yours by rule 14). So: commit + push, then npm run deploy, and this heals. (The live smoke is designed to fail red right now for this exact reason.)

Now the same-line layout — qual first (red), then the CSS:

Holding the CSS edit until the red run lands (the story server serves style.css live from disk — editing mid-run would contaminate the red evidence).

Red confirmed. Applying the same-line CSS:

Green run in flight. Two things pending — the story suite and the format-swap verification workflow — then the wrap-up with the new screenshot.

Yes — and the machinery mostly exists already. Design sketch, sized to the house style:

The skew gate: sver, a server-generation counter. A plain integer constant in Code.gs (bver's precedent), carried in every state payload; app.js carries the generation it was built against. One new conjunct in [assertState](app.js#L329) — res.sver >= <what this page needs> — fails loudly at the very first adoption: the page never leaves its gray, and the banner carries exact marching orders ("deployed Code.gs (3) predates this page (needs 4) — npm run deploy"). That's "don't even load" in effect, with zero special dead-page mode.

What makes it cheap:

• No pulse-tab analog needed. The pulse exists to avoid API reads; boot already does a state read before anything else, so the version rides the existing payload for free.
• Old servers fail the check by construction — they don't send sver at all, so *today's* skew class becomes loud retroactively the moment this ships.
• Stale localStorage snapshots self-heal — paintCached already purges cached state that fails the shape assert, then the live fetch delivers the verdict.
• The reverse skew (old page + new server) needs nothing new — shape drift already trips assertState, and additive server changes are harmless to old pages. One direction is the whole disease: lane 4's push-then-deploy ordering *manufactures* the new-page/old-server window every time.
• Deploy smoke: live-quals pins deployed sver === repo's, so a half-landed deploy also fails by name.

The discipline (the only non-mechanical part): bump the constant whenever the client starts depending on new server behavior — archive would have been such a bump. Two welds close the forget-risk: a qual pins the two runtimes' constants equal in-repo, and a ledger qual records the action-list fingerprint per generation, so adding an action without bumping fails with marching orders ("new action ⇒ bump sver + ledger line"). A behavior change *inside* an existing action still needs human judgment — that residue is irreducible.

Semantics choice, made deliberately: the client requires *minimum*, not exact match — exact would brick the site on every frontend-only push (lane 1) until a pointless server redeploy.

Nominology to ratify: sver (server version — joins bver/wver). If ratified as specced, it's maybe an hour of work including quals.

Meanwhile: the same-line Closed-stamp layout is applied (qual went red first, CSS landed, green-confirming story run is in flight), and the format-swap verification workflow is still out. Both land shortly.

Same-line ruling shipped and green: "Closed 2026-08-09 20:37 Sun — Archive" on one line, right of the stamp (story suite 239, red-then-green). The format-swap verification workflow is the last thing in flight; the sver skew-gate proposal awaits ratification.

Real catches. Reading the full findings list, then fixing:

Now the qual reworks and the stale-vocabulary sweep:

Gas 299 and serve green; frontend and story running. Final wrap-up follows their verdicts.

Story green (239). Frontend still running.

All settled and green: 1,200 assertions across the four suites (gas 299, frontend 643, serve 19, story 239). The full state of play:

Format swap done — foo-archive1, foo-archive2, …, N minted numeric max+1 (never refilling hand-made gaps), unbounded. The choke refusal and tfin assert died with the date; the typeable -archiveN shape is fenced by the name-field gate plus the server's squat refusal.

The verification pass over the swap caught five real things, all fixed:

• The probe trusted Number() past 2⁵³ — a hand-edited absurd N would have renamed the record onto an *existing* slug (silent duplicate) or minted 1e+21-style names both runtimes refuse. Now a loud assert.
• Gate order: an overlong archive-shaped name got the too-long words when the server would say squat — the reserved-shape check now runs first, so client words are server words in every case.
• The URL matcher adopted /-archive1, which every server call refuses (empty base) — a hand-typeable dead page. The matcher is now an exact mirror of cleanSlug's verdict: charset, strip suffix, judge the base.
• A lexical-max regression (9 beating 10) would have passed the whole suite and minted a duplicate — now pinned with a two-digit rollover qual.
• A comment sweep purged the dead dated-format vocabulary from five files.

Same-line ruling shipped: "Closed 2026-08-09 20:37 Sun — Archive", one line, story-pinned (same top, right of the stamp), red-then-green, screenshot eyeballed.

Open items, all yours:

1. Deploy — commit+push, then npm run deploy. The ERROR1510 you saw heals at that moment.
2. The sver skew gate — specced in the previous message, awaiting your ratification; unbuilt.
3. ERROR1511's words ("must be alphanumeric") and five Latin TODOs in stringles await your English.
4. sourcery.html regeneration whenever.

Synced — 404.html now carries v2026.08.09-c; a reload on localhost:8001 shows it. This is the documented gotcha from the workflow's lane 1: after hand-editing index.html, run npm run sync-404 before eyeballing slug URLs (deploys re-derive it automatically; local eyeballing doesn't). Note npm run quals deliberately does *not* auto-sync — the auditor-doesn't-rewrite-what-it-inspects rule — so the 404-parity qual would have gone red on the next run and caught it anyway.

The nicest version: the archive name *itself* names the way home — foo-archiveN mechanically contains foo — so the back-link can be derived client-side from the slug alone: zero data stored, zero server work, works retroactively for every archive ever, and can never rot. It joins the Closed line beside the grayed Archive control (lifecycle chrome together): a quiet "Auctio viva: /foo" link, ?api= preserved. Red quals first:

Red confirmed. Implementing the way home:

The purge did its job on the purger. Frontend re-running; story still out.

Story green (242 — the way home walks in real Chrome). Now the move, byte-exact:

Docs and memory updated. The frontend suite is the last gate.

The way home is in, all suites green — 1,205 assertions (gas 299, frontend 645, serve 19, story 242).

What shipped: an archive page's Closed line now ends with a live link home — "Closed 2026-08-09 21:31 Sun · Archive (grayed) · Auctio viva: /weekly". The nicest property: the link is *derived* from the archive name itself (strip the suffix), so nothing is stored, it works for every archive past and future, and it can never rot. ?api= survives the hop for local testing. The story suite clicks it in real Chrome and lands on the open next round; screenshot at [story-archive-wayhome.png](quals/screenshots/story-archive-wayhome.png).

Your live copy edits are absorbed — including your own fix of ERROR1511. One thing needed a structural follow-through: you gave archiveUnclosed an ERROR number ("ERROR2107: Race condition?...") while it sat in gameRefusals, and the weld qual enforces number ⟺ plumbing-table membership. Since your copy names the race and numbers it anyway, the entry moved to plumbingRefusals — string byte-preserved, only the table changed. If you'd rather it be an unnumbered game-class refusal instead, drop the "ERROR2107: " prefix and move it back; the weld will hold either way.

Still wearing Latin TODOs: evergreenPrefix ("Auctio viva: ") and archivedTip ("Iam in tabulario est").

Unchanged from before: deploy is push-then-npm run deploy (the ERROR1510 you saw heals there), and the sver skew-gate proposal awaits your yes/no.

Matching the forward pointer's anchortext convention — and folding in your latest copy edits (blank prefix, "Can't archive an archive"):

Anchortext now location.host + path — tauction.dreev.es/weekly in production, honest on localhost — with the href still relative and ?api=-preserving. Gas and serve are green; frontend and story confirming in the background.

Story green (242). Frontend still running.

Done and green across the board — 1,205 assertions (gas 299, frontend 645, serve 19, story 242), 404 in sync.

The way-home link now reads tauction.dreev.es/weekly (full URL sans scheme, the pointer blub's convention) — derived from location.host, so it stays truthful on localhost; the href itself is still relative with ?api= preserved. Your latest copy edits are all absorbed: the blank prefix stands (the URL is the whole message), "Can't archive an archive" on the grayed control, and the reclassified ERROR2107.

Still open, both yours: the push-then-npm run deploy to make the live server speak archive, and a yes/no on the sver skew gate.

Killed as follows: archiving now leaves blub content entirely alone, both directions. The reborn auction inherits the standing blub unchanged (bver and tbed ride along), and the archive keeps its frozen copy — so the evergreen URL's description persists across incarnations and nothing is ever written *into* a blub by machinery. (One factual note on the parenthetical: the *archived* record's blub was never touched — byte-pinned by a qual; what dies here is the reborn side's pointer-overwrite, which was indeed the wrong half to spend.) A straggler's mid-archive draft now lands as an ordinary edit on the continuous blub instead of bouncing — the CAS history carries. The one loss: no forward navigation from /foo to its archives (the way-home link covers the reverse); if that's wanted later, the state payload could carry the highest existing N and the client could derive a "previous incarnation" chrome link the same rot-proof way. Quals first:

One leftover pointer assert my sweep missed — deleting it:

While they run — the AGENTS.md reference catches up (pointer prose dies there too):

Docs and memory reflect the ruling. Awaiting the frontend and story verdicts.

Red confirmed. Now the implementation — server first:

Now the client:

While they run — AGENTS.md and memory catch up to the arcs design:

Docs current. Awaiting the two suite verdicts.

Story green (243) — the chain walks in real Chrome, including the newest-archive link on the open reborn page. Frontend still running.

Built and green: 1,211 assertions (gas 301, frontend 648, serve 19, story 243), verification pass in flight.

The design made sense, and the less-if-statementy answer dissolved both of your cases into one rule. The trick: your two cases are the *same* case once "previous incarnation" is defined uniformly. Every page derives base (slug minus suffix) and its own N (the suffix number — with the live page counting as N = ∞). The server ships one family-wide field, arcs — the existing archive numbers, ascending, computed by the same scan the mint already used — identical whether you ask as /foo or /foo-archive3. The links are then a single derived list:

• base, included iff base ≠ slug (only archives get a home link — a set-membership fact, not a page-kind branch)
• base-archiveM, where M = the greatest arcs entry below your own N (∞ on the live page ⇒ the *newest* archive — your case 1; N on an archive ⇒ the previous one — your case 2; archive1 gets nothing)

The rendering has zero display logic: the span is exactly as visible as its content, so the empty list on an archive-less page renders nothing. Net if-count went *down* — the old CSS gates, body.archive class, prefix constant, and init-time population all died. The one guard that remains is a rebuild-only-on-change key (node stability, the descview pattern).

Two places the uniform rule deliberately deviates from your literal spec — veto if wrong:

1. Gaps skip. At /foo-archive3 with archive2 hand-deleted, the prev link goes to archive1 (your "N−1 if that URL exists" would show nothing). The max-below rule doesn't know about gaps, which seems like the right ignorance.
2. Live pages link their newest archive even while the round is OPEN — "that line where Closed goes" is the location, but the link is data-gated, not closed-gated. Mid-round is exactly when someone wants last round; gating on revealed would be one more if.

Also pinned: link order (home first, then prev, your ordering), anchortext full-URL-sans-scheme, ?api= surviving the hop, and the click-home journey in real Chrome. The arcs name is new payload vocabulary — yours to rename. One nuance for the record: a sibling archive's cached arcs can lag an archive event by the 4s TTL, same as any out-of-band edit.

The verification pass surfaced one real bug and one incident requiring immediate disclosure. Verifying the git situation first:

The launched run snapshots app.js at startup, so the fix can land in parallel without contaminating the red evidence. Applying it:

Fix and docs in. Waiting on the red run against the unfixed snapshot; the green run follows on the fixed tree.

Red confirmed — the unfixed app dies exactly as the finding described (unhandled rejection from the settle-path ingest). Green run on the fixed tree:

Gas and serve green on the fixed tree; frontend and story confirming in the background. Final wrap-up when they land.

This maps to an established loop for this repo (research the top designer complaint, fix, re-ask, repeat to quiescence) — scaled up per the mandate. Plan: deep research + full-state audit workflow now (isolated worktrees, read-only — the new standing rule after the tampering incident), then fixes applied in rounds with fresh story screenshots and a fresh-eyes critic each round until complaints go quiet. The two pending suite runs land meanwhile; CSS edits wait for them. First, the screenshot inventory the auditors will work from:

The wedge fix is proven end to end — frontend 651 green (the skew scenario: the crash banners loudly, the next write still flies, and the page heals when the server catches up; the pre-fix run died exactly as predicted). All four suites green on the current tree: 1,214 assertions.

The design pass is underway: three research agents distilling spacing/Gestalt/ergonomics principles into checklists, five auditors reading all 28 screenshots against them (the tombstone squish has a dedicated diagnosis), then a synthesis into an ordered fix plan. Fixes land in rounds with fresh screenshots and a fresh-eyes critic between rounds, until the top complaint goes quiet.

The audit synthesized 28 raw findings into 19 verified issues in ordered groups. Reading the full plan before applying:

Waiting on story12's completion notification.

While frontend runs — eyeballing the headline fix and launching the fresh-eyes critic:

Round 2 is in (yield rules re-homed to coarse-or-narrow, hit inflation with ink held in place, stack-spread compensation, stale captures purged) — gas and serve green, the two big suites and the fresh-eyes critic all running. Remaining after they land: the critic's verdict, the 8b coarse-emulation assessment, and the consolidated report with your two open calls (the legend band-step and the blub comment-vs-markup contradiction).

Story re-running post-revert. Still out: that run, the round-2 frontend run, and the critic.

Standing by for those two.

All four suites green — 1,216 assertions (gas 301, frontend 651, serve 19, story 245, the hidden-pencil pin included). Only the fresh-eyes critic remains before the consolidated report.

Not quiescent — three concrete findings, all well-diagnosed. Applying fixes plus story pins:

Critic round-1 fixes applied (one-line pills, rightward ledger tips, balanced name card) with story pins for all three. Both suites confirming in the background; critic round 2 follows if they're green.

Story 248 green — all three pins pass in real Chrome. Eyeballing the fixed pill:

The pill is one line and the ledger tip now rides its own row's band. Frontend still running; critic round 2 queued behind it.

Critic re-inspecting. Its verdict decides whether a round 3 happens or the loop is quiescent — then the consolidated report.

QUIESCENT. The critic verified all three round-1 fixes in the recaptures, re-measured the full set, and reports nothing above nitpick level remaining. Closing out with memory and the consolidated report:

The design pass is complete and quiescent: two audit-driven fix rounds plus a designer-complaint loop that ended with the fresh-eyes critic re-measuring everything and finding nothing above nitpick level. All suites green — 1,219 assertions (gas 301, frontend 651, serve 19, story 248), fresh screenshots in quals/screenshots/ for eyeballing.

How it ran: three research agents distilled spacing/Gestalt/ergonomics principles into checklists; five auditors measured all 28 captures against them (28 raw findings → 19 verified); fixes landed in rounds; the critic then found three more (a two-line ADD PARTICIPANT pill, ledger tooltips landing in the next row's lap, a bottom-heavy name card), those were fixed and pinned, and round 2 came back QUIESCENT with all fixes verified in the recaptures.

What changed, in one breath: your squished archive URL now carries the Closed stamp's own 1.1rem of breath (and the whole tombstone line spaced evenly); buttons bind to *their* fields instead of their neighbors (SUBMIT, SAVE/DISCARD); shadows stopped eating gutters (your-row's pop, re-bid piles — the stack hands back exactly the ink it spreads); hit targets grew to spec with ink held perfectly still (dialog ×, tombstone + footer links, the coarse-pointer ~44px law completed); the help dialog scrolls its body so the × stays parked; the QR's phantom gap is compensated; pills never break mid-label; ledger tips ride their own row's band; the named page's first card is optically balanced; assorted gap-scale drift unified.

Three rulings are yours (all flagged in place):

1. 320px desktop windows: the bid column crushes to ~48px there. The fix exists (widening the phone column-yield to narrow windows) but was built, caught by a qual, and *reverted* — the yield's shrinking name column breaks the pinned header-text-over-cell-text alignment. Crushed-but-aligned vs roomy-but-drifting: your call.
2. Legend band-step: 0.9rem vs the 1.1rem used everywhere else — unify or register as deliberate.
3. Blub editor spec contradiction: the CSS comment says field → preview → buttons; the markup ships field → buttons → preview. Which is the spec?

Scoped follow-up: the phone story captures render *fine-pointer* CSS (no touch emulation), so the entire touch-ergonomics block ships unaudited on film. Enabling hasTouch is one line; re-deriving the phone scenes' asserts and captures is the real cost.

QDD honesty: two spacing asserts' red runs were contaminated (the story server reads CSS live from disk mid-run), so their pre-fix failures rest on the audit's and critic's pixel measurements rather than observed reds; the hidden-pencil tooltip pin was born green against a defect visible in two pre-fix captures.

Unchanged and still pending on your side: commit/push + npm run deploy (the archive feature and arcs payload go live then), and the sver skew-gate yes/no.

Two good asks. The concept recommendation first, then it gets built for a screenshot thumbs-up (the house precedent):

Closed = a stamped, settled ledger page. Three moves that compound: (1) rows shed their controls entirely — no stars, no ×s (your ratified anti-magic exception; a record has no knobs); (2) the paper turns decisively to warm parchment instead of the current one-shade hint — ambient, unmissable, works at a glance from across the room; (3) the cute bit: your own kawaii gavel art, small, stamped inline beside the "Closed …" date — the gavel at rest IS "adjudicated," wordless and on-theme. Archives read identically (they *are* closed records); what distinguishes them is the nav.

The nav goes Spotify: ‹ › » — one cluster on the tombstone line, no words. ‹ = one incarnation older (on /foo: the newest archive). › = one newer (on the newest archive: the live page). » = jump to current. Grayed when the target doesn't exist (nav arrows keep gray-don't-suppress — the exception is for the closed-record controls), Latin tips explaining grays, hit-inflated per the new law. All derived from arcs + the slug — same zero-extra-data machinery as the text links it replaces.

Building it — recon of the affected styles first:

Red run in flight — and this time the implementation waits for it (no live-file contamination). The deck and settled-record code land the moment the red is confirmed.

Red confirmed. Implementing:

Both suites running against the new design. Old pins that assert post-reveal grayed controls will flip red — each gets re-derived under your ruling as they surface. Screenshots for the thumbs-up follow the green.

Axis pin re-derived (the glyph owns the axis now, text follows). Story re-running; frontend still out.

Deck styling landed properly this time. The superseded story19 run's verdict can be ignored when it lands; story20 is the one that counts.

That notification is the superseded run — ignored. The clean story21 run is the one that counts.

Pins re-derived; story re-running.

Story 251 green — everything landed. All four suites: gas 301, frontend 651, serve 19, story 251 = 1,222 assertions. The thumbs-up screenshots:

Both asks are built and green — 1,222 assertions (gas 301, frontend 651, serve 19, story 251). Eyeball quals/screenshots/story-archive-closed.png and story-archive-wayhome.png for the thumbs-up.

The settled record (closed/frozen look): the paper turns decisively to warm parchment at the close — unmistakable next to the blue open-page weather, in both themes. Rows shed every control outright per your exception — no stars, no ×s, and the "★ = you" legend goes with them; a closed ledger is names and bids, nothing else. The cute bit: your kawaii boxed-gavel art, stamped small beside "Closed 2026-08-10 01:24 Mon" — the gavel at rest, wordlessly "adjudicated." (Your own row still keeps its dead editor holding your frozen draft — the dead-draft law stands.)

The transport deck: ‹ › » on the tombstone line, no words. ‹ one incarnation older (skips hand-made gaps), › one newer with the live page as the timeline's end, » jump to current. Grayed when there's no target, with Latin tips explaining (nav keeps gray-don't-suppress — your exception covers the record's controls, not navigation). A family of one shows nothing. All derived from arcs + the slug; hit-inflated, coarse-pointer sized, ?api= rides every hop. On weekly-archive1 you see: gavel + Closed stamp · Archive (grayed) · ‹(grayed) › ».

Pins that flipped under your rulings, all re-derived with comments: the Closed-stamp axis (the glyph owns the axis now), the wayhome-visibility (buttons, not links), and the ledger-tooltip pin (moved to an open page — closed pages have no stars to hover). The open-game grays — bid-locked stars, bid-protected ×s — are untouched; the exception is scoped to closed pages only.

Yours: thumbs-up/down on the parchment strength (72% mix — it's assertive; easy to dial) and the gavel-stamp choice; English for the three deck tips (Incarnatio prior / Incarnatio recentior / Ad auctionem vivam); and the standing items — deploy (archive + arcs need the server), sver yes/no, the 320px axes-vs-crush ruling, the legend band-step, the blub comment-vs-markup contradiction.

Straight answer to the process question: nothing you should have needed to do — the miss is identifiable and mechanical. The fresh-eyes critic pass ran *before* the deck existed, and the deck itself shipped without one; and the eyeball was a full-page screenshot glance, where a 1.1rem glyph is a few pixels — no zoomed crop of the changed region, and no alignment pin at the element's birth (the Archive control got one; the arrows didn't). The standing fix, adopted as of now: any new visible element gets (1) a numeric alignment/size pin at birth, (2) a zoomed-crop eyeball, (3) a critic pass — before it's presented. If you want it enforceable on every future agent, a line for your rules section (yours to add, Fable can't edit above the scratchpad line): *"New UI gets pinned geometry + a critic pass before it's shown to me."*

Now the arrows, fastidiously. The right fix is structural, not more numeric duct-tape: the tombstone occupants become one flex row (align-items: center makes alignment exact by construction, gap replaces the margin dance, and the vertical-align hack dies), and the glyphs grow to real size. Pins first, red first:

Pins in; red run going. The flex-row restructure lands the moment red is confirmed — no mid-run edits this time.

Both suites running against the flex-row tombstone. Zoomed-crop eyeball follows the green — the new discipline.

Both corrections in: unselected stars hold their column invisibly, your star and the footnote stay, ×s gone, no icon. The in-flight story run is superseded (mid-run file edits); the clean run launches the moment it exits — the port-collision lesson — then fresh screenshots with a zoomed crop of the tombstone region.

Right call for click-through ergonomics. The fix: the deck right-anchors in the tombstone row (margin-left: auto on its first arrow) — the arrows then sit at the card's right edge on *every* page, immune to the stamp's variable-width date and the Archive control's presence, so the pointer stays put while paging through versions. (One honest caveat: hopping archive↔live still shifts the row *vertically* by the reveal-button's height — page anatomy differs; x and the archive↔archive loop become fully stable.) Pin first, cross-page:

Port free, frontend green. Red run for the right-anchor pin:

Red run going — this one also verifies the star-column amendment and the icon removal in the same pass. The one-line CSS lands on its red verdict.

Measurement corrected; red run re-going for the right-anchor pin.

Anchor applied; green run going.

Story 254 green. The zoomed-crop eyeball, per the new discipline:

The live page confirms it: the deck sits at the identical right-edge x (pinned within 2px cross-page), with its breath below REVEAL — ‹ live, › » grayed. Memory, then the wrap:

All three corrections landed, true-red-first, all suites green — 1,225 assertions (gas 301, frontend 651, serve 19, story 254). Zoomed crops verified this time.

• Stars amendment: unselected stars are visibility: hidden — the box holds its column, which is what repairs the alignment the display:none broke (the header-over-cell axis had no closed-page pin; it does now). Your gold star and the "★ = you" footnote are back; ×s stay gone.
• Icon: removed. Closed-conveyance now rests on the parchment and the stripped-down record alone.
• Arrows: rebuilt structurally — the tombstone is one flex row (stamp · Archive · deck on a single pinned centerline), glyphs at 1.5rem (pinned ≥ 1.4rem), and the deck right-anchors, so it sits at the identical x on archived and live pages — the red run measured 250px of drift before the fix; the cross-page pin now holds it within 2px. One disclosed caveat: hopping archive↔live still shifts the row vertically by the REVEAL button's height (page anatomy differs); the archive↔archive paging loop is fully stable in both axes.

The fastidiousness answer from earlier stands as adopted practice — birth pins, zoomed crops, critic pass before anything is shown — and the one-line rule is yours to add to your section if you want it binding on every future agent.

Still in your court: deploy (archive + arcs need the live server), the sver yes/no, English for the three deck tips, and the earlier rulings (320px axes-vs-crush, legend step, blub comment-vs-markup).

Implementation in; story running. The frontend red run (pre-implementation snapshot) and its green successor, plus the write-feedback research, are all pending. Then: crops of the chips for the eyeball, and the research proposal for item 2.

The chips read well — hairline-bordered mini-chips with the house hard shadow, the disabled ‹ visibly flat, right-anchored on the shared centerline. Pressable-looking, still quiet. Waiting on the frontend red verdict, then its green run, then the item-2 research proposal.

Green run going. One process note for the record: the drumroll pin's red was lost to the qual crash (the title pin crashed first, before the drumroll asserts ran, and the implementation had landed in parallel by the rerun) — its discriminating power is by inspection (a pressArchive that never set .stale fails it directly).

Proposal complete. The frontend green run is the last gate; the consolidated answer (chips, drumroll, titled links, and the four-option write-feedback proposal for your pick) lands with its verdict.

All green — 1,229 assertions (gas 301, frontend 655, serve 19, story 254). The deck restyle and README items 1 and 3 are shipped; item 2 has a researched proposal awaiting your pick.

The buttons: now mini-chips — the corner-icon recipe at whisper strength: hairline --border outline, card paper, a 2px hard shadow in border ink (not the chips' full 4px pop), glyphs unchanged at 1.5rem so the size pin holds. Disabled reads flat and faded; hover takes accent. The crop looks right — pressable, still quiet.

README item 3 (gavelspinner during Archive): yes, and it's in — the archive now wears the reveal's exact drumroll (gavel over the grayed ledger until its own settle). The revealInFlight flag generalized to verdictInFlight, one concept for the two table-wide one-way ops.

README item 1 (titled markdown links): fixed — [anchor text](url "hover text") renders with a real title attribute; pinned end to end through the blub pipeline, escape-first posture intact. On "a smarter markdown renderer?": recommend against vendoring one — the hand-rolled subset's escape-first design is the app's XSS armor, and a real renderer means adopting a sanitizer and re-fuzzing the whole surface; extending the subset per-construct (as here) keeps that posture. If you want more markdown features, name them and they get arms.

README item 2 (the saved-then-failed whiplash) — four researched options, ranked:

• A (recommended): the pending gavel. Keep the optimistic paint; while the save is aloft, a mini hammering gavel badges the description card (gavel = "untrusted picture," the app's own vocabulary), appearing only if the settle takes >0.3s. The conflict dialog then resolves a visibly-open question instead of revoking a closed one. Zero new words, zero latency, near-zero new paths. Needs one ruling from you: bless the desc card as a second gavel site (the one-gavel law).
• B (your pre-authorized fallback): pessimistic blub save. Editor stays open, grayed under the gavel until the verdict; the trusted-then-revoked state becomes unreachable, and it *deletes* the walk-back/reopen machinery — but every save pays the honest 0.5–2s, and two standing rulings (signless writes, version-at-click) get amended.
• C: A plus a small Docs-style "saving…" wordmark (Latin until you word it) — maximal legibility, most chrome; hold in reserve.
• D: merely pacing the bounce with a timer — not recommended.

Common ground from the research: your own diagnosis ("feels ok once i'm used to it — it wasn't obvious enough") is illegibility, not optimism; and the blub is the app's only refusable-by-rival op, so treating it specially is principled, not inconsistent. Pick a letter and it gets built red-first.

Building A now. And no — the one-gavel ruling inside A was just the newest; the full open list is at the bottom. First, the gavel CSS mechanics, then red quals:

Red run going; implementation lands on its verdict.

The busy-sign probes are presence-based, and the desc gavel is now a permanent resident (visible only via CSS). Re-deriving all three probes to visibility semantics with the resident excluded:

Both suites re-running with the re-derived probes.

Whack-a-mole territory — sweeping every remaining presence probe at once instead:

That was the last presence probe (the grep found exactly one). Story re-running; frontend still out.

The gavel is placed right but the capture caught it mid-fade — tightening the pin to full opacity before the shot (which also pins full visibility, not just onset):

Full-ink pin in (the 0.45s lit-point sits inside the 800ms flight window). Story and the frontend discriminator both running.

Noted for the record. Solo frontend run follows the story verdict.

Centered, pinned. Story queues behind the solo frontend run (serial discipline holds).

Running. The consolidated reply — including the full open-questions inventory you asked for — lands with its verdict.

Option A is built and green — 1,232 assertions (gas 301, frontend 656, serve 19, story 256). While a blub save is aloft, the description card wears a mini hammering gavel at full ink beside the pencil — appearing only if the settle takes >0.3s, fading with the tint at the ack, dark for every other kind of write. Crop-verified (the crop rule caught one real fault pre-presentation: a fixed-top gavel hung off one-line cards; now centered and containment-pinned). The signless-writes ruling carries its carve-out in the code comment, and four probes were re-derived to allow the resident gavel while requiring it dark for non-desc writes. See quals/screenshots/story-pending-gavel.png.

No — that wasn't the only open question. The full inventory, ordered by consequence:

1. Deploy — the big one. Everything server-side from this whole stretch (the archive action, the arcs payload) is dead on the live site until you commit/push and run npm run deploy. Until then, live pages also fail the state-shape assert against the new client. Everything else below is optional; this one gates actual use.
2. The sver skew gate — specced, awaiting yes/no. (Would make item 1's skew window loud-by-design forever.)
3. 320px fine-pointer ruling — crushed-bids-with-aligned-axes (status quo) vs roomier-bids-with-drifting-axes (the reverted fix). Flagged in the CSS at the column-yield block.
4. Deck tips' English — Incarnatio prior / Incarnatio recentior / Ad auctionem vivam await your words (they're the arrows' tooltips/accessible names).
5. Blub-editor spec contradiction — the CSS comment says field → preview → buttons; the markup ships field → buttons → preview. Which is spec?
6. Legend band-step — 0.9rem vs the 1.1rem step used everywhere else: unify or register as deliberate.
7. 8b, coarse-pointer emulation — phone story captures render fine-pointer CSS, so the touch-ergonomics block ships unaudited on film; one-line harness change plus re-deriving the phone scenes' asserts. Go/no-go.
8. Housekeeping: the pulse-gate qual 1c3b's known flake class (zombie edit-beats in its counting window) — deflake or leave; and sourcery.html regeneration via your tool whenever.

Also on record from earlier: a3febb2 in your pushed history is a red commit (the disclosed mutation-test incident) — rewriting is your call and probably not worth it.

While the touch sweep iterates (each run surfaces the next scene to re-derive), the two answers you're waiting on:

Version-handshake cost, precisely:

• Speed: zero measurable. The version is a hard-coded integer constant in Code.gs — no sheet read, no extra request in either direction. It adds ~12 bytes to the state payload the server already builds, and the client check is one integer comparison inside the shape-assert that already runs on every adopted snapshot.
• Code complexity: one constant in Code.gs, one constant plus one assert-conjunct in app.js, one line in the deploy smoke, and two small quals (a weld pinning the two constants' relationship, and a ledger that fails loudly if someone adds a server action without bumping). Roughly 30 lines total, no new states or branches at runtime.
• The real cost is a ritual: whenever the page starts *depending* on new server behavior, the number must be bumped. Forgetting the bump for a new action is caught mechanically by the ledger qual; forgetting it for a behavior change *inside* an existing action still relies on the human/agent remembering. That judgment-residue is the whole price.

320px, see for yourself — two screenshots beside the others: [320-aligned.png](quals/screenshots/320-aligned.png) (status quo) vs [320-roomy.png](quals/screenshots/320-roomy.png) (the column-yield variant). The trade in one line: aligned gives you full names (@bartholomew) but bid cards crushed to tiny squares; roomy gives bids honest width but clips names hard (@annab, @barth). Sealed decoys shown; with revealed long bids the aligned variant's crush gets considerably worse than pictured.

Also done from your earlier answers: the blub-editor comment now records the markup as spec, and the phone captures now emulate touch — first re-derivation (the star-alignment pin, moved from box to ink semantics, honoring the coarse block's own ink-stays-put promise) is running now.

All four suites green — 1,232 assertions (gas 301, frontend 656, serve 19, story 256), with your three answers acted on:

• Blub layout: markup ratified as spec; the stale comment now says so.
• Touch quals: phone captures emulate touch. The entire pass cost one pin re-derivation — the star-alignment pin now measures the glyph's *ink* instead of its inflated hit box, which is exactly the invariant the coarse block promises ("ink stays put"). Everything else held, and the touch-ergonomics layer finally exists on film. NARROW deliberately stays fine-pointer since it probes the case your 320px ruling governs.
• Version handshake: cost figures delivered above — ~zero runtime, ~30 lines, the real price being the bump-the-number ritual (mechanically fenced for new actions, judgment for behavior changes). Your call stands open.

Waiting on you: the sver yes/no; the 320px pick ([320-aligned.png](quals/screenshots/320-aligned.png) vs [320-roomy.png](quals/screenshots/320-roomy.png)); English for the three arrow tooltips; the legend 0.9-vs-1.1rem nit; and the deploy — still the gate for everything server-side this whole stretch built.

Both rulings in hand — building the handshake red-first and applying the roomy ruling. (Fragility answer in the wrap-up: the short version is that forgetting a bump degrades to *today's* behavior, never below it.) Gas red first:

Frontend running (solo, per the serial rule); story follows it. Then the wrap with the fragility answer.

Story running — the roomy yield and the narrow-scene re-derivation get their real-Chrome verdict there.

Both rulings shipped, all suites green — 1,235 assertions (gas 301, frontend 659, serve 19, story 256).

The fragility question, answered directly. Forgetting to bump the number can only ever degrade to *today's* behavior — a dead button during a skew window — never below it. The gate is a pure ratchet: it adds loudness when the number is right and adds nothing when it's forgotten; there is no failure mode where it makes things worse. And most forget-paths are mechanically fenced:

• Forget on a new action → impossible to ship: the ledger qual fingerprints the server's action list per generation, so adding an action without bumping fails the suite by name, with instructions.
• Forget on a new payload field the page requires → already caught: the shape assert refuses a state missing the field (that's exactly how the arcs change behaves), loudly, with the same deploy marching orders.
• The truly silent residue: a semantics-only change *inside* an existing action — same fields, same actions, different meaning. That one genuinely relies on the human/agent remembering. It's also the rarest kind of change here.
• The reverse mistake — bumping the page's requirement but forgetting to deploy — can't hide either: the deploy smoke now asserts the live server's generation meets the published page's requirement, so it fails on every run until the deploy happens.

What shipped: the server states generation 1 in every response; a page needing newer refuses at load with a banner that *is* the fix ("deployed Code.gs generation … predates this page — npm run deploy"); weld + ledger + skew-scenario quals; the deploy smoke line.

Roomy is in at narrow widths — the column yield now applies on coarse pointers *or* windows ≤26rem. The narrow scene's three axis/edge legs were retired under your ruling and replaced by a doubled bid-box floor (≥6rem), with the ruling cited in both the CSS and the qual.

Still yours: the deploy (now doubly worthwhile — it makes the handshake live), English for the three arrow tooltips, and the little legend band-step nit.

That failure is worth chasing before your retry finishes — reading the idempotency qual and reproducing solo:

Heads-up while your retry runs: the deflake edit just dirtied quals/frontend-quals.js in your tree. If your current retry already passed the era guard, it will finish normally (and if its frontend suite launched after my edit, it even picks up the fix). But any *subsequent* npm run deploy will be refused by the era guard until the deflake is committed and pushed — so if this retry fails again or you re-run, commit first.

Diagnosis recap: the failing qual samples with a fixed 100ms sleep for its claim/release round trips; under deploy load (clasp and friends sharing your CPU) the ops lost that race. It's the suite's own documented fixed-sleep flake class, not a real idempotency break — the same qual passed repeatedly solo here. It now waits the ops out properly; solo confirmation run is in flight.

Frontend 659 green with the deflake. Standing state: all four suites green (gas 302, frontend 659, serve 19, story 256), one uncommitted file (quals/frontend-quals.js, the deflake) that needs your commit before any *next* deploy passes the era guard. If your current retry lands, the archive feature, incarnation deck, arcs, and the version handshake all go live together — and the handshake makes every future skew window announce itself.

Not crazy — right instinct, but the label swap alone won't buy the alignment back. Two separate things are off in the skinny layout:

1. "PARTICIPANTS" clips (it renders hard-cut at the column edge, e.g. "PARTICIPA"). Swapping to "PARTIC." at skinny widths fixes that cleanly — your copy, a two-span toggle in the markup, cheap.
2. "BIDS" drifts off the bid column — but that's not the label's width doing it. The header cell and the name cells sit in *different flex rows*: under pressure the name column shrinks below its 8.1rem basis (to ~80px at 320px) while the header row, having no such pressure, holds the full basis — so BIDS floats ~50px right of the cards no matter how short the header text is.

To actually restore header-over-column at skinny widths, the name column and its header need a fixed, equal width there (≈5.2rem), so nothing shrinks divergently — which also makes name-clipping deterministic instead of pressure-dependent, and pairs naturally with "PARTIC." since the full word wouldn't fit the fixed column anyway. That would un-waive the alignment concession from the roomy ruling entirely: roomy bids *and* true axes, at the cost of harder name truncation at narrow widths (which roomy already accepted in kind).

One question: do the full version (PARTIC. + fixed-equal narrow columns, axes restored and re-pinned), or just the label swap (unclipped header, BIDS keeps drifting)?

Short version: the label swap alone won't fix it — BIDS drifts because the name *column* shrinks, not the label. Doing the full nicer thing: "PARTIC." plus equal fixed columns at truly-skinny widths, headers exactly over columns again. Building it, red-first:

Red run going; implementation staged for its verdict (no mid-run edits).

Red confirmed. Implementing:

Applied; green run going. A fresh 320 screenshot follows so you can see it.

Done — see [320-skinny-final.png](quals/screenshots/320-skinny-final.png): PARTIC. sits exactly over the names, BIDS exactly over the cards, bids roomy. The restored axis quals pin it numerically (story 256 green); one frontend sanity run is finishing in the background.

All green — gas 302, frontend 659, serve 19, story 256, 404 in sync. The skinny tier is complete: PARTIC. over the names, BIDS over the cards, axes pinned again at every width. Outstanding on your side: commit (the tree has the deflake + this tier uncommitted, and the era guard will insist), then the deploy if your retry didn't already land it — plus the two small stragglers whenever: English for the three arrow tooltips, and the legend band-step nit.

The blub spec already names eat-the-richtext as the reference ("standard markdown rules a la…"), so first: what it actually does. Fetching its source:

Implementation and docs in; awaiting the red verdict, then the green run.

Red confirmed against the pre-implementation snapshot. Green run:

Green run going; gas/serve/story follow serially (the fuzz battery and blub scenes get their say on the new arms).

The pre-existing code-span pin caught the nesting regression before it could ship — running again.

Frontend 662 green. Story last:

Story running — the last gate before the wrap.

Done — all suites green: 1,239 assertions (gas 302, frontend 662, serve 19, story 256).

The dialect landed: _underscores_ italicize, __doubles__ embolden, both asterisk forms unchanged — and underscores never trigger intraword, so snake_case_words and URLs like e.com/a_b_c come through untouched (links now shelter behind the same stash that protects code spans). On "just do what eat-the-richtext is doing": adopted its *dialect* — it's Quill + Turndown, and Turndown emits exactly _em_/**bold** — but not its machinery, which is an editor stack, not a renderer; the hand-rolled escape-first subset keeps the XSS posture.

One regression during the build was caught by an existing qual before it could ship: reordering the link pass broke code-spans-labeling-links (a nested placeholder went unresolved); fixed by resolving nesting at stash time. One known trade, disclosed in the comment: emphasis markers inside link *text* now stay literal — rare, and the price of underscore-safe URLs.

Uncommitted in your tree and era-guard-relevant: this dialect change, the PARTIC. tier, and the earlier deflake. Commit, then deploy when ready.

Two workstreams: the star bug (hands-on reproduction of your exact flow first, quals once diagnosed) and the anti-magic audit (fresh AGENTS.md read + a worktree-isolated review pass). Launching both:

Now writing the red quals. First the anchors — the tail of the gas archive happy path, and the frontend claim-action shape:

Gas qual red as intended. Frontend now:

load() already pads — r.dvid is always a string. Implementing the server side:

Now the SVER ledger entry (the fence qual would otherwise fail the bump by design):

Diagnosed and fixed. All suites green: 308 + 666 + 19 + 259 = 1,252.

Diagnosis. A scripted Chrome walkthrough of the literal replicata *passes* — the bug is a class, not that exact sequence. Post-reveal, the is-you star rode two mutable legs, and either can rot after bidding is done:

1. The claim column. A rival device claiming your seat takes it last-write-wins, and the radio law simultaneously blanks the rival's *old* seat — so your dvid can end up on no claim at all. One-browser path to the same state: your amended gesture — typing as ann, star-switching to ben — leaves ann's seat claimless too.
2. The slug-keyed ledger. tauction-usids remembers "at famstar you are X" — but the archive renames the slug out from under that key, and round two recycles it. The archive page then has no memory and (with leg 1 rotted) no claim to re-latch from. Reproduced: archive page renders with no star on any row.

The fix — no cases added. The bids log already carries dvid per row ("cheating forensics"). The server's fold was walking those rows and dropping that column; it now keeps it, and every bidders entry carries its *standing* bid's dvid — unconditionally, zero new branches ([Code.gs:646](apps-script/Code.gs#L646)). Client-side there is exactly one new if: whoHere's revealed-fork ([app.js:1189](app.js#L1189)) — post-reveal, mineness is a pure filter over the immutable record (usidOfRecord); pre-reveal, the claim model stands, necessarily, since identity must exist before any bid row does. The fork sits at the single choke point all consumers share (star, "Your bid" tips, hidden-tab title, editing beat), so none can disagree. The converse is pinned too: a stale claim in your favor over a rival's standing bid stars *nothing* — the record outranks the claim. The ingest re-latch still writes vestigial ledger entries on revealed pages; removing that would cost a new if for zero visible change, so it stands. New names for veto: usidOfRecord, whoHere.

Quals (red first, then green): gas forensic-column block (theft, re-bid re-attribution, rides the rename); frontend replicata + converse + your draft-jump amendment (draft rides the star-switch; then on through submit→close→archive to the star); a story journey in real Chrome ending at the archive via the deck — screenshot story-record-star.png shows ben starred, ann's star hidden, footnote intact.

Deploy owed: this is SVER 2 (SVERMIN 2), so pages will refuse the deployed generation-1 server at load with the marching-orders banner until: commit + push, then npm run deploy (lane 4 — the skew heals when the deploy lands).

The anti-magic audit (three lenses over app.js/Code.gs, adversarial verify per proposal) is in its last verification — 21 of ~22 verdicts in, 13 proposals surviving so far. Findings follow when it completes.

The anti-magic audit finished — 25 agents, 22 proposals judged, adversarial verification per proposal. Reading the full survivor list:

Now the pulse seed. Reading tab(), pulseCheck, mutate, and fake-gas's mirror:

Now the fake-gas mirror for the seed, then the gas suite:

fake-gas runs the real Code.gs, so the seed flows through the real tab() path. Running the gas suite:

Now the five .ready qual re-expressions:

Cluster B green. Cluster C texts:

Starting cluster C with the verdict class. Reading all verdictInFlight sites and the refresh tail:

Applying the verdict class — JS sites first, then CSS aliases:

The edit dropped pressReveal's class-add line — restoring it as verdict:

Verdict class complete and green. Now the null-state abolition:

Now the story-suite computed pin, added to the settled-record scene:

The anti-magic sweep is applied: 14 verified simplifications, all suites green — 308 + 667 + 19 + 259 = 1,253. The audit ran 22 proposals through adversarial refute-by-default verification; 8 were refuted (left alone), 14 survived with file-level receipts and are now in the tree, alongside the star fix. Every change *removes* conditionals or moves a fact to one owner — nothing was fixed by adding cases.

Code.gs (4): patch reads its record unconditionally (the memo is warm — the ternary guarded a free read and hid a null-deref); getState defaults a missing auctions row to a virgin *value*, so tfin/blub/bver read unconditionally and virgin bver flows through the same corruption parse as real rows; the four dead ensureAuction calls in rename/remove/claim/release are deleted — they could only ever fire on a hand-gutted sheet, where they silently forged a fresh row with a fake tini (anti-postel: that heal is gone, the invariant is documented on ensureSeat); the pulse row is born with its tab (TAB_SEEDS, painted at creation like the cheater banner), which collapsed mutate's insert-vs-patch fork, pulseCheck's undefined branch, and getState's ternary — an emptied pulse tab now refuses as corruption.

app.js structural (5): state is never null — born as the virgin snapshot, re-seeded per page before the cache gets a say — deleting render's guard, myUsid's ternary (the star fix's fork is now just whoHere(seats, state)), syncPencil's null leg, the pulse gate's null check, and switchAuction's dead re-null. The slug is write-once, asserted once in ingest — four scattered res.slug === slug re-checks dissolved; a canonicalizing server would now crash loudly by name instead of silently skipping adoption. The reveal/archive drumroll got its own verdict class (CSS aliases the five .stale selectors): the verdictInFlight boolean is deleted and every remove('stale') went unconditional — two meanings, two classes, no flag mediating. editors joined arcs' assertState convention (the silent empty-desk fallback died; a stripEditors skew fence pins the loud refusal). And syncNamed() is the one owner of the unnamed-page freeze — five controls derived from slug === '' at the two slug moments; the render-time re-disables are deleted and the + row's post-reveal retirement belongs wholly to CSS, both directions (the archive rebirth un-hides it with no JS hand).

app.js small (5): the ingest re-latch reads as its one real condition; commitRename's settles close over field (killing two if (node) guards and a latent flash/settle mispairing); the reveal button is disabled = !ready with the ready class vocabulary deleted outright; the row ×'s freeze collapsed to "a bid protects its seat" (the revealed leg was doubly dead); mdRender's h/hr emitters went line-wise, so the run-merge special case died with byte-identical output (fuzz-pinned).

Qual edits, disclosed (the loop-you-in list): five .ready asserts re-expressed to disabled — same pins through the surviving vocabulary; six drumroll asserts re-aimed from stale to verdict; the roster-closed-once-revealed pin relocated from jsdom-DOM to a stylesheet-source pin plus a computed zero-width pin in the story settled-record scene; one new fence (stripEditors). Nothing was loosened — say the word and any of these revert.

New vocabulary awaiting your veto: usidOfRecord, whoHere (star fix), syncNamed, TAB_SEEDS, and the verdict class.

TAB_SEEDS causes no schema drift (headers unchanged; your live pulse tab already has its row), so the deploy story is unchanged: commit + push, then npm run deploy — still owed from the star fix's SVER 2 either way.

A fair challenge — here's the honest ledger for the seed:

Deleted: mutate's insert-vs-patch fork (a branch inside *every* write, whose insert arm hardcoded '1', silently duplicating the String(cur + 1) knowledge), pulseCheck's undefined early-return, and getState's existence ternary. Added: one creation-time if (TAB_SEEDS[kind]) sitting next to the structurally identical TAB_WARNINGS lookup, plus one name. Net: three runtime branches out, one creation-time branch in — and the absence case didn't just move, it changed meaning: an empty pulse tab used to read as "virgin, 0"; on a seeded world it can only be hand-editing, so it refuses through the existing corruption throw (anti-postel).

One part of the criticism does land: the [['0']] 2D shape generalized past the need (multi-row/multi-column seeds nobody asked for — YAGNI). Trimming it to a scalar cell:

Both suites green after the trim (gas 308, frontend 667). TAB_SEEDS is now { pulse: '0' } with a plain setValue — one cell, matching the one need.

So the standing answer to "too much?": the seed's direction is a real win (a fork inside every write plus two reader branches and a duplicated '1' died for one creation-time lookup), and the table-of-one shape follows TAB_WARNINGS, the existing precedent three lines up in the same block. The over-generalized 2D machinery was the genuinely excessive part and is gone.

If the judgment is that even this isn't worth a new name, the honest fallback is reverting to lazy minting wholesale — but that resurrects all three branches, including the write-path fork, which is the worse side of the trade by the anti-magic ledger. Reverting on request is a two-minute change either way.

Fable is looking at the recent commits to identify Sol's work, then will review it against the AGENTS.md rules (reread — the full content is loaded in context) and run the quals.

Interim status while the two background runs finish: the full qual suite is running on the working tree, and a five-dimension review workflow with adversarial verification is running over Sol's commit. Findings so far, from direct inspection:

• The pushed tree is qual-red. [frontend-quals.js:6603](quals/frontend-quals.js#L6603) pins 404.html as an exact copy of index.html, but Sol's commit bumped index.html to v2026.08.11-b without syncing, so HEAD (= origin/main, published) has a stale 404.html — every /slug deep link on Pages currently serves the old -a page. The fix already exists as the uncommitted 404.html change in the working tree (deploy's own sync-404 step produced it); it needs a human commit + push.
• The server side was deployed after the commit (deploy stamp 10:22, commit 10:16), so committed Code.gs is live.
• .codex/rules/git.rules is a Codex-side mirror of the read-only-git rule — consistent with the git-workflow rule, harmless.

Full verdict when the suite and the review workflow report back.

Qual suite is fully green on the working tree: 1271 assertions across the four suites (gas 315, frontend 678, serve 19, story 259), exit 0 — so with the uncommitted 404.html sync in place, nothing is broken that the quals can see. The review workflow is still running; final verdict when it completes.

Provisionally yes, with one blemish. What's established so far:

• The substance of the commit is real improvement in intent: fewer API reads (the pulse gate no longer held open by your own editing presence), coalesced refresh triggers instead of dropped ones, a commit barrier so the pulse can't outrun its data, and a storage memo that stays coherent instead of re-reading the sheet after every write. All of it came with ~480 lines of new quals, and the full suite is green (1271 assertions).
• The blemish: the commit was pushed with index.html bumped but 404.html unsynced, so the pushed tree fails its own exact-copy qual and Pages is serving the stale 404.html to /slug deep links right now. The fix is sitting uncommitted in the working tree — it just needs the usual human commit + push.

Whether anything got *subtly* worse — races in the new refresh loop, memo/sheet divergence, weakened quals, spec drift — is exactly what the five-reviewer workflow with adversarial verification is still checking. "Improved" gets confirmed or amended when that reports back.

/workflows in this session shows the live progress tree. Checking current state directly:

Two ways to watch it, and a rough ETA:

• Watching: type /workflows in this session — it shows the live progress tree (phases, per-agent status). The raw transcripts also land in the workflow's transcript directory if you want to tail them, but /workflows is the intended view.
• Status right now: 14 of 15 agents are done — four of the five dimension reviewers finished and their adversarial verifiers have already run. One reviewer is still working (by elimination and transcript size, the storage-memo-coherence one — the heaviest dimension; its transcript was still growing 15 seconds ago). When it reports, whatever serious findings it has each get two refuters, then the workflow returns.
• ETA: its siblings' verification rounds took about 5–8 minutes, so roughly 10–15 more minutes if it reports findings, less if it comes back clean. A completion notification arrives here either way, and the full verdict follows immediately after.

Checking the live state directly:

Yes — confirmed still running, and progressing: the fifth reviewer (memo-coherence) finished at 11:41:39, and two fresh verifier agents spawned about 20 seconds ago and are actively writing their transcripts. So it's now in the last verification round; the two-refuter passes have been taking a few minutes each.

On /workflows: that's a terminal-UI command and it apparently didn't attach in this session (the stdout says the restored session had no launch handoff to replay — a harness quirk, not a sign the workflow died). The journal and per-agent transcripts under the workflow's directory are the ground truth, and they show live writes as of seconds ago. The completion notification will land here either way, followed by the final verdict.

Review complete: 17 agents, every serious finding adversarially verified by two independent refuters, on top of the green 1271-assertion qual suite. Verdict: the commit is a net improvement with one confirmed user-visible regression, one qual-governance violation, and a pile of doc/comment drift. Nothing touches data integrity.

Confirmed regression (found independently by two reviewers, reproduced empirically by three agents against both versions):

• Background-opened tabs now boot blind. The new drain loop in [app.js:550](app.js#L550) gates every iteration on visibilityState === 'visible', and init's boot refresh flows through it. Cmd-click a tauction link into a background tab: before, it loaded the roster and set the padlock title within ~1s; now it stays an empty page titled "tauction" for up to 60s (until the title peek), and content arrives only after focus plus a full round trip. Both timelines cost the same one API read, so this bought no quota — pure sluggishness from a commit titled "improves polling / sluggishness". It heals on focus, and no qual pins hidden boot in either direction.

Rule violations worth a human ruling:

• Qual 1f3 was loosened without sign-off ([frontend-quals.js:3156](quals/frontend-quals.js#L3156)): the parent's absolute "one state read for the page's whole life" pin became a relative count behind a self-healing retry loop. The review found the loosening was probably *necessary* (restoring the absolute pin failed 2 of 4 runs — zombie editor beats from earlier quals bump the pulse), but "never loosen a qual without looping in the human" makes this yours to ratify.
• Several new quals carry fictional "Resultata pre-fix" narratives: 18v and 18x in gas-quals (and 1c3c0 in frontend-quals) describe pre-fix failures that the parent commit never exhibited — they narrate Sol's own abandoned intermediate drafts as if they were shipped history. The quals themselves are legitimate fences; the recorded bug-report framing is false.

Verified-split risks (one refuter each side; judgment calls, not clear regressions):

• The new write-through memo means write responses assert the *intended* values rather than re-reading what Sheets committed — the old memo-drop rule was an accidental fidelity check. The armor (plain-text columns, all-string writes) should make them identical; the guard is gone regardless.
• The new calm-count assertions share the same zombie-beat flakiness class that forced the 1f3 rewrite, so occasional suite flakes are possible.

The scary-sounding memo findings ("memo mutated before the sheet write leaves fiction on a throw") were refuted: a failed execution dies with its memo, and nothing catches and continues.

Nits, condensed: appended-retraction comments leave retired rules standing in current tense in three blocks (mutate, wrote, the pulse gate); [Code.gs:330](apps-script/Code.gs#L330) and the archive() comment at [Code.gs:867](apps-script/Code.gs#L867) still describe retired behavior with no retraction at all; AGENTS.md's "nobody is at the desk" pulse-gate sentence is now false; the load-bearing bare getState(slug) preflight in noteEditing ([Code.gs:969](apps-script/Code.gs#L969)) is uncommented and reads as dead code (three reviewers flagged it); one new qual hardcodes patchGhost copy the suite's convention derives.

Plus the already-reported hygiene item: the pushed tree fails its own 404-parity qual — the uncommitted 404.html sync needs your commit + push, and until then Pages serves the stale page on /slug deep links.

What was checked and came back clean: the refresh queue/drain has no lost-wakeup or stuck-flag races; the rivals-only pulse gate is coherent with the pencil (same filter, one function) and nothing displayed depends on own-presence aging; the flush-inside-lock ordering closes the races it claims without opening new ones; no human-written prose or microcopy was altered byte-wise; no existing qual was removed; .codex/rules/git.rules is consistent with the git rule.

Suggested order if fixes are wanted: the hidden-boot gate (smallest honest fix is likely letting the boot/first refresh run regardless of visibility), the 404 commit, then the comment/doc drift sweep. Say the word and Fable will take any of these, red quals first.

I'll check sourcery.html for exposed secrets.

No credentials leaked. No OAuth/refresh tokens, API keys, private keys, JWTs, cookies, or passwords. Notably absent: the clasp scriptId from [.clasp.json](.clasp.json) and the full AKfycb… deployment id from [app.js:9](app.js#L9) — both appear only as truncated placeholders in prose.

What *is* in there, with exposure already-existing elsewhere:

| item | where | verdict |
|---|---|---|
| Sheet ID 1hclph…hiMA8 | [sourcery.html:428](sourcery.html#L428) | already public — in [README.md](README.md), [Code.gs:11](apps-script/Code.gs#L11), and shipped to every visitor as state.sheet ([Code.gs:737](apps-script/Code.gs#L737)) so app.js can poll gviz. sourcery adds nothing. |
| user_content_key=AUkAhn… | [sourcery.html:8569](sourcery.html#L8569) | dead — probed it, 404. Ephemeral response URL from a pasted console line. |
| dreeves@gmail.com ×4, dreeves@beeminder.com ×2, /Users/dreeves ×136 | throughout | PII, not secrets |
| "Portland, OR" + device signalments for @dreev and @faire | prose + a console screenshot (img05) | PII, not secrets |
| 9 embedded images | — | opened all: app screenshots + gavel art, nothing sensitive |

Confirmed sourcery.html is world-readable at tauction.dreev.es/sourcery.html (200).

The thing actually worth caring about — and it isn't sourcery.html. Fetching the sheet's /edit page with no credentials returns "oui":"ANONYMOUS_00801369372001435688","editable":true,"commentable":true. The sheet is anonymously writable, not just readable. Since the sheet ID is handed to every visitor by design, anyone who loads tauction can open the sheet and rewrite or delete production data directly, bypassing Code.gs's locks, cutoffs, and the reveal latch entirely. "Sealing is honor-system" is documented; unauthenticated write is a strictly larger grant than the honor system needs.

Fix is one setting: change link sharing from Editor to Viewer. Code.gs writes as you, so nothing server-side notices, and the gviz pulse read keeps working — read is what viewer-level link sharing grants.

That's the runaway grep killed earlier (catastrophic backtracking on the 2MB single-line HTML). Its target was already covered by the Python scan: the only clasprc occurrence is prose explaining that clasp's token lands in ~/.clasprc.json locally. No change to the findings.

Two problems: the empty-bid-cell tooltip, and the gavelspinner/ERROR2152 transport failure. Rereading AGENTS.md and the relevant code first.

Now implementing. Red quals first — starting with the harness so it can simulate the relay's HTML 404.

Now the red run, before touching app.js.

Red #1 captured. Now Fix A, so the run advances to the relay quals.

Red #2 captured — the console reported the parser's confusion, not the 404. Now Fix B.

All green (1281 assertions). Verifying the two quals I hadn't yet proven red — the story one, and the bounced-write banner.

Recording both rulings in the agent-maintained section.

Both fixed, red-to-green, full suite green at 1281 assertions (gas 315, frontend 686, serve 19, story 261).

1. The mobile tooltip. Sol's final diagnosis held up against the code: the persistence is correct and load-bearing — a tap summons via compatibility hover events, and finger-lift must not snatch the words back (the star's tap-tip depends on exactly that, pinned by story 5). The bug was a bidless cell *being* a tooltip host with nothing to say. [bidTip](app.js#L1955) returns '' there, which takes showTip's existing nothing-to-say leg — the one the REVEAL button already walks at the gavel. No touch branch, no timer, no dismissal handler; one if-statement's return value changed and awaitingTip is deleted from [stringles.js](stringles.js#L38).

Consequence to eyeball: desktop loses that hover tip too. The empty .bid-card.slot and the padlock's straggler-naming tip both already say it, which is why it reads as redundant — but it is a visible change, one word to revert.

2. The gavelspinner. Confirmed Sol's verdict by reading the wire path: nothing frontend-side causes the spin, and there is no retry deadlock. What was wrong is the diagnosis — a blind r.json() reported the parser's confusion, which reads like Code.gs emitting garbage when the script never ran at all. New [jsonOrDie](app.js#L79) judges status and content-type before parsing, in fetchPulse's idiom (assert the shape, quote what came instead), so the console now reads ERROR2152: assert: state HTTP 404 text/html: "<!DOCTYPE html>...". Both apiGet and apiPost route through it. No user-facing behavior moved: bounced poll is still weather, bounced write still banners.

Quals. The harness now answers like a real Response (ok/status/headers/text), which is what let the relay's HTML 404 be simulated at all — that path was absent from the suite entirely. New: frontend 1c3a (six assertions: bounced boot grays without bannering, console names the 404 and never "Unexpected token", the request names itself, a bounced write banners honestly, the weather heals) and two story assertions on a 390×844 touch viewport, with a padlock tap as the control so the cell's silence isn't vacuous. Each was run red first: the walk-back tip, the console diagnosis, the write banner, and the story tap all failed before their fix.

No Latin needed — no new user-facing copy; the console text is assert-family operator diagnostics, which AGENTS.md keeps in readable English. Frontend-only, so the ship step is commit + push; no deploy. Rule 14 is enforced: .claude/settings.json denies the mutating git verbs and ~/.claude/hooks/git-guard.sh allowlists only diff/log/show (it blocked a git grep during this work). Rule 8's answer: SPOT — Single Point of Truth, which stringles.js already embodies.

One open question, Sol's flagged tradeoff: should apiGet/apiPost get a fetch timeout? Leaving it out for now, because the measured successes ran 14.4s and 35s — a timeout short enough to shorten the spin would abandon requests that currently land.

Two real questions. Checking the regression risk first — my content-type gate is only safe if the live endpoint actually says JSON.

Content-type is application/json — the gate is safe. No service worker, no CSS keyed on [data-tip]. Now the latency. Reading the server's request path.

Now the actual diagnosis. Reads run unlocked through a 4s cache, so the server isn't obviously slow. Testing the live endpoint under concurrency — that's the decisive experiment.

Reproduced both symptoms locally. Splitting the two hops to find where the time and the 404 actually live.

The split is decisive. One more measurement to isolate dispatch from any sheet work — the no-action liveness reply touches no sheet at all.

Nothing worse, with one thing worth naming — and the fishiness is real, but it isn't tauction's.

On the regression risk. The one change that could have broken production was the content-type gate: if the live endpoint didn't say JSON, every request would now refuse. Checked against the deployment — the final response after the redirect is application/json; charset=utf-8, and every Code.gs reply goes through the one respond() that sets it. Suite is green in real Chrome too. Two things did change and both are disclosed rather than accidental: desktop hover loses "Awaiting bid..." on empty cells, and a bounced *write* now banners a longer string carrying 80 characters of Google's error HTML — uglier than Unexpected token '<', and true, which is the trade. No qual was loosened; the two that pinned the old tooltip were re-pinned and eight assertions added.

The multi-minute wait. The instinct is right, and the answer is that the sheet and the app are two different doors. Opening the sheet is Google's own frontend on its private endpoints. /exec instead schedules an *Apps Script execution*, then parks its output on a second host the browser has to go fetch.

Timing each hop separately shows where it all goes:

| hop | what it is | measured |
|---|---|---|
| /exec → 302 | dispatch + cold start + running the script | 1.1s, 2.5s, 6.6s, 9.0s, 20.7s |
| follow → content host | fetching the output | 0.18s, 0.28s, 0.28s, 7.4s, 404 after 30.7s |

time_connect was 0.03s on every one, so it is not the network. The 4s server cache was warm, so it is not Sheets work. To remove even that doubt, the same test against the no-action liveness reply — one line of JS that touches no sheet at all:

1.2s ✓   1.2s ✓   8.4s ✓   16.2s ✓   12.3s → 404   58.8s → 404

Fifty-nine seconds, and a 404, for a request that does nothing. Two of six failed. That exonerates Code.gs, the sheet, the quota, and the poll design: the latency and the 404s live entirely in Apps Script's dispatch layer, and execute as me means every visitor's request queues into one Google user's execution stream.

That composes into minutes like this: the poll fires every 5s but skips while one is in flight (!refreshing), and there is no fetch timeout — so the retry cadence is bounded below by Google's tail, not by POLL_MS. Two unlucky rounds is already a minute of gavel. Boot is the exposed moment: steady state costs zero /exec calls thanks to the pulse gate, and a returning visitor with a cached snapshot usually boots without one, so a cold first visit is what gets hit.

Caveat on the numbers: an 8-way concurrent burst was fired earlier in the session and may have left that queue backed up. But the very first cold sequential call, before any load was generated, took 18.5s and 404'd — so the effect is not self-inflicted.

This changes the timeout picture I gave earlier, which rested on weaker evidence. With a third of no-op requests burning 12–59s while successes often land in ~1.2s, abandoning a straggler and retrying might genuinely beat waiting it out — the counterargument being that a retry re-enters the same queue. Worth your call: should apiGet/apiPost get a timeout, and at what cutoff?

Both of those are real bugs, and neither needs a timeout. Reading the two paths.

Error 2 is the more interesting one. It can only come from a 200 JSON body with no error and no sver reaching ingest — and exactly one reply in Code.gs fits: the no-action liveness reply. Testing whether the relay crosses responses under load.

No crossed wires — every 200 answered its own question at sver=2, so the deployment is current. But 5 of 15 requests 404'd, and the bodies match dreev's error 1 byte for byte. Now testing the POST path, which is where error 2 must live.

Every proper POST works (302 → echo → 200 JSON, sver=2). Measuring the alternative read path the app already uses, to make the comparison concrete.

The comparison is stark. Now fixing the ERROR2158 banner — it violates the app's own weather law. Red qual first.

1285 green. Now making error 2 self-identifying rather than guessing at it — the assert currently discards the evidence that would name it.

1286 green. Both errors are explained; one was a real bug.

Error 1 was the new diagnostic working, and it exposed a genuine bug. The beat hit the relay's 404 — but it *bannered*, against the app's own transport-death law. A beat is a timer's ping, not a person's deed: nothing of the user's rides on it and the next one 10s later re-establishes presence. At the measured bounce rate an open blub editor threw a red plumbing code every few beats saying nothing actionable. It now dies into the one weather ritual, making it three legs (pulse, state fetch, beat). A *spoken* refusal from the beat still banners. That's a deleted code path, not an added one.

Error 2 could not be reproduced, and the obvious hypothesis is disproven. It can only be a 200 JSON with no error and no sver reaching ingest through the write chain — that message comes from chainOp's bare String(e). The suspicion was that the relay crosses responses; 15 concurrent requests with distinguishable answers say no — every 200 answered its own question at sver 2. Code.gs at sver 2 emits exactly one sver-less non-error payload: the no-action liveness reply. Honest disclosure: ~40 probe requests were fired at the live endpoint while you were experimenting, six of them action-less pings whose reply *is* that object. No crossing was demonstrated, but the overlap is real and the lags you saw were probably partly self-inflicted by this session.

Rather than patch on a guess, assertState now carries its evidence — it kept claiming "exactly one cause and one fix" while sending you to redeploy code that was already deployed, because *any* sver-less payload reads as an old generation. The verdict stands; the message now quotes what arrived, so the next sighting names itself.

The root problem, measured. Apps Script's dispatch is the tax — not Sheets, not Code.gs, not the network. The no-action liveness reply, one line of JS touching no sheet at all:

1.2s ✓   1.2s ✓   8.4s ✓   16.2s ✓   12.3s → 404   58.8s → 404

Fifteen concurrent state reads: five 404s. Split by hop, the seconds are in the /exec 302 itself (1.1–20.7s = dispatch + cold start); the content-host follow is ~0.2s normally. connect was 0.03s throughout and the 4s cache was warm, so nothing local explains it. Execute-as-me means every visitor queues into one Google user's execution stream.

The same fifteen reads against the sheet's own gviz CSV face — the door the pulse already uses, on the visitor's quota:

15/15 succeeded, 0.24s – 0.48s

So the simplification is: stop paying the tax on reads. Writes need OAuth and must stay on /exec, but they're user-initiated, already optimistic, already bannered. Reads are the flaky, frequent half, and the app is *already* reading this sheet directly for one cell. Extending that to the whole database deletes rather than adds: the server-side state cache, quotaChoke on reads, ERROR2152's entire read leg, and the pulse gate itself — the gate exists only to dodge an expensive read, so cheap reads retire it. What it adds is real: getState's derivation (bidders, arcs, editors, claims) moves to the client.

One thing makes that a product decision rather than a refactor, and it's yours to rule on: sealing. Today bid text never leaves the server until reveal (bids: null). Reading the bids tab client-side puts every bid in every visitor's browser — "honor system if you go open the sheet" becomes "the bids are already on your page". Preserving today's sealing would mean the bids tab keeps its own door while everything else moves, which is a seam, not a simplification.

Is that sealing cost acceptable, or does sealing have to survive as-is?

Two things to check before proposing anything: whether that 33% is a burst artifact of my own probing, and whether the beat is quietly forcing every client back onto /exec.

7 of 7 spaced requests succeeded, ~2s each — no 404s at all. That reframes everything: the endpoint is reliable until you burst it. Verifying what makes the app burst.

12/12 spaced, zero failures. And the fake-gas run confirms the mechanism offline. Reading the storage layer to see how small the fix can be.

One more honest check: the app's real burst shape is 5 tabs reacting within one poll period, not 8 at once. Testing that exact pattern.

Correcting my own measurement before anything else: the app's realistic pattern is clean.

Noted — that's a good constraint to pin structurally rather than by discipline. Surveying where platform-specific code actually lives in both runtimes.

There's already a storage fence (Code.gs 300–614), but several platform calls sit outside it. Reading the fence's own contract and the client's sheet knowledge.

The client's coupling is already tight — two adjacent functions. Code.gs has a real fence but it only polices *below* it, and one platform call already slipped past. Strengthening the qual first.

It passed, which means my below-fence check was too narrow — it never included the Apps Script services. Restructuring so both sides police the same vocabulary.

The fence marker lives *inside* a comment, so decommenting erased it and made the check vacuous. Fixing, and verifying both quals actually bite.

Real leak caught. Fixing it with one named owner for the cache.

The roster qual bites — proving it isn't vacuous. Adding the new sibling by name, which is exactly what the roster is for.

Now the client-side counterpart, in the idiom of the existing source-scanning qual.

The qual didn't bite — my comment stripper was eating https:// as a line comment. Fixing and re-verifying both directions.

Dug in. The headline is a correction to my own evidence.

The 33% failure rate was an artifact of my probing, not something users hit. Firing 8 requests in the same instant broke things; nothing realistic does that. Spaced 7s apart: 12/12 clean, 1.9–6.3s. Five staggered 1s apart — the shape N tabs actually make when one pulse change wakes them — three rounds: 15/15 clean, ~1–2s. So the honest baseline is 1–6s per /exec call with a tail to ~20s, and the lever is *fewer calls*, never a cap on each. My earlier message overstated this; the 404 storms it described were largely self-inflicted, and they overlapped your live session.

Withdrawing the gviz-for-everything idea. Your sealing ruling settles it, but it was wrong on its own terms too: it would have put getState's derivation in two runtimes at once. That's a DRY violation dressed as a speedup, and it's the complexity you're warning about.

What digging actually turned up — the beat shouts news at the whole database. pulse.wver is ONE global counter, and mutate bumps it for any write that touched a cell. The editing beat patches devices.blip every 10s, so it bumps. Proven offline against the real Code.gs on fake-gas:

add (real news)      → wver 1
presence beat #1     → wver 2
presence beat #2     → wver 3
presence beat #3     → wver 4

Nothing any page displays changed after the first. But one person with a blub editor open *anywhere* makes every client of *every* auction see "the world moved" six times a minute and spend a full /exec read each time — at 1–6s apiece, on your 60/min meter. That is exactly the saturation the pulse work exists to prevent, reintroduced by presence.

The fix is a deletion, not an addition: the pulse should count changes a page can SEE, and blip is invisible to pages (editors carries usid/dvid/anym). So stamp blip through a write that isn't news, patch blug/blid only when they change — the existing no-op-mutates-nothing law then makes a steady beat free — and have the stop clear blug, so a *departure* stays news. Arrival and departure keep waking the crowd; the heartbeat stops. Roughly ten lines in Code.gs, no new client code.

There's a second, narrower leak I did not touch: the gate's rivalEditors().length === 0 arm skips the pulse entirely while a rival edits, so that auction's clients read every 5s by design. Removing it means letting the client age presence out locally, which needs blip in the payload — a real change, and yours to call separately.

On circumscribing the Sheets code — done, and it found a live leak. There was already a storage fence in Code.gs, but the qual guarding it only checked *below* the fence and only for Sheets *nouns*, so Apps Script's own services roamed free — and CacheService had already reached the archive action where nothing was looking. Now both sides judge the same vocabulary (Sheets nouns plus CacheService/LockService/ContentService/Sheets.Spreadsheets), and above the fence they're legal only inside a named roster: respond, withLock, cachedState, forgetState, mutate. The leak moved behind forgetState — flag that name if you want a different one. The client got the sibling fence: pulseUrl/fetchPulse are cut out by name and the rest of app.js must know nothing, with state.sheet an opaque handle. Both quals were verified to bite, and the client one caught me first — my //-stripper was eating https:// as a comment, silently blinding the exact check I was writing.

Suite is green at 1289. Code.gs changed, so that one is ship lane 2 — push, then npm run deploy.

The question: want the beat's pulse fix as described, or would you rather rule on the pulse's contract first?

Fair — I was holding to the one-at-a-time rule; here's the explanation properly, and then everything else actually awaiting you.

The beat/pulse collision

Three pieces, each fine alone.

The pulse. pulse.wver is a single counter cell. Clients read it through the sheet's public CSV — cheap, ~0.3s, on the visitor's own quota. It answers exactly one question: *has anything changed since my snapshot?* If the number matches, the client skips the expensive /exec read. That's what made steady state cost zero API reads.

The bump. Any write bumps wver inside the lock. "Any write" means the execution touched a cell — a semantic no-op touches nothing and doesn't bump. That part is careful and correct.

The beat. A page with the description editor open pings editing every 10s so other people's pencils scribble. That ping writes devices.blip = now, proving the tab is still alive.

The collision: the beat is a write, so it bumps — and wver is one counter for the whole database, not per auction.

What it costs

Say schelling is open in one tab, and you open the description editor on foo in another.

• The foo editor beats at 0s, 10s, 20s… each bumps wver.
• The schelling tab polls every 5s, reads the pulse, sees a new number, concludes "the world moved," and spends a full /exec state read — 1–6s, on your owner quota.
• schelling didn't change. Nobody bid, nobody joined. The number moved because a *different auction's* editor said "still here."

Six bumps a minute, one /exec read per bump per open tab anywhere. Five tabs is 30 reads/min against the 60/min meter — the exact saturation the pulse was built to eliminate, switching on the moment anyone opens a description.

Why it's a bug, not a trade

The pulse is supposed to mean "something you'd display changed." Ask what a beat changes in what a client can *see*: nothing. The editors entries carry usid, dvid, anym. blip is never sent — it exists only so the server can judge freshness at read time. So re-stamping it changes zero bytes of anyone's picture while announcing to everyone that their picture is stale. The pulse tells the truth about the sheet and a lie about the world.

The fix

Split the beat's write by what it means:

| field | meaning | news? |
|---|---|---|
| blug, blid | *which* auction, *as whom* — the part editors shows | yes |
| blip | "still here", server-side only | no |