feat(control-plane): promote the personal Agent workspace

.github/workflows/python-tests.yml

@@ -59,6 +59,8 @@ jobs:
         run: python -m mypy
 
       - name: Qualify agent-facing CLI output
+        env:
+          LOOPX_CLI_OUTPUT_BASE_REF: origin/${{ github.event.pull_request.base.ref || 'main' }}
         run: python examples/control_plane/cli-output-budget-regression-smoke.py
 
       - name: Run fast tests

AGENTS.md

@@ -5,9 +5,13 @@
 ### Worktree And PR Gate
 
 For any tracked repository change beyond a trivial typo fix, create or use a
-dedicated clean `git worktree` on a `codex/` branch from latest `origin/main`
-before editing files. Do not implement changes directly in a dirty primary
-worktree, even when the task starts by inspecting that dirty tree.
+dedicated clean `git worktree` on a `codex/` branch. Use latest `origin/main`
+unless the user explicitly names an integration or release branch; in that
+case, fetch that branch and use its latest remote head as both the worktree
+baseline and pull-request base. Before pushing, verify the merge base and PR
+base so unrelated `main` history cannot leak into a stacked integration PR.
+Do not implement changes directly in a dirty primary worktree, even when the
+task starts by inspecting that dirty tree.
 
 When a dirty worktree contains potentially valuable changes, first classify it
 read-only, then copy or reapply the valuable subset into the dedicated clean

README.md

@@ -341,6 +341,7 @@ evidence → recovery; continuation → governance.
 | Quota and interaction contract | Decides whether a turn should deliver, ask, wait, self-repair, or stay quiet. | `loopx quota should-run`, [quota allocation](docs/quota-allocation.md) |
 | Agent runtime bridges | Keeps Codex App, Codex CLI, Claude Code, and generic workers aligned with the same guard. | `loopx heartbeat-prompt`, `loopx codex-cli-bootstrap-message`, `loopx worker-bridge` |
 | Operator surfaces | Renders compact status without making the browser the state authority. | `loopx serve-status`, [dashboard](apps/presentation/dashboard/README.md) |
+| Session dash | Starts a live single-page panel that tracks fleet progress: sessions, their goals, and each goal's status/todo progress, with result statistics; auto-refreshes in place. | `loopx dash`, [session dash design](docs/product/surfaces/session-dash-panel-design.md) |
 | External projections | Projects todos and gates into collaboration surfaces while LoopX remains authoritative. | `loopx lark-kanban`, [Lark Kanban adapter](docs/integrations/lark-kanban-control-plane-adapter.md) |
 | Domain capabilities | Packages repeatable work lanes such as issue fixing, content operations, value connector planning, ML experiment advice, benchmark evidence, and Explore. | `loopx issue-fix`, `loopx content-ops`, `loopx value-connectors`, `loopx ml-experiment`, `loopx benchmark`, [Explore](loopx/capabilities/explore/README.md) |
 | Experimental context learning | Lets named registered agents trial provider-neutral Reward Memory through ignored, default-off project configuration. OpenViking is one provider option, not a global dependency. | `loopx reward-memory experiment-status`, [Reward Memory architecture](loopx/capabilities/reward_memory/README.md) |

apps/presentation/dashboard/README.md

@@ -116,80 +116,57 @@ generated site artifact.
 
 ## Run
 
+From any directory after installing LoopX:
+
+```bash
+loopx dashboard
+```
+
+This command installs the dashboard's npm dependencies on first run, then
+starts the Vite UI together with the loopback status and Chat services. Open
+`http://127.0.0.1:5173/` after the readiness messages appear.
+
+The equivalent source-checkout command remains available for dashboard
+development:
+
 ```bash
 npm ci
 npm run build
 npm run dev
 ```
 
-The default screen is the Chinese-first control-plane home. It is meant to
-answer the operator's first questions before raw status drill-down: which
-project line is active, which user todo is truly blocking, which agent todo is
-high priority, which quota/guard state applies, and what evidence has already
-been written back. It loads the shared global status source by default when the
-loopback global server is available, so multi-project state is visible without
-passing `view=share` or opening a debugging table.
-Because this screen is the operator-facing home, it translates raw machine
-status into Chinese decision copy. Exact tokens such as `single_surface`,
-`focus_wait`, or `quota_slot_spent` may remain useful in `?view=ops` and packet
-drill-downs, but the home should foreground user todos, agent priorities,
-quota guard judgments, and evidence writeback in human-readable terms.
-
-`?view=ops` remains as the explicit detailed workbench. That view keeps the
-legacy operator tools: `Todo Focus`, `User Actions`, `Goal Directory`,
-attention lanes, selected-goal run history, reward dry-run/append controls,
-and raw queue filters. Use it when debugging status contracts, reward overlays,
-or individual queue items; do not treat it as the product's main screen.
-
-The old `view=share` URL value is tolerated as a compatibility alias for the
-main control-plane home, but the dashboard normalizes non-`ops` views out of
-the URL. Browser search parameters such as `actionKind`, `goalId`, `lane`,
-`severity`, `statusUrl`, and `view` are UI state only. They are not approval,
-reward append, controller opt-in, write-control, or durable goal truth.
-
-The detailed ops workbench consumes the same agent-facing
-`loopx status` JSON. Its first-screen action cards can group reward
-gates, controller opt-ins, evidence watches, Codex handoffs, and health blocks;
-each card may expose a safe local path and reward-draft hint. The copied
-handoff remains a short `【GH Packet】` artifact with user todo, gate, safety
-boundary, safe path, command, and project-agent stop rule. It is still a
-handoff artifact; it is not approval, reward append, controller opt-in, or
-write-control.
-
-The selected-goal detail in `?view=ops` starts with `Operator Decision`, which
-turns the selected goal's queue item, lifecycle phase, and readiness gates into
-one of the user-level stances: review or authorize, let Codex continue, wait
-for evidence, or fix health first. That same panel includes a `Safe CLI Path`:
-a local dry-run, history, or status command that matches the current stance. It
-is a bridge from user-facing review to agent-facing CLI execution, not a
-browser write path.
-
-When a selected goal has a compact run record, the run-history panel also shows
-a `Reward CLI Draft`. It is intentionally local-only and defaults to
-`--dry-run`; browser writes to private runtime indexes remain disabled unless
-the local status server explicitly enables the reward write API. Draft defaults
-are derived from the selected `Operator Decision`
-and missing gates, so an evidence watch, controller opt-in, mapped handoff, and
-already-rewarded run start with different decision/reward/reason/follow-up
-values. The operator can still edit or reset the draft before validation.
-
-When the dashboard is loaded from the loopback `Live` source, the same panel can
-send that draft to `POST /reward/dry-run` for local validation. The endpoint
-returns a compact validation result, the Chinese active-state summary Codex can
-write after a real reward append, and the project-agent history command. It
-also returns a `preview_id` that locks the selected goal, run, reward payload,
-and current raw index count.
-If the live server was started with `--enable-reward-write-api`, the dashboard
-can then call `POST /reward/append` for that exact preview. The append writes
-one run-bound `human_reward` overlay, refreshes status, and leaves the compact
-overlay as the source of truth future agents read through `status` or
-`history`.
-Durable reward should be recorded as a run-bound `human_reward` overlay through
-`loopx reward`; active state may summarize the reward afterward, but it
-should not be the only source of truth for multi-agent reward signals.
-When a real CLI append should also update the active goal state, use
-`loopx reward --write-active-state-summary`; the dashboard append path
-sets the same summary-write intent after the operator confirms the preview.
+`npm run dev` starts the Vite UI together with the loopback status and Chat
+services on ports `5173`, `8766`, and `8767`. Use `npm run dev:web` when those
+LoopX services are already running separately. Vite proxies the default
+`/status.json` request to port `8766`, so an SSH user only needs to forward port
+`5173` for the normal development page.
+
+The live `/status.json` route keeps repository-wide public-boundary scanning
+out of the first-screen request. Its contract projection reports that scan as
+deferred; run `loopx check` before publishing or pushing public surfaces to
+perform the complete boundary audit.
+
+The default screen is the Personal Workspace—LoopX's sole operator-facing frontend.
+It provides a unified, coherent experience for managing long-running agent Goals:
+
+- **LoopX Manager Overview (`/`)**:
+  Cross-Goal triage answering operator priorities before raw drill-down:
+  - 4-lane overview flow (`需要你` / `执行中` / `观察中` / `已安排`);
+  - System Health diagnostics highlighting control-plane and registry status;
+  - Unified conversation tray supporting global questions, Goal creation drafts, and progress summaries.
+
+- **Goal Workspace (`/?goalId=<id>`)**:
+  Dedicated workspace for an individual Goal:
+  - **Chat**: Goal-scoped Agent communication, streaming turns, and action previews;
+  - **Tasks**: 4-column kanban board (`待确认`, `待执行 / 进行中`, `定时与持续`, `已完成`) with quick status updates and one-click conversion of Agent replies to Task drafts;
+  - **Files**: Repository artifact browser and file inspects;
+  - **Context Drawer**: Goal diagnosis, repository bindings, Lark Topic connections, and session health.
+
+- **Action Safety & Control Plane**:
+  Durable modifications to Goals, Todos, Heartbeats, monitors, or settings follow the typed preview → explicit user confirmation → verified receipt protocol. The browser never performs unmediated direct writes to control-plane truth.
+
+- **Public Frontstage (`/frontstage`)**:
+  Public `/frontstage` continues to serve as an unauthenticated, read-only showcase and public-safe presentation surface. Real local operator workflows belong exclusively in the Personal Workspace.
 
 ## Load Live Status
 
@@ -281,6 +258,43 @@ local inspection file only. For public demos, use the sanitized
 You can also import a JSON file directly in the browser, or load a local API
 URL that returns the same `loopx --format json status` shape.
 
+## Live Single-Page Session Dash
+
+The primary way to watch session task progress is a loopback single-page panel:
+
+```bash
+loopx dash                 # serve at http://127.0.0.1:8767/ (auto-refresh every 10s)
+loopx dash --goal-id <goal-id>   # narrow the panel to one goal
+```
+
+Open the printed URL in any browser and keep it open while the agents work.
+The page is a human-focused fleet view: an overview strip of sessions, goals,
+active / needs-you / blocked / done buckets, open todos and run statistics,
+followed by one card per session with the goals it owns and each goal's
+status badge, todo progress bar, waiting reason, and latest run. It refreshes
+itself in place every 10 seconds by re-fetching the `/panel` fragment.
+Internal control machinery (decision frames, work-lane contracts, quota slot
+math, source warnings) is intentionally not rendered. The panel is
+read-only: no write controls, no browser write authority. The server binds
+loopback only and exposes no write routes.
+
+A one-shot static snapshot is also available for demos or sharing:
+
+```bash
+loopx dash generate [--goal-id <goal-id>] --out dash.html
+```
+
+Open `dash.html` in any browser. The command runs the public/private
+boundary scan before reporting success and withholds output on failure.
+
+```bash
+# print the projection + html as JSON instead
+loopx --format json dash generate --goal-id <goal-id>
+```
+
+See [the session dash panel design](../../../docs/product/surfaces/session-dash-panel-design.md)
+for the layout, data boundary, and validation contract.
+
 ## Browser Smokes
 
 Dashboard browser smokes are explicit because they start a temporary Vite

apps/presentation/dashboard/chat/index.html

@@ -0,0 +1,22 @@
+<!doctype html>
+<html lang="zh-CN">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <meta name="color-scheme" content="light" />
+    <meta name="theme-color" content="#f7f8f6" />
+    <link
+      rel="icon"
+      href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 32 32'%3E%3Crect width='32' height='32' rx='9' fill='%230f172a'/%3E%3Cpath d='m8 11 8-4 8 4-8 4-8-4Zm0 5 8 4 8-4M8 21l8 4 8-4' fill='none' stroke='white' stroke-width='2' stroke-linejoin='round'/%3E%3C/svg%3E"
+    />
+    <meta
+      name="description"
+      content="LoopX 个人 Agent 工作区：在同一个频道里查看、纠偏并推进 Goal。"
+    />
+    <title>LoopX 个人 Agent 工作区</title>
+  </head>
+  <body>
+    <div id="root"></div>
+    <script type="module" src="../src/chat-main.tsx"></script>
+  </body>
+</html>