Polish futuristic office UI

Author: wangchunji

.kiro/specs/ui-redesign-composer-only-center-input/design.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The home center composer becomes a compact command bar inspired by the provided reference image. It should feel like a lightweight command input floating over the scene, not like a full task card or autopilot dashboard. The right drawer takes over explanatory and contextual content.
+The home center composer remains a compact command bar inspired by the provided reference image, but the surrounding central control area now uses an Ant Design vertical `Splitter`. The upper Splitter panel contains the launch guidance and Support / Logs / Artifacts / Runtime tabs that were previously rendered as a separate bottom panel. The lower Splitter panel contains the compact composer input.
 
 ## Component Strategy
 
@@ -18,27 +18,39 @@ Primary files:
 ## Target Visual Structure
 
 ```text
-rounded translucent composer
-  input row
-    leading spark/icon
-    text input / placeholder
-    send icon button
-  action row
-    add file | cite data | generate report | create task | more
+rounded translucent center control
+  Ant Design Splitter vertical
+    upper panel
+      launch guidance
+      Support / Logs / Artifacts / Runtime tabs
+    lower panel
+      compact composer
+        input row
+          leading spark/icon
+          text input / placeholder
+          send icon button
+        compact controls
+          add files | runtime meta | submit
 ```
 
-The container should use restrained glass styling already present in the project: translucent white, subtle border, blur, and low visual weight.
+The container should use restrained glass styling already present in the project: translucent white, subtle border, blur, and low visual weight. The Splitter handle should be visible enough to indicate resizing without competing with the composer.
 
 ## Data and Interaction
 
-No launch contract changes are planned.
+No launch contract changes are planned. The composer remains the submit surface, while the lower Support tab derives destination preview and route planning from the current launch draft.
 
 ```text
 UnifiedLaunchComposer
   -> attachments
   -> current runtime mode/context
   -> launch/create task flow
   -> existing task/workflow stores
+
+OfficeTaskCockpit central control upper panel
+  -> useNLCommandStore.draftText
+  -> buildLaunchDestinationPreview
+  -> buildLaunchRoutePlan
+  -> LaunchDestinationPreviewCard + RoutePlanningOverlay
 ```
 
 Clarification remains separate:
@@ -52,14 +64,17 @@ currentDialog absent -> composer-only center
 
 Desktop:
 
-- action buttons remain in one row when possible;
+- compact composer controls remain readable;
+- destination preview and route planning stay in the Support tab inside the upper Splitter panel rather than expanding inside the composer;
 - composer max width remains bounded so it does not become a full-width dashboard card.
+- the control panel has a bounded max height so it does not cover the scene or push the composer off-screen.
 
 Tablet/mobile:
 
 - actions can wrap or compact;
 - no text overlap;
 - send button remains visible.
+- the Splitter still stacks support/runtime content above the composer.
 
 ## Testing Strategy
 
@@ -75,6 +90,9 @@ Expected test coverage:
 - composer is bare/dense where appropriate;
 - action controls are visible;
 - large center autopilot guidance is absent by default;
+- central control uses a vertical Splitter and renders the control panel above the composer;
+- destination preview and route planning are absent from the composer surface;
+- destination preview and route planning render in the Support tab when draft text exists;
 - clarification panel only appears when current dialog exists.
 
 ## Non-Goals

.kiro/specs/ui-redesign-composer-only-center-input/requirements.md

@@ -2,23 +2,25 @@
 
 ## Introduction
 
-This follow-up spec covers the home center composer-only input treatment. The user provided a reference image showing a compact rounded composer with a single input row, send button, and action buttons below. The center of the home cockpit should no longer show a large autopilot card. It should keep only the composer surface and let the office scene remain visible.
+This follow-up spec covers the home center command treatment. The user provided a reference image showing a compact rounded composer with a single input row, send button, and action buttons below, then refined the target so the former bottom support/runtime panel moves into the central control area above that input. The center of the home cockpit should use a vertical Ant Design Splitter: support/runtime control above, composer below.
 
 This spec is separate from the home shell spec because the composer visual and interaction details need their own focused acceptance criteria.
 
 ## Requirements
 
-### Requirement 1: Center Shows Only the Composer Surface
+### Requirement 1: Center Uses a Control Splitter Above the Composer
 
-**User Story:** As a user on the home page, I want the center bottom area to show only the command input composer, so the office scene remains visible and uncluttered.
+**User Story:** As a user on the home page, I want the former bottom support panel to live directly above the command input, so the central control area is unified and the input stays immediately reachable.
 
 #### Acceptance Criteria
 
-1. WHEN the home cockpit renders THEN the center-bottom surface SHALL show one compact composer.
-2. WHEN the composer renders THEN it SHALL NOT be accompanied by a large autopilot guidance card in the center.
-3. WHEN launch guidance is needed THEN it SHALL be available through the home right drawer `发起` tab.
-4. WHEN runtime support context is expanded THEN it SHALL not permanently occupy the center as a large default panel.
+1. WHEN the home cockpit renders THEN the center-bottom surface SHALL show one vertical Ant Design Splitter.
+2. WHEN the Splitter renders THEN the upper panel SHALL contain the launch guidance and Support / Logs / Artifacts / Runtime tabs that previously lived in the bottom panel.
+3. WHEN the Splitter renders THEN the lower panel SHALL contain exactly one compact `UnifiedLaunchComposer`.
+4. WHEN the control panel renders THEN it SHALL appear above the composer in DOM order and visual order.
 5. THE composer SHALL remain usable with keyboard input and send action.
+6. WHEN a draft destination exists THEN destination preview and route planning SHALL render in the Support tab inside the central control panel instead of inside the composer surface.
+7. THE implementation SHALL NOT render a second standalone bottom copy of the support/runtime panel below the composer.
 
 ### Requirement 2: Match the Reference Composer Structure
 
@@ -28,7 +30,7 @@ This spec is separate from the home shell spec because the composer visual and i
 
 1. THE composer surface SHALL use a rounded translucent container with restrained shadow and blur.
 2. THE main input row SHALL include a placeholder-style prompt and a send icon/button on the right.
-3. THE secondary action row SHALL include controls equivalent to add file, cite data, generate report, create new task, and more.
+3. THE secondary controls SHALL keep attachment, runtime, and submit access compactly without duplicating lower console actions.
 4. THE action buttons SHALL stay in one compact row on desktop where width allows.
 5. WHEN text is long or viewport narrows THEN controls SHALL wrap or compact without overlapping.
 
@@ -54,7 +56,7 @@ This spec is separate from the home shell spec because the composer visual and i
 1. WHEN clarification is active THEN a clarification surface MAY appear above the composer.
 2. WHEN clarification appears THEN it SHALL be temporary and clearly tied to the current command.
 3. WHEN clarification is not active THEN no clarification panel SHALL occupy center space.
-4. WHEN pending launch exists THEN status MAY be shown compactly in the composer or right drawer.
+4. WHEN pending launch exists THEN status MAY be shown compactly in the composer or lower support tab.
 5. WHEN pending launch resolves THEN focus MAY return to task context without opening a left queue drawer.
 
 ### Requirement 5: Test and Visual Verification
@@ -66,5 +68,7 @@ This spec is separate from the home shell spec because the composer visual and i
 1. THE implementation SHALL include a test asserting exactly one launch composer is rendered.
 2. THE implementation SHALL include a test asserting the large center autopilot panel visual role is absent by default.
 3. THE implementation SHALL include a test or smoke assertion for the composer action controls.
-4. THE implementation SHALL include desktop screenshot review after code changes.
-5. THE progress SVG SHALL be updated after this spec is implemented.
+4. THE implementation SHALL include a test asserting destination preview and route planning are not rendered inside the composer surface.
+5. THE implementation SHALL include a test asserting destination preview and route planning render in the lower Support tab when a draft destination exists.
+6. THE implementation SHALL include desktop screenshot review after code changes.
+7. THE progress SVG SHALL be updated after this spec is implemented.

.kiro/specs/ui-redesign-composer-only-center-input/tasks.md

@@ -2,11 +2,13 @@
 
 ## Tasks
 
-- [ ] 1. Lock composer-only center expectations with tests
+- [x] 1. Lock composer-only center expectations with tests
   - [x] 1.1 Update `OfficeTaskCockpit.test.tsx` to assert exactly one `UnifiedLaunchComposer`.
   - [x] 1.2 Add an assertion that the default center does not render a large autopilot guidance panel.
   - [x] 1.3 Add or update launch tests so key composer actions remain visible.
-  - [ ] 1.4 Run the targeted tests and confirm the large-panel absence assertion fails before implementation if the panel is still present.
+  - [x] 1.4 Run the targeted tests and confirm the large-panel absence assertion fails before implementation if the panel is still present.
+  - [x] 1.5 Add a launch composer test asserting destination preview and route planning are not rendered inside the composer surface.
+  - [x] 1.6 Add an office cockpit test asserting destination preview and route planning render in the lower Support tab when a draft destination exists.
 
 - [x] 2. Simplify the center composer stack
   - [x] 2.1 In `OfficeTaskCockpit.tsx`, keep the composer in the center-bottom launcher stage.
@@ -25,8 +27,19 @@
   - [x] 4.2 Verify create-task access remains present.
   - [x] 4.3 Verify advanced/more actions remain present.
   - [x] 4.4 Verify launch submission uses existing `UnifiedLaunchComposer` behavior.
+  - [x] 4.5 Move destination preview and route planning from the composer surface into the lower Support tab without changing the launch submission path.
 
-- [ ] 5. Verify composer-only center
-  - [x] 5.1 Run `npx vitest run --pool=forks --poolOptions.forks.singleFork client/src/components/office/OfficeTaskCockpit.test.tsx client/src/components/launch/__tests__/LaunchPanelShell.test.tsx client/src/components/launch/__tests__/LaunchPanelIntegration.test.tsx`.
-  - [ ] 5.2 Manually inspect home desktop and confirm the center shows only the compact composer over the scene.
-  - [ ] 5.3 Update the UI progress SVG after implementation.
+- [x] 5. Move the support/runtime panel into the central Splitter
+  - [x] 5.1 Add an `OfficeTaskCockpit.test.tsx` assertion that the central control Splitter exists.
+  - [x] 5.2 Assert the control panel renders above the composer panel in markup order.
+  - [x] 5.3 Import and use Ant Design `Splitter` for the center control area.
+  - [x] 5.4 Move launch guidance and Support / Logs / Artifacts / Runtime tabs into the upper Splitter panel.
+  - [x] 5.5 Keep the compact `UnifiedLaunchComposer` in the lower Splitter panel.
+  - [x] 5.6 Remove the separate standalone bottom support/runtime panel below the composer.
+
+- [ ] 6. Verify composer-centered control area
+  - [x] 6.1 Run `npx vitest run --pool=forks --poolOptions.forks.singleFork client/src/components/office/OfficeTaskCockpit.test.tsx client/src/components/launch/__tests__/LaunchPanelShell.test.tsx client/src/components/launch/__tests__/LaunchPanelIntegration.test.tsx`.
+  - [x] 6.2 Run `npx vitest run --pool=forks --poolOptions.forks.singleFork client/src/components/launch/__tests__/UnifiedLaunchComposer.test.ts client/src/components/office/OfficeTaskCockpit.test.tsx`.
+  - [ ] 6.3 Manually inspect home desktop and confirm the central Splitter shows support/runtime content above the compact composer.
+  - [ ] 6.4 Manually inspect a draft destination and confirm the central Support tab shows destination preview and route planning.
+  - [x] 6.5 Update the UI progress SVG after implementation.

client/src/App.shell-layout.test.tsx

@@ -22,7 +22,9 @@ vi.mock("wouter", () => ({
     component: Component,
     path,
   }: {
-    children?: React.ReactNode | ((params: Record<string, string>) => React.ReactNode);
+    children?:
+      | React.ReactNode
+      | ((params: Record<string, string>) => React.ReactNode);
     component?: React.ComponentType;
     path?: string;
   }) => {
@@ -128,8 +130,8 @@ describe("AppShell fixed sidebar layout", () => {
 
     expect(markup).toContain('data-testid="app-sidebar"');
     expect(markup).toContain('data-testid="tasks-page"');
-    expect(shell).toContain("--sidebar-width:240px");
-    expect(shell).toContain("padding-left:240px");
+    expect(shell).toContain("--sidebar-width:248px");
+    expect(shell).toContain("padding-left:248px");
   });
 
   it("does not offset the home page because it uses embedded scene chrome", () => {

client/src/App.tsx

@@ -43,9 +43,7 @@ function Router() {
       <Route path={"/command-center/legacy"}>
         {() => <LegacyCommandCenterPage />}
       </Route>
-      <Route path={"/command-center"}>
-        {() => <RedirectRoute to="/" />}
-      </Route>
+      <Route path={"/command-center"}>{() => <RedirectRoute to="/" />}</Route>
       <Route path={"/lineage"} component={LineagePage} />
       <Route path={"/404"} component={NotFound} />
       <Route component={NotFound} />
@@ -118,7 +116,7 @@ export function AppShell() {
     setSidebarCollapsed(isTablet);
   }, [isTablet]);
 
-  const sidebarWidth = isMobile ? 0 : sidebarCollapsed ? 64 : 240;
+  const sidebarWidth = isMobile ? 0 : sidebarCollapsed ? 64 : 248;
 
   return (
     <>