ZION-20 — business workspace polish (one inbox card, polish items 5-7)

Updated just now.

2026-09-06 — The new inbox card is live on hub.heroesandsidekicks.io and independently checked in a fresh browser signed in as Dean: every item now shows where it came from, one plain sentence saying what it needs, its title, a two-line preview with a Read more control, and its buttons, with the old Open link gone from all 31 cards. Measured against the approved design drawing of the inbox, every card-level property matches; the remaining differences are on the page layout around the cards (the grid, the filter row, the band headings and the loading placeholders), which are being rebuilt now. One small leftover goes to the next step: after opening an item and going back, keyboard focus lands on the page instead of the card you came from, though the scroll position still returns. Nothing needs Nick.

2026-09-06 — The five older build checks that used to pin the old inbox controls now accept either the old control or the new card, so the rebuild can land without breaking the build: all five pass on today's code, each still fails when its target is deliberately broken, and six numbered deviation rows record what changes on the inbox and why. One out-of-date comment in the inbox code could not be corrected here because this step was only permitted to edit specific lines, so it is corrected in the next step. That next step has started: the card itself is being written in the live app, so every inbox item will show a source tag, one sentence saying what it needs, and its buttons. Nothing needs Nick.

2026-09-06 — The automated comparison that will measure the rebuilt inbox on hub.heroesandsidekicks.io against the locked design drawing is now proven: compared with itself it reports zero differences on all ten screen-size and colour-scheme pairs, twice; with the drawing deliberately broken it flags every one of the 18 measured properties; and it refuses to call a screen finished when an inbox band shows fewer than three cards. It also never records a sign-in secret. It runs after every publish of the site. With this comparison and the nine build tests that must fail on today's inbox until the new card exists both proven, the inbox card rebuild itself can start once the five older build checks that still pin the old inbox controls are re-pointed, which a builder is doing now. Nothing needs Nick.

2026-09-06 — The nine tripwire tests for the new inbox card on hub.heroesandsidekicks.io are in place and proven: each one fails on today's inbox for the reason the design gives, each turns green only when the real behaviour changes, and none can be fooled by a code comment. They run automatically every time hub.heroesandsidekicks.io is published, in a waiting mode that reports but does not block, so publishing continues until the card is actually rebuilt. Also done tonight: the generated page that draws every inbox state (the target the rebuilt inbox is measured against) reached revision two; the table pairing its 36 drawn parts with the live inbox's HTML was verified; and the automated comparison tool that measures the live inbox against that page was built and proven able to fail. That tool's independent check is running now. Next: re-point the five older build checks that still pin the old inbox controls so they measure the new card instead, then rebuild the card itself in the live app. Nothing needs Nick.

2026-09-06 — The table that pairs every one of the 36 drawn parts of the new inbox card with the matching piece of the live inbox's HTML is now signed by the design lead and confirmed by a second agent that had never seen it: every part in the drawing has a row, every row points at something real in the drawing, and only two deliberate exceptions are listed, each with its reason. That table is what the automated comparison will use to measure the rebuilt inbox against the drawing. Next in progress: the nine tests that must fail on today's inbox before the card is rebuilt (STEP 4) are being written, and the automated comparison itself (STEP 3) starts once those land. Nothing needs Nick.

2026-09-06 — The design target for the new inbox card is locked: one generated page drawing every inbox state at five screen widths in both the light and dark looks, so the rebuilt inbox can be measured against it instead of eyeballed. Its sha256 checksum was recorded by machine, and a second agent that had never seen the work regenerated the page from scratch and got the same checksum. A second revision fixing four small drawing details is being built in parallel and will be recorded the same way when it lands. Next in progress: an independent agent is confirming that the table pairing each drawn element with the live inbox's matching HTML class (STEP 2) is complete, and the nine tests that must fail on today's inbox before the card is rebuilt (STEP 4) are being written. Nothing needs Nick.

37% overall0 of 16 steps finished
  1. Lock the design target: generator, rendered file, coverage table, hash99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: output file committed in the business workspace project copy with REV in the generator header; machine-written hash in the relevant record §TARGET; coverage table has 16 rows U1–U16; the address result recorded

    Proof: the relevant item then the relevant item on its output

    Verified: 2026-09-06 (100%, a Sonnet checker in a fresh session re-ran the generator in a scratch folder and got the same hash 98d4a2a5 as the state note, HEAD and the working tree; counted 16 coverage rows; four verdicts PASS in the relevant record; the published address returned 404 so the checker loads the committed file by path, the recorded fallback)

  2. Anchor map and the viewport/theme list, signed by Sienna99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: map committed with its machine-written hash in the relevant record; at most two GAP rows, each with a reason; the signed viewport/theme line present

    Proof: the relevant item

    Verified: 2026-09-06 (100%, a Sonnet verifier in a fresh session: a DOM walk of one populated 1280 light cell resolved 34 of the 36 map rows directly and the other two by grep on the CSS and the 375 markup; all 36 target selectors matched a node or a CSS rule; the map re-hashed twice to 2d1922df matching the state note; business workspace commit 733ce596 is the tip of origin/main; exactly two GAP rows with reasons and the signed viewport line present; four verdicts PASS in the relevant record)

  3. The fidelity check: selftest, sabotage, colour sweep, fence check, rested mode99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: selftest reports 0 · 0; sabotage red on every property; registered TIER-2

    Proof: the relevant item

    Verified: 2026-09-06 (100%, Opus verifier, two rounds: round one A to D PASS and E FAIL because the three-cards-per-band floor was computed but never enforced; the builder's fix at business workspace 985939eb wires the floor into the measurement (rows 1 to 18 and 35 become not measurable, exit 2) and strips the response body from the sign-in error path; round two E1 to E4 PASS in the relevant record from the checker's own runs: floor selftest 20 of 20 card anchors not measurable, selftest 0 and 0 on ten pairs, TIER-2 count 16 to 17, no log path carries the cookie or bearer; two tool bugs found and fixed on the way: a bare sabotage run fell through to the live path, and one sabotage value was silently rejected by Chromium so one property never went red)

  4. Red-first stub checks a–i for the card, words, grid, filter, states, actions, leaving, FYI default99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: checks a–i RED on HEAD for the design's reasons; registered TIER-1 in app/gates.js

    Proof: the relevant item

    Verified: 2026-09-06 (100%, Opus verifier, two rounds: round one PASS on A to E and FAIL on its own criterion F because the nine checks were not the plan's nine and the loading check could be greened by a code comment; the builder's fix at business workspace 817263cc re-keyed all nine to the plan's own letters, added the missing FYI-open-by-default check, grew the fixture table to 24 cases and asserted the POST-before-fade order; round two F1 to F5 PASS in the relevant record, with the nine red on a pristine export of origin/main, a one-line real behaviour change turning exactly one check green, the comment and dead-string fabrications leaving all nine red, TIER-1 count 63 to 64, --pending exit 0)

  5. Re-point the five pinned checks; DEVIATIONS rows; correct the relevant record's stale note99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: all five re-pointed harnesses green on HEAD and each red on its sabotage; DEVIATIONS rows written or handed to Nick

    Proof: the relevant item

    Verified: 2026-09-06 (100%, Opus verifier in the relevant record: A to E PASS on business workspace 356d0cdb — fence respected, four harnesses green from the checker's own runs including the Chrome one at 1142 pass, the checker's own sabotage red, every OR pairs two exact selectors with one sanctioned loosening recorded (nothing pins the FYI accordion's existence any more), DEVIATIONS rows 268 to 273 appended with the numbering method reproduced; F FAIL is a contradiction inside the plan itself — its PROOF line asked for a stale-citation count of zero at the relevant record line 2098, a spot its own file fence forbade; overseer's ruling: that comment fix is folded into STEP 6, which edits the relevant record anyway, and this step closes)

  6. The card component plus tagText and needText in the relevant record and the card CSS99%

    ⚠️ claimed done with only 1 of the required 2 independent verifications — shown as in progress, not done

    How we know

    Definition of done: checks a–c GREEN, d–i still RED; live counts recorded

    Proof: the relevant item

    Verified: 2026-09-06 (100%, Sonnet verifier in the relevant record: B to E PASS from its own runs and its own live session as dean — checks a to c green and d to i red, four guards green, live build revision 6198eb12, 31 cards each with a title anchor and zero old open links, four cards' tag and needs-you text verbatim against the design, padding radius accent width and title clamp matching anchor rows 1 2 and 9, the only live mismatches on page-level rows 22 23 25 26 which STEPS 7 and 8 own; A FAIL was the builder re-pointing one line of harness-larryinbox as the sixth old-control pin, which the step's own If-it-fails clause orders in exactly that shape citing DEVIATIONS row 268 — overseer's ruling: sanctioned, step closes; one handoff to STEP 7: the return-focus selector at the relevant record 1983 still names the removed open link, so focus lands on the body after going back while scroll still restores)

  7. The page: one grid per band, filter row, band folds without fills, FYI open, group folds gone0%
    How we know

    Definition of done: checks d–f GREEN; live counts recorded

    Proof: the relevant item

  8. The actions row order, the leaving motion, the skeleton, the deal ease token0%
    How we know

    Definition of done: checks g–i GREEN; inbox guards PASS; live counts recorded

    Proof: the relevant item

  9. The screen's publish: fidelity 0 · 0 on ten pairs, side-by-sides, Sienna's round, checker reproduction0%
    How we know

    Definition of done: 0 · 0 on ten viewport-theme pairs on the checker's own run; Sienna PASS

    Proof: the relevant item

  10. Feed-side label fixes at source, three strings0%
    How we know

    Definition of done: the three labels read as the design's examples on the live feed; harness green

    Proof: the relevant item

  11. Polish 5: the open-items number counts up, the ticks fill0%
    How we know

    Definition of done: rested diff 0; count-up seen live; 0ms under reduced motion

    Proof: the relevant item

  12. Polish 6: screen title and department headings wipe in0%
    How we know

    Definition of done: rested diff 0; wipe seen live once per arrival

    Proof: the relevant item

  13. Polish 7: the check stroke and the row fade on tick0%
    How we know

    Definition of done: rested diff 0; stroke and fade seen live; undo intact

    Proof: the relevant item

  14. Sienna's design-QA round on the polish screens, fresh live captures0%
    How we know

    Definition of done: receipt PASS or one named fix per item

    Proof: the relevant item

  15. Live walkthrough as all six identities: inbox, tasks, nav0%
    How we know

    Definition of done: every action round-trips; no horizontal scroll at 375; evidence saved

    Proof: the relevant item

  16. Blind finish-line sweep, postmortem, close0%
    How we know

    Definition of done: all seven FINISH LINE items graded; §6a written; registry appended

    Proof: the relevant item