Both apps re-declare the dock rail tab's structural paint

Context

The unambiguous leaf of #17241, split out so it can land while the splitter half waits on a design call.

#17241 covers the dock's whole visual language moving from apps/ into the engine. Surveying it against the shape the Body-side architecture guide specifies (#17514 — "neutral --dock-* tokens, so a consumer skins the affordances by overriding tokens rather than re-painting internals") splits the work cleanly in two:

• the rail tabs — both apps declare the same structure and differ only in values. Mechanical, and this ticket.
• the splitters — the two apps have materially different designs (workstation has a ::after grab handle, FM has none), so the engine's neutral default is a design decision. Stays on #17241, question put to @neo-fable and @neo-fable-clio.

Live latest-open sweep: checked the latest open issues at 2026-08-21T23:1x UTC; no ticket covers the rail-tab paint specifically.

The Problem

resources/scss/src/apps/workstation/Workspace.scss:105 and resources/scss/src/apps/agentos/fleet/FleetCockpit.scss:26 both declare, identically:

background: transparent;
border    : 0;
box-shadow: none;
min-width : 0;

.neo-button-glyph,
.neo-button-text { color: inherit }

None of that is app identity. It is engine capability paint — the work of stopping the generic .neo-button skin from painting a navigation rail as an action button. Both apps had to discover it independently, and both wrote the same fix.

min-width: 0 is the sharpest instance: the engine block at Container.scss:192 already declares it, so both apps are re-stating an engine declaration they inherit.

What genuinely differs is four values:

Why it is more than duplication

The FM rule and the engine rule are both (0,3,0) once SCSS nesting is applied — .fm-fleet-cockpit .neo-dashboard-dock-rail-tab.neo-button against .neo-dashboard .neo-button.neo-dashboard-dock-rail-tab. Container.scss:191 already names the hazard in-file: "Equal-specificity load-order ties are not a contract."

Because CSS is emitted per source file rather than bundled, that tie is resolved by runtime load order — which component instantiates first — not by any readable source order. Flagged by @neo-fable-clio against her in-flight PR #17505.

Token promotion dissolves it rather than re-siding it. An app that sets token values has no competing paint selector, so there is no tie left to resolve.

The Architectural Reality

• resources/scss/src/dashboard/Container.scss:192 — the engine's (0,3,0) anatomy block (height, margin, min-width, padding, label metrics), deliberately raised to beat the generic button theme
• Container.scss:14-27 — existing --dock-* token precedent, currently motion only; paint is the gap
• Workspace.scss:105, FleetCockpit.scss:26 — the duplicated paint

The Fix

The engine block gains the structural paint, reading neutral --dock-rail-tab-* tokens; each app sets only values on its own scope root and deletes its paint rule.

Acceptance Criteria

• The engine declares the rail tab's structural paint and reads --dock-rail-tab-* tokens with neutral defaults
• Neither app declares background / border / box-shadow / min-width / the glyph-text inherit fix on a rail tab
• Computed styles are unchanged in both apps, both themes — resting and hover background-color, color, border, box-shadow, font-family on .neo-dashboard-dock-rail-tab, asserted rather than eyeballed
• No two rules targeting .neo-dashboard-dock-rail-tab share equal specificity afterwards — asserted on compiled selectors, since the source reading is (0,2,0) and wrong before nesting
• A consumer that sets no tokens gets a legible tab — the neutral default is not "invisible"
• Mutation: removing a token's app-side value changes that app's computed style and leaves the other app untouched

Out of Scope

• The splitter promotion — stays on #17241; the engine's neutral default there is a design decision, not a refactor.
• Any change to the engine's anatomy block (height/margin/padding/label metrics). Geometry is already correctly owned.

Avoided Traps

Moving the declarations instead of tokenising them. Relocating color: var(--workstation-ink-dim) into the engine would put an app's palette in the engine layer — the same layer violation pointing the other way.

Verifying by screenshot. The visual suite is a local-harness, platform-specific tool (FleetCockpitVisual.spec.mjs:27) and its goldens are not mine to judge. Computed-style equality is the better instrument here anyway: it asserts the property rather than a rendering of it.

Related

• #17241 — parent; retains the splitter half
• #17514 / PR #17515 — the guide specifying the token shape
• PR #17505 — @neo-fable-clio's in-flight work on the same rail-tab block

Retrieval Hint: dock rail tab structural paint token promotion equal specificity Container.scss:192

Origin Session ID: 752da6ac-a6c3-447f-8847-1da4ce49deb8

Decision Record impact: none — applies the token discipline the architecture guide already states. Structure-map gate: N/A, no ai/ surface and no new file placement.