feat: rebuild warm operations workbench

docs/superpowers/specs/2026-07-30-fluid-wide-workbench-design.md

@@ -0,0 +1,29 @@
+# Fluid Wide Workbench Design
+
+**Date:** 2026-07-30
+
+**Status:** Approved
+
+## Problem
+
+The final workbench cascade reintroduced `width: min(100%, 92rem)` and `max-width: 92rem` on `.app-layout`. A 1920px viewport therefore leaves approximately 224px of unused space on each side. The existing browser acceptance matrix stopped at 1440px, so it could not detect this regression.
+
+## Selected Design
+
+- Nodes, Automation, and Settings use one fluid top-level application container with no global maximum width.
+- Desktop outer gutters stay between 16px and 24px, including at 1920px and above.
+- The Fleet sidebar remains 17rem and sticky above 60rem; this correction does not move or restyle it.
+- Fleet retains one column at 390px, two at 768px and 1024px, three at 1440px, and uses four columns at 1920px.
+- Width limits on focused content such as forms, drawers, dialogs, message bubbles, and empty states remain unchanged.
+
+## Cascade Ownership
+
+The canonical `.app-layout` rule owns `width: 100%` and `max-width: none` for both normal and single-layout variants. Later workbench guards may adjust padding but must not redefine container width. Obsolete `92rem` and `106rem` top-level width declarations are removed so future visual changes cannot reactivate them through specificity or source order.
+
+## Acceptance
+
+- Real Chrome checks at 390px, 768px, 1024px, 1440px, and 1920px.
+- At 1920px, `.app-layout` has no more than 24px of empty space on either side for Nodes, Automation, and Settings.
+- Fleet has four columns at 1920px and no horizontal overflow.
+- Existing sidebar geometry and the 390/768/1024/1440 card-column expectations remain unchanged.
+- Focused content width limits remain intact.

docs/superpowers/specs/2026-07-30-komari-inspired-fleet-workbench-design.md

@@ -0,0 +1,65 @@
+# Komari-Inspired Fleet Workbench Design
+
+**Date:** 2026-07-30
+
+**Status:** Approved, card structure revised
+
+## Intent
+
+Use the reference monitor's information density and scan order without copying its photographic background, glass treatment, striped cards, red decoration, fixed footer, or broken mobile overflow. SimAdmin remains a warm operations workbench: cream surfaces, brown typography, mint status accents, restrained elevation, and direct operational controls.
+
+## Layout Contract
+
+- The desktop Fleet overview and search remain in the fixed left sidebar. They must not move into the center content pane.
+- The top-level application remains fluid with 16px to 24px outer gutters and no global maximum width.
+- The existing responsive card matrix remains 1 / 2 / 2 / 3 / 4 columns at 390 / 768 / 1024 / 1440 / 1920 pixels.
+- At 960px and below, the sidebar stacks above results and remains collapsible without horizontal overflow.
+
+## Main Results Pane
+
+- A compact five-metric resource health strip appears above the tag groups: online rate, average CPU, average memory, highest temperature, and readable SMS channels.
+- The strip reports only values already available in the Fleet snapshot and message-summary state. Missing measurements render as `--` rather than invented zero values.
+- A horizontal tag group row provides `全部节点` plus available instance tags. It updates the existing tag filter and does not duplicate search ownership.
+- The result count, sort control, and batch controls retain their current behavior.
+
+## Node Card Structure
+
+The node card is a warm SimAdmin adaptation of the reference monitor card. It borrows the reference's stable top-to-bottom telemetry rhythm, not its striped decoration, glass surface, red frame, photographic background, or footer treatment.
+
+1. A compact header owns identity and controls: status-aware avatar, node name, dashboard affordance, status tag, optional batch checkbox, and a single icon action-menu trigger.
+2. Origin, instance tags, and capability tags form one compact metadata flow immediately below the header. They must not render as separate card sections.
+3. Phone number and maximum temperature share one quiet hardware facts strip. Values align to the outer edges and missing values remain explicit.
+4. CPU and memory render as uniform, full-width telemetry rows. Every row uses the same label column, progress track, and right-aligned tabular value.
+5. Latest SMS becomes a compact card footer: message state/direction and number on the left, timestamp on the right. Empty and unavailable states occupy the same geometry.
+6. Service restart and system reboot move into the header action menu. The destructive system reboot item uses semantic danger color, while the menu trigger remains visually secondary.
+
+The batch checkbox is hidden outside batch-selection mode. In selection mode it remains in the header control cluster beside the status and action menu, so identity geometry does not shift unpredictably.
+
+## Interaction Contract
+
+- The card title remains the primary link to the instance dashboard.
+- The origin remains a separate external link and cannot activate card navigation.
+- The action trigger is a 44px icon button with an accessible name, `aria-haspopup="menu"`, and accurate `aria-expanded` state.
+- Menu commands keep the existing confirmation and operation-client behavior. Choosing a command closes the menu before the confirmation flow starts.
+- Operation progress or errors render below the SMS footer without restoring the old full-width action bar.
+- Keyboard focus is always visible. Reduced-motion removes card movement and progress animation.
+
+## Visual System
+
+- Cards use a flat cream surface, one warm hairline border, a 12px radius, and no decorative glow or default drop shadow.
+- Hover changes border and surface tone with a subtle `translateY(-1px)` response; selected cards use a mint inset ring.
+- Progress tracks are quiet warm-neutral rails with solid mint fills. No animated diagonal stripes are introduced.
+- Section hierarchy comes from spacing, weight, a single hardware strip, one footer hairline, and tabular numerals rather than stacked dividers or nested cards.
+- The card action menu may use a restrained warm elevation because it floats above the card; the card itself remains shadowless.
+- Motion stays between 120ms and 220ms and is removed under `prefers-reduced-motion`.
+
+## Cascade Ownership
+
+Fleet workbench refinements live in the existing final approved cascade section at the end of `apps/web/src/styles.css`. New Fleet selectors must not be appended as another theme experiment. Earlier legacy rules may remain for unrelated screens, but the final section is the single owner of Fleet layout, health strip, grouping row, card, resource, SMS, and selection geometry.
+
+## Acceptance
+
+- Component tests verify all five health metrics, tag group filtering, card content order, checkbox placement semantics, and menu-only restart controls.
+- Real Chrome verifies the left/stacked sidebar relationship and 1 / 2 / 2 / 3 / 4 card matrix at all five viewport widths.
+- Chrome geometry verifies the health strip, tag groups, resource rows, card menu trigger, and cards stay within the viewport.
+- Screenshots are reviewed at 390px, 1440px, and 1920px.

docs/superpowers/specs/2026-07-30-warm-operations-workbench-design.md

@@ -51,7 +51,8 @@ Automation contains three views:
 - Use solid warm surfaces. Translucency may be used only for a sticky overlay that visibly floats over scrolling content; it is not the default material.
 - Remove oversized page headers and decorative English kickers.
 - Use plain semantic headings rather than Animal Island ribbon titles on dense operational pages.
-- Keep page gutters between 16px and 24px on ordinary desktop widths and lock very wide content to a practical maximum width.
+- Keep top-level page gutters between 16px and 24px at every desktop width. The application shell remains fluid and must not introduce centered outer whitespace through a global `max-width`.
+- Content-specific limits remain valid for forms, dialogs, drawers, message bubbles, and empty states where long line lengths would reduce usability; these limits must never constrain the top-level Nodes, Automation, or Settings workspaces.
 
 ### 4.2 Tokens
 
@@ -80,9 +81,10 @@ Automation contains three views:
 
 ### 5.1 Layout
 
-- Remove the persistent left summary/sidebar.
-- Combine summary counts, search, filters, sorting, refresh, add-instance, and batch-mode entry into a compact page header and toolbar.
-- Render nodes in three columns on wide desktop, two columns on medium layouts, and one column on mobile.
+- Preserve the persistent Fleet sidebar on desktop as the primary node directory. It contains the node summary, search, status facets, advanced filters, and active-filter state.
+- Keep sorting, refresh, add-instance, batch-mode entry, and node cards in the main results pane so filtering and results remain visually distinct.
+- At widths above 60rem, use a sticky two-column workspace with a 17rem sidebar that can collapse to a compact 4.5rem rail. At 60rem and below, stack the sidebar above the results and let the existing disclosure control collapse its contents.
+- Render nodes in four columns at 112rem and above, three columns on wide desktop, two columns on medium layouts, and one column on mobile, measured within the available results pane.
 - Keep panel dimensions stable so status changes and progress updates do not shift the grid.
 
 ### 5.2 Node panel
@@ -237,9 +239,11 @@ Requests and responses use strict contracts, bounded arrays/strings, exact-key v
 
 - Real-browser flow for creating, editing, pausing, running, and deleting schedules.
 - Keyboard-only completion of Fleet selection and schedule creation.
-- Screenshots at 390px, 768px, 1024px, and 1440px.
+- Screenshots at 390px, 768px, 1024px, 1440px, and 1920px.
 - No horizontal overflow or overlapping text.
-- Fleet renders one, two, or three columns at the intended widths.
+- Fleet renders one, two, three, or four columns at the intended widths.
+- At 1024px and 1440px, the Fleet summary and search remain in a left-hand sidebar beside the results pane. At 390px and 768px, the sidebar becomes a top disclosure without losing its heading or controls.
+- At 1920px, the Nodes, Automation, and Settings top-level workspaces keep 16px to 24px outer gutters rather than a centered fixed-width shell.
 - Selection controls appear only in batch mode.
 - Reduced-motion and increased-contrast states remain usable.
 - Existing instance actions and deep links remain functional.