The Problem
A change-guarded, legitimate config write on a header-action button (one set(), one update) issued while the dock projection/reconcile train is still applying can duplicate retained tab-bar chrome: the bar renders a doubled tab button and a doubled action set with IDENTICAL element ids (one subtree applied twice). Reproduced only on slow rigs (GitHub CI), never locally — timing-gated.
Evidence
PR #17974's CI history: three consecutive red runs with the strict-mode signature resolved to 2 elements (identical ids) and a page snapshot showing Alpha, Beta, Beta in one strip. Every intermediate mitigation (write batching, deferral, fixture isolation) only moved which arm failed; the PR went green once bar writes were serialized onto the refresh's settled tail (4dd6b0edf5).
That serialization is insufficient, measured 2026-08-31 22:10Z. It merged and is on dev (refreshPromise chaining at src/dashboard/dock/Workspace.mjs:1018, :1038, :1532), and dev is RED at fa20136f29 with the identical signature — run 33440382357, DockReload.spec.mjs:181. A second capture on PR #17987 (33444096674) hit :250 instead. Both arms are activation-followed-by-write, so the reachable set is that shape rather than one test, and every branch cut from dev inherits the red at a rotating arm number.
One residual unserialized write path is already identified: Workspace.mjs:1387's mount-time sweep is time-based (timeout(100)) with a !refreshPromise guard sampled 100ms before the write lands, so a refresh starting inside that window is invisible to it. Not yet shown to be the path either capture took — both fail well after mount — but it is an unserialized bar write that survived the serialization above.
The Fix (to investigate)
The update-collision handling between a child component's vdom round trip and a parent-level reconcile application should either queue or merge — never double-apply. Consumers can serialize (the settled-tail idiom now in Workspace), but the engine hazard remains for any toolbar/tab consumer writing during projection.
Acceptance Criteria
Related
Parent: #13158 (surfaced by the dock family). Consumer-side mitigation shipped in PR #17974.
Origin Session ID: 914dffcd-0057-46a5-a0c6-9ca807fd5c91
Retrieval Hint: "tab bar duplicate chrome vdom update collision reconcile double apply"
— Vega (Fable 5, Claude Code) 🌿
The Problem
A change-guarded, legitimate config write on a header-action button (one
set(), one update) issued while the dock projection/reconcile train is still applying can duplicate retained tab-bar chrome: the bar renders a doubled tab button and a doubled action set with IDENTICAL element ids (one subtree applied twice). Reproduced only on slow rigs (GitHub CI), never locally — timing-gated.Evidence
PR #17974's CI history: three consecutive red runs with the strict-mode signature
resolved to 2 elements(identical ids) and a page snapshot showingAlpha, Beta, Betain one strip. Every intermediate mitigation (write batching, deferral, fixture isolation) only moved which arm failed; the PR went green once bar writes were serialized onto the refresh's settled tail (4dd6b0edf5).That serialization is insufficient, measured 2026-08-31 22:10Z. It merged and is on
dev(refreshPromisechaining atsrc/dashboard/dock/Workspace.mjs:1018,:1038,:1532), anddevis RED atfa20136f29with the identical signature — run33440382357,DockReload.spec.mjs:181. A second capture on PR #17987 (33444096674) hit:250instead. Both arms are activation-followed-by-write, so the reachable set is that shape rather than one test, and every branch cut fromdevinherits the red at a rotating arm number.One residual unserialized write path is already identified:
Workspace.mjs:1387's mount-time sweep is time-based (timeout(100)) with a!refreshPromiseguard sampled 100ms before the write lands, so a refresh starting inside that window is invisible to it. Not yet shown to be the path either capture took — both fail well after mount — but it is an unserialized bar write that survived the serialization above.The Fix (to investigate)
The update-collision handling between a child component's vdom round trip and a parent-level reconcile application should either queue or merge — never double-apply. Consumers can serialize (the settled-tail idiom now in
Workspace), but the engine hazard remains for any toolbar/tab consumer writing during projection.Acceptance Criteria
Related
Parent: #13158 (surfaced by the dock family). Consumer-side mitigation shipped in PR #17974.
Origin Session ID: 914dffcd-0057-46a5-a0c6-9ca807fd5c91
Retrieval Hint: "tab bar duplicate chrome vdom update collision reconcile double apply"
— Vega (Fable 5, Claude Code) 🌿