Beagle SCM

WORK-014: work view post-click repaint is stale — the +1 post lands, the repaint shows the OLD counts

Reported by gritzko 2026-07-19, live: //ABC-021 tracks ///jab/dog/abc/ (dir-form, .be row get ///jab/dog/abc/#3e047885) and renders UNDER the abc mount; it was ahead 1. Clicking [+1] posted the commit (post ?#8339157e, 23:03) — the wt's +1 vanished but the abc mount row showed NO +1 in the repaint. A FRESH jab work (orchestrator, 23:0x) renders it RIGHT: abc mount +1 23:03 #8339157e, //ABC-021 under it counter-less. The data model is correct; the pager's post-mutation repaint serves stale state.

Input

Context

• Fresh-render truth (verified): the post wrote through to the tracked worktree's log — nodeTip(abc) (wtlog curTip, work.js:213) = 8339157e; mount ahbeh = tip vs parent's de-jure pin (:662-664) → +1; the dir-form tracker leg compares wt.sha vs nodeTip(mount) → in sync, no counter. All correct when computed cold.
• The incident is therefore in the CLICK → repaint path: after an O mutation (+1 bare post in //ABC-021's context) the pager repainted counts that neither showed abc's new +1 nor matched the fresh render.
• Suspects, in order: (a) the view is not RE-DRIVEN after a mutation O click — old hunks repaint; (b) it re-drives but registry() memos (keepers/ancs/metas/grafs Maps, work.js:101-150) or graf idx state are captured per pager process and serve pre-post data; (c) wtlog/keeper reads cached below (shared/wtlog.js, store open) in the long-lived pager process.
• Related ground: WORK-002 (mutation clicks run in the row's context, landed), WORK-004 (+N/-N mint bare post/get), WORK-004's post-click behavior; BRO-035 (streaming bro / resident producer) may own the long-term repaint story — this ticket wants the minimal correct-now fix.

Goals

• After a [+N]/[-N] mutation click succeeds, the repainted work view equals a fresh jab work of the new state: the poster wt's counter clears AND the tracked mount's counter appears in the SAME repaint.
• Establish which suspect (a)/(b)/(c) it is and record it in Design decisions before fixing; fix at that one seam.
• Red-first pty repro: fixture mount + tracker ahead 1 → click [+1] → assert the repaint shows the mount's +1 and the wt's cleared counter (today: stale, pinned red).

Constraints

• Rulings in force: verify through the real UI path (pty), context only changes by navigation, no VC ops by the worker (the pty fixture may post inside its OWN sandbox trees only).
• Counts keep flowing through the WORK-011 graf-backed registry; if the fix is "rebuild the registry per drive", show the pty flip proves it and graf/parity stays green.
• Do not touch the WORK-013 mint-side lines (nav/navLink :646/:666, wtSpans :530/:544) — a sibling worker owns them; coordinate, expect weaves.
• Overlaps none of the landed WORK-012 logic (WHICH shas compare) — this is WHEN they are recomputed.

WIP

Design decisions

• Could NOT reproduce the stale repaint on WORK tip #b4ec4c47 with the working jab (~/bin/jab, jsrc-scan). The re-drive path is correct — see Blockers for the seam analysis.

TODOs

• red pty fixture built (scratchpad): mount sub pinned at C0, tracker //SUB-1 dir-form ahead 1; click +1 -> post writes through to sub/.be/wtlog. Comes up GREEN, not red: the repaint shows sub +1 and //SUB-1 cleared, == fresh render, deterministic over 3 runs.
• seam analysis: (a) DISPROVEN — the O mutation click IS re-driven: mouse -> actSpell (post in verbs/ => mutation) -> _refresh -> driveSpell("work") re-runs emitForest fresh. (b) DISPROVEN — registry() is fresh per drive; no module-level caches in store/graf/idxmaint/wtlog. (c) DISPROVEN — store.open/wtlog.open re-read disk each drive; the posted commit PRE-EXISTS in the shard keeper (a tracker can only be "ahead" of a commit already walkable in its shard), so no keeper/graf staleness can blank the mount.
• fix — NONE APPLIED: no defect reproduced to fix.

Blockers and bummers

• The "jab is ASAN" binary (beagle/build/bin/jab) is STALE: pre-jsrc-rename (scans be/), renders a broken forest (missing rows, wrong sha) — not a valid test binary. The only working binary is ~/bin/jab (jsrc-scan; view/pinahbeh/graf all pass).
• Need from orchestrator/gritzko: the EXACT jab binary + rev the incident used, or a reproducing state. The stale repaint may be a native artifact of the stale ASAN build, or already fixed at WORK tip. No JS fix invented for a non-repro.

Outcome

• No code change. Worktree left clean (jab diff empty).
• Investigation only; awaiting a reproducing case.