docs: refine mobile ui refresh design spec

docs/superpowers/specs/2026-04-01-mobile-ui-refresh-design.md

@@ -2,34 +2,35 @@
 
 ## Goal
 
-Refresh the Flutter mobile app UI so it feels technological and minimal instead of default Material. The redesign should create one coherent visual system across the project list, session list, and terminal page without changing the underlying workflows.
+Refresh the Flutter mobile app UI so it feels technological, fashionable, and minimal instead of default Material. The redesign should create one coherent visual system across the project list, session list, and terminal page without changing layout structure, interaction flow, or underlying workflows.
 
 ## Product Context
 
 - Audience: developers and operators using a phone to connect to a Windows terminal agent remotely
 - Primary jobs: review projects, open sessions quickly, manage active terminal work, and send terminal input reliably
-- Desired tone: technological, calm, precise, minimal, and slightly premium
+- Desired tone: technological, calm, precise, minimal, slightly premium, and intentionally designed
 
 ## Design Direction
 
-Use a restrained future-industrial aesthetic:
+Use a precision-console aesthetic with a light editorial influence:
 
-- Dark graphite surfaces with cool blue-cyan accents
-- Strong typography hierarchy with compact, controlled spacing
-- Thin borders and subtle inner contrast instead of loud shadows
-- Minimal card usage, with sections reading more like instrument panels than consumer tiles
+- Graphite-black surfaces with steel-tinted neutrals instead of pure blue-black panels
+- Small, deliberate electric-blue accents reserved for focus, status, and primary actions
+- Stronger typography rhythm so the product feels designed rather than merely themed
+- Thin structural borders, restrained highlights, and minimal shadow so surfaces read like equipment modules
 - Clear status signaling for connection state, live output, and input mode
 
-This direction fits a remote terminal product better than a generic dashboard or decorative neon style.
+This direction fits a remote terminal product better than either a generic dashboard or a decorative neon sci-fi treatment. The intended result is "high-end control surface" rather than "developer tool with a dark theme."
 
 ## Problems In The Current UI
 
 ### Visual
 
-- The app still uses a near-default `ThemeData(colorSchemeSeed: Colors.blue)` theme.
-- Page structure is mostly standard `Card` plus `ListTile`, so the interface feels generic.
-- Status information, editable settings, and primary actions do not have a clear visual hierarchy.
-- The terminal page has useful controls, but they are visually fragmented and do not read as one work surface.
+- The current dark theme already feels minimal, but not notably fashionable or technological.
+- The app relies on repeated rounded panels with similar treatment, so every section carries the same visual weight.
+- Accent color is present, but it behaves more like generic dashboard decoration than deliberate product branding.
+- Status information, editable settings, and primary actions do not have a strong enough hierarchy.
+- The terminal page has useful controls, but they are visually fragmented and do not read as one focused work surface.
 
 ### UX
 
@@ -48,6 +49,7 @@ This direction fits a remote terminal product better than a generic dashboard or
 - Terminal page visual redesign
 - Shared visual primitives extracted where helpful
 - Improved empty, loading, and error presentation within the touched pages
+- Surface, border, color, typography, and state-treatment updates only
 
 ### Out Of Scope
 
@@ -55,6 +57,9 @@ This direction fits a remote terminal product better than a generic dashboard or
 - New product flows or new backend capabilities
 - Rewriting page navigation structure
 - Major terminal rendering changes inside `xterm`
+- Reordering existing controls
+- Adding or removing actions
+- Changing page composition in a way that alters the current layout model
 
 ## Approach Options
 
@@ -70,7 +75,7 @@ Change the app theme and lightly restyle existing widgets.
 Introduce a custom visual system and recompose the three target pages while preserving behavior.
 
 - Pros: best balance of impact and risk
-- Cons: requires targeted widget restructuring
+- Cons: risks drifting into layout changes if not tightly constrained
 
 ### Option C: Full Design System Pass
 
@@ -81,9 +86,9 @@ Create a broad component library and refactor all touched screens into new reusa
 
 ## Recommended Approach
 
-Choose Option B.
+Choose Option B, but apply it in a layout-preserving way.
 
-It reaches the real goal, which is a visible identity shift, without expanding into a broad refactor. The app only needs a compact shared visual layer and deliberate page composition, not a large design-system project.
+It reaches the real goal, which is a visible identity shift, without expanding into a broad refactor. The app needs a compact shared visual layer and better surface treatment, not new workflows or a broad design-system rewrite.
 
 ## Visual System
 
@@ -92,27 +97,30 @@ It reaches the real goal, which is a visible identity shift, without expanding i
 Build a dark-first palette with tinted neutrals:
 
 - Background: deep graphite, not pure black
-- Surface: slightly elevated steel-gray panels
-- Accent: cool cyan-blue for active controls and highlights
+- Surface: steel-gray and smoke-blue neutrals with subtle tonal separation
+- Accent: small-area electric blue for active controls, focus, and live states
 - Success: restrained mint-green
 - Warning: muted amber
 - Error: controlled red, not saturated orange-red
 
-Color should signal state, not decorate everything. Most surfaces should remain neutral.
+Color should signal state, not decorate everything. Most surfaces should remain neutral and slightly tinted so the interface feels cohesive without looking loud.
 
 ### Typography
 
 Use the default Flutter font stack if introducing a custom font increases delivery risk, but tighten hierarchy through:
 
 - larger, heavier page titles
+- tighter letter spacing for major headings
 - compact supporting metadata
 - stronger small-label usage for state and section headers
+- more intentional contrast between operational text and descriptive text
 
-Typography should carry much of the visual identity because the target style is minimal.
+Typography should carry much of the visual identity because the target style is minimal. The interface should feel more editorial and deliberate without becoming decorative.
 
 ### Shape
 
-- Medium-large corner radius for panels and toolbars
+- Medium corner radius for primary panels and controls
+- Straighter edges for the terminal work surface and dense control zones
 - Pill shapes for compact status chips
 - Thin borders for structure
 - Minimal drop shadows, mostly replaced by tonal contrast and outline separation
@@ -125,11 +133,20 @@ Use denser spacing than default Material while preserving touch comfort:
 - more deliberate separation between sections
 - minimum 44 logical pixels for tappable controls
 
+The rhythm should feel engineered rather than spacious-for-its-own-sake.
+
+### Visual Texture
+
+- Prefer dual-surface layering over heavy shadows
+- Use restrained top-edge highlights or subtle inner separation to give panels more precision
+- Avoid glow, blur, and decorative gradients
+- Let the terminal viewport remain the quietest and darkest region on the screen
+
 ## Screen Designs
 
 ### Project List Page
 
-Restructure the page into three visual layers:
+Keep the existing page structure, but sharpen the three visual layers:
 
 1. A compact top app bar with stronger title styling and clearer secondary actions
 2. A connection panel for the agent URL, styled as an integrated control surface instead of a basic card
@@ -141,6 +158,7 @@ Each project row should include:
 - working directory as compressed secondary metadata
 - a high-priority terminal launch action
 - lower-visual-weight edit and delete actions
+- recent session rows that read as subordinate operational history rather than equal peers to the project itself
 
 Empty state should explain that projects define known working directories for new terminals.
 
@@ -175,6 +193,8 @@ Specific visual goals:
 - turn the input bar into a compact command console instead of a generic form field
 - reduce noisy button chrome while keeping primary actions obvious
 - keep diagnostics and auxiliary tools accessible but secondary
+- make the terminal viewport the dominant visual anchor without changing its placement or behavior
+- make scrollback and mode indicators feel like system states rather than ordinary content blocks
 
 ## Component Strategy
 
@@ -184,6 +204,7 @@ Introduce small shared presentation widgets only where they reduce duplication a
 - status pill
 - empty-state block
 - page header treatment
+- reusable surface styling helpers for primary modules versus subordinate modules
 
 Do not create abstractions for single-use layout fragments.
 
@@ -194,6 +215,7 @@ Do not create abstractions for single-use layout fragments.
 - Keep all existing actions discoverable
 - Make focused and disabled states visibly distinct
 - Avoid motion-heavy effects; use restrained transitions only if they reinforce state
+- Preserve current control locations and interaction sequences so visual polish does not become a behavior change
 
 ## Error, Loading, And Empty States
 
@@ -212,12 +234,15 @@ Validate through:
 ## Risks
 
 - Over-styling the terminal page could reduce readability or control discoverability
+- Chasing fashion too literally could produce decorative noise that weakens the tool-like character
 - Excessive custom components could increase maintenance cost without improving clarity
 - Theme changes may affect existing widget tests that assert text or widget structure
 
 ## Mitigations
 
 - Keep the terminal viewport itself visually quiet
+- Reserve accent color for action and state, not decoration
+- Treat typography and edge treatment as the main source of sophistication
 - Limit new abstractions to repeated presentation patterns
 - Verify the touched tests after implementation
 
@@ -225,6 +250,8 @@ Validate through:
 
 - The app no longer looks like default Flutter Material
 - Project list, session list, and terminal page share one coherent visual language
-- The UI reads as technological and minimal rather than generic or decorative
+- The UI reads as technological, fashionable, and minimal rather than generic or decorative
 - Primary actions are easier to scan than in the current design
+- The terminal page reads as one deliberate workbench instead of separate stacked panels
+- No layout structure or feature behavior changes are introduced
 - Existing behavior remains unchanged