@xulthekl/team-flow 0.59.0 → 0.61.0

package/skills/decision-surrogate/SKILL.md

@@ -1,87 +0,0 @@
----
-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 六步协议、**决策日志与早报格式**