@mstar-harness/dsh 3.6.3 → 3.7.0

package/README.md

@@ -39,7 +39,7 @@ dsh plugin --profile web add dsh-llm-fallbacks
 
 The **two-command install is the contract** — folding a `dsh-llm-fallbacks` row into this bundle's patch is explicitly rejected (roadmap §8.3 F4): the loader has no insert-if-absent semantics, so a same-`id` insert is a `duplicate loader entry id` boot failure (the whole dsh session fails to start), and a different-`id` insert mounts the plugin twice — two `apply()` runs with split fallback state (per-context state stores, double listeners, config-override lottery) for anyone who also installs the package directly. Layer order is the reconcile append order: `dsh-llm-fallbacks` lands **after `dsh-base`/`llm-retry`** (its hard ordering requirement) and after the mstar row. Single-command multi-activation is an upstream feature gap (reconcile dedup or insert-if-absent patch semantics), not actionable from this repo.
 
-**What you get with zero configuration** — with BOTH rows installed (via the CLI entry or the two commands above), the mstar plugin declares the 13 `mode: subagent` mstar role seeds (derived from the bundled `harness-agents/` mirror, `project-manager` excluded) into the fallbacks taxonomy at boot: each seeded role's persona defaults to its mirror `description` plus the mandatory role-loading guidance line, the seeded state stays revertible (the `fallbacks/revert-seed` gateway / the settings rollback button), and the runtime advisory reports missing ids and persona overrides. The seeds mechanism is B4 (delivered iter-20260816-dsh-seeds-bridges) — the installed-deployment e2e (`tests/install-e2e.spec.ts`) closes the verification loop: a real `init --target dsh` install into a temp `DSH_HOME`, booted from the installed artifacts, asserts all 13 ids present in the effective taxonomy with non-empty personas. Not included: model routing, automatch dispatch, or the dsh TUI.
+**What you get with zero configuration** — with BOTH rows installed (via the CLI entry or the two commands above), the mstar plugin declares the 13 `mode: subagent` mstar role seeds (derived from the bundled `harness-agents/` mirror, `project-manager` excluded) into the fallbacks taxonomy at boot: each seeded role's persona defaults to its mirror `description` plus the mandatory role-loading guidance line, the seeded state stays revertible (the `fallbacks/revert-seed` gateway / the settings rollback button), and the runtime advisory reports missing ids and persona overrides. The seeds mechanism is B4 — the installed-deployment e2e (`tests/install-e2e.spec.ts`) closes the verification loop: a real `init --target dsh` install into a temp `DSH_HOME`, booted from the installed artifacts, asserts all 13 ids present in the effective taxonomy with non-empty personas. Not included: model routing, automatch dispatch, or the dsh TUI.
 
 > **Fresh-publish age window**: pnpm's `minimumReleaseAge` gate can make a `dsh plugin add <spec>` range resolution pick an older published version (without the seeds surface) for up to ~24h after a fresh publish — re-run `npx @mstar-harness/cli init --target dsh` after the window (or pin the version) to converge on the latest surface.
 
@@ -512,10 +512,8 @@ back-scan of a resumed long log (the server re-emits the row at every turn's
 first step, digest-gated); no custom top-level slot (the `conversation.view`
 tab is the only session-level panel seat available without dsh-private layout
 changes — spec §1). Panel acceptance is dual-track: in-loop browser harness
-verification against the rebuilt bundle (see iteration guides
-`iter-20260810-panel-zones/guides/`) plus user-restart final GUI acceptance —
-rerun steps in the install-verification guide §8. R1 (browser observation)
-closed and archived 2026-08-10.
+verification against the rebuilt bundle plus user-restart final GUI acceptance —
+rerun steps in the install-verification guide §8.
 
 ## Development
 
@@ -578,7 +576,7 @@ The catalog row is appended at the END of the composed step messages, after dele
 - **Iteration stepper: Step 1 is compass-driven, Step 5 is schema-driven** — the zone dashboard's Step 1 (iteration-start) is the current step while the steering compass is `status: active` (Phase 1 in flight — no gate verdict, so no PASS/FAIL badge); Step 5 (merge-ready) is a schema constant the engine gate never lights as current (transition covers Phase 2→3→4 only), so it always renders idle — recorded in the iteration guide, not a defect. The full panel-limitation list lives in the Web client plugin section.
 - **`dsh-llm-fallbacks` is an optional dev-time-only dependency** — dsh natively covers subagent customization, so fallbacks is strictly optional: `src/` carries zero imports of it (runtime and type — the consumed surface is the local structural mirror `fallbacks-structural.ts`, kept in sync by the probe's exact-keys drift gate plus the `typecheck:tests` real → view assignability check), `package.json` carries it only under `devDependencies` (type mirroring + the real-package test harness), and `dist/` carries no import and no type reference (only ONE string literal naming the package — the probe's loader-entry match; the advisory logs say `fallbacks`). Activation is a SEPARATE explicit install (two-command contract), never transitive; there is no `--external` guard anymore — a future value import must re-add a runtime dependency by design.
 - **Role→model override NOT delivered this batch** — routing a role to a fallbacks `model` (or persona via fallbacks rules) would require rewriting the child's `agentOptions` on the start request, but start-request options are caller-controlled (tool-subagent's own Config; call args are `description`/`prompt`/`run_in_background` only, deep-frozen). Awaits upstream `fallbacks-explicit-role-tool` or the N-B1 systemPrompt adoption (roadmap §10.4).
-- **Persona delivery is dsh-native — no additive section** — the role persona merges into `SubagentStartRequest.persona` (one-shot `start` AND the opt-in continuable `startContinuable`) and SHADOWS the deployment persona for role-matched children (child embodies the role; persisted + reapplied on resume). There is NO `mstar:role-persona` system-prompt section anymore (plan 20260831-dsh-alpha2-optional-fallbacks).
+- **Persona delivery is dsh-native — no additive section** — the role persona merges into `SubagentStartRequest.persona` (one-shot `start` AND the opt-in continuable `startContinuable`) and SHADOWS the deployment persona for role-matched children (child embodies the role; persisted + reapplied on resume). There is NO `mstar:role-persona` system-prompt section anymore.
 - **Persona injection is fallbacks-independent** — `dsh-llm-fallbacks` only routes LLM failures; it is never required for persona delivery. Unmounted → the same persona lands via the native channel with the single delivery debug log (AC-4). One-shot starts for providers without the native `persona` capability (out-of-process) skip the persona with one contained debug log; continuable starts for providers without `prepareContinuable` skip it the same way (the native start fails loud on its own) — the start is never failed by the channel for either.
 - **Fork gating is default-only; explicit `dispatchTools` can omit `subagent_fork`** — a custom `dispatchTools` list overrides the default wholesale (pre-existing rename pattern), so a deployment that declares its own list must include `subagent_fork` to keep fork dispatches gated.
 - **Persona values must not contain `{{...}}`** — dsh system-prompt renders persona text with strict `{{variable}}` interpolation and throws on a `{{` paired with a later `}}` (unknown/malformed/undefined reference), which would break child prompt assembly for every role-matched dispatch. The Config schema rejects such `rolePersonas` values at plugin mount with a clear error; the escape rule is single braces or rewording (a lone `{{` with no later `}}` renders as literal prose).

package/README.zh.md

@@ -39,7 +39,7 @@ dsh plugin --profile web add dsh-llm-fallbacks
 
 **双命令安装即契约**——把 `dsh-llm-fallbacks` 行折叠进本 bundle 的补丁**明确否决**（roadmap §8.3 F4）：loader 没有 insert-if-absent 语义，因此同 `id` 插入是 `duplicate loader entry id` 启动失败（整个 dsh 会话无法启动）；异 `id` 插入则插件被挂载两次——对同时直接安装该包的人，会出现两次 `apply()` 与分裂的 fallback 状态（各自独立的 state store、双份监听器、配置覆盖抽签）。层序为 reconcile 追加序：`dsh-llm-fallbacks` 落在 **`dsh-base`/`llm-retry` 之后**（其硬性排序要求）并位于 mstar 行之后。单命令多激活是上游功能缺口（reconcile 去重或 insert-if-absent 补丁语义），本仓库无法实施。
 
-**零配置获得什么**——两条行都装上后（经 CLI 入口或上面两条命令），mstar 插件在 boot 时把 13 个 `mode: subagent` 的 mstar 角色种子（从打包的 `harness-agents/` 镜像派生，排除 `project-manager`）声明进 fallbacks taxonomy：每个 seeded 角色的 persona 默认取其镜像 `description` 外加一行强制角色加载引导；seeded 状态保持可 revert（`fallbacks/revert-seed` 网关 / settings 回滚按钮）；运行时 advisory 报告缺失 id 与 persona 覆盖。该 seeds 机制即 B4（iter-20260816-dsh-seeds-bridges 已交付）——installed-deployment e2e（`tests/install-e2e.spec.ts`）本轮把验证闭环：真实 `init --target dsh` 安装进临时 `DSH_HOME`、从安装产物 boot，断言 13 个 id 全部出现在 effective taxonomy 且 persona 非空。不含模型路由、不含 automatch 派发、不含 dsh-tui。
+**零配置获得什么**——两条行都装上后（经 CLI 入口或上面两条命令），mstar 插件在 boot 时把 13 个 `mode: subagent` 的 mstar 角色种子（从打包的 `harness-agents/` 镜像派生，排除 `project-manager`）声明进 fallbacks taxonomy：每个 seeded 角色的 persona 默认取其镜像 `description` 外加一行强制角色加载引导；seeded 状态保持可 revert（`fallbacks/revert-seed` 网关 / settings 回滚按钮）；运行时 advisory 报告缺失 id 与 persona 覆盖。该 seeds 机制即 B4——installed-deployment e2e（`tests/install-e2e.spec.ts`）本轮把验证闭环：真实 `init --target dsh` 安装进临时 `DSH_HOME`、从安装产物 boot，断言 13 个 id 全部出现在 effective taxonomy 且 persona 非空。不含模型路由、不含 automatch 派发、不含 dsh-tui。
 
 > **fresh publish 年龄窗口提示**：pnpm 的 `minimumReleaseAge` 门禁可能让 `dsh plugin add <spec>` 的 range 解析在全新发布后约 24h 内选中旧版本（不含 seeds surface）——窗口过后重跑 `npx @mstar-harness/cli init --target dsh`（或显式 pin 版本）即可收敛到最新 surface。
 
@@ -290,7 +290,7 @@ dsh web                     # 启动 → 服务 /plugins/@mstar-harness/dsh/clie
 
 本地已验证（install-verification guide）：boot 图包含客户端 entry（`@mstar-harness/dsh` 携声明的 inject 面）、`/plugins/<id>/client.js` 路由服务的正是构建产物（rev = 内容 sha1）、浏览器握手 materialize 出插件入口（`inject` + `apply` + CSS 注入，经典脚本语义）——见 panel-beautify 迭代的 `install-verification.md` guide（本地 harness root）。
 
-**Known Limitations**（本迭代）：迭代 stepper 的 Step 1（iteration-start）在 steering compass `status: active`（Phase 1 进行中——catalog `compassStatus` 字段）时为**当前步**，且不携带 PASS/FAIL 徽标（Phase 1 无 gate 判定）；Step 5（merge-ready）**永远不会是当前步**——engine 相位门只评估 Phase 2→3→4（merge-ready 从不是 gate transition）；仅当 Step 4（pr-delivery）为当前步时渲染 `next`，其余为 idle；当前步跟随 TTL 刷新的 `compassStatus`——会话中途 `active`→`locked` 翻转后最多落后一个 catalog 间隔（60 秒）（有界、已记录的陈旧；绝不给出错误判定）；代理实体状态按**精确配对**派生（paired settle 携带的 `(agent, role, planId, taskId)` 标识精确配对到对应派发——QC tri N=3 并发下各卡各自结算；未配对派发保持 running，绝不捏造）；无 steering compass 时的「当前迭代」过滤按 plan id（8 位日期前缀）+ doneAt 推导迭代——确定性、已记录的启发式，且只丢弃可证明跨迭代的事件）；不回溯 resumed 长日志的历史行（服务端每 turn 首步必重发，digest 门控）；无自定义顶层槽位（不改 dsh-private 布局的前提下，`conversation.view` tab 是唯一的会话级面板位——spec §1）。面板验收为双轨：in-loop 浏览器 harness 验证（对重建 bundle，见迭代 guides `iter-20260810-panel-zones/guides/`）+ 用户重启后 GUI 终验——重跑步骤见 install-verification guide §8。R1（浏览器观察）已于 2026-08-10 关闭归档。
+**Known Limitations**（本迭代）：迭代 stepper 的 Step 1（iteration-start）在 steering compass `status: active`（Phase 1 进行中——catalog `compassStatus` 字段）时为**当前步**，且不携带 PASS/FAIL 徽标（Phase 1 无 gate 判定）；Step 5（merge-ready）**永远不会是当前步**——engine 相位门只评估 Phase 2→3→4（merge-ready 从不是 gate transition）；仅当 Step 4（pr-delivery）为当前步时渲染 `next`，其余为 idle；当前步跟随 TTL 刷新的 `compassStatus`——会话中途 `active`→`locked` 翻转后最多落后一个 catalog 间隔（60 秒）（有界、已记录的陈旧；绝不给出错误判定）；代理实体状态按**精确配对**派生（paired settle 携带的 `(agent, role, planId, taskId)` 标识精确配对到对应派发——QC tri N=3 并发下各卡各自结算；未配对派发保持 running，绝不捏造）；无 steering compass 时的「当前迭代」过滤按 plan id（8 位日期前缀）+ doneAt 推导迭代——确定性、已记录的启发式，且只丢弃可证明跨迭代的事件）；不回溯 resumed 长日志的历史行（服务端每 turn 首步必重发，digest 门控）；无自定义顶层槽位（不改 dsh-private 布局的前提下，`conversation.view` tab 是唯一的会话级面板位——spec §1）。面板验收为双轨：in-loop 浏览器 harness 验证（对重建 bundle）+ 用户重启后 GUI 终验——重跑步骤见 install-verification guide §8。
 
 ## Development
 
@@ -350,7 +350,7 @@ catalog 行在委托之后追加到组合步骤消息的**末尾**——请求
 - **迭代 stepper：Step 1 为 compass 驱动，Step 5 为 schema 驱动**——zone dashboard 的 Step 1（iteration-start）在 steering compass `status: active`（Phase 1 进行中）时为当前步（无 gate 判定 → 无 PASS/FAIL 徽标）；Step 5（merge-ready）是 engine 闸门永不点亮为当前的 schema 常量（transition 只覆盖 Phase 2→3→4，merge-ready 从不是 gate transition）；仅当 Step 4 为当前步时作为 `next` 渲染，其余为 idle——已记录于迭代 guide，非缺陷。完整面板限制清单见 Web 客户端插件一节。
 - **`dsh-llm-fallbacks` 为可选的开发期依赖**——dsh 原生覆盖 subagent 定制，fallbacks 因此严格可选：`src/` 对其零导入（运行时与类型——被消费面是本地结构镜像 `fallbacks-structural.ts`，由探测的 exact-keys 漂移闸门 + `typecheck:tests` 的 real → view 可赋值检查保持同步），`package.json` 仅在 `devDependencies` 携带它（类型镜像 + 真实包测试 harness），`dist/` 无导入也无类型引用（仅 1 处命名该包的字符串字面量——探测的 loader 条目匹配；建议日志写作 `fallbacks`）。激活是**单独显式安装**（双命令契约），绝不传递；不再有 `--external` 护栏——未来的值导入必须按设计重新加入运行时依赖。
 - **本批次未交付角色→模型覆盖**——把角色路由到 fallbacks `model`（或经 fallbacks 规则路由 persona）需要改写启动请求上的子会话 `agentOptions`，但启动请求选项由调用方控制（tool-subagent 自己的 Config；调用参数仅为 `description`/`prompt`/`run_in_background`，且深度冻结）。等待上游 `fallbacks-explicit-role-tool` 或 N-B1 systemPrompt 采纳（roadmap §10.4）。
-- **persona 交付为 dsh 原生——不再有附加段**——角色 persona 合入 `SubagentStartRequest.persona`（一次性 `start` 与可选的 continuable `startContinuable` 两个启动面），对角色匹配的子会话**遮蔽**部署 persona（子会话体现角色；持久化并在 resume 时重放）。`mstar:role-persona` system-prompt 段已不复存在（plan 20260831-dsh-alpha2-optional-fallbacks）。
+- **persona 交付为 dsh 原生——不再有附加段**——角色 persona 合入 `SubagentStartRequest.persona`（一次性 `start` 与可选的 continuable `startContinuable` 两个启动面），对角色匹配的子会话**遮蔽**部署 persona（子会话体现角色；持久化并在 resume 时重放）。`mstar:role-persona` system-prompt 段已不复存在。
 - **persona 注入与 fallbacks 无关**——`dsh-llm-fallbacks` 只路由 LLM 失败；persona 交付从不依赖它。未挂载 → 同一 persona 经原生通道交付，仅一条交付 debug 日志（AC-4）。一次性 start 中不具备原生 `persona` 能力的提供者（进程外）以一条受控 debug 日志跳过 persona；continuable start 中不具备 `prepareContinuable` 的提供者同样跳过（原生 start 会自行 fail loud）——通道绝不因两者使 start 失败。
 - **fork 门禁仅默认开启；显式 `dispatchTools` 可省略 `subagent_fork`**——自定义 `dispatchTools` 列表整体覆盖默认（既有重命名模式），因此自行声明列表的部署须包含 `subagent_fork` 才能继续门禁 fork 派发。
 - **persona 值绝不能包含 `{{...}}`**——dsh system-prompt 以严格 `{{variable}}` 插值渲染 persona 文本，对与后文 `}}` 配对的 `{{`（未知/畸形/未定义引用）直接抛错，会破坏每一次角色匹配派发的子会话提示组装。Config schema 在插件挂载时以清晰报错拒绝此类 `rolePersonas` 值；转义规则是改用单花括号或改写措辞（不带后续 `}}` 的孤立 `{{` 按字面散文渲染）。

package/dist/client/panel/PanelView.d.ts

@@ -7,7 +7,7 @@
  * `useMstarEngineStatus()` hook riding the kit's `useChat` selector (spec
  * §5) — the render body is a pure function of (source, lastUpdated, t).
  *
- * Layout (spec panel-tabs §2, plan 20260811-panel-tabs-shell): root grid
+ * Layout (spec panel-tabs §2): root grid
  * `"main sidebar"` fills the Tab (height 100%, overflow hidden — the page
  * never scrolls); the right sidebar is RESIDENT (all tabs share it, its props
  * `{ t, state, source }` unchanged); main = the fixed header nav (TabNav, 3
@@ -19,18 +19,17 @@
  * Tab state (spec §6.2): local `useState<PanelTab>` (default 'tasks', D1, no
  * routing) — `renderToStaticMarkup` renders the default tasks page, keeping
  * SSR assertions stable. The tasks tab renders the IterationTaskPage (Content
- * Head + Steps 横排/收拢 + full-width kanban, spec §3 — landed with Task 2,
+ * Head + Steps 横排/收拢 + full-width kanban, spec §3 —
  * replacing the WorkflowCanvas zone dashboard); the agents tab renders the
- * draggable AgentCanvasPage (spec §4 — landed with the agent-canvas plan,
- * replacing the muted placeholder + the AgentFlowZone); the events tab
+ * draggable AgentCanvasPage (spec §4 — replacing the muted placeholder + the AgentFlowZone); the events tab
  * renders the EventLogPage (spec §5 — the non-canvas log page with per-row
- * `<details>` expansion, landed with the event-log plan Task 2, replacing
+ * `<details>` expansion, replacing
  * the muted placeholder AND the AgentEventDock — 无双份日志).
  *
  * Empty branches (spec §2): waiting / no-harness render no tabs / no
  * sidebar. Waiting keeps the muted hint; the no-harness branch renders a
  * CENTERED inactive-state card (icon + title + hint, plan
- * 20260812-panel-f5-agent-layout T3 — replaces the left-aligned hint) with
+ *  T3 — replaces the left-aligned hint) with
  * the freshness footer; the no-harness main keeps `data-mstar-graph` on its
  * content container. Degradation stays total: `projectGraph` never throws;
  * no iteration → the IterationTaskPage's collapsed muted head (spec §8);
@@ -53,14 +52,12 @@ export interface PanelContentProps {
 /**
  * Tab → page mapping (spec §6.2): the only per-tab-switching part of the
  * layout. tasks = the IterationTaskPage (spec §3 — Content Head + Steps
- * 横排/收拢 + full-width kanban, landed with Task 2; it replaced the
+ * 横排/收拢 + full-width kanban, it replaced the
  * WorkflowCanvas zone dashboard, whose file is removed by the plan close);
  * agents = the draggable AgentCanvasPage (spec §4 — full KNOWN_AGENTS roster
- * + idle states + AgentEdge collaboration edges, landed with the agent-canvas
- * plan; it replaced the muted placeholder and the AgentFlowZone); events =
+ * + idle states + AgentEdge collaboration edges; it replaced the muted placeholder and the AgentFlowZone); events =
  * the real EventLogPage (spec §5 — non-canvas log page: Agent 流转事件 +
- * 违规记录 partitions with per-row `<details>` expansion, landed with the
- * event-log plan Task 2; it replaced the muted placeholder AND the
+ * 违规记录 partitions with per-row `<details>` expansion; it replaced the muted placeholder AND the
  * AgentEventDock — 无双份日志, the dock is removed with this plan).
  */
 export declare function PanelContent({ tab, source, t }: PanelContentProps): React.JSX.Element;

package/dist/client/panel/TabNav.d.ts

@@ -1,5 +1,5 @@
 /**
- * TabNav (spec panel-tabs §2/§6.1, plan 20260811-panel-tabs-shell Task 1) —
+ * TabNav (spec panel-tabs §2/§6.1) —
  * the fixed header nav: 3 MenuTabs (任务迭代 / 代理执行 / 事件记录, F1.2)
  * switching the main content. Tab state is owned by PanelView
  * (`useState<PanelTab>`, default 'tasks', no routing — SSR-stable under
@@ -10,7 +10,7 @@
  * every tab and `data-mstar-tab-active="true|false"` (activation state). The
  * active tab gets the business-token underline; inactive tabs stay secondary.
  *
- * A11y (QC wave): the nav is a WAI-ARIA tablist and each tab is a
+ * A11y: the nav is a WAI-ARIA tablist and each tab is a
  * `role="tab"` button with `aria-selected` (APG Tabs pattern, replacing the
  * former `aria-pressed` toggle). Deliberately minimal: every tab stays Tab-
  * reachable (no roving tabindex / arrow-key handling — that behavior would

package/dist/client/panel/graph/event-log.d.ts

@@ -1,8 +1,7 @@
 /**
- * Event-log entry assembly (spec panel-tabs §5 — plan 20260811-panel-event-log
- * Task 1): `eventLogEntries(view)` turns the projected `ZoneView` slices
+ * Event-log entry assembly (spec panel-tabs §5): `eventLogEntries(view)` turns the projected `ZoneView` slices
  * (`events` / `violations`) into display-ready log entries for the 事件记录
- * tab (`EventLogPage`, Task 2). A pure function over the projection output —
+ * tab (`EventLogPage`). A pure function over the projection output —
  * the projection interfaces (`ZoneView` / `FlowEventView` / `GraphViolation`)
  * are consumed unchanged, ZERO projection changes.
  *
@@ -17,8 +16,7 @@
  *   re-implemented). Off-pipeline (unexpected) DISPATCHES fold in via
  *   `expected: false`: `view.unexpected` is a RE-LIST of rows already inside
  *   `view.events`, so reading it here would double-append — the page decides
- *   how to section/badge them. Workflow rows (plan `20260815-dsh-workflow-ledger`
- *   Task 4) carry the run identity (`runId` / `name` — agent/end rows resolve
+ *   how to section/badge them. Workflow rows  carry the run identity (`runId` / `name` — agent/end rows resolve
  *   the run's name from the window's workflow-run row); unknown kinds pass
  *   through as generic rows (`name` '' — never fabricated).
  * - `violation` rows — `view.violations` (gate violations, str()-guarded)
@@ -26,8 +24,7 @@
  *   partition.
  */
 import type { FlowEventStatus, FlowEventView, ZoneView } from './project-graph.ts';
-/** The three workflow ledger kinds (plan `20260815-dsh-workflow-ledger` W-B2). */
-export declare function isWorkflowKind(kind: FlowEventView['kind']): boolean;
+/** The three workflow ledger kinds */ export declare function isWorkflowKind(kind: FlowEventView['kind']): boolean;
 /** One agent-flow event row: the log's 流转事件 partition (spec §5). */
 export interface EventLogEventEntry {
     /** Entry discriminator — this row is an agent-flow event. */
@@ -57,8 +54,7 @@ export interface EventLogEventEntry {
     /** Workflow run id (workflow-* + unknown rows, when carried); '' otherwise. */
     runId: string;
     /**
-     * The workflow run's display name (plan `20260815-dsh-workflow-ledger`
-     * Task 4): the workflow-run row carries its own name; workflow-agent /
+     * The workflow run's display name : the workflow-run row carries its own name; workflow-agent /
      * workflow-run-end rows resolve the run's name from the window's
      * workflow-run row (same runId — honest, the ledger row itself carries no
      * name); '' when not a workflow row or the run row is truncated out.

package/dist/client/panel/graph/project-graph.d.ts

@@ -9,18 +9,16 @@
  * Two strictly separated inputs (spec §3):
  * - schema constants (`./schema.ts`) — the 5 iteration steps (PHASE_IDS), the
  *   5 kanban buckets (PLAN_STATE_IDS — Blocked/unknown merged into
- *   `blocked-unknown`, plan 20260813-panel-quick-fixes Task 1) and the
+ *   `blocked-unknown`) and the
  *   expected role pipeline (EXPECTED_ROLE_FLOW), all client-side design
  *   knowledge;
  * - catalog evidence — `iteration.gate.transition` lights the current step
- *   (steps before it become `done` — plan 20260812-panel-f5-iteration-zone-fix
- *   Task 1, its forward target becomes `next`), `gate.ok/violations` become
+ *   (steps before it become `done`, its forward target becomes `next`), `gate.ok/violations` become
  *   the PASS/FAIL verdict + count, and `state.plans[].status` rows fall into
  *   the exact-match kanban buckets. `iteration.compassStatus` (the steering
  *   compass frontmatter `status`, `'active' | 'locked'` — spec panel-f4 §2.3
  *   R9 / §5 D5) re-derives the current step during Phase 1: `'active'` WITH a
- *   `phase-2-execute` transition (compass and gate mutually consistent — QC
- *   wave F-001) → Step 1 (iteration-start) is current with verdict 'unknown'
+ *   `phase-2-execute` transition (compass and gate mutually consistent) → Step 1 (iteration-start) is current with verdict 'unknown'
  *   (Phase 1 has no gate evaluation → no PASS/FAIL badge) + next Step 2;
  *   `'active'` with a transition past Phase 2 (an inconsistent harness
  *   state), `'locked'`, or missing → the transition-driven logic below
@@ -40,26 +38,21 @@
  *   / truncated`, `agents` (entities + actual/supervise edges + executing/
  *   pending counts — spec §4).
  *
- * Agent-entity semantics (plan 20260811-panel-f3-agent-general — the
- * per-role aggregation refactor): entities aggregate by ROLE, not by session
+ * Agent-entity semantics (the per-role aggregation): entities aggregate by ROLE, not by session
  * — a KNOWN_AGENTS roster role keys its own card (same role across sessions
  * folds into one card ×N), and EVERY non-roster dispatch (`scout`,
  * unregistered roles, anonymous `role === ''`) folds into the single
  * `general` bucket entity (key `'general'`, role shown `'general'`). The
  * legacy `unexpected` zone is GONE — stage-null non-on-demand entities now
- * project `zone: 'general'`. Placement (plan 20260812-panel-f5-agent-layout
- * Task 1, user 2026-08-12): the projection only declares the zone — the
+ * project `zone: 'general'`. Placement: the projection only declares the zone — the
  * RENDER places `zone: 'general'` entities in an unknown sub-partition at
- * the bottom of the LAST column (plan 20260812-panel-f5-design-system Task
- * 5, user 2026-08-12 feedback #3 — the standalone rightmost unknown column
+ * the bottom of the LAST column (the standalone rightmost unknown column
  * is superseded: 4 columns total). The SDD loop back-edge (sdd-implement →
- * general) stays REMOVED from the projection (plan 20260811-panel-f4-agent-view
- * Task 1); the F5 supervise line is a SEPARATE sub-bucket edge
+ * general) stays REMOVED from the projection; the supervise line is a SEPARATE sub-bucket edge
  * (`kind: 'supervise'`, see `superviseEdges`). The event-log `unexpected`
  * badge is a SEPARATE, unchanged semantic (`expected` ⟺ role ∈
  * EXPECTED_ROLE_FLOW union). The `sdd-implement` column is further split
- * into implementor / reviewer SUB-BUCKETS (plan 20260812-panel-f5-agent-layout
- * Task 1): every entity carries a projected `bucket` field ('implementor' /
+ * into implementor / reviewer SUB-BUCKETS: every entity carries a projected `bucket` field ('implementor' /
  * 'reviewer' / null via SDD_BUCKET_ROLES — a layout dimension ORTHOGONAL to
  * expectedness: on-demand roles keep their `unexpected` badge inside the
  * implementor bucket).
@@ -74,12 +67,11 @@
  * missing/unreadable → agents roster + `degraded` (full KNOWN_AGENTS idle
  * cards, no executing/pending claims); 0 events → `empty` (idle roster +
  * pending skeleton). `state.project` missing/malformed → the additive
- * project rollup zone (compass AC-4) degrades to empty aggregates — the
+ * project rollup zone degrades to empty aggregates — the
  * four existing ZoneView shapes are unaffected. `iteration.compassStatus`
  * missing, non-union (old catalog rows / fixtures — the field is OPTIONAL,
  * spec D5), or `'active'`
- * with a transition past Phase 2 (an inconsistent harness state — QC wave
- * F-001) degrades to the existing transition-driven current-step logic
+ * with a transition past Phase 2 (an inconsistent harness state) degrades to the existing transition-driven current-step logic
  * (Step 2→4) — backward compatible, `active` semantics unchanged.
  */
 import type { MstarEngineStatusSource } from '../../../types.ts';
@@ -96,8 +88,8 @@ export interface GraphViolation {
 export type FlowEventStatus = 'dispatched' | 'advisory' | 'denied' | 'ok' | 'error' | 'unknown';
 /**
  * One projected agent-flow event (spec agent-flow-catalog-graph §2.4 —
- * unchanged by the zone refactor; plan `20260815-dsh-workflow-ledger` Task 4
- * adds the workflow kinds + the unknown-kind degradation path). Every field
+ * unchanged by the zone refactor; the workflow-ledger source adds the
+ * workflow kinds + the unknown-kind degradation path). Every field
  * degrades individually via `guards.ts` — a missing/illegal value becomes
  * `null`/''/`0`/a base status, never a throw and never a guessed value.
  * Dispatch/settle rows keep their gate semantics; the three WORKFLOW kinds
@@ -128,7 +120,7 @@ export interface FlowEventView {
     } | null;
     /** dispatch: has an EXACT-identity-paired settle (exact pairing; an unpaired settle stays unpaired — honest); settle: always false. */
     settled: boolean;
-    /** Settle rows only (plan `20260811-panel-f4-timeliness` Task 1): the settle carries the PAIRED dispatch's identity (exact pairing). */
+    /** Settle rows only: the settle carries the PAIRED dispatch's identity (exact pairing). */
     paired?: boolean;
     durationMs: number | null;
     /** Workflow run identity (workflow-* + unknown rows, when carried; absent otherwise). */
@@ -149,10 +141,9 @@ export interface FlowEventView {
     readonly stopReason?: string;
 }
 /**
- * One iteration step (spec §3 + plan 20260812-panel-f5-iteration-zone-fix
- * Task 1): the PHASE_IDS skeleton with current/next/done/idle lit by
+ * One iteration step (spec §3): the PHASE_IDS skeleton with current/next/done/idle lit by
  * `gate.transition` evidence — the CURRENT step, its forward target (`next`)
- * and every step BEFORE it (`done` — completed: the Task 1 fix, a finished
+ * and every step BEFORE it (`done` — completed: a finished
  * Step 1 must not read as idle「待命」 while Step 2 is current). The `step`
  * number is 1-based (1..5). `verdict` is carried by the CURRENT step only.
  */
@@ -167,7 +158,7 @@ export interface IterationStepView {
     verdict: PhaseVerdict;
 }
 /**
- * One kanban column (spec §3 + plan 20260813-panel-quick-fixes Task 1): the
+ * One kanban column (spec §3): the
  * PLAN_STATE_IDS skeleton with plan rows bucketed by status — `Blocked` and
  * any non-matching status (the former `unknown` catch-all) both fold into the
  * single `blocked-unknown` column. `count` is the FULL column count; `plans`
@@ -209,7 +200,7 @@ export interface AgentZoneStage {
     evidenced: boolean;
 }
 /**
- * One agent entity card (spec §4 + §6.2 + plan 20260811-panel-f3-agent-general):
+ * One agent entity card (spec §4 + §6.2):
  * either a ROLE aggregated across its dispatch rows (count + latest ts;
  * identity fields reflect the LATEST dispatch — the same dispatch that
  * decides the status; `agent` / `task` are record fields, never the title)
@@ -222,7 +213,7 @@ export interface AgentEntityView {
     /**
      * THE ROLE id for lit cards (KNOWN_AGENTS membership — `general` for every
      * non-roster dispatch); the KNOWN_AGENTS role id for idle cards. INVARIANT
-     * (spec §6.2, F-001): keys are UNIQUE across the whole `entities` array —
+     * (spec §6.2): keys are UNIQUE across the whole `entities` array —
      * an evidence-derived `general` key suppresses the idle general twin in
      * `idleEntities`, so the React `key` / `layoutAgents` `cards.set` never see
      * duplicates.
@@ -250,22 +241,20 @@ export interface AgentEntityView {
         phase: PhaseId;
         stage: string;
     } | null;
-    /** Column zone (plan 20260811-panel-f3-agent-general — projection-owned,
+    /** Column zone (projection-owned,
      * the render NEVER heuristically guesses): 'flow' (stage columns), 'on-demand'
      * (ops-engineer / prompt-engineer — implementor-sub-bucket dispatches with
-     * an on-demand badge; the standalone on-demand column is REMOVED, plan
-     * 20260812-panel-f5-agent-layout Task 2) or 'general' (the general bucket —
-     * the rightmost UNKNOWN column, Task 2). Derived from the role for lit
-     * cards, from the KnownAgent `zone` for idle cards. */
+     * an on-demand badge; the standalone on-demand column is REMOVED) or
+     * 'general' (the general bucket — the rightmost unknown column). Derived
+     * from the role for lit cards, from the KnownAgent `zone` for idle cards. */
     zone: AgentZone;
-    /** SDD sub-bucket (plan 20260812-panel-f5-agent-layout Task 1 —
-     * projection-derived, the render ONLY consumes it): role ∈
+    /** SDD sub-bucket (projection-derived, the render ONLY consumes it): role ∈
      * SDD_BUCKET_ROLES.implementor → 'implementor' (incl. on-demand roles),
      * role ∈ SDD_BUCKET_ROLES.reviewer → 'reviewer' (code-reviewer); every
      * other role (qc/qa/review-edit-chain/general) → null. Same rule for idle
      * cards (KNOWN_AGENTS id → SDD_BUCKET_ROLES lookup). */
     bucket: AgentBucket | null;
-    /** Transparency tier (plan 20260812-panel-f5-design-system Task 4 — the
+    /** Transparency tier (the
      * TIME dimension, design doc §3): the iteration's current phase vs the
      * entity's pipeline-stage phase — 'current' (chrome full-strength), 'next'
      * (mid transparency), 'off' (low transparency — passed phases, on-demand /
@@ -275,13 +264,13 @@ export interface AgentEntityView {
      * point and the running ring/glow NEVER fade (design doc §3.4 HARD). */
     emphasis: AgentEmphasis;
 }
-/** The SDD sub-bucket a role belongs to within the `sdd-implement` column
- * (plan 20260812-panel-f5-agent-layout Task 1): 'implementor' | 'reviewer';
+/** The SDD sub-bucket a role belongs to within the `sdd-implement` column:
+ * 'implementor' | 'reviewer';
  * roles in neither bucket project `null`. The bucket is a LAYOUT dimension,
  * ORTHOGONAL to expectedness (SDD_BUCKET_ROLES vs EXPECTED_ROLE_FLOW — an
  * on-demand role in the implementor bucket stays OUTSIDE the expected union). */
 export type AgentBucket = 'implementor' | 'reviewer';
-/** Transparency tier (plan 20260812-panel-f5-design-system Task 4 — design
+/** Transparency tier (design
  * doc §3.1): the TIME dimension of an entity — the iteration's current phase
  * vs the entity's pipeline-stage phase. 'current' → chrome full-strength,
  * 'next' → mid transparency (expected but not yet), 'off' → low transparency
@@ -289,8 +278,7 @@ export type AgentBucket = 'implementor' | 'reviewer';
  * no iteration/plan (NO override — the render keeps the idle status quo). */
 export type AgentEmphasis = 'current' | 'next' | 'off' | null;
 /**
- * Entity status (spec §4, hardcoded priority; plan
- * 20260813-panel-quick-fixes Task 2): `denied` comes from the LATEST dispatch's
+ * Entity status (spec §4, hardcoded priority): `denied` comes from the LATEST dispatch's
  * verdict (the only terminal verdict — settle-independent); `error`/`settled`
  * come from the settle paired with that dispatch; `running` = no paired settle
  * yet (exact identity pairing — an unpaired settle stays unpaired, honest);
@@ -303,23 +291,22 @@ export type AgentEmphasis = 'current' | 'next' | 'off' | null;
 export type AgentEntityStatus = 'running' | 'settled' | 'error' | 'denied'
 /** Retained for shape compat; the derivation (entityStatus) no longer emits it. */
  | 'advisory' | 'idle';
-/** Edge kinds (spec §4 + plan 20260812-panel-f5-design-system Task 5 — the
- * 2026-08-12 finalized line semantics, design doc §2.2): handoff / sub-bucket
+/** Edge kinds (spec §4 — the finalized line semantics, design doc §2.2): handoff / sub-bucket
  * supervision arrows. `expected` (stage skeleton) and `next` (running
  * animation) are REMOVED — the column order implies the flow, the running
- * card glow/status point carries the position (user feedback #1/#5). */
+ * card glow/status point carries the position. */
 export type AgentEdgeKind = 'actual' | 'supervise';
 /**
- * One agents-zone arrow (spec §4 + plan 20260812-panel-f5-agent-layout Task
- * 1 + plan 20260812-panel-f5-design-system Task 5):
+ * One agents-zone arrow (spec §4):
  * - `actual`: same-plan handoff between ts-adjacent dispatch ENTITY keys
- *   (source/target = entity key — role-based since plan
- *   20260811-panel-f3-agent-general). Task 5 filters general-bucket endpoints
+ *   (source/target = entity key — role-based). The line set filters
+ *   general-bucket endpoints
  *   (a general handoff is noise, not a meaningful transfer) and keeps at most
  *   ONE edge per entity-key pair (the latest direction) — design doc §2.2;
  * - `supervise`: ONE static sub-bucket line inside the `sdd-implement`
- *   column — implementor ↔ reviewer mutual supervision (mstar-sdd contract;
- *   the render draws it as a bidirectional double arrow, Task 2).
+ *   column — implementor ↔ reviewer mutual supervision (the mstar-sdd
+ *   mutual-supervision contract; the render draws it as a bidirectional
+ *   double arrow).
  *   source/target embed the column id as an anchor prefix:
  *   `<stage-id>:implementor` / `<stage-id>:reviewer`. NOT per-entity pairs —
  *   drawing per-role pairs would fabricate concrete supervision relations
@@ -333,17 +320,17 @@ export interface AgentEdge {
     /** actual: entity key; supervise: `<stage-id>:implementor|reviewer`. */
     source: string;
     target: string;
-    /** Unused by the Task 5 line set (the removed `next` arrow carried the
+    /** Unused by the line edge set (the removed `next` arrow carried the
      * running entity key); kept for shape stability — always null. */
     entityKey: string | null;
-    /** Supervise edges only (plan 20260812-panel-f5-agent-layout Task 1):
+    /** Supervise edges only:
      * evidence-driven lighting — true when any dispatch row's role belongs to
      * an SDD sub-bucket (implementor ∪ reviewer), false otherwise (dim).
      * Absent (undefined) for actual. */
     evidenced?: boolean;
 }
 /**
- * The canvas degradation-note classification (spec §8, F-002): the projection
+ * The canvas degradation-note classification (spec §8): the projection
  * decides the note from the RAW ledger (never a UI-side heuristic on the
  * entity list): `empty` = 0 events; `settle-only` = events present but NO
  * dispatch row (all settle / garbage rows — genuinely no dispatch evidence);
@@ -369,7 +356,7 @@ export interface AgentZoneView {
     degraded: boolean;
     /** `state.agentFlow` present but 0 events (recording started at plan merge). */
     empty: boolean;
-    /** The projected canvas note (spec §8, F-002 — see `AgentZoneNote`). */
+    /** The projected canvas note (spec §8 — see `AgentZoneNote`). */
     note: AgentZoneNote;
     /** Evidence-derived dispatch entities ∪ idle KNOWN_AGENTS cards — the full roster is NEVER hidden (spec §6.2). */
     entities: readonly AgentEntityView[];
@@ -380,9 +367,8 @@ export interface AgentZoneView {
     /** Sum of expected roles of stages with no dispatch evidence — the summary "M 待执行". */
     pending: number;
     /** The FIRST `state.plans[]` row with status 'InProgress' (catalog order);
-     * null when no plan is in progress (plan 20260812-panel-f5-design-system
-     * Task 8 — the Phase 2 group's current-plan annotation, user 2026-08-12
-     * feedback #2). Total function: state/plans missing or no InProgress row →
+     * null when no plan is in progress (the current-plan group annotation).
+     * Total function: state/plans missing or no InProgress row →
      * null (never fabricated). */
     activePlanId: string | null;
     /** How many `state.plans[]` rows are InProgress (the render shows
@@ -391,9 +377,8 @@ export interface AgentZoneView {
     activePlanCount: number;
 }
 /**
- * The additive project rollup zone (plan `20260819-workflow-dsh-viz`
- * Task 3 — compass v3.0.0 AC-4: "Additive project rollup (roadmap +
- * residuals) renders without changing the four existing ZoneView shapes"):
+ * The additive project rollup zone: additive project rollup (roadmap +
+ * residuals) renders without changing the four existing ZoneView shapes —
  * roadmap milestones + open-residual severity counts from the project layer
  * (`state.project` — produced by the catalog from `projects/<id>/roadmap.md`
  * frontmatter `milestones[]` + `projects/<id>/residuals.json` registers).
@@ -438,7 +423,7 @@ export interface ZoneView {
         truncated: boolean;
     };
     agents: AgentZoneView;
-    /** The additive project rollup zone (compass AC-4 — roadmap milestones +
+    /** The additive project rollup zone (roadmap milestones +
      * open residual severity counts from `state.project`; additive, the four
      * existing ZoneView shapes stay byte-compatible). */
     project: ProjectRollupZoneView;
@@ -461,8 +446,7 @@ export declare function projectGraph(source: MstarEngineStatusSource | null): Zo
  * `projectAgents(source, currentStep): AgentZoneView` — the agents zone (spec
  * §4 + §6.2). `currentStep` is the ITERATION's current step (1-based into
  * PHASE_IDS, null when inactive — already computed by `projectGraph`, spec
- * §3): it drives each entity's `emphasis` tier (plan
- * 20260812-panel-f5-design-system Task 4 — design doc §3.3; `null` → every
+ * §3): it drives each entity's `emphasis` tier (design doc §3.3; `null` → every
  * entity `emphasis: null`, no override).
  * Total function: NEVER throws and NEVER fabricates values:
  *
@@ -475,12 +459,11 @@ export declare function projectGraph(source: MstarEngineStatusSource | null): Zo
  * - otherwise: entities aggregated from dispatch rows (with `idle: false`),
  *   statuses via the shared pairing walk, the un-evidenced KNOWN_AGENTS
  *   members appended as idle cards, actual/supervise edges (design doc §2.2 —
- *   the `expected` skeleton and `next` animation edges are REMOVED by plan
- *   20260812-panel-f5-design-system Task 5), and the
+ *   the `expected` skeleton and `next` animation edges are REMOVED), and the
  *   executing (running entities — idle never counts) / pending
  *   (un-evidenced stage roles) counts.
  *
- * Entity-key invariant (F-001 — qc1/qc2 Warning): the concatenated key space
+ * Entity-key invariant: the concatenated key space
  * (evidence keys ∪ idle role ids) is UNIQUE by construction — `idleEntities`
  * suppresses a known role's idle card when its id already exists as an
  * evidence-derived entity key (a NON-roster dispatch produces a lit `general`
@@ -488,20 +471,18 @@ export declare function projectGraph(source: MstarEngineStatusSource | null): Zo
  * suppressed via `litKeys`), so the render layer's `key`/`cards.set` never
  * collide.
  *
- * Canvas note (F-002 — qc1 Warning): `note` classifies the readable ledger in
+ * Canvas note: `note` classifies the readable ledger in
  * the projection ('empty' / 'settle-only' / null — see `AgentZoneNote`); the
  * UI consumes it directly and never infers settle-only from the entity list
  * (garbage rows would fake it).
  *
- * Phase-2 plan note (plan 20260812-panel-f5-design-system Task 8 — user
- * 2026-08-12 feedback #2): `activePlanId` / `activePlanCount` ride the
+ * Current-plan note: `activePlanId` / `activePlanCount` ride the
  * `state.plans[]` InProgress rows (catalog order) — the Phase 2 group label
  * annotates the current plan; degraded/empty branches include the note too
  * (it is a state.plans annotation, independent of the ledger evidence).
  */
 export declare function projectAgents(source: MstarEngineStatusSource | null, currentStep: number | null): AgentZoneView;
-/** One row of the pairing walk — the identity a PAIRED settle carries (plan
- * `20260811-panel-f4-timeliness` Task 1, spec R1: exact identity pairing,
+/** One row of the pairing walk — the identity a PAIRED settle carries (spec R1: exact identity pairing,
  * never owner+time guessing). The kind is the FULL projected kind union:
  * workflow/unknown rows are walk no-ops (they carry no paired marker) —
  * widened so the classify output feeds the walk unchanged. */
@@ -528,8 +509,8 @@ export declare function pairSettleIndexes(rows: readonly PairingRow[]): Readonly
  * NEVER throws, NEVER fabricates values.
  *
  * - events: the actual events, latest first, ≤50 — dispatch, settle, the
- *   three workflow kinds (run identity: name / member count / stopReason,
- *   plan `20260815-dsh-workflow-ledger` Task 4) and ANY unknown kind string
+ *   three workflow kinds (run identity: name / member count / stopReason)
+ *   and ANY unknown kind string
  *   as a generic row (degradation — never dropped, never guessed);
  * - unexpected: DISPATCH events whose role is not in the expected role union
  *   (e.g. `general` / `explore` / `scout`). Settle rows are completion