PR #878 portalled the right-panel tab strip into the titlebar and added
a #pawwork-titlebar-tabs slot. Two visual regressions surfaced after the
merge:

1. The Right utility panel toggle vanished when the right panel was
   open. The slot stamps data-component='tabs' so the sidepanel CSS in
   tabs.css matches the portalled <Tabs.List>; that borrowed identity
   also inherits the base [data-component='tabs'] rule
   'background-color: var(--bg-base)'. With the slot positioned
   absolute / right: 0 / width: var(--right-panel-width) / z-10, the
   opaque background painted over the toggle button portalled into
   #pawwork-titlebar-right. PR #878 added pointer-events-none which
   restored clickability, but not visibility.

   Fix: reset background-color to transparent in the sidepanel host
   block in packages/ui/src/components/tabs.css. The slot becomes the
   transparent portal-landing it was always intended to be; the real
   right-panel-body underneath owns the visible surface.

2. The sidebar toggle in the titlebar lost its aria-expanded selected
   chip (surface-base background when sidebar is open). The CSS rule
   .titlebar-icon[aria-expanded='true'] was scoped to
   [data-component='icon-button'], but all four titlebar usages render
   <Button variant='ghost'> (data-component='button'). The selector
   silently never matched — this predates #878 but the broader titlebar
   reshape made it visible.

   Fix: drop the [data-component='icon-button'] ancestor from the
   .titlebar-icon rules in packages/ui/src/components/icon-button.css.
   The class name carries the contract; the selector should not narrow
   it. Scope blast: same fix re-enables the selected chip on the Right
   utility panel toggle and the StatusPopover trigger — both also use
   <Button class='titlebar-icon'> + aria-expanded.

Also updated the slot comment in titlebar.tsx to document both the
click and visual occlusion modes so the next reader does not have to
re-derive them.

Verification

- bun run --filter=@opencode-ai/app typecheck OK
- bun run --filter=@opencode-ai/ui typecheck OK
- bun run --filter=@opencode-ai/ui (357 unit tests) OK
- bun run --filter=@opencode-ai/app snap right-panel-titlebar OK,
  light + dark grid shows the sidebar toggle chip + the close-panel
  button restored at the right edge.

E2E helper rightPanelTabList is untouched: the slot keeps both
data-component='tabs' and data-scope='right-panel'.

The right-panel shell tab strip (Status / Files / Review) carried an
app-level override in packages/app/src/index.css that painted
var(--sidebar) on the selected trigger. This pre-dates PR #878 (the
override has been there since the phase-1 desktop port in PR #35) but
PR #878 reshaped the strip and surfaced the inconsistency: Status (the
default landing tab) got a chip while Files / Review did not, so the
selected tab visibly bulged wider than its siblings.

The sidepanel comment in packages/ui/src/components/tabs.css already
spelled out the intended active marker — 'weight + color shift only.
No chip background, no brand underline' — but the app-level rule
overrode it.

Drop the rule. All three triggers now share a transparent background;
the selected tab is conveyed by fg-strong + 500 weight, matching the
tabs.css comment and DESIGN.md's restrained warm-neutral palette.

Verification (TDD)

- New e2e spec session-shell-tab-consistency.spec.ts asserts at the
  rendered seam that all three triggers share the same computed
  background-color. Red on HEAD~1 (Status rgb(248, 246, 243) vs Files
  rgba(0, 0, 0, 0)), green after the index.css deletion. The
  assertion does not hard-code 'transparent' — the contract is
  'agree with each other'.
- bun run --filter=@opencode-ai/app typecheck OK
- bun run --filter=@opencode-ai/app snap right-panel-titlebar — light
  + dark grid shows all three tabs at equal visual weight.

This reverts commit 412d706.

PR #878 left two visual contracts unresolved on the right-panel tab strip:
the selected-tab chip was still the opaque var(--sidebar) hex that read too
heavy now that the strip lives in the titlebar, and the close × overflowed
its slot because (a) the inner Icon is fixed at 16×16 in icon.css, (b) the
slot was sized with literal 14px / 10px values that ignore this app's
13px html base font-size — so 'size-3.5' (used by the leading icon span and
icon-button) actually renders ~11px, leaving the × off-center by 2-3px and
visually bigger than its neighbours.

Changes:

- packages/app/src/index.css: switch the selected-tab chip from
  var(--sidebar) (opaque #f2f1ee / #1d1d1b) to var(--row-active-overlay)
  (rgba black/white at 6% — the exact overlay the sidebar session row uses
  for its own selected state). Single selection vocabulary across the app.

- packages/ui/src/components/tabs.css:
  * Drop the redundant font-weight: 500 on [data-selected] — every sidepanel
    trigger already picks up 500 from text-h3 (--font-weight-h3), so the
    rule was setting an existing value and produced no visible emphasis.
    Selection is now color shift (fg-weak → fg-strong) + chip only, with
    constant tab widths under selection.
  * Replace literal 14px / 10px on the close-button slot with rem-aware
    values (0.875rem width/height, 0.625rem left) so it tracks 'size-3.5'
    and the trigger's 'px-2.5' padding under the 13px html base. The slot
    now matches the leading icon span exactly in size and position.
  * Constrain the inner [data-component='icon'] in the close-button slot
    to 8×8 (was 16×16 from icon.css) so the × reads as a subordinate
    affordance instead of a peer of the 16×16 leading icon.
  * Suppress the IconButton's own --hover-overlay background inside the
    slot so the × renders as a bare glyph, not a chip-shaped button.
  * Drop the 100ms opacity transition on the icon ↔ × swap — the fade
    produced a 'both icons visible' mid-frame whenever the cursor crossed
    multiple closable tabs in quick succession. Instant swap eliminates it.
  * Refresh the surrounding comments to describe the row-active-overlay
    chip + rem-aware footprint, replacing the now-incorrect 'no chip' and
    '14×14 cell' descriptions.

Verification:

- New packages/app/e2e/session/session-tab-chip-contract.spec.ts pins the
  contract: chip computes to a low-alpha rgba (overlay band, not opaque);
  the close-button slot's width/height equal the leading icon span's
  width/height; the visible × glyph is 6–10px; the leading icon and ×
  centers align within 1px; the swap has zero transition; Status (the
  non-closable tab) never renders an × and keeps its icon on hover.
  All 5 assertions pass post-fix.

- New packages/app/e2e/snap/right-panel-tabs-hover.snap.ts captures three
  states (rest / hover Files / hover Review) in light + dark — the
  existing right-panel-titlebar snap intentionally parks the mouse at
  (0,0) and would not catch hover-state regressions. Visually confirms
  chip is the lighter overlay, × is small and centered, no double-icon
  artifact.

The previous commit (858c394) addressed the chip color, × size, and
alignment, but missed one state: a selected closable tab with the cursor
parked away rendered both the leading icon AND the ×. Reproduction was
the user-reported 'click Files, mouse off the tab strip — folder icon and
× visible at the same time.'

Root cause is a specificity loss. The base [data-component="tabs"] block
in this file declares:

  [data-slot="tabs-trigger-wrapper"]:has([data-selected])
    [data-slot="tabs-trigger-close-button"] { opacity: 1 }

at 4 attribute selectors. The sidepanel variant's slot rule sat at 3 attrs
([data-component="tabs"][data-variant="sidepanel"]
 [data-slot="tabs-trigger-close-button"]), so the :has([data-selected])
forced opacity:1 on every selected closable tab regardless of hover. The
hide-leading-icon rule only fires on :hover, so the leading icon stayed
visible whenever the cursor wasn't over the tab — producing the double-icon
state the sidepanel design explicitly forbids.

Fix: route the sidepanel slot's rest and :hover rules through
[data-slot="tabs-trigger-wrapper"] so the chain hits 4 attrs (rest) and
5 (hover), winning over the base :has([data-selected]) path. The × is
now strictly hover-driven on sidepanel; selected closable tabs at rest
show only their leading icon.

Verification:

- New assertion in session-tab-chip-contract.spec.ts: click Files (select +
  closable), park the cursor far off the tab strip, then assert leading
  opacity 1 and close-slot opacity 0. Six contract assertions now pass
  (chip color, × size, alignment, instant swap, hover-only ×, Status guard).

Two visual regressions on the right-panel tab strip flagged after PR #878
shipped:

  1. Hovering a tab produced no chip background — the strip felt dead and
     clicks landed without any visual lead-in. UX expects hover to preview
     the selection (lighter overlay), then click to lock in (heavier).
  2. Status / Files / Review / Terminal labels have different lengths, so
     the chips rendered visibly mismatched.

Fixes:

  - app: scoped two right-panel chip rules to the wrapper (matches the
    sidebar session row's chip-on-container vocabulary):
      hover  → --row-hover-overlay  (4% overlay)
      :has([data-selected]) → --row-active-overlay (6% overlay)
    Hover rule carries :not(:disabled) to tie specificity (0,6,0) with the
    sidepanel base rule that forces transparent bg on hover; later
    declaration order wins.

  - ui: sidepanel trigger gets min-width: 7.5rem (~97px @ 13px html base)
    plus justify-content: flex-start. Base trigger uses
    justify-content: center, which works for content-sized tabs but drifts
    the leading icon to the cell center as soon as min-width pushes the
    trigger wider than its content — the close-button slot stays at
    left: 0.625rem (absolute), so centering content offsets × from the
    leading icon by half the slack. background-color: 120ms transition
    added so the hover overlay fades in rather than snapping.

E2e contract: 6 → 8 assertions. Adds 'hover paints a chip preview' and
'all sidepanel tabs share a uniform min-width chip'. Updated the selected-
overlay assertion to sample the wrapper (where the chip now lives) instead
of the inner trigger button.

Verified:
  - bun script/e2e-local.ts -- session-tab-chip-contract → 8/8
  - bun run typecheck → 8/8
  - bun run snap right-panel-tabs-hover → grid shows hover + selected
    overlays in both light and dark themes, × stays aligned with the
    leading icon at the wider chip width.

Acted on the 6 crosscheck findings worth merging; declined 3 with reason.

Code findings addressed
-----------------------
1. e2e contract assertions were too loose (codex P2/P3, flagged 4×):
   - selected-overlay test now compares chip bg to a paint-resolved
     `--row-active-overlay` exactly, instead of "some low-alpha rgba"
     in 0-0.2. Swapping the active token for hover (or any other low-alpha
     value) now fails.
   - hover-overlay test compares to `--row-hover-overlay` exactly and
     also asserts inequality with the active overlay, so the two-tier
     vocabulary stays distinct.
   - min-width footprint test was a "≥ 71" floor — silently passed if
     the floor was raised to 120. Now per-tab: Status + Files must equal
     72 (the floor is what keeps them uniform); Review tolerates ≥ 72
     because its Latin natural width slightly exceeds the floor.
   - "trigger gap" test extended to a full chip-geometry contract: also
     pins trigger padding-inline (4px) and wrapper border-radius (10px,
     --radius-md), the two geometry decisions PR #880 settled that had
     no test coverage.

2. Pointer-events leak in the titlebar tab strip (codex P2 / claude P1):
   `<Tabs.List>` re-enables pointer events for the whole list so the tab
   triggers stay clickable, but the flex-1 spacer between the last tab
   and the `+` button was also inheriting that, silently swallowing
   clicks on the Right utility toggle in `#pawwork-titlebar-right` that
   overlaps the same x range. Fix is one class on the spacer:
   `pointer-events-none`. Titlebar comment updated to record the new
   chain (slot none → list auto → spacer none).

3. `aria-keyshortcuts="Delete"` on closable tabs (codex P3) — the
   handler also accepts Backspace as the macOS alias, so screen readers
   were getting a partial advertisement. Now `"Delete Backspace"` per
   ARIA spec.

4. Post-close focus restore could land on a detached node (claude P2):
   rapid successive closes can remove the captured sibling before its
   rAF fires; calling `.focus()` on a detached element silently moves
   focus to <body>. Guard with `isConnected` inside the rAF.

5. Duplicate comment blocks in titlebar.tsx (claude P3): two stacked
   block comments both explained the portal landing pad's "borrowed
   identity" and the two-fold occlusion fix. Merged into one ordered
   block.

6. `openExtraTabs` poll asserted `=== 3` (claude P3): would fail before
   reaching real assertions if any future default-open tab landed in the
   strip. Relaxed to `>= 3`.

Declined with reason
--------------------
- Anchor positioning Chrome-125 floor (claude P1): Electron 40 ships
  Chromium 134, comfortably past the floor. The dev web preview also
  targets recent Chromium. The comment in tabs.css already records this.
- 4-attr-specificity workaround and split chip-bg authority between
  tabs.css and index.css (claude P2 ×2): real architectural smells, but
  fixing them means cascade/@layer surgery touching unrelated variants.
  Out of scope for this PR; worth its own follow-up if it keeps biting.
- `tabs-drag-preview` still uses the old 26h/6r dimensions (claude P3):
  drag-preview is a single shared component across all tab variants and
  was already mismatched before PR #880. Per-variant drag-preview
  geometry is out of scope.

Verification: 10/10 chip-contract e2e green; lint clean.

…meets the panel separator

Followup-review P2 (non-blocking): with `#pawwork-titlebar-tabs` moved
from absolute overlay to an in-flow flex sibling, its `self-stretch`
only reaches the parent rail's content height. The titlebar root uses
`items-center` (grid), which lets each grid cell collapse to its child
content box unless the cell opts out — so the rail was sized to the
toggle button (≈30px) and the tabs slot's `border-l` only painted the
toggle row, breaking above and below it and failing to meet the
right-panel body's `border-l` directly underneath.

Add `self-stretch` to the outer right rail so it fills the full
titlebar height (44px on desktop). `#pawwork-titlebar-right`'s inner
`items-center` keeps the toggle vertically centered as before.

Regression test pins the tabs slot's bounding height to the titlebar's
own height — would have caught this drift the first time and will catch
any future regression that drops the stretch chain.

Verified:
- bun run test:e2e session-tab-chip-contract.spec.ts (13/13, including
  the new "tabs slot border-l spans the full titlebar height" guard)
- bun run snap right-panel-titlebar (the seam now reads as one
  continuous line from titlebar top to viewport bottom)

Refs PR #880.

…essionSidePanel

PR #880 followup review P2: `SessionSidePanel` only renders the panel
(and portals tab content into the titlebar slot) at viewport ≥768px,
guarded by `createMediaQuery("(min-width: 768px)")`. But
`--right-panel-width` and the titlebar's `tabsRailActive` only checked
`layout.rightPanel.opened()`. Opening the panel at desktop width and
then shrinking the viewport below 768px would leave the titlebar
reserving panel-width of empty rail (nothing portals in under the
breakpoint), pushing the right utility toggle off the viewport edge
with nothing visible to justify the gap.

Add the same `createMediaQuery("(min-width: 768px)")` gate to
`tabsRailActive` so the titlebar rail and the panel agree on "is the
right panel actually visible right now": route + state + viewport.

A cleaner future direction is to lift this predicate to shared layout
state so titlebar and panel both consume it; out of scope for this PR.

CSS anchor positioning note (reviewer's "待验证" item): PawWork is a
macOS/Windows desktop product per AGENTS.md, shipped only via Electron
(Chromium 134+ in Electron 40, well above the 125+ anchor-positioning
floor). `bun run dev` web mode is a dev convenience, not a shipped
surface — no fallback needed.

Verified:
- bun run typecheck (clean)
- bun run test:e2e titlebar-right-rail-contract.spec.ts (3/3 including
  the new "tabs slot shrinks to 0 width when viewport drops below the
  desktop breakpoint" guard, which was RED before this fix)

Refs PR #880.

…spec

PR #880 review followup: reading `#pawwork-titlebar-tabs` geometry
immediately after `page.setViewportSize(...)` raced the
viewport → media query → Solid memo → DOM update chain. Replace the
single `page.evaluate` with `expect.poll` so the assertion only runs
after layout settles.

Skipped review nit: extracting `768px` to a shared `DESKTOP_BREAKPOINT`
constant was already flagged as a follow-up scope item in the previous
commit (alongside lifting the entire desktop/route/state predicate to
shared layout state). CodeRabbit itself marked it 💤 Low value.

Refs PR #880.