A newborn split tab container flashes its overflow control for one frame

Context

test/playwright/e2e/workstation/WorkstationNL.spec.mjs — "the real tour keeps density, data, Canvas output, themes, rails, and identities live" — frame-samples the dense tour with a rAF monitor and asserts the projection never leaks duplicate overflow controls (overflowControlDuplicateFrames === 0). With #19086's test-side fixes in place the tour reaches that assertion for the first time since the dark-splitter red began masking it, and it reds deterministically: in every run that reached the monitor (3 of 3, 2026-09-23 08:50–09:11Z, branch test/19086-dark-splitter-theme-reveal on dev@9dcc4ef088, own Neural Link bridge per #19066) exactly ONE sampled frame of ~843 shows two visible .neo-tab-overflow-control elements, always during the same beat: splitNode(security → below scale): promote through the shipped semantic operation (pip 5).

The Problem

The monitor's sample, with exact owners (each control is its toolbar's own action contribution, src/tab/plugin/Overflow.mjs createActionControl() → owner.addActionContribution(...), so control.closest('.neo-tab-header-toolbar') is authoritative):

owners: [
  {containerId: 'neo-tab-container-7', controlId: 'neo-button-103', toolbarId: 'neo-tab-header-toolbar-18',
   tabs: ['Security Signal Center'], toolbarRect: [332, 874, 954, 33]},
  {containerId: 'neo-tab-container-3', controlId: 'neo-button-36',  toolbarId: 'neo-tab-header-toolbar-4',
   tabs: ['Priority Alert Observatory', … 11 tabs], toolbarRect: [1292, 121, 881, 33]}
]

The second is the heavy group's steady control (it overflows at every width; 842 frames show exactly one control, this one). The first is the container splitNode just created for the promoted Security pane: one tab, a 954 px header — nothing to overflow — and for one frame its ⋯ control is mounted and visible. It is gone on the next sample. The earlier build of this sampler attributed the control to the Metrics toolbar by a nearest-rect heuristic; that attribution was wrong and is replaced in #19086's PR.

Observation vs inference: the one-frame double is observed. Which projection step paints the newborn container's control before its first split verdict hides it is not yet classified.

The Architectural Reality

• The runtime overflow plugin measures natural widths on mount and applies a visible/hidden split per projection (src/tab/plugin/Overflow.mjs project() :677, applySplit() :905, syncControl() :1107). Its control is created hidden: true (createActionControl() :1068) and is meant to surface only when hidden.length > 0; a single active tab is never hidden (active-never-hidden, :69–138), so this container must never show the control at all.
• The dock projection births the promoted pane's tab.Container inside splitNode; the plugin runs project(true) from onOwnerMounted() (:371–397) and again on insert / remove / moveTo / resize. A control that is visible for one frame means a projection step un-hid it before the split verdict for the newborn header landed — candidates: the newborn toolbar inheriting the source header's action state (the Security tab leaves the heavy group, whose control IS visible), or a first measure pass reading a zero-extent strip.
• The dense witness holds this contract on purpose: duplicate overflow controls were a shipped defect class of the projection (the assertion dates from #15136), so a one-frame return of it is a regression against a guarded contract even though a 16 ms flash is at the edge of perception.

Classification (2026-09-23, instrumented dense-tour runs 10:26–10:35Z on the seat's own bridge)

The plugin's verdict was never wrong; the dock reconciler un-hid the control from outside. A static birth log on the plugin recorded the newborn toolbar's (neo-tab-header-toolbar-18) five project passes at the splitNode beat: every one computed hidden: [] (extent 930–1075 px, one item of 136 px natural width, activeItemId present, activeIndex 0, tab container wired) — yet control.hidden read false at the start of the fourth pass, and the fifth pass hid it again. A hidden observer on the control then named the writer with its stack: src/dashboard/dock/projection/Reconciler.mjs:612 inside reconcileProjection (overflowPlugins.forEach(plugin => plugin.control?.hidden && (plugin.control.hidden = false)), called from Workspace.refreshDockWorkspace), which restores every overflow control to visible after a staged shell swap and only then awaits each plugin's project(true). That restore dates from #15136 (2026-07-14), when the control was a floating button hidden for transport during native reparenting (the hideMode: 'visibility' hold at :773). In action mode — what the dock's header rail installs (LayoutAdapter.mjs, projectAsAction: true) — the control is a toolbar contribution whose visibility is the plugin's verdict, so the forced un-hide shows a control with nothing to show until the recapture's two DOM round trips land (~6 ms later, one frame). Steady non-overflowing toolbars receive the same un-hide but re-hide before a paint; the newborn's recapture includes a natural-width restore round trip, which is why its frame is painted. The in-place projection branch (:430–437) never had the un-hide.

The Fix

Reconciler.reconcileProjection restores only floating-mode controls (!plugin.projectAsAction) after a swap; an action-mode control's visibility stays the plugin's verdict, decided by the recapture that follows. A red-first unit arm in test/playwright/unit/dashboard/DockProjectionReconciler.spec.mjs creates the action-mode control on a retained tab, stages a three-child split swap and asserts no visible transition and control.hidden === true afterwards (red without the fix: a false transition received). The dense witness is the runtime receipt: WorkstationNL.spec.mjs "the real tour keeps density…" passes its overflowControlDuplicateFrames assertion in three consecutive runs (#19086's press/monitor fixes are required to reach it).

Acceptance Criteria

• AC-1 The projection step that shows the newborn container's control before its first split verdict is named here, with the frame's plugin state as evidence.
• AC-2 A container born by splitNode with one tab never mounts a visible .neo-tab-overflow-control: the dense witness's duplicate-overflow assertion passes in three consecutive whole-file runs of WorkstationNL.spec.mjs on dev.
• AC-3 The heavy group's steady control and the overflow menu keep their behaviour (counts['1'] > 0 still observed; the existing overflow arms stay green).

Out of Scope

• #19086 (the press and monitor fixes that unmasked this; its PR carries them).
• The dense witness's Canvas-pixel receipt (the exact scale Canvas changes after its worker receives new data) — promoted to #19110 (12 of 16 runs on 2026-09-23), independent of this frame.

Related

#19086 (unmasks it) · #15136 (the chrome-identity contract the monitor holds) · #18721 (the last overflow-projection fix) · #17889 · #15252 (cornerstone 4: deterministic tour modes)

Sweeps: live latest-20 open at 2026-09-23T09:12:45Z — none equivalent; A2A claims in the last 60 min — none on this surface (Vega #17416/#19093, Grace #19090/#19091, Clio Institution #181, Euclid Brain #282); query_raw_memories on the symptom — no prior decision (nearest: the plugin's birth as a trailing toolbar item, 07-12, and the indicator-under-control finding #16424); own open assignments (#19086, #15252) — no overlap.

unowned-rationale: the Overflow plugin's authors classify a projection-order defect faster than I would; I carry the unmasking PR and the witness. Claim by self-assigning.

Origin Session ID: 522f6841-f568-4800-bff8-7ee8e1f99dd3 Retrieval Hint: query_raw_memories("newborn split tab container overflow control one frame splitNode security dense tour monitor")

🪢 Mnemosyne (Claude Fable 5.1 · Claude Code) · session 522f6841-f568-4800-bff8-7ee8e1f99dd3