Issues view + sync rendering: render #242's sync states on Issues, Inbox, Work, counts and Molecule view (after #262) #266

Issues view and sync rendering (UI half of #242, split 2026-10-27)

#242 builds the read-only GitHub sync engine and its API. This slice renders it on every surface. It runs after the module split (#262) and owns web/js/issues.js, plus the sync-related parts of inbox.js, work.js and molecule.js.

Read #242 for the full contract, especially the "every state" matrix (rows 1–17), the precedence rules and the startable rule. This slice must render exactly what syncState returns, with no state logic of its own in JS.

• Issues view: every open Issue with its state pill and "GitHub state from ".
  • One primary per row: Start intake only when startable, otherwise Open Molecule.
  • Filters: All · Not started · In progress · Needs you · Draft PR · Merged; label, milestone and text search, all kept in the URL.
  • "Run the loop on these" fills the loop selector with the current label or milestone filter.
  • Truncation is shown ("showing 500 of N"), and so are stale-snapshot and not-checked states.
• Work grid and Inbox: live work first. Merged and history collapse into one row ("38 merged · show", ?history=1). Row 14 ("Issue was closed while in progress") appears in Needs you.
• Counts header: the same split everywhere, for example "3 running · 0 need you · 38 merged".
• Molecule view:
  • the live Issue state ("Cohort: run attempts in parallel with --parallel N (default 1, deterministic report) #174 · closed 2026-10-18"), or "OPEN at intake (date)" when not checked;
  • "Merged · · · production unverified";
  • PR CI and review state, plus the "changed on GitHub after Forgecell published" note;
  • a merged Molecule shows gate and ship resolved, with "Nothing to do · merged on GitHub".
• Refresh: a Refresh button, with a single-flight indicator while fetching.

Done when

• Tests: one fixture renders the Issues view, Inbox, Work grid, counts and Molecule view. Every surface agrees for every matrix row; history collapses by default and the toggle is in the URL. Start intake is refused when the Issue closed meanwhile; there's no raw gh text and no innerHTML.
• Visual check: the operator checks against docs/design/ui/redesign-2026-10-26/Issues.html.
• Targeted checks: go test ./internal/ui/....

UX rules for every redesign slice (from the 2026-10-26 UI review)

• Follow the approved mockup in docs/design/ui/redesign-2026-10-26/ (its README lists the tokens and rules), with the assets in lab/internal/ui/web/assets/. Reuse the .btn primary, secondary and danger system and the glass panel from UI polish: composed Start Work controls, segmented lane bar, sharper glass (visual only) #241.
• One primary action per card or row. Destructive actions (Retire, Stop Molecule, Stop loop) sit behind a disclosure and a confirmation that names the Molecule or loop. Never place them next to a primary action.
• State in the URL: view, selected Molecule, filter and search (for example ?view=inbox, ?m=<id>, ?filter=…&q=…) via history.pushState, so Back, reload and copied links work. Navigation uses real <a href>.
• Forms: real <form>s, so Enter submits. Inputs carry name, autocomplete="off" and an example placeholder ending in "…". A submit button stays enabled until the request starts, then shows progress. Errors appear inline, linked with aria-describedby, and focus moves to them.
• No rebuild under the user: polling patches the DOM in place, keyed by id. Never rebuild a block that has focus or an input being typed in. Keep one persistent aria-live region and update its text only when it changes.
• Readable values:
  • dates via Intl.DateTimeFormat plus relative time;
  • money via Intl.NumberFormat (one precision rule; small amounts never round to $0);
  • counts via Intl.PluralRules;
  • tabular-nums for numbers;
  • never raw phase codes, assay-… or mol-… ids, full digests or ISO timestamps in the main UI (short forms only, behind "details" with a copy button).
• Plain language, second person, Title Case buttons: "Plan ready for your approval", "Coding · 18 min", "Ready to publish". Keep the primitives true: Lab, Molecule, Atom and Formula keep their names and meanings.
• Accessibility and touch:
  • a skip link;
  • one <main>;
  • ordered headings;
  • visible :focus-visible everywhere;
  • targets at least 44 px on coarse pointers;
  • touch-action: manipulation;
  • reduced motion and forced colors honoured;
  • no horizontal page scroll at 400 px.

Review checklist (read before coding)

The adversarial review checks these every time. Recent slices failed review on all of them, so build them in from the start:

• Bounds: sizes, counts, time and total work are bounded, and hitting a bound fails safe (incomplete or truncated, never silently accepted).
• Filesystem safety: paths cannot traverse. Use Lstat and O_NOFOLLOW, and check symlinks and ownership. Watch for TOCTOU races on shared dirs (/tmp). Only ever delete Forgecell-owned, marked paths.
• Untrusted input: issue text, repository files, model and tool output, and ledgers can be malformed, huge or hostile. Validate them, never interpolate them into HTML or a shell, and never let them trigger retries or approvals.
• No local leaks: no absolute local paths, environment variables or credentials in output, logs, the UI or ledgers.
• Contract changes: a changed adapter invocation bumps the protocol, and approved digests still bind exactly what was shown.
• Tests: deterministic. Use no wall-clock budgets (use readiness markers or seams), write nothing into the user's real temp or home, and cover the failure path as well as the happy path.

Plan checks (for intake)

Check category must be one of regression, candidate or setup. Use targeted package tests only as plain go test commands (for example go test ./internal/<pkg>/...); the protected view adds -json itself when protected deltas are declared. The Formula baseline already runs the full suite once, so don't add another full go test ./... check, and don't repeat its go vet or gofmt checks. A plan may hold at most 16 checks in total, counting the 5 Formula baseline checks, so prefer one combined targeted command over one check per package.

• Keep base tests compiling (added 2026-10-27): the protected view runs the base _test.go files against your code. Never change the signature of an existing Go function, method or type that a base test file calls. Add a new one instead. A protected build failure cannot be declared as an expected delta.
• After UI foundation: split app.js/style.css into per-view modules (no behaviour change) so v1 UI slices run in parallel #262: this slice owns its own web/js/<view>.js module(s) and web/css/<view>.css. Don't edit other views' modules; shared helpers go in core*.js.

Plan checks for this slice (2026-10-27)

• The operator's visual or browser check is a manual step after delivery, not a plan check. Don't add a check for it.
• Every plan check: category: regression or candidate, with reviewedAcceptance and independentProvenance left empty. The analysis must never assert independent acceptance.
• Use one combined targeted go test check for the packages this slice changes.