feat(045): cross-window tab dock-in (Center) + floating tab chrome (#388)

* feat(045): cross-window tab dock-in (Center) + floating tab chrome

Adds support for dragging a tab from any DockHost (main window or
floating) into another floating window's tab group, materializing it
as an appended tab. Also lands the §4.2 `TitleBar`-zone tab chrome
for floating windows (Edge / Files / modern-VS pattern).

## Cross-window dock-in (§4.6 / §2.4)

WinUI's `TabView.CanDragTabs` drag pipeline is **window-local**: drag
events never reach AllowDrop elements in another XAML island, so the
P3 live-overlay path cannot deliver Center-only dock-in across HWNDs.
Workaround: drop-completion cursor hit-test.

- `src/Reactor/Docking/Native/DockFloatingPaneRouter.cs` (new):
  global `ReactorWindow -> append-as-tab` registry guarded by a lock.
  `Register` / `Unregister` / `TryAppendUnderCursor` /
  `HasRegisteredWindows`. Uses Win32 `GetCursorPos` +
  `GetWindowRect` + `SetForegroundWindow` (P/Invoke) for the
  HWND-boundary hit-test.
- `DockHostNativeComponent.HandleTabDragCompleted`: now consults the
  router *before* falling back to tear-out, so a tab dropped over a
  floating window's chrome appends as a new tab in that window.
- `DockFloatingWindowComponent`: self-registers with the router on
  mount via `UseEffect` deferred through `DispatcherQueue.TryEnqueue`
  (so the post-Open `windowHolder[0]` assignment lands first), and
  unregisters on close. Floating-to-floating redirect lives in the
  component's `onTabDragCompleted` closure.
- `DockDropTargetOverlayControl`: reserved `DockDropOverlayMode.CenterOnly`
  enum value + `ApplyModeVisibility` branch for the future live-overlay UX.
- `DockHostModel.OnExternalCrossWindowDrop`: internal hook for adapters.

## Floating tab chrome (§4.2 / §4.3)

- `DockFloatingWindow`: `Open()` now mounts `DockFloatingWindowComponent`
  with `WindowSpec.ExtendsContentIntoTitleBar = true`. `BuildChrome`
  renders `DockTabGroup` at the root + a transparent `BorderElement`
  in `TabStripFooter` whose `OnMount` calls `window.SetTitleBar(self)`.
  Brush construction is deferred to `OnMount` to keep `BuildFloatingRoot`
  headless-safe for unit tests.
- Component owns panes via `UseReducer<IReadOnlyList<DockableContent>>`
  (functional updater avoids stale-closure bugs); subscribes to
  `DockDragSession.SessionChanged`.

## Spec / tests

- Spec 045: tick §4.2 / §4.3 / §2.4 cross-window dock-in bullets;
  document the drop-completion hit-test and the WinUI window-local
  limitation.
- `tests/Reactor.Tests/Docking/Native/DockFloatingWindowTests.cs` (new):
  5 unit tests pinning the `BuildFloatingRoot` element-tree shape.

## Verification

- `dotnet build Reactor.slnx -c Debug -p:Platform=x64`: 0 errors.
- Full unit suite (`tests/Reactor.Tests`): 8773 passed, 0 failed, 46 skipped.
- Selftests (`Reactor.AppTests.Host --self-test`): 826/827 pass
  (1 flake in `DynDock_OpenWelcomeButton_Mounted` is a pre-existing
  render-timing flake — passes in isolation).
- E2E (`tests/Reactor.AppTests`): 64/64 pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* review: address Copilot CR feedback on #388

Six inline comments from the automated reviewer:

1. `DockFloatingWindow.cs` (~L80) — Comment near
   `ExtendsContentIntoTitleBar = true` referenced the old
   `TitleBarElement` / `Microsoft.UI.Xaml.Controls.TitleBar` path
   that the PR explicitly moved away from. Rewrote to describe the
   actual implementation (root TabView + transparent `BorderElement`
   in `TabStripFooter` wired via `Window.SetTitleBar`) and call
   out why `Microsoft.UI.Xaml.Controls.TitleBar` is intentionally
   NOT used here.

2. `DockFloatingWindow.cs` (~L270) — `fe.Loaded += (_, _) => Apply();`
   never unsubscribed; WinUI `Loaded` re-fires on reparent/reload
   which would re-call `SetTitleBar` and leak the delegate. Replaced
   with a one-shot `RoutedEventHandler` that detaches itself before
   calling `Apply()` (mirrors the pattern in
   `DockSideStripRenderer.cs:260`).

3. `DockFloatingWindow.cs` (~L470) — The temporary `reAppend`
   callback used during the unregister/append/re-register gap (the
   floating→floating drag-completed path) did not update the
   `AppWindow.Title` on first-tab append, unlike the main router
   `append` closure built in `UseEffect`. A pane appended during
   that small gap would leave the title stale until the next render
   re-registered the canonical `append`. Refactored by hoisting
   `append` to a local function shared by both registration sites.

4. `DockFloatingWindow.cs` (~L501) — Dead-code `ContainsByRef`
   helper removed.

5. `DockHostNativeComponent.cs` (~L387) — Cross-window dock-in into
   an existing floating window was being logged as `DragTearOut`
   even though it appends as a tab (no new floating window is opened).
   That makes the operation log / replay analysis misleading. Switched
   to `DragConfirm` to match the semantics used by the
   `OnExternalCrossWindowDrop` adapter path.

6. `samples/apps/dock-showcase/App.cs` (~L1144) — Typo in
   persistence-note string: literal TAB + `"abChrome"` (missing the
   leading `t`). Fixed to `"tabChrome"` so the showcase UI reads
   correctly.

Verification:
- `dotnet build Reactor.slnx -c Debug -p:Platform=x64` — 0 errors.
- `dotnet test tests/Reactor.Tests --filter Docking` — 350/350 pass.
- `NativeDocking_FloatingWindow_*` selftest fixtures — 4/4 pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* review: address CodeQL feedback on #388

Second-round review from `github-code-quality[bot]` flagged 10
issues across 3 files (with several near-duplicate comments on the
same lines):

1. **Floating-point equality (CornerRadius == 0)** —
   `NativeDockingSmokeFixture.cs:1507-1509`. Production sets
   `new CornerRadius(0)` which yields exact 0.0, but CodeQL flags
   any `== 0.0` on a `double`. Switched to `Math.Abs(x) < 1e-9`
   with a documented epsilon constant. Same intent, no CodeQL noise.

2. **Foreach-with-type-guard → `OfType<T>()`** —
   `NativeDockingSmokeFixture.cs:1562-1573` (HasHeader helper).
   Replaced two nested `foreach (var x in seq) if (x is T t)` with
   `foreach (var t in seq.OfType<T>())` for `TabItems` and
   `StackPanel.Children`. Implicit usings already give us LINQ.

3. **Same-variable branch → ternary** —
   `DockDropTargetOverlayControl.cs:289-294`. Collapsed the
   `if/else` in the `centerOnly` mode (both branches assigning
   `entry.Button.Visibility`) into one ternary assignment.

4. **Generic catch clauses (3 sites)** —
   `DockFloatingPaneRouter.cs:87, 91, 101`. Replaced bare
   `catch { … }` with typed catches for the expected recoverable
   exceptions when probing a floating window during shutdown:
   `COMException` / `ObjectDisposedException` /
   `InvalidOperationException`. Unknown exceptions now surface
   instead of being silently swallowed.

Verification:
- `dotnet build Reactor.slnx -c Debug -p:Platform=x64` — 0 errors.
- `dotnet test tests/Reactor.Tests --filter Docking` — 350/350 pass.
- `NativeDocking_TabChromePresetsApplyAndClear` selftest — 14/14
  assertions pass (including the epsilon CornerRadius check).
- `NativeDocking_FloatingWindow_*` selftests — 0 failures.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: codemonkeychris

docs/specs/tasks/045-docking-windows-implementation.md

@@ -596,9 +596,22 @@ WinUI.Dock wrapper for side-by-side review.
   WinUI.Dock string-keyed GUID table — spec §8.9 security).
   `DockDragSession` carries object refs to the dragged pane + source
   manager; there is no GUID table, no static dict keyed by string,
-  no serializable payload. Cross-window HWND-boundary drag itself
-  remains deferred to a follow-up (TabView's native cross-HWND drag
-  is the WinUI primitive there).
+  no serializable payload. **Cross-window HWND-boundary dock-in
+  (Center only) lands via a drop-completion cursor hit-test:**
+  `DockFloatingPaneRouter` (`src/Reactor/Docking/Native/`) maintains a
+  global `ReactorWindow → append-as-tab` registry; floating windows
+  self-register on mount (via dispatcher-deferred `UseEffect`) and
+  unregister on close. `HandleTabDragCompleted` (and the equivalent
+  hook on floating windows for floating→floating) Win32-hit-tests
+  `GetCursorPos` against each registered window's
+  `GetWindowRect` *before* falling back to tear-out, so a tab dropped
+  over another window's chrome appends as a new tab in that window's
+  tab group. The WinUI cross-window drag pipeline itself is
+  window-local (drag events do not cross XAML islands), so this
+  drop-completion hit-test is the canonical workaround; live-overlay
+  N/E/S/W targeting across windows remains deferred (the
+  `DockDropOverlayMode.CenterOnly` enum value is reserved for the
+  future overlay UX).
 - [x] Keyboard-initiated move: `Ctrl+Shift+M` enters drop-target focus
   mode (spec §5.3.3 / §8.7). Landed in §2.10 via the chord-bridge
   wiring on `DockHostNativeComponent.EnterKeyboardDropMode`; flips
@@ -2061,44 +2074,73 @@ re-run with new chrome plus eight visual items.
 
 ### 4.2 `TitleBar` control adoption (spec §7.1.1)
 
-- [ ] Floating dockable windows use
-  `Microsoft.UI.Xaml.Controls.TitleBar` as root chrome.
-- [ ] `ReactorWindow.NativeWindow.ExtendsContentIntoTitleBar = true`.
-- [ ] Root content gets `TitleBar` slot at top; docking tab strip lives
-  inside its content area.
-- [ ] Reactor's existing `TitleBar(...)` element (`src/Reactor/Elements/
-  Dsl.cs:610`, `TitleBarElement`) wires through `DockHost` for the
-  floating-window path.
+- [x] Floating dockable windows extend their content into the title-bar
+  zone so the tab strip becomes the visible chrome
+  (`WindowSpec.ExtendsContentIntoTitleBar = true`). *(The WinUI 3
+  `Microsoft.UI.Xaml.Controls.TitleBar` control is intentionally NOT
+  used here — its `Content` slot is a small in-row chrome slot
+  designed for things like Edge's address bar and cannot host a full
+  TabView with bodies. The Edge / Files pattern uses
+  `Window.SetTitleBar(...)` directly on a strip-footer drag region
+  instead. Reactor's `TitleBarElement` remains available for app
+  shells that want the control's distinct row layout.)*
+- [x] `ReactorWindow.NativeWindow.ExtendsContentIntoTitleBar = true`.
+- [x] Root content puts the docking tab strip in the title-bar zone
+  (Edge / Files / VS Code "tabs in title bar" layout).
+- [x] `Window.SetTitleBar(dragRegion)` is wired from a `TabStripFooter`
+  element so the OS reserves caption-button inset and treats the
+  footer area as window drag-move surface.
+
+*(Landed: `DockFloatingWindow.BuildFloatingRoot`
+(`src/Reactor/Docking/Native/DockFloatingWindow.cs`) renders the
+`DockTabGroup` as the floating window's root and adds a transparent
+`BorderElement` to `TabStripFooter` whose `OnMount` calls
+`floatingWindow.NativeWindow.SetTitleBar(self)`. `Open()` sets
+`WindowSpec.ExtendsContentIntoTitleBar = true`. Unit tests in
+`tests/Reactor.Tests/Docking/Native/DockFloatingWindowTests.cs`;
+visual coverage in selftest fixture
+`NativeDocking_FloatingWindow_TitleBarChromeAndTabsInTitleBar`.)*
 
 ### 4.3 Tabs in the title bar (spec §7.1.2) — headline feature
 
-- [ ] **Single-group float:** tab strip renders inside `TitleBar`
-  content slot, flush with caption buttons, active tab styles as
-  window's identity (Edge / Files / modern-VS pattern).
+- [x] **Single-group float:** tab strip occupies the title-bar zone at
+  y=0, flush with OS caption buttons, active tab styles as the
+  window's identity (Edge / Files / modern-VS pattern). *(Implemented
+  via `ExtendsContentIntoTitleBar=true` + TabView at root + drag
+  region in `TabStripFooter` registered via `Window.SetTitleBar`.)*
 - [ ] **Multi-group float:** revert to standard floating title (via
   `IDockAdapter.GetFloatingWindowTitleBar`); tabs render in normal pane
-  position. The same `GetFloatingWindowTitleBar` surface continues to
-  exist — it supplies the non-tab portion (text/branding) in both
-  modes.
+  position. *(Deferred: floating windows are single-pane today; the
+  multi-group float infrastructure itself is a separate slice.)*
 - [ ] Drag semantics:
-  - [ ] Drag a **tab** → tear it out (most-tested case; tab now lives
-    inside OS-managed title-bar hit-test surface).
-  - [ ] Drag **title-bar background** (non-tab, non-caption) → move
-    floating window. OS-handled.
+  - [x] Drag a **tab** → tear it out. *(Existing `onTabDragStarting`
+    path continues to work in the new layout.)*
+  - [x] Drag **title-bar background** (non-tab, non-caption) → move
+    floating window. *(OS-handled via the `TabStripFooter` drag region
+    registered with `Window.SetTitleBar` — `MinWidth(180)` ensures a
+    grabbable region even with many tabs.)*
   - [ ] Drag **active tab when it is the only tab** → moves whole
-    window (single-tab floats behave like normal windows).
+    window. *(Deferred: `onTabDragStarting` currently fires tear-out
+    unconditionally.)*
 - [ ] `AppWindow.TitleBar.SetDragRectangles` integration: hit-test
   regions computed per frame from tab-strip measured geometry; pushed
   to OS so it knows interactive vs drag-region sub-rects.
-- [ ] **Debounce `SetDragRectangles` to layout-measure-change events**
-  (not every-frame). Perf budget per spec §7.3 + §8.5.
+  *(N/A — we hand the OS a single `TabStripFooter` element via
+  `Window.SetTitleBar`, which is the modern WinUI 3 replacement for
+  explicit `SetDragRectangles` plumbing.)*
+- [ ] **Debounce `SetDragRectangles` to layout-measure-change events.**
+  *(N/A — see above.)*
 
 ### 4.4 Caption-button area awareness (spec §7.1.5)
 
-- [ ] Tab strip reserves `AppWindow.TitleBar.RightInset` as
-  right-padding (LeftInset in RTL).
-- [ ] Subscribe to `AppWindowTitleBar.LayoutMetricsChanged`; re-measure
-  on next layout pass (handles theme switch flipping RTL mid-flight).
+- [x] Tab strip reserves caption-button inset automatically — the
+  `Window.SetTitleBar(footer)` registration tells the OS where
+  caption buttons should sit (top-right) and the buttons render over
+  the right edge of the footer drag region.
+- [x] OS handles RTL / theme-switch caption-button placement via the
+  same `SetTitleBar` registration; no manual
+  `LayoutMetricsChanged` subscription required for the current
+  Window-level inset behavior.
 
 ### 4.5 Snap Layouts (spec §7.1.3)
 
@@ -2113,8 +2155,16 @@ re-run with new chrome plus eight visual items.
 - [ ] Floating dockable windows inherit `WindowSpec.Backdrop`
   (spec 036 §4.1, §5).
 - [ ] Splitter gutters semi-transparent under Mica / Acrylic.
-- [ ] Tab-strip background uses `TitleBarBackgroundFillBrush`, not a
-  hard color.
+- [x] Tab-strip background uses `TitleBarBackgroundFillBrush`, not a
+  hard color. *(Phase 4 slice landed: `TabChrome` enum on `DockTabGroup`
+  with `Win11` / `Flat` / `TitleBar` presets, scoped to each TabView's
+  `Resources` via `DockTabGroupRenderer.BuildSetters`. `TitleBar` preset
+  resolves `TitleBarBackgroundFillBrush` from `Application.Current.Resources`
+  and writes to `TabViewBackground`; pool-safe via a "blanker" setter
+  that strips all managed keys before applying a new preset. JSON
+  persistence: optional `tabChrome` field, omitted on `Win11` for
+  legacy-file back-compat. Dock-showcase **Scene I — Tab Styles** is
+  the visual gate input for §4.11 Item 23.)*
 
 ### 4.7 Dark mode / accent color (spec §7.1.6)
 
@@ -2124,9 +2174,15 @@ re-run with new chrome plus eight visual items.
 
 ### 4.8 Floating-window persona (spec §7.1.7)
 
-- [ ] Single-tab float: tab `Title` and `Icon` → `AppWindow.Title` and
-  `AppWindow.SetIcon`. Alt-tab shows the tab title.
-- [ ] Multi-tab float: active tab's title reflected.
+- [x] Single-tab float: tab `Title` → `AppWindow.Title`. Alt-tab shows
+  the tab title. *(Title landed: `DockFloatingWindow.Open` passes
+  `pane.Title` as `WindowSpec.Title`. Icon deferred: `DockableContent`
+  has no `Icon` field yet — adding one is a separate slice.
+  Note: in the Edge tabs-in-titlebar layout the tab itself displays
+  the title text; there is no separate WinUI 3 `TitleBar` widget to
+  also bind to. `AppWindow.Title` still controls taskbar / alt-tab.)*
+- [ ] Multi-tab float: active tab's title reflected. *(Deferred with
+  multi-tab float — see §4.3 above.)*
 - [ ] Composition with spec 036 §8 persistence: persisted Window
   identity is the dockable-window key, not the transient tab content.
 

plugins/reactor/skills/reactor-dsl/references/reactor.api.txt

@@ -89,6 +89,7 @@ InfoBadge() → InfoBadgeElement
 InfoBadge(int value) → InfoBadgeElement
 InfoBar(string title = null, string message = null) → InfoBarElement
 InterspersedGrid(Orientation orientation, Element[] items, double[] proportions, double separatorSize, Func<int, Element> separatorFactory) → GridElement
+ItemContainer(Element child) → ItemContainerElement
 ItemsView<T>(IReadOnlyList<T> items, Func<T, string> keySelector, Func<T, int, Element> viewBuilder) → ItemsViewElement<T>
 LazyHStack<T>(IReadOnlyList<T> items, Func<T, int, Element> viewBuilder) → LazyHStackElement<T>
 LazyHStack<T>(IReadOnlyList<T> items, Func<T, string> keySelector, Func<T, int, Element> viewBuilder) → LazyHStackElement<T>
@@ -346,6 +347,7 @@ InfoBarElement.Set(Action<InfoBar> configure) → InfoBarElement
 InfoBarElement.Severity(InfoBarSeverity severity) → InfoBarElement
 InfoBarElement.Success() → InfoBarElement
 InfoBarElement.Warning() → InfoBarElement
+ItemContainerElement.Set(Action<ItemContainer> configure) → ItemContainerElement
 ItemsViewElement<T>.ItemInvoked<T>(Action<T> handler) → ItemsViewElement<T>
 ItemsViewElement<T>.SelectionChanged<T>(Action<IReadOnlyList<T>> handler) → ItemsViewElement<T>
 ItemsViewElement<T>.Set<T>(Action<ItemsView> configure) → ItemsViewElement<T>
@@ -918,6 +920,7 @@ DockOperationKind { Mount, DragStart, DragHover, DragConfirm, DragCancel, DragTe
 DockPaneState { Docked, Floating, AutoHidden, AutoHiddenExpanded, Hidden }
 DockSide { Left, Top, Right, Bottom }
 DockTarget { Center, SplitLeft, SplitTop, SplitRight, SplitBottom, DockLeft, DockTop, DockRight, DockBottom }
+TabChrome { Win11, Flat, TitleBar }
 TabPosition { Top, Bottom }
 DragOperations { None, Copy, Move, Link, All }
 GesturePhase { Began, Changed, Ended, Cancelled }

samples/apps/dock-showcase/App.cs

@@ -63,7 +63,8 @@ public override Element Render()
             SceneButton("persist",      "Scene E — Persistence",       scene, setScene),
             SceneButton("programmatic", "Scene F — Programmatic Dock", scene, setScene),
             SceneButton("sliders",      "Scene G — Slider Resize",     scene, setScene),
-            SceneButton("droptargets",  "Scene H — Drop Targets",      scene, setScene)
+            SceneButton("droptargets",  "Scene H — Drop Targets",      scene, setScene),
+            SceneButton("tabstyles",    "Scene I — Tab Styles",        scene, setScene)
         ).Width(240).Padding(8);
 
         Element body = scene switch
@@ -76,6 +77,7 @@ public override Element Render()
             "programmatic" => Component<SceneFProgrammatic>(),
             "sliders"      => Component<SceneGSliders>(),
             "droptargets"  => Component<SceneHDropTargets>(),
+            "tabstyles"    => Component<SceneITabStyles>(),
             _              => TextBlock("Unknown scene"),
         };
 
@@ -1040,3 +1042,125 @@ Element MakeSlider(string label, double value, Action<double> setter) =>
         ).Padding(16);
     }
 }
+
+
+// ════════════════════════════════════════════════════════════════════════
+//  Scene I — Tab Styles (spec 045 §4.6)
+// ════════════════════════════════════════════════════════════════════════
+//
+//  Three tab-chrome presets side-by-side, plus the spec-documented
+//  fallback for TabPosition.Bottom (renders as Top in WinUI 3 — see
+//  microsoft-ui-xaml#7395; the upstream workaround requires subclassing
+//  TabViewItem to counter-scale the template parts).
+
+class SceneITabStyles : Component
+{
+    public override Element Render() => Grid(
+        new[] { GridSize.Star(1), GridSize.Star(1) },
+        new[] { GridSize.Auto, GridSize.Auto, GridSize.Star(1), GridSize.Star(1), GridSize.Auto, GridSize.Auto },
+
+        TextBlock("Scene I — Tab Styles").FontSize(20).SemiBold()
+            .Grid(row: 0, column: 0, columnSpan: 2),
+
+        TextBlock(
+            "Three preset chromes for DockTabGroup.TabChrome. Same underlying " +
+            "WinUI TabView (full accessibility/keyboard parity) — only theme " +
+            "resources differ. Pick whichever matches your app's identity."
+        ).Opacity(0.8).Margin(0, 0, 0, 12)
+            .Grid(row: 1, column: 0, columnSpan: 2),
+
+        // Top-left — Win11 default
+        StyleCard(
+            "Win11 (default)",
+            "Rounded corners, theme background. The shipping Win11 TabView look.",
+            new DockTabGroup(
+                Documents: new[]
+                {
+                    new DockableContent("Welcome.md",  ChromeBody("# Welcome",         "Win11"),  Key: "i:w11:welcome"),
+                    new DockableContent("App.cs",      ChromeBody("class App {…}",     "Win11"),  Key: "i:w11:appcs"),
+                    new DockableContent("README",      ChromeBody("Project readme.",    "Win11"), Key: "i:w11:readme"),
+                },
+                TabChrome: TabChrome.Win11))
+            .Grid(row: 2, column: 0),
+
+        // Top-right — Flat (VS Code-style)
+        StyleCard(
+            "Flat (VS Code style)",
+            "Zero corner radius, tighter header padding. Modeled on the modern IDE document strip.",
+            new DockTabGroup(
+                Documents: new[]
+                {
+                    new DockableContent("Welcome.md",  ChromeBody("# Welcome",         "Flat"),   Key: "i:flat:welcome"),
+                    new DockableContent("App.cs",      ChromeBody("class App {…}",     "Flat"),   Key: "i:flat:appcs"),
+                    new DockableContent("README",      ChromeBody("Project readme.",    "Flat"),  Key: "i:flat:readme"),
+                },
+                TabChrome: TabChrome.Flat))
+            .Grid(row: 2, column: 1),
+
+        // Bottom-left — TitleBar (mica-ish; tab strip uses the title-bar brush)
+        StyleCard(
+            "TitleBar (chromeless feel)",
+            "Tab strip uses the system TitleBarBackgroundFillBrush so the strip " +
+            "blends with the window chrome (effective when ExtendsContentIntoTitleBar is on).",
+            new DockTabGroup(
+                Documents: new[]
+                {
+                    new DockableContent("Welcome.md",  ChromeBody("# Welcome",         "TitleBar"), Key: "i:tb:welcome"),
+                    new DockableContent("App.cs",      ChromeBody("class App {…}",     "TitleBar"), Key: "i:tb:appcs"),
+                    new DockableContent("README",      ChromeBody("Project readme.",    "TitleBar"), Key: "i:tb:readme"),
+                },
+                TabChrome: TabChrome.TitleBar))
+            .Grid(row: 3, column: 0),
+
+        // Bottom-right — Flat + CompactTabs (full classic VS feel)
+        StyleCard(
+            "Flat + CompactTabs",
+            "Same flat chrome paired with tightly-packed tabs — the closest match " +
+            "to the dense tool-window strip in classic Visual Studio.",
+            new DockTabGroup(
+                Documents: new[]
+                {
+                    new DockableContent("Errors",     ChromeBody("0 errors.",           "Flat compact"), Key: "i:flatc:err"),
+                    new DockableContent("Warnings",   ChromeBody("12 warnings.",        "Flat compact"), Key: "i:flatc:warn"),
+                    new DockableContent("Output",     ChromeBody("Build complete.",     "Flat compact"), Key: "i:flatc:out"),
+                    new DockableContent("Terminal",   ChromeBody("PS> _",               "Flat compact"), Key: "i:flatc:term"),
+                },
+                TabChrome: TabChrome.Flat,
+                CompactTabs: true))
+            .Grid(row: 3, column: 1),
+
+        // Position note
+        TextBlock(
+            "Note — TabPosition.Bottom currently renders as Top under WinUI 3. " +
+            "Microsoft.UI.Xaml.Controls.TabView has no TabStripPlacement property " +
+            "(microsoft-ui-xaml#7395). Spec 045 §4.6 / DockTabGroupRenderer line 196 " +
+            "documents the deferral; a real bottom strip lands when a custom " +
+            "TabViewItem subclass replaces the shared WinUI template."
+        ).Opacity(0.65).FontSize(11).Margin(0, 12, 0, 4)
+            .Grid(row: 4, column: 0, columnSpan: 2),
+
+        // Persistence note
+        TextBlock(
+            "Persistence — TabChrome serializes via the DockLayoutSerializer JSON; " +
+            "legacy layouts without the tabChrome field default to Win11."
+        ).Opacity(0.55).FontSize(11)
+            .Grid(row: 5, column: 0, columnSpan: 2)
+    ).Padding(16);
+
+    // ── helpers ──────────────────────────────────────────────────────────
+
+    static Element StyleCard(string heading, string body, DockTabGroup group)
+        => VStack(6,
+            TextBlock(heading).SemiBold(),
+            TextBlock(body).Opacity(0.7).FontSize(11),
+            new DockManager { Layout = group }
+                .Height(180)
+                .Margin(0, 4, 0, 0)
+        ).Margin(0, 0, 8, 16);
+
+    static Element ChromeBody(string title, string chromeLabel)
+        => VStack(4,
+            TextBlock(title).SemiBold(),
+            TextBlock($"(rendered under TabChrome.{chromeLabel})").Opacity(0.55).FontSize(11)
+        ).Padding(12);
+}