@xulthekl/team-flow 0.58.0 → 0.59.0

package/scripts/lib/cmd-state.mjs

@@ -18,15 +18,18 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 const SETTABLE_FIELDS = [
   'workflow', 'batches_completed', 'spec_merged',
   'dp_0_decisions', 'dp_0_confirmed', 'dp_0_timestamp', 'dp_0_result',
-  'dp_1_result', 'dp_1_timestamp', 'dp_1_decisions', 'dp_1_confirmed',
-  'dp_2_result', 'dp_2_timestamp', 'dp_2_decisions', 'dp_2_confirmed',
-  'dp_3_result', 'dp_3_timestamp', 'dp_3_decisions', 'dp_3_confirmed',
+  // v0.59.0（P4 实测）：dp_{1,2,3,5,6,7}_decisions / _confirmed 共 12 个字段已移除——
+  // 它们虽在旧白名单内，但 writeState 无对应序列化分支，tf state set 会**回显成功却零写入**
+  // （静默假成功；全仓零消费者）。dp_0_decisions / dp_0_confirmed 保留（二者确有序列化分支）。
+  'dp_1_result', 'dp_1_timestamp',
+  'dp_2_result', 'dp_2_timestamp',
+  'dp_3_result', 'dp_3_timestamp',
   // v2.1 §6.6/§6.7：GLAF4 委托决策与状态位（dp_4_result 仍由 tf execution plan --confirm 程序化写入，不在列表）
   'dp_4_glaf4_mode', 'dp_4_write_set_hash',
   'delegation_status', 'delegation_retry_count', 'delegation_partial_writes',
-  'dp_5_result', 'dp_5_timestamp', 'dp_5_decisions', 'dp_5_confirmed',
-  'dp_6_result', 'dp_6_timestamp', 'dp_6_decisions', 'dp_6_confirmed',
-  'dp_7_result', 'dp_7_timestamp', 'dp_7_decisions', 'dp_7_confirmed',
+  'dp_5_result', 'dp_5_timestamp',
+  'dp_6_result', 'dp_6_timestamp',
+  'dp_7_result', 'dp_7_timestamp',
   // Architecture design gate (v0.9 §26, v0.22.5 评审修复 F02)
   'arch_design_decision', 'arch_design_reason',
   'arch_design_timestamp', 'arch_design_artifacts',

package/skills/decision-surrogate/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: decision-surrogate
+description: This skill should be used when the user asks to "启动替身", "夜间替身", "我要睡了，今晚把 X 推下去", "睡前布置任务", "surrogate mode", or wants an agent to take over team-flow decision points while away (overnight or otherwise). It loads the user's decision-preference library and a surrogate home, dispatches workers via Orca orchestration on team-flow projects, adjudicates pre-authorized decision points, and delivers a decision log in the morning. Optional, opt-in only.
+---
+
+# 决策替身（Decision Surrogate）
+
+在用户离席期间扮演「决策代理」：用户睡前布置任务并逐点预授权，替身在夜间派 worker 跑 team-flow 工作流、裁决**可代答**的决策点、其余一律 HOLD 等用户，早上交付决策过程汇总。
+
+**核心边界**：替身只做决策与编排，**不写代码、不改状态文件、不发明任务方向**。
+
+## 何时使用
+
+- 用户要睡前（或离席前）布置任务，希望期间持续推进
+- 当前会话承担替身角色（本 skill 由主会话加载，不是 dispatch 的子代理）
+
+## Phase 0：首次接入（环境探测 + 初始化）
+
+**每次启动先跑探测**；缺项即引导补齐，**不降级、不跳过**。完整探测矩阵、初始化步骤与偏好库访谈问题见 `references/onboarding.md`。
+
+| 探测项 | 命令 | 缺失时 |
+|--------|------|--------|
+| Orca CLI | `which orca` | 引导安装（`brew install orca`） |
+| Orca runtime | `orca status --json` → `result.runtime.state == "ready"` | 引导 `orca open` |
+| orchestration 可用 | `orca orchestration run-list --json` → 返回 JSON 且 `ok: true` | 引导开启 Settings → Experimental |
+| 已绑定的 Run | `orca orchestration run-current --json`（确认当前会话可作协调者） | 说明须在 Orca 管理的终端内运行 |
+| 可用项目 | `orca worktree list --json` | 列出项目供用户选择目标 |
+| 偏好库 | `~/.claude/lt-preferences/decision-preferences.md` 存在 | 走「偏好库初始化」（onboarding.md §2） |
+| 替身 home | 用户指定路径（默认 `~/Documents/work/code/practice/surrogate-home/`）含 `state/` | 创建 + `git init`（onboarding.md §3） |
+| 项目空间判据 | 目标含 `.team-flow/` + `changes/` | **拒绝派发**（普通模式本期不支持） |
+| 机器不休眠 | `pmset -g` 的 `sleep` 为 0 | 引导 `caffeinate -i` |
+
+探测结果向用户报告一张「就绪/待补齐」清单，补齐后方可进 Phase 1。
+
+## Phase 1：睡前授权（用户在场，约 5 分钟）
+
+1. 接收任务：项目空间、change、完成标准
+2. **预案扫描**：读 change 现状 + 偏好库，列出预期决策点及其默认裁决，一并确认**架构门状态**与**执行模式**（两者决定夜间能走多远）
+3. **读回**：把任务 + 逐点授权 + 红线完整读给用户
+4. **落盘**：用户确认后写 `state/mandate-<YYYY-MM-DD>.md`（模板见 `references/protocols.md`）
+5. **派发**：`run-create` → `task-create --spec <...>` → `worker-start --task <id> --worktree "path:<项目根>" --agent claude`
+   - task spec **必须**包含两条硬指令：**禁止使用 AskUserQuestion**；决策点一律 `orca ask` 转协调者
+
+## Phase 2：夜间执行
+
+循环处理：
+
+1. `orca orchestration check --wait --types question,worker_done,escalation --timeout-ms 600000 --json`
+2. 逐条处置：
+   - `question` → 按 `references/decision-points.md` 的三档裁决 → `reply`（代答）或 `reply --body "HOLD: <原因>"`
+   - `worker_done` → 处置 worker（`worker-release`；有后续 task 则转派）
+   - `escalation` → 记入早报「等你决定」
+3. **每个裁决即时写日志**（不等收工）：`state/decisions-<YYYY-MM-DD>.log`
+4. 处理完再确认：`orca orchestration check --ack <delivery_id> --wait ...`
+5. **`check` 超时未收到 `worker_done` 时**：用 `orca orchestration worker-show --dispatch <id>` 判状态并处置——
+   - `ready` → 继续等（长任务常态）
+   - `failed` / `stopped` → `orca orchestration worker-start --task <t> --retry-of <dispatch> --on <saved-environment> --worktree <...> --agent claude` 重启（`--retry-of` **不继承位置**——须显式重复 `--on` / `--worktree` / `--agent`，否则多 server 场景会落到默认 server）
+   - `outcome_unknown` → `worker-stop --dispatch <id>` 后检查
+   - **注意**：worker 停在人工应答（`observation.agentWait`）是**健康态**，不是故障
+   - 每次判状态后追加一条 `health` 日志行
+6. **替身自身异常的恢复**（通道堵死 / 会话崩溃）：
+   - **通道停更判据**：`check --wait` 连续 2 次满超时（各 10 分钟）且期间零消息 → 记 `health` 行 `channel_stalled`，改用 `worker-show --dispatch <id>` 逐个轮询既有 dispatch，不再依赖长等待
+   - **崩溃恢复**：替身会话中断后，状态**只在磁盘**——重入时先读 `state/mandate-<date>.md` + `decisions-<date>.log`，再用 `worker-show` 逐个对账 dispatch 状态，**禁止凭记忆续跑**
+   - **续跑依赖 `send --to dispatch` 唤醒 worker（未实证，见设计文档 §7.5 ⑧⑨）**——已实证的是 `reply` 通路，**与主动 `send` 不是同一条路**；首次启用前须实测，通不过则退化为人工重新派发
+
+**裁决依据优先级（高→低）**：授权书红线 > 授权书逐点授权 > 偏好库条目 > 可推断。
+**冲突时红线优先**（例如偏好库里「收尾即提交推送」在夜间不适用，一律不 push）。
+
+## Phase 3：早上交付
+
+从决策日志渲染早报 `state/report-<YYYY-MM-DD>.md`（格式见 `references/protocols.md`），六段式：① 夜间健康度 ② 各 change 进度 ③ 我替你做的决策 ④ 等你决定的 ⑤ 试过但失败的 ⑥ 成本。
+
+**早报必须逐条列出 HOLD 项**，每项附「问题 + 选项 + 替身倾向 + 依据」，便于用户批量裁决。
+
+## 硬约束
+
+- **禁止 AskUserQuestion**：P0 实证 `orca terminal send` 会返回 `agent_prompt_stalled`——一旦 worker 弹出 TUI 模态，**没有任何自动化手段能救它**。故此禁令是硬要求，不是建议
+- **替身不改状态文件**：决策点状态由 worker 经 `tf state set` 写入（`dp_4_result` 由 `tf execution plan --confirm` 程序化写入，不可 set；**HOLD 场景不写任何决策点字段**——`dp_{1,2,3,5,6,7}_decisions` 等 12 个字段在白名单内但不可落盘，见 `references/protocols.md` §三）
+- **HOLD 是主要形态**：无法代答的点一律 HOLD，**不得静默放行**
+- **不做沉默即同意**：`ask` 超时不产生默认裁决，保留 thread id 待恢复
+- **不假设未验证的机制**：worker 遵循指示是靠 task spec 约束的运行时行为；每次任务须核对早报与**决策日志 + change 的 `state` 位置**是否一致（HOLD 项按设计不写 `dp_N_result`；字段能否落盘须实测，勿据白名单推断）
+
+## 参考文件
+
+- **`references/onboarding.md`** — 首次接入：环境探测矩阵、偏好库初始化（三种方式）、替身 home 初始化、就绪检查
+- **`references/decision-points.md`** — 9 个决策点 + 5 个确认点的代答权限、三档处置规则、夜间红线清单
+- **`references/protocols.md`** — 授权书模板、worker task spec 模板、HOLD 六步协议、**决策日志与早报格式**

package/skills/decision-surrogate/references/decision-points.md

@@ -0,0 +1,87 @@
+# 决策点代答权限与处置规则
+
+> 来源：工作区仓 `docs/plan/decision-surrogate-design.md`（v4.1 §6）；决策点权威定义见插件内 `docs/decision-points.md`
+
+## 一、完整清单（9 个 DP 门 + 5 个确认点）
+
+| 决策点 | 名称 | 守门者 | 位置证据 |
+|--------|------|--------|---------|
+| DP-0 | 设计前确认 | 主会话 | workflow-start |
+| DP-1 | 需求确认 | 主进程（need-explorer 为交互式澄清） | `skills/workflow-start/SKILL.md:71` |
+| DP-2 | 工件审查 | 待 P0/P2 确认 | `skills/spec-writer/SKILL.md:151` |
+| DP-A | 架构设计确认 | 主会话（AskUserQuestion） | `skills/workflow-start/references/routing-rules.md:104,153` |
+| DP-3 | 契约批准（硬门禁） | 主会话 | `skills/workflow-start/references/routing-rules.md:212` |
+| DP-4 | 执行模式选择 | 主会话 | `skills/workflow-start/references/routing-rules.md:215` |
+| DP-5 | 调试升级（3+ 失败） | 待确认 | `skills/bug-investigator/SKILL.md:50` |
+| DP-6 | 验证失败 | 待确认 | `skills/release-archivist/references/closing-procedures.md:65` |
+| DP-7 | 归档确认 | 待确认 | 同上 `:82` |
+| G4 | 同步 change 规划制品 | 主会话 | `skills/workflow-start/SKILL.md:124` |
+| G5 | 归档相关 | 随 DP-7 | — |
+| **Code Landing** | `tf deisolate --merge`（**不可逆**） | — | `skills/release-archivist/SKILL.md:110` |
+| **S3.5 publish** | `tf publish --arch --push`（含 push） | — | — |
+| Step 5b E2E | E2E 验证 | — | `skills/release-archivist/SKILL.md:87` |
+
+## 二、代答权限
+
+| 决策点 | 判定 | 条件 |
+|--------|------|------|
+| DP-0 | ✅ **无条件代答** | 照 change-brief 继承 |
+| DP-1 | ⚠️ 条件代答 | 授权书写明需求范围 |
+| DP-2 | ⚠️ 条件代答 | 独立评审已通过 |
+| **DP-A** | ⛔ **一律挂起** | 架构门禁（用户决定，2026-09-12） |
+| DP-3 | ⚠️ 条件代答 | 见下节四条件 |
+| DP-4 | ⚠️ 条件代答 | 授权书**明确指定**执行模式；未指定 → 挂起 |
+| DP-5 | ⛔ 挂起 | — |
+| DP-6 | ⛔ 挂起 | — |
+| DP-7 | ⛔ 挂起 | — |
+| G4 | ⚠️ 条件代答 | 随 DP-3 判定 |
+| G5 | ⛔ 挂起 | 随 DP-7 |
+| Code Landing | ⛔ 挂起 | 不可逆 |
+| S3.5 publish | ⛔ 挂起 | 含 push |
+| Step 5b E2E | ⚠️ 条件代答 | 结果客观 |
+
+**汇总**：无条件代答 1 ｜ 条件代答 6 ｜ 挂起 7。
+
+## 三、DP-3 条件代答四条件
+
+**同时满足**才批准，缺一 HOLD（命中的条件编号写入决策日志）：
+
+1. 授权书授予本次 change 的 DP-3 代答权
+2. 独立评审已通过（**锚点待 P0 出结论**，候选：`tf execution review` receipt 或 change 内 review 报告）
+3. test-matrix 就绪——判据以 `scripts/guard/checks/test-matrix-ready.mjs:25-55` 为准
+4. 契约内容未超出授权书声明的范围
+
+## 四、合并组处置
+
+合并组（`docs/decision-points.md:101-111`）：`DP-0+DP-A`（架构判定 `skipped` 时）、`DP-3+G4+DP-4`、`DP-7+代码落地+G5`；判定 `required` 时 DP-A 必须独立。
+
+**规则**：对批次内**逐项独立裁决、逐项落盘**；**以最靠前的 HOLD 项决定 change 停止位置**。
+
+- 全部可代答 → 逐项给裁决
+- 含 HOLD 项 → 可代答项**照常裁决并落盘**；HOLD 项及其之后停止推进
+
+（合并只是交互层的降轮次手段，**门禁强度不变**——`docs/decision-points.md:103`）
+
+## 五、三档处置与优先级
+
+| 档 | 判据 | 处置 |
+|---|------|------|
+| 已授权 | 授权书明确写了 | 直接答 |
+| 可推断 | 与已授权项同类 **且偏好库有对应条目** | 答，早报标「待复核」 |
+| HOLD | 方向/路线分叉；不可逆；偏好库无对应；上表标 ⛔ | HOLD（见 protocols.md §三） |
+
+**优先级（高→低）**：授权书红线 > 授权书逐点授权 > 偏好库条目 > 可推断。
+
+## 六、夜间红线（用户确认 2026-09-12）
+
+**允许**：worktree 内本地提交（可整体丢弃）。
+
+**禁止清单**：
+
+1. `push`（含 `tf publish --arch --push`）
+2. 发布（`npm publish`）
+3. 删除任何文件/分支/worktree
+4. 修改契约范围外的公共接口
+5. 任何对外发送（消息/邮件/评论）
+6. 自行发明任务方向
+7. 执行 Code Landing（`tf deisolate --merge`）

package/skills/decision-surrogate/references/onboarding.md

@@ -0,0 +1,79 @@
+# 首次接入：环境探测与初始化
+
+> 目标：把「一台裸机 + 一个想用替身的人」带到可启动状态。全部探测**只读**；所有写操作（建目录、写偏好库）**先向用户说明再执行**。
+
+## 1. 环境探测矩阵
+
+按顺序执行，记录每项状态；任何一项不可用都应给出**具体引导命令**，而非笼统报错。
+
+| # | 探测项 | 命令 | 就绪判据 | 缺失时的引导 |
+|---|--------|------|---------|-------------|
+| 1 | Orca CLI | `which orca` | 返回路径 | `brew install orca`（macOS） |
+| 2 | Orca runtime | `orca status --json` | `result.runtime.state == "ready"` | `orca open`（启动桌面应用并等待 runtime 可达） |
+| 3 | orchestration 可用 | `orca orchestration run-list --json` | 返回 JSON 且 `ok: true` | 在 Orca 打开 **Settings → Experimental** 启用 orchestration |
+| 4 | 协调者锚点 | `orca orchestration run-current --json` | 能显示当前终端绑定的 Run（或可 `run-create` 绑定） | 说明：本 skill 须在 **Orca 管理的终端**内运行，普通终端无法接收 worker 消息 |
+| 5 | 可用项目 | `orca worktree list --json` | 列出项目 | 用 `orca repo add --path <路径>` 注册项目 |
+| 6 | 目标项目空间 | 目标路径含 `.team-flow/` 与 `changes/` | 两者存在 | **拒绝派发**——普通模式本期不支持，改用 workflow-start 常规推进 |
+| 7 | 偏好库 | `test -f ~/.claude/lt-preferences/decision-preferences.md` | 文件存在 | 走 §2 |
+| 8 | 替身 home | `test -d <home>/state` | 目录存在 | 走 §3 |
+| 9 | 机器不休眠 | `pmset -g` 的 `sleep` 为 0；`pgrep -x caffeinate` 有进程 | 两者满足 | `caffeinate -i`（前台保持）；或说明夜间须保持机器唤醒 |
+
+**输出**：一张「就绪 / 待补齐」清单交给用户，**补齐后才进 Phase 1**。
+
+## 2. 偏好库初始化（三种方式，按投入递增）
+
+偏好库是替身判断力的唯一来源；**没有它就不要启动替身**（否则替身只能全量 HOLD，等于没做）。
+
+### 方式 A：交互式最小收集（约 5 分钟，建议起步用）
+
+逐条询问用户，**一次问 3-4 个**避免疲劳；把答案按偏好库格式落成 `~/.claude/lt-preferences/decision-preferences.md`：
+
+| # | 情境 | 记录字段 |
+|---|------|---------|
+| 1 | **文档与实现不一致**时：补强代码 / 修正文档 / 两者都改？ | 情境 / 选项 / 倾向 |
+| 2 | **方案评审强度**：每方案必评 / 仅中大型评 / 看情况？ | + Why（追问一句） |
+| 3 | **流程与任务规模失配**：砍流程环节 / 忍受 / 重构流程本身？ | + How to apply |
+| 4 | **信息不足**时：直接问 / 按最可能猜并标注 / 挂起等确认？ | 置信度 = 用户明述 |
+| 5 | **不可逆操作**（发布 / 合并 / 删除）：一律确认 / 满足条件可自动 / 看影响面？ | |
+| 6 | **收尾动作**：完成即提交推送 / 等确认 / 只提交不推送？ | |
+| 7 | **最在意的质量维度**（列 3 个，如可维护性 / 一致性 / 可回溯性）？ | |
+| 8 | **绝对红线**：无论如何都不做的操作？ | 单列「红线」节 |
+
+每条写成：`情境 → 倾向（选项全集）→ Why → How to apply → 置信度`。
+
+### 方式 B：从既有资产提炼（可与 A 并行）
+
+读 `~/.claude/CLAUDE.md`、项目 `CLAUDE.md` 的「强制要求 / 禁止」条目、以及 memory 目录下的既有条目，提炼成偏好条目。
+
+**注意**：显式规则（"不允许用魔法常量"这类）可靠性最高，优先收录；从语气/风格推断的结论标 `[断]`。
+
+### 方式 C：从历史会话挖掘（最完整，成本最高）
+
+适用：用户已积累数月会话记录，希望替身更贴近本人。
+
+1. 定位会话：`~/.claude/projects/<按路径转义的项目目录>/*.jsonl`
+2. 提取人类输入（过滤 `tool_result`、以 `<` 开头的注入块、上下文压缩摘要、skill 内容）
+3. 分片派**独立子代理**提炼：新偏好 / 已有偏好的新证据 / 矛盾证据
+4. 合并去重后落盘，标注置信度与出处
+
+**建议**：先用 A+B 起步运行，积累几周后再用 C 做一次深度校准。
+
+## 3. 替身 home 初始化
+
+```bash
+mkdir -p <home>/state
+cd <home> && git init
+```
+
+- 默认路径 `~/Documents/work/code/practice/surrogate-home/`（用户可指定其他路径）
+- `state/` 承载：授权书 `mandate-<date>.md`、决策日志 `decisions-<date>.log`、早报 `report-<date>.md`、任务队列 `queue.md`
+- home **与业务项目解耦**；偏好库不放这里（它在 `~/.claude/lt-preferences/`，属用户级、跨项目可用）
+
+## 4. 就绪检查（进 Phase 1 前）
+
+- [ ] 环境探测矩阵 9 项全部就绪
+- [ ] 偏好库存在且非空（≥1 条）
+- [ ] 替身 home 存在且含 `state/`
+- [ ] 用户已确认目标项目空间与 change
+
+全部打勾后，向用户复述一次本次任务的**范围与红线**，再进 Phase 1。

package/skills/decision-surrogate/references/protocols.md

@@ -0,0 +1,116 @@
+# 协议模板集
+
+## 一、授权书模板 → `state/mandate-<YYYY-MM-DD>.md`
+
+```markdown
+# 授权书 <日期> ｜ change：<name>
+
+## 任务
+- 项目空间：<路径>
+- change：<name>
+- 完成标准：<可验证的完成条件>
+- **架构门状态：已过 / 未过**（未过则夜间止于 exploring）
+- 需求范围：<scope 摘要，供 DP-1 条件代答判据>
+- **执行模式：<TDD|SDD|inline|不指定>**（不指定则夜间止于 approved-for-build）
+
+## 逐点授权
+| 决策点 | 授权 | 条件 |
+|--------|------|------|
+| DP-0 | 代答 | 照 change-brief 继承 |
+| DP-1 | 条件代答 | 不超出上述需求范围 |
+| DP-2 | 条件代答 | 独立评审通过 |
+| DP-A | 挂起 | 架构门禁 |
+| DP-3 | 条件代答 | 四条件（见 decision-points.md §三）|
+| DP-4 | 条件代答 | 已指定执行模式（见上）|
+| DP-5 ~ DP-7 | 挂起 | — |
+| G4 | 条件代答 | 随 DP-3 |
+| G5 | 挂起 | 随 DP-7 |
+| Code Landing / S3.5 publish | 挂起 | 不可逆 / 含 push |
+| Step 5b E2E | 条件代答 | 结果客观 |
+
+## 红线
+允许 worktree 内本地提交；禁止：push / 发布 / 删除 / 改契约外接口 / 对外发送 / 发明任务 / Code Landing
+```
+
+## 二、Worker task spec 模板（**硬指令不可省**）
+
+```
+<任务描述：项目空间、change、完成标准>
+
+【协调协议 — 必须遵守】
+1. 严格禁止使用 AskUserQuestion 工具。任何需要用户确认的点，一律用
+   `orca orchestration ask --question "<问题>" --options "<选项逗号分隔>" --timeout-ms 600000`
+   转给协调者（替身），等待 reply 后再继续。
+2. 子代理上报的决策请求同样转给协调者，不得自行裁决。
+3. **若 `ask` 超时：禁止自行裁决**。保留 message_id，用
+   `orca orchestration ask --resume <message_id> --timeout-ms 600000` 续等；
+   续等仍超时则停止推进并向协调者上报。
+4. 完成或阻塞时用
+   `orca orchestration send --type worker_done --outcome <succeeded|failed> --subject "<状态>" --body "<三句话：做了什么、发现了什么、还剩什么>" --json`
+   报告，随后结束本轮。task/dispatch ID 使用 Orca 启动时注入的值，**不要自行编造**。
+
+【红线 — 绝对禁止（违反即停）】
+- `push`（含 `tf publish --arch --push`）
+- 发布（`npm publish`）
+- 删除任何文件、分支或 worktree
+- 修改契约范围外的公共接口
+- 任何对外发送（消息 / 邮件 / 评论）
+- 自行发明任务方向
+- 执行 Code Landing（`tf deisolate --merge`）
+```
+
+> 派发命令：`orca orchestration worker-start --task <task_id> --worktree "path:<项目根>" --agent claude --json`
+> `path:` 只能指向**项目根**（Orca 注册主 worktree）；`tf isolate` 建的 `.worktrees/...` 路径不可用（返回 `selector_not_found`）。
+
+## 三、HOLD 协议（worker 侧六步）
+
+| 步骤 | 动作 |
+|------|------|
+| ① 替身裁决 | `orca orchestration reply --id <msg_id> --body "HOLD: <原因>"` |
+| ② worker | 停止当前 change 推进；不提交半成品；已落 worktree 的工作**保留** |
+| ③ worker 记录 | **不写任何决策点字段**。两条禁令：① `dp_N_result` 是门禁判据（`dp-gate-passed` 只校验非空），写入 HOLD 值会让 change 呈现"已批准"假象；② `dp_{1,2,3,5,6,7}_decisions` 与 `dp_{1,2,3,5,6,7}_confirmed`（共 12 个）**不可落盘**——它们在 `cmd-state.mjs` 的 `SETTABLE_FIELDS` 白名单内，但 `state-loader.mjs` 的 `writeState` 无对应序列化分支，`tf state set` **回显 ✅ 却零写入**（v0.59.0 P4 亲测；**注意 `dp_0_decisions`/`dp_0_confirmed` 不在此列，它们确实会落盘**）。HOLD 的持久锚点 = 步④ 的 escalation 消息 + 步⑥ 的替身决策日志 + change 的 `state` 仍停在门禁前（客观事实）。**约束**：不得新建 `changes/<name>/` 下任何文件（Artifact Ownership：主会话 MUST NOT 直接 Edit/Write `changes/` 或 `.worktrees/`） |
+| ④ worker 上报 | `orca orchestration send --type escalation --subject "HOLD at <门>" --body "<摘要>" --json` |
+| ⑤ worker 处置 | 用 `orca orchestration worker-retain --dispatch <id>` 标记保留（**不可用 `worker-release`**——官方禁止因 escalation/question/idle 释放） |
+| ⑥ 替身 | 写决策日志 + 早报「等你决定」段（问题/选项/替身倾向/依据/msg_id） |
+
+**多任务**：一个 HOLD 不阻塞其他 worker。
+**早上恢复**：用户批阅早报 → 给出裁决 → `orca orchestration send --to dispatch:<id> --subject "<裁决>"` 投递 → worker 解除 HOLD 继续。
+
+> ⚠️ **此路径依赖 §7.5 ⑧⑨（未实证）**：附录 D ⑧ 验证的是 `reply` 唤醒（ask→reply 通道），**与「向 dispatch 主动 `send`」不是同一条路径**。首次启用前必须实测；不通则退化为人工续跑（重新派发任务）。**不得据相邻机制的实测结论推断本路径可用**。
+
+## 四、决策日志格式 → `state/decisions-<YYYY-MM-DD>.log`（append-only）
+
+**多类型行**（早报六段各有数据源）：
+
+```
+decision | [HH:MM] | <change> | <决策点> | <问题摘要> | 选项:<...> | 裁决:<代答值|HOLD> | 理由:<...> | 依据:<授权书§N|偏好库#N> | 命中条件:<...> | msg:<id> | 置信:<高|中|低>
+progress | [HH:MM] | <change> | 停止位置:<...> | 推进步数:<N> | 隔离位置:<路径> | diff:<摘要>
+health   | [HH:MM] | <dispatch> | 状态:<ready|agentWait|failed|stopped|outcome_unknown|channel_stalled> | 心跳:<时间戳>
+cost     | [HH:MM] | 累计:<token|时长>
+```
+
+**即时写**（不等收工）——日志是抗压缩的锚点，也是早报的唯一数据源。
+
+## 五、早报格式 → `state/report-<YYYY-MM-DD>.md`
+
+```
+# 替身早报 <日期>
+
+## ① 夜间健康度
+心跳时间戳范围 / 是否卡过 / 有无告警
+
+## ② 各 change 进度
+| change | 停止位置 | 推进步数 | 隔离位置 | diff 摘要 |
+
+## ③ 我替你做的决策
+| 时间 | change | 决策点 | 选择 | 理由 | 依据 | 置信 |
+
+## ④ 等你决定的（HOLD）
+| 决策点 | 问题 | 选项 | 替身倾向 | 依据 | 恢复命令 |
+（逐条列全，便于批量裁决）
+
+## ⑤ 试过但失败的
+## ⑥ 成本
+```
+
+**渲染原则**：从决策日志渲染，**不从对话记忆渲染**（抗压缩、可审计）。

package/.zcode/hooks.json

@@ -1,8 +0,0 @@
-{
-  "hooks": [
-    {
-      "event": "sessionStart",
-      "command": "bash /Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/hooks/session-start"
-    }
-  ]
-}

package/.zcode/rules/phase-guard.mdc

@@ -1,33 +0,0 @@
----
-description: team-flow phase guard — 防止阶段漂移和未授权实现
-alwaysApply: true
----
-
-# Phase Guard
-
-## 入口规则
-
-- 所有工作必须从 "/workflow-start" 入口开始。
-- 在 .team-flow.yaml 中确认当前 state 和 workflow 模式之前，不要开始写代码。
-
-## 全局禁止
-
-- 没有 execution-contract.md 或未经用户明确批准，不得进入实现。
-- full/hotfix 必须先运行 tf execution plan <change-dir> ...；没有 current execution plan 不得开始实现。
-- 只有 all pass review receipts 后才可 closing；不得把未审查的 wave 当作完成。
-- 上述 plan/receipt gates 仅适用于 full/hotfix；tweak 免除这些 gates (tweak exempt)。
-- 执行过程中如果发现需求/范围变化，必须回退到 specifying 或 bridging，而不是直接改代码。
-- 不要直接调用执行类 skill（如 "/build-executor"），必须通过入口路由。
-
-## 决策点协议
-
-- DP-0：设计前确认
-- DP-1：需求确认
-- DP-2：工件审查
-- DP-3：是否批准 execution contract？
-- DP-4：先运行 tf execution recommend，展示可用模式与推荐；用户用 --confirm 确认，非推荐选择额外使用 --acknowledge-recommendation
-- DP-5：调试升级
-- DP-6：验证失败
-- DP-7：是否收口归档？
-
-> 本文件由 scripts/install-zcode.mjs 生成；对具体变更的 guard 内容请运行 tf inject <change-dir> 更新。

package/.zcode/skills/workflow-start/SKILL.md

@@ -1,175 +0,0 @@
----
-name: workflow-start
-description: Primary entry point for the team-flow state-machine workflow. Invoke when the user is inside an active team-flow change directory (look for .team-flow.yaml, changes/<name>/, proposal.md, specs/, design.md, tasks.md, or execution-contract.md) and asks to start, continue, resume, implement, plan, or figure out the next workflow step. Also invoke when the user explicitly asks to start a new team-flow change or route through the team-flow workflow. Do not invoke for unrelated coding tasks that happen to use words like start, continue, implement, or plan.
----
-
-# Workflow Start
-
-Primary entry point for `team-flow`. Jobs: inspect change context, check for updates, confirm DP-0, determine state, route to correct skill, block invalid transitions.
-
-## Use This Skill When
-
-Only invoke when team-flow context is present: `.team-flow.yaml` exists, artifacts like `proposal.md`/`specs/`/`design.md`/`tasks.md`/`execution-contract.md` are present, or user explicitly invokes team-flow by name. When in doubt, check for `.team-flow.yaml` first.
-
-Do NOT invoke for: general coding tasks outside team-flow changes, casual questions, unrelated work.
-
-## States
-
-`exploring` → `specifying` → `bridging` → `approved-for-build` → `executing` → `closing`, with `debugging` side-path from `executing`, and `abandoned` as terminal. If a transition is ambiguous, run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' runtime asset read docs/state-machine.md`.
-
-## Initialization
-
-1. **Update check**: Run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' runtime check-update`. Exit 0 → continue. Exit 1 → non-blocking upgrade reminder. Exit 2 → skip.
-2. **Inspect change folder**: Check for `proposal.md`, `specs/`, `design.md`, `tasks.md`, `execution-contract.md`. Answer: Is the change fuzzy? Artifacts missing/unstable? Contract exist? User approved contract? Execution in progress or blocked? In verification/wrap-up?
-3. **Overlay recovery scan**: Run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' handoff list <change-dir> --json` and `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' handoff resolve` before resuming the affected work. An `active` handoff is non-blocking side work. Show a non-stale checkpoint as recovery context; show a stale checkpoint only as historical evidence.
-4. **Execution-control recovery scan**: For `approved-for-build`, `executing`, `debugging`, or `closing`, run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution show <change-dir> --json`. Treat only `current: true` plus `waves[].eligible: true` as permission to start a wave; report plan revision, mode, next eligible wave, and every wave's receipt/blockers. A missing, invalid, or stale plan blocks implementation and routes to `build-executor`; do not infer progress from chat history.
-
-## DP-0: User Confirmation Gate
-
-Run DP-0 when: change folder doesn't exist, planning artifacts missing/empty, or `dp_0_confirmed` ≠ `true`. Skip if `dp_0_confirmed` is `true`.
-
-### Upstream Inheritance (v0.9)
-
-若 `change-brief.md` 存在且 `upstream_source == orchestrator`（本 change 由 orchestrator S4 分发），**继承** brief 的 scope/约束/AC 为默认值，DP-0 从"从零问"改为"一次确认继承或修正"，**不**重新问"你想做什么"。否则（手动新建 / hotfix / 单 change 快速通道 / 存量 change 无 brief）照常 DP-0。**主信号 = brief 文件存在**（非 yaml 字段——可天然排除无 brief 的快速通道，且对存量手动 change 零误伤）；双源冲突以 `requirement/vN/plan.md` 为准并触发 Brief drift（见「Staleness Detection」）。完整判定伪代码与主信号理由见 `references/routing-rules.md`「DP-0」。
-
-Ask (manual path): change name + one-sentence intent, known constraints, related optimizations (include or stay focused?), communication preference (ask per decision or draft for review).
-
-After confirmation:
-```bash
-node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' state set <change-dir> dp_0_decisions "<summary>"
-node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' state set <change-dir> dp_0_result confirmed
-node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' state set <change-dir> dp_0_confirmed true
-node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' state set <change-dir> dp_0_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
-```
-
-Config-aware routing: check `artifacts.order` and `artifacts.skip` from project config.
-
-## Mode Detection
-
-If workflow is `auto`/`null`/unset: run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' runtime infer <change-dir>`. Inference: **hotfix** (≤2 tasks, ≤2 files, no schema/API/new modules), **tweak** (≤4 tasks, config/doc only), **full** (anything larger). Persist with `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' state set <dir> workflow <mode>`.
-
-Validate mode against artifact content. If hotfix/tweak criteria not met → upgrade to `full` and output reason. Don't overwrite explicit mode unless user asks.
-
-## Routing Rules
-
-### Route to need-explorer
-Change is fuzzy, scope unclear, comparing options, no stable change name.
-
-### Route to architecture-design (v0.9 §26)
-Guard: `arch_design_decision` in `.team-flow.yaml` is `null` → must run before spec-writer. Dispatch `architecture-design` as sub-agent; after return, run reasonableness check and write yaml. Full protocol in `references/routing-rules.md`「Route to architecture-design」.
-
-### Route to spec-writer
-Guard: `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' runtime guard check <dir> exploring specifying --json` → fail = BLOCK. **arch_design_decision must not be null** → fail = BLOCK (v0.9 §26). User knows what they want, artifacts missing/incomplete.
-
-### Route to contract-builder
-Guard: `... check <dir> specifying bridging --json` → fail = BLOCK. Artifacts exist, implementation requested, contract missing/stale. Include `DP-3: 契约批准`.
-
-### Route to build-executor
-Contract exists and approved, contract matches artifacts. Include `DP-4: 执行模式选择`: propose waves, run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution recommend <change-dir> [--wave ...]`, show the user every available mode plus evidence and the recommendation, then obtain a clear selection. The command saves a current receipt; before the first implementation edit, `build-executor` must run `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution plan <change-dir> --mode <selected> --confirm ...` (and `--acknowledge-recommendation` when the selected mode differs from the recommendation) using matching artifacts, contract, and waves, then `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution show <change-dir> --json`; report the saved revision, selected mode, recommendation alignment, ordered waves, and actual concurrent-dispatch capability. A revision must repeat recommend and confirmation. Do not transition to `executing` until `show` reports `current: true`; then run `... check <dir> approved-for-build executing --json` → fail = BLOCK.
-
-### Route to bug-investigator
-Execution hit blockage: test failure, unexpected behavior, build error, task cannot proceed. After debugging, route back to build-executor.
-
-### Route to code-reviewer
-The current planned wave is implemented and ready for spec-compliance + code-quality verification. A reviewer must write an `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <path> --verdict <pass|fail>` receipt before any dependent wave or closing transition.
-
-### Route to release-archivist
-Guard: `... check <dir> executing closing --json` → fail = BLOCK. Implementation complete, verification complete/nearly complete. Include `DP-7: 归档确认`.
-
-### Route to spec-merger
-Delta specs exist that need merging, change closing with ADDED/MODIFIED/REMOVED/RENAMED specs.
-
-### Route to abandoned
-User explicitly requests, bug-investigator escalates after 3+ failures AND user chooses, scope change makes change no longer worthwhile AND user confirms. Block from `closing` or `abandoned`.
-
-### Optional Prototype Handoff
-
-When the user's brief explicitly contains UI, screen, interaction, layout, UX,
-or product-experience uncertainty, ask once whether a prototype would reduce
-uncertainty. Do not create a prototype handoff or enter a prototype worktree
-until the user confirms. After confirmation:
-
-```bash
-node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' handoff create <change-dir> \
-  --type prototype --objective "<confirmed objective>" \
-  --expected-output "<expected evidence>" --acceptance "<completion criterion>"
-tf isolate <change-dir> prototype-<handoff-id>
-```
-
-Never suggest or enter this route automatically for backend, CLI, configuration,
-or internal-refactor work. Never pass `--force` to `tf isolate` for prototype
-work.
-
-### Fast-Path Routing
-
-**DP-0 处理**（v0.22.5 F03 修复）：hotfix/tweak 路径隐式跳过 DP-0（`dp_0_confirmed` 保持 `null`），因为意图已明确（修复/微调），无需从零探索。contract-builder 的 DP-3 审批成为唯一门禁。
-
-- **Hotfix**: Route to contract-builder (minimal), skip need-explorer + spec-writer, guard check `exploring bridging --workflow hotfix`, then `bridging -> approved-for-build`, after DP-3 → build-executor (recommend, show, and confirm an execution mode), after → release-archivist (lightweight). Hotfix may skip `proposal.md`, `design.md`, `tasks.md`, and `specs/`, but it still requires a fresh minimal `execution-contract.md`, DP-3 approval, and a current execution plan before build. **architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门，快速判定是否涉及架构变更（hotfix 可能正是架构缺陷导致）
-- **Tweak**: Route to build-executor (direct edit), skip need-explorer + spec-writer + contract-builder, guard check `exploring approved-for-build --workflow tweak`, after → release-archivist (lightweight). **architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门
-
-Post-transition: 💡 `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' inject <change-dir>` to update phase-guard artifacts.
-
-## Staleness Detection
-
-Use content inspection, not timestamps.
-
-**Stale contract**: proposal scope expanded beyond contract scope fence, or contract references capabilities no longer in proposal → route back to `contract-builder`.
-
-**Stale planning artifacts**: capability in proposal has no spec file, or spec exists for capability not in proposal → drift detected.
-
-**Stale tasks**: requirement in specs has no corresponding task → stale tasks.
-
-**Brief drift (advisory, v0.9, 不阻断)**: change-brief.md 是上游输入（非 team-flow 产物），**不**混入上述三条产物互查、**不**进入 `artifacts_hash`。当 brief 的 `plan_hash` 与当前 `requirement/vN/plan.md` 不一致，或 brief AC 列表与 PRD 功能清单明显出入 → 提示"产品层已变更，brief 可能过期，建议回 orchestrator 重新分发（S4→S3 环路）"，**不**触发产物重审。
-
-## Guardrails
-
-- No implementation before planning artifacts or contract exist
-- No implementation for full/hotfix without a current `node '/Users/litong/Documents/work/code/practice/team-flow-workspace/team-flow/.zcode/team-flow/scripts/team-flow.mjs' execution plan`; no state transition based on an unverified DP-4 string
-- No "continue" without state inspection
-- No implementation past stale contract
-- No implementation past bug without investigation
-- No closure without all planned wave review receipts recorded as `pass`
-- No closure with unsynced delta specs
-- No transitions from `abandoned` (terminal)
-- No transition to `abandoned` from `closing` or `abandoned`
-- No auto-abandon without user confirmation
-- No merging delta specs from abandoned change
-- **No routing to spec-writer without architecture-design gate pass** (v0.9 §26): `arch_design_decision` must be `required` or `skipped` (not `null`). hotfix/tweak 不豁免
-
-## State Writes (v0.22.5 F06 修复)
-
-workflow-start 负责写入以下字段到 `.team-flow.yaml`：
-
-**核心状态字段**：
-- `state`：当前状态（exploring/specifying/bridging/approved-for-build/executing/debugging/closing/abandoned）
-- `workflow`：工作流类型（auto/full/hotfix/tweak）
-
-**决策点字段**（各阶段确认后写入）：
-- `dp_0_*`：need-explorer 完成后的需求澄清决策
-- `dp_1_*`：spec-writer 完成后的规格决策
-- `dp_2_*`：contract-builder 完成后的契约决策
-- `dp_3_*`：build-executor 完成后的执行决策
-- `dp_5_*`：code-reviewer 完成后的审查决策
-- `dp_6_*`：release-archivist 完成后的发布决策
-- `dp_7_*`：其他决策点
-
-**架构设计门控字段**（v0.9 §26，v0.22.5 F02 修复）：
-- `arch_design_decision`：`required` | `skipped`（architecture-design 子代理返回，workflow-start 经 reasonableness check 后写入）
-- `arch_design_reason`：判断理由
-- `arch_design_timestamp`：ISO 8601 时间戳（UTC）
-- `arch_design_artifacts`：产出路径列表（required 时必填，skipped 时为空）
-
-**职责边界**：architecture-design 负责判断+产出，workflow-start 负责 reasonableness check + 状态写入。详细写入命令见 `references/routing-rules.md`「Route to architecture-design」。
-
-## Output Standard
-
-Always state: (1) current detected state, (2) why (cite file/content/condition), (3) which skill should run next. If blocking, explain missing artifact/approval.
-
-Decision point references when routing:
-- architecture-design → DP-A（架构设计判断门，v0.9 §26）, contract-builder → DP-3, build-executor → DP-4, bug-investigator (escalation) → DP-5, release-archivist (verification failure) → DP-6, release-archivist → DP-7
-
-## Exception Handling
-
-- **Parse failures**: Fall back to content-level detection if `.team-flow.yaml` is malformed
-- **Missing files**: Route to the skill that generates the missing files
-- **User interruption**: Re-inspect change directory content (not cached state) on resume