@xulthekl/team-flow 0.59.0 → 0.61.0

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "description": "Unified workflow plugin: team-flow (spec-driven dev) + compound-engineering core subset + architecture-design (4A/DDD) + prototype (local HTML) + business-analysis (independent requirement/scenario artifact). 28 skills, one install.",
-  "version": "0.59.0",
+  "description": "Unified workflow plugin: team-flow (spec-driven dev) + compound-engineering core subset + architecture-design (4A/DDD) + prototype (local HTML) + business-analysis (independent requirement/scenario artifact) + jarvis (team-flow decision agent, opt-in). 28 skills, one install.",
+  "version": "0.61.0",
   "contextFileName": "GEMINI.md"
 }

package/hooks/session-start

@@ -1,11 +1,11 @@
 #!/usr/bin/env bash
-# v0.59.0: auto-sync CLI version with plugin version
+# v0.61.0: auto-sync CLI version with plugin version
 set -e
 
 # ═══════════════════════════════════════════════════════════════
 # Plugin version (update this when releasing new versions)
 # ═══════════════════════════════════════════════════════════════
-PLUGIN_VERSION="0.59.0"
+PLUGIN_VERSION="0.61.0"
 
 # ═══════════════════════════════════════════════════════════════
 # Step 1: Auto-sync CLI version with plugin version

package/llms.txt

@@ -3,7 +3,7 @@
 ## Overview
 spec-superflow is a self-contained workflow integration plugin for Claude Code, Cursor, OpenAI Codex CLI/App, GitHub Copilot CLI, Gemini CLI, OpenCode, WorkBuddy, and Trae. It merges spec-driven planning artifacts (proposal, specs, design, tasks) with disciplined execution guardrails (TDD, review gates, controlled handoff) into one unified workflow.
 
-Current version: v0.59.0.
+Current version: v0.61.0.
 
 ## Key Documents
 - README.md: Chinese homepage with full usage guide and FAQ

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xulthekl/team-flow",
-  "version": "0.59.0",
+  "version": "0.61.0",
   "description": "Unified plugin (28 skills + 17 agents) integrating team-flow, compound-engineering, architecture-design, prototype, design-system, workflow-orchestrator, workflow-bootstrap, e2e, session-handoff, workflow-feedback, business-analysis for multi-agent coding tools.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "team-flow",
-  "version": "0.59.0",
-  "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact) + design-system (design tokens + component contract + AI primer + showcase) + test-strategy (test strategy design) + project-initialize (new service onboarding). 28 skills + 17 agents, one install.",
+  "version": "0.61.0",
+  "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking) + business-analysis (independent requirement/scenario artifact) + design-system (design tokens + component contract + AI primer + showcase) + test-strategy (test strategy design) + project-initialize (new service onboarding) + jarvis (team-flow decision agent, opt-in). 28 skills + 17 agents, one install.",
   "author": {
     "name": "LT"
   },

package/scripts/check-version-consistency.mjs

@@ -73,7 +73,7 @@ const TEXT_CHECKS = [
   { file: 'GEMINI.md',              extract: /# team-flow v(\d+\.\d+\.\d+) \|/ },
   // v0.59.0：新增 usage-guide 版本锚点（此前不在扫描面内，0.58.0 与 0.59.0 两次发版均靠人工改；
   // P3-15 ② 半项闭合——**检出**已覆盖，本段仍无 --fix 分支，自动修复待做）
-  { file: 'docs/usage-guide.md',    extract: /版本锚点：v(\d+\.\d+\.\d+)/ },
+  { file: 'docs/team-flow 使用说明（研发团队版）.md',    extract: /版本锚点：v(\d+\.\d+\.\d+)/ },
 ];
 
 for (const check of TEXT_CHECKS) {
@@ -165,7 +165,7 @@ for (const check of SKILL_COUNT_JSON_CHECKS) {
 const SKILL_COUNT_TEXT_CHECKS = [
   { file: 'README.md', extract: /(\d+) skills/, replace: (content, count) => content.replace(/(\d+) skills/, `${count} skills`) },
   { file: 'AGENTS.md', extract: /Skills 索引（(\d+) 个）/, replace: (content, count) => content.replace(/Skills 索引（(\d+) 个）/, `Skills 索引（${count} 个）`) },
-  { file: 'docs/usage-guide.md', extract: /(\d+) 个 skills/, replace: (content, count) => content.replace(/(\d+) 个 skills/, `${count} 个 skills`) },
+  { file: 'docs/team-flow 使用说明（研发团队版）.md', extract: /(\d+) 个 skills/, replace: (content, count) => content.replace(/(\d+) 个 skills/, `${count} 个 skills`) },
   { file: 'docs/platform-matrix.md', extract: /(\d+) 个 skill 部署/, replace: (content, count) => content.replace(/(\d+) 个 skill 部署/, `${count} 个 skill 部署`) },
   { file: 'INSTALL.md', extract: /应有 (\d+) 个 skill 目录/, replace: (content, count) => content.replace(/(\d+) 个 skill 目录/g, `${count} 个 skill 目录`) },
   { file: 'INSTALL.md', extract: /包含 (\d+) 个 skill、/, replace: (content, count) => content.replace(/(\d+) 个 skill、/, `${count} 个 skill、`) },

package/scripts/lib/cmd-version.mjs

@@ -31,6 +31,10 @@ const TEXT_FILES = [
   { file: 'llms.txt',               pattern: /(Current version: v)\d+\.\d+\.\d+(\.)/g,             replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },
   { file: '.claude/always/phase-guard.md', pattern: /(# team-flow v)\d+\.\d+\.\d+( \|)/g,      replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },
   { file: 'GEMINI.md',              pattern: /(# team-flow v)\d+\.\d+\.\d+( \|)/g,              replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },
+  // v0.60.0：补 usage-guide 的**同步面**——v0.59.0 只把它纳入检出（check-version-consistency.mjs），
+  // 漏了本列表，导致升版时「package.json 已改但 usage-guide 未同步 → 检出失败 → npm version 非 0 退出」
+  // 的脏状态。检出与同步现已同源（两处 pattern 对应同一锚点）。
+  { file: 'docs/usage-guide.md',    pattern: /(版本锚点：v)\d+\.\d+\.\d+/g,                     replacement: '$1%MAJOR%.%MINOR%.%PATCH%' },
   { file: 'skills/workflow-start/SKILL.md', pattern: /(npx --yes --package @xulthekl\/team-flow@)\d+\.\d+\.\d+( tf)/g, replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },
   { file: 'skills/need-explorer/SKILL.md', pattern: /(npx --yes --package @xulthekl\/team-flow@)\d+\.\d+\.\d+( tf)/g, replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },
   { file: 'skills/spec-writer/SKILL.md', pattern: /(npx --yes --package @xulthekl\/team-flow@)\d+\.\d+\.\d+( tf)/g, replacement: '$1%MAJOR%.%MINOR%.%PATCH%$2' },

package/skills/bug-investigator/SKILL.md

@@ -92,6 +92,14 @@ Write the investigation report with this structure:
 - **Mechanism:** [How the bug works, step by step]
 - **Evidence:** [What proves this is the cause]
 
+## 源 Change 关联（v0.61.0 新增，设计依据 v0.26 §203）
+
+- **是否匹配到源 change**：是 / 否
+- **源 change 目录**：`<changes/<name>/>`（若匹配到；否则填「独立缺陷 / 新文件，无源 change」）
+- **匹配方式**：`git blame` 受影响文件/符号 → 引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查；或全局 `specs/` 按 capability 检索
+- **复用约束**：修复时复用源 change 的 `design.md` / `specs/` / `tests` 作为已知设计约束，避免偏离原设计意图；若源 change 已 closing，仅在本 bugfix change 内复用上下文，**不重开**源 change
+- **用户确认**：匹配结果须由用户确认；失准时本段填「匹配失败，按独立缺陷处理」
+
 ## Recommended Fix
 [Suggested approach — describe what to change and why, but do NOT implement it]
 - **Fix location:** [where to change]

package/skills/ce-plan/references/change-splitting.md

@@ -17,6 +17,18 @@ Break the work into logical **changes** (team-flow change units). Each change re
 - 一个内聚功能模块（如"下单""权限体系"）通常对应一个所有权单元 → 通常 = 一个 change
 - 但"一个用户故事"不等于"一个 change"的充要条件——若多个故事共享同一所有权单元（如看板多视角共享同一读模型），它们应合为一个 change
 
+## 拆分默认姿态（粗粒度优先，v0.60.x 新增）
+
+**默认不拆细。** 把一个迭代版本的工作拆成 change 时，优先合并为少量**粗粒度** change（按所有权单元计）。只有在以下三条中**至少一条成立**时，才向下拆细：
+
+1. **越过所有权边界**：子块对应不同的聚合 / 限界上下文 / 读模型 / 契约所有权，必须各自独立做架构增量设计（即 D5 判据要求拆）。
+2. **需要独立并行验证**：子块可被不同人/不同时间独立实现并验证，合在一起反而难测。
+3. **团队领取需要**：协作分发时，必须拆开才能分给不同成员认领。
+
+**"拆太细"的代价**：每个 change 都要走完整 8 态 + 4+1 产物 + 架构增量设计 + 复利回写——当 change 细到单接口/单文件/单方法时，这些仪式开销远大于改动本身价值。`change-split-auditor` D3 会主动提示合并候选（见该 agent D3），但**仅为建议、不硬拦**（与 D5「切碎所有权」的硬 FAIL 不同级）。
+
+> 一句话：**宁粗勿细。拆细是例外，不拆是默认。**
+
 ## Good Changes
 
 **根因判据**：每个 change 的 scope 必须对应**一个所有权自包含的架构设计单元**——持有不被其它 change 分享的聚合/上下文/读模型/契约所有权，且该设计能在本 change 内闭合。

package/skills/jarvis/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: jarvis
+description: This skill should be used when the user asks to "启动 Jarvis", "让 Jarvis 接手决策", "我要睡了，今晚把 X 推下去", "睡前布置任务", "jarvis mode", or wants an agent to take over team-flow decision points — whether away (overnight handoff) or present (to offload decision bandwidth). It loads the user's decision-preference library and a Jarvis home, dispatches workers via Orca orchestration on team-flow projects, adjudicates pre-authorized decision points, and delivers a decision log. Optional, opt-in only.
+---
+
+# Jarvis（team-flow 决策代理）
+
+作为 **team-flow 工作流**的决策代理：在用户设定的授权范围内代做决策点裁决，缓解决策带宽瓶颈。Jarvis 派 worker 跑工作流、裁决**可代答**的决策点、其余一律 HOLD 交回用户。
+
+**两种典型场景**：
+
+| 场景 | 形态 |
+|------|------|
+| **夜间 / 离席值守**（核心） | 睡前逐点预授权 → 夜间派 worker → 裁决可代答点、其余 HOLD → 早上交付汇总 |
+| **在场分流** | 用户在时也先过一遍决策点，只把 HOLD 项交给人 —— 减少打断 |
+
+**核心边界**：Jarvis 只做决策与编排——**不写产线代码、不改 team-flow 状态文件（`.team-flow.yaml`）、不发明任务方向**。（「不改状态文件」专指 team-flow 的门禁真相源；Jarvis 自己的 `state/*.log|md` 当然要写。）
+
+> **与 firstmate 的分工**：Jarvis 是 **team-flow 专用**的决策代理，深度集成状态机 / 决策点 / 门禁；通用跨项目的「大副」角色由 firstmate 承担。两者不重叠——Jarvis 不做通用编码、调查或审计工作。
+
+> **命令形态以官方为准**：本文命令随 Orca 版本演进，**运行前先读一次** `orca skills get orchestration`，不要凭记忆推断子命令或参数——v0.60.0 实测暴露的 skill 缺陷之一即命令形态错误。
+
+## 何时使用
+
+- 用户要睡前（或离席前）布置任务，希望期间持续推进
+- 用户在场，但希望将某 change 的决策点分流给 Jarvis 处理
+- 当前会话承担 Jarvis 角色（本 skill 由主会话加载，不是 dispatch 的子代理）
+
+## Phase 0：首次接入（环境前置检查 + 初始化）
+
+**每次启动先跑检查**；缺项即引导补齐，**不降级、不跳过**。完整检查矩阵、初始化步骤与偏好库访谈问题见 `references/onboarding.md`。
+
+| 检查项 | 命令 / 判据 | 缺失时 |
+|--------|-----------|--------|
+| **shell 启动无交互提示** | 新开终端不停在等待输入；shell 配置无更新检查 / read | **派发会静默失败**——见「硬约束」 |
+| **目标目录已被 claude 信任** | `~/.claude.json` → `projects["<路径>"].hasTrustDialogAccepted == true` | 预置该字段（**先备份**），否则首次派发必失败 |
+| Orca CLI | `which orca` | `brew install orca` |
+| Orca runtime | `orca status --json` → `result.runtime.state == "ready"` | `orca open` |
+| orchestration 可用 | `orca orchestration run-list --json` → `ok: true` | 开启 Settings → Experimental |
+| 已绑定 Run | `orca orchestration run-current --json`（或可 `run-create` 绑定） | 须在 **Orca 管理的终端**内运行 |
+| 可用项目 | `orca worktree list --json` | `orca repo add --path <路径>` |
+| 偏好库 | `~/.claude/lt-preferences/decision-preferences.md` 存在 | 走 onboarding.md §2 |
+| Jarvis home | 用户指定（默认 `~/jarvis-home/`）含 `state/` | 创建 + `git init`（onboarding.md §3） |
+| 项目空间判据 | 目标含 `.team-flow/` + `changes/` | **拒绝派发**（普通模式本期不支持） |
+| 机器不休眠 | `pmset -g` 的 `sleep` 为 0 且 `pgrep -x caffeinate` 有进程 | `caffeinate -i` |
+
+**并取得自身会话名**（反向寻址的前提）：`ListAgents` 的首行 `This session is <name>` 即本会话名。**崩溃恢复后须重新取得**（重启即新会话，名可能变）。
+
+探测结果向用户报告一张「就绪 / 待补齐」清单，补齐后方可进 Phase 1。
+
+## Phase 1：睡前授权（用户在场，约 5 分钟）
+
+1. 接收任务：项目空间、change、完成标准
+2. **预案扫描**：读 change 现状 + 偏好库，列出预期决策点及其默认裁决，一并确认**架构门状态**与**执行模式**（两者决定夜间能走多远）
+3. **读回**：把任务 + 逐点授权 + 红线完整读给用户
+4. **落盘**：用户确认后写 `state/mandate-<YYYY-MM-DD>.md`（模板见 `references/protocols.md`，**须含 Jarvis 会话名字段**）
+5. **派发**：`run-create` → `task-create --spec <...>` → `worker-start --task <id> --worktree "path:<项目根>" --agent claude`
+   - task spec **必须含五条硬指令**（完整措辞见 `references/protocols.md` §二）：① **禁止使用 AskUserQuestion**；② 决策点一律 `orca orchestration ask` 转 Jarvis（**须补 `--from` / `--dispatch-capability` 鉴权参数**）；③ **`ask` 超时禁止自行裁决**——保留 message_id 用 `--resume` 续等，续等仍超时则停并上报；④ 完成或阻塞时用 `send --type worker_done` 上报；⑤ **附上 Jarvis 会话名**，供 worker 启动后主动联系（反向寻址）
+
+## Phase 2：夜间值守
+
+### 主循环（worker 提问 → 代答）
+
+1. `orca orchestration check --wait --types question,worker_done,escalation --timeout-ms 600000 --json`
+2. 逐条处置：
+   - `question` → 按 `references/decision-points.md` 三档裁决 → `orca orchestration reply --id <msg_id> --body "<答复>"`（代答）或 `--body "HOLD: <原因>"`
+   - `worker_done` → **先选定该 worker 终端的归宿**（官方强制：不得留活终端）：有后续 task 则 `worker-start --task <next> --terminal <worker.agent_terminal_handle>` 复用，否则 `orca orchestration worker-release --dispatch <id>`
+   - `escalation` → 记入早报「等你决定」
+3. **每个裁决即时写日志**（不等收工）：`state/decisions-<YYYY-MM-DD>.log`
+4. 处理完再确认：`orca orchestration check --ack <delivery_id> --wait ...`
+
+> **走 `ask` 还是等 worker 主动？** 二者的分野不在命令，而在**接收端是否有进程阻塞等待**：worker 阻塞在 `ask` 时消息必达；worker settle 后则无人读邮箱。
+
+### 唤醒通道（worker 已停）
+
+**`send --to dispatch` 唤醒已实证不可用**（消息 `read=0` 永久滞留邮箱）→ 改用 Claude Code 原生 **`SendMessage`**：
+
+- **发现**：`ListAgents` 能看到本机所有会话，含 Orca 派发的 worker
+- **唤醒 / 追问**：`SendMessage(to: <worker 会话名>)`——**已实测可唤起 idle 会话**
+- **反向寻址**：worker 会话名随机，Jarvis 无法预知 → 由 worker 启动后主动联系 Jarvis（task spec 已附 Jarvis 会话名；worker 侧地址来自其 session 的 `from=`）
+- **不可达时退化**：重新派发（`worker-start` 新 task，已实证可行，代价是原 worker 上下文丢失）
+
+### 异常处置
+
+5. **`check` 超时未收到 `worker_done`**：`worker-show --dispatch <id>` 判状态——
+   - `ready` → 继续等（长任务常态）
+   - `failed` / `stopped` → **先 `orca orchestration task-update --id <t> --status ready`**（失败会连坐 task，否则报 `task_not_startable`），再 `worker-start --task <t> --retry-of <dispatch> --on <saved-environment> --worktree <...> --agent claude`（`--task` 为必填；`--retry-of` **不继承位置**，须显式重复三个参数）
+   - `outcome_unknown` → `worker-stop --dispatch <id>` 后检查
+   - worker 停在 `observation.agentWait` 是**健康态**，不是故障
+   - 每次判状态后追加 `health` 日志行
+6. **Jarvis 自身异常恢复**（通道堵死 / 会话崩溃）：
+   - **通道停更判据**：`check --wait` 连续 2 次满超时（各 10 分钟）且期间零消息 → 记 `health` 行 `channel_stalled`，改用 `worker-show --dispatch <id>` 逐个轮询
+   - **崩溃恢复**：状态**只在磁盘**——重入时先读 `state/mandate-<date>.md` + `decisions-<date>.log`，再用 `worker-show` 逐个对账 dispatch 状态，**禁止凭记忆续跑**
+   - **会话名核对**（反向寻址的持久性）：重启后 `ListAgents` 重新取得自身会话名；**若与 mandate 记录不同，旧地址已失效** → 用 `ListAgents` 反查 worker 会话名后主动联系，或让 worker 重新上报
+
+**裁决依据优先级（高→低）**：授权书红线 > 授权书逐点授权 > 偏好库条目 > 可推断。
+**冲突时红线优先**（例如偏好库里「收尾即提交推送」在夜间不适用，一律不 push）。
+
+## Phase 3：早上交付
+
+从决策日志渲染早报 `state/report-<YYYY-MM-DD>.md`（格式见 `references/protocols.md`），六段式：① 夜间健康度 ② 各 change 进度 ③ 我替你做的决策 ④ 等你决定的 ⑤ 试过但失败的 ⑥ 成本。
+
+**早报必须逐条列出 HOLD 项**，每项附「问题 + 选项 + Jarvis 倾向 + 依据」，便于用户批量裁决。
+
+## 硬约束
+
+- **禁止 AskUserQuestion**：`agent_prompt_stalled` 在**派发阶段**最常见的触发点是 **shell 启动期的交互提示**（2026-09-12 实测：oh-my-zsh 更新提示吃掉 `claude` 命令首字母 → 实际执行 `laude`），故障发生在 worker 真正启动**之前**，报错完全不指向真因。**注意**：运行中弹 TUI 模态是另一触发点，同样无自动化手段可救——该结论**未被推翻**
+- **Jarvis 不改 team-flow 状态文件**：决策点状态由 worker 经 `tf state set` 写入（`dp_4_result` 由 `tf execution plan --confirm` 程序化写入，不可 set；**HOLD 场景不写任何决策点字段**——12 个字段已于 v0.59.0 移出白名单，写入即**显式报错**，见 `references/protocols.md` §三）
+- **HOLD 是主要形态**：无法代答的点一律 HOLD，**不得静默放行**
+- **不做沉默即同意**：`ask` 超时不产生默认裁决，保留 thread id 待恢复
+- **不假设未验证的机制**：worker 遵循指示是靠 task spec 约束的运行时行为；每次任务须核对早报与**决策日志 + change 的 `state` 位置**是否一致（字段能否落盘须实测，勿据白名单推断）
+
+## 参考文件
+
+- **`references/onboarding.md`** — 首次接入：环境检查矩阵、偏好库初始化（三种方式）、Jarvis home 初始化、就绪检查
+- **`references/decision-points.md`** — 9 个决策点 + 5 个确认点的代答权限、三档处置规则、夜间红线清单
+- **`references/protocols.md`** — 授权书模板、worker task spec 模板、HOLD 六步协议、**决策日志与早报格式**

package/skills/{decision-surrogate → jarvis}/references/decision-points.md

@@ -1,6 +1,6 @@
 # 决策点代答权限与处置规则
 
-> 来源：工作区仓 `docs/plan/decision-surrogate-design.md`（v4.1 §6）；决策点权威定义见插件内 `docs/decision-points.md`
+> 来源：工作区仓 `docs/plan/jarvis-design.md`（v4.2 §6）；决策点权威定义见插件内 `docs/decision-points.md`
 
 ## 一、完整清单（9 个 DP 门 + 5 个确认点）
 
@@ -8,7 +8,7 @@
 |--------|------|--------|---------|
 | 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-2 | 工件审查 | 待 P0 确认 | `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` |

package/skills/{decision-surrogate → jarvis}/references/onboarding.md

@@ -1,12 +1,26 @@
-# 首次接入：环境探测与初始化
+# 首次接入：环境检查与初始化
 
-> 目标：把「一台裸机 + 一个想用替身的人」带到可启动状态。全部探测**只读**；所有写操作（建目录、写偏好库）**先向用户说明再执行**。
+> 目标：把「一台裸机 + 一个想用 Jarvis 的人」带到可启动状态。全部检查**只读**；所有写操作（建目录、写偏好库、改信任配置）**先向用户说明再执行**。
 
-## 1. 环境探测矩阵
+## 1. 环境检查矩阵
 
 按顺序执行，记录每项状态；任何一项不可用都应给出**具体引导命令**，而非笼统报错。
 
-| # | 探测项 | 命令 | 就绪判据 | 缺失时的引导 |
+### 1.1 派发前置项（v0.60.0 新增，据 2026-09-12 实测）
+
+**这两项不满足时 worker 派发会静默失败**，且报错（`agent_prompt_stalled`）完全不指向真因——**故障发生在 worker 真正启动之前**。
+
+| # | 检查项 | 命令 / 判据 | 缺失时的引导 |
+|---|--------|-----------|-------------|
+| P1 | **shell 启动无交互提示** | 新开一个终端，观察是否停在等待输入（如更新提示）；检查 shell 配置有无更新检查 / `read` | 关闭自动更新检查（如 oh-my-zsh 的 `DISABLE_UPDATE_PROMPT` / `DISABLE_AUTO_UPDATE`）。**修复后仅对新建终端生效**，已存在的终端不受影响 |
+| P2 | **目标目录已被 claude 信任** | `~/.claude.json` → `projects["<路径>"].hasTrustDialogAccepted == true` | 预置该字段（**先备份** `~/.claude.json`；并发 claude 进程可能覆盖配置，改完尽快验证） |
+
+> **实测教训（2026-09-12）**：oh-my-zsh 更新提示吃掉 Orca 注入的 `claude` 命令首字母 → 实际执行 `laude` → claude 从未启动 → task spec 落进 shell。造成 **5 次连续派发失败**。
+> **现场特征**：spec 文本落在 shell 上（`zsh: parse error`）、启动命令被吃字符（`command not found: laude`）。**见到这两个特征先查 shell 提示，不要先怀疑 Orca。**
+
+### 1.2 环境项
+
+| # | 检查项 | 命令 | 就绪判据 | 缺失时的引导 |
 |---|--------|------|---------|-------------|
 | 1 | Orca CLI | `which orca` | 返回路径 | `brew install orca`（macOS） |
 | 2 | Orca runtime | `orca status --json` | `result.runtime.state == "ready"` | `orca open`（启动桌面应用并等待 runtime 可达） |
@@ -15,14 +29,14 @@
 | 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 |
+| 8 | Jarvis home | `test -d <home>/state` | 目录存在 | 走 §3 |
 | 9 | 机器不休眠 | `pmset -g` 的 `sleep` 为 0；`pgrep -x caffeinate` 有进程 | 两者满足 | `caffeinate -i`（前台保持）；或说明夜间须保持机器唤醒 |
 
 **输出**：一张「就绪 / 待补齐」清单交给用户，**补齐后才进 Phase 1**。
 
 ## 2. 偏好库初始化（三种方式，按投入递增）
 
-偏好库是替身判断力的唯一来源；**没有它就不要启动替身**（否则替身只能全量 HOLD，等于没做）。
+偏好库是 Jarvis 判断力的唯一来源；**没有它就不要启动**（否则只能全量 HOLD，等于没做）。
 
 ### 方式 A：交互式最小收集（约 5 分钟，建议起步用）
 
@@ -49,7 +63,7 @@
 
 ### 方式 C：从历史会话挖掘（最完整，成本最高）
 
-适用：用户已积累数月会话记录，希望替身更贴近本人。
+适用：用户已积累数月会话记录，希望 Jarvis 更贴近本人。
 
 1. 定位会话：`~/.claude/projects/<按路径转义的项目目录>/*.jsonl`
 2. 提取人类输入（过滤 `tool_result`、以 `<` 开头的注入块、上下文压缩摘要、skill 内容）
@@ -58,22 +72,24 @@
 
 **建议**：先用 A+B 起步运行，积累几周后再用 C 做一次深度校准。
 
-## 3. 替身 home 初始化
+## 3. Jarvis home 初始化
 
 ```bash
 mkdir -p <home>/state
 cd <home> && git init
 ```
 
-- 默认路径 `~/Documents/work/code/practice/surrogate-home/`（用户可指定其他路径）
+- 默认路径 `~/jarvis-home/`（用户可指定其他路径）
 - `state/` 承载：授权书 `mandate-<date>.md`、决策日志 `decisions-<date>.log`、早报 `report-<date>.md`、任务队列 `queue.md`
 - home **与业务项目解耦**；偏好库不放这里（它在 `~/.claude/lt-preferences/`，属用户级、跨项目可用）
+- 建议在 home 下加 `.gitignore`，排除实测沙箱等临时目录
 
 ## 4. 就绪检查（进 Phase 1 前）
 
-- [ ] 环境探测矩阵 9 项全部就绪
+- [ ] **派发前置项 2 项**（shell 提示 / 目录信任）
+- [ ] 环境项 9 项全部就绪
 - [ ] 偏好库存在且非空（≥1 条）
-- [ ] 替身 home 存在且含 `state/`
+- [ ] Jarvis home 存在且含 `state/`
 - [ ] 用户已确认目标项目空间与 change
 
 全部打勾后，向用户复述一次本次任务的**范围与红线**，再进 Phase 1。

package/skills/{decision-surrogate → jarvis}/references/protocols.md

@@ -1,5 +1,7 @@
 # 协议模板集
 
+> **命令形态以官方为准**：本文件与 SKILL.md 中的 `orca` 命令随 Orca 版本演进。**运行前建议先读一次版本匹配的官方指南**（`orca skills get orchestration`），不要凭记忆推断子命令或参数——v0.60.0 实测暴露的 4 处 skill 缺陷之一即命令形态错误（`orca ask` 简写不存在）。
+
 ## 一、授权书模板 → `state/mandate-<YYYY-MM-DD>.md`
 
 ```markdown
@@ -12,6 +14,7 @@
 - **架构门状态：已过 / 未过**（未过则夜间止于 exploring）
 - 需求范围：<scope 摘要，供 DP-1 条件代答判据>
 - **执行模式：<TDD|SDD|inline|不指定>**（不指定则夜间止于 approved-for-build）
+- **Jarvis 会话名：<name>**（供 worker 主动联系用。**崩溃恢复后须核对是否仍有效**——重启即新会话、名可能变，失效时应让 worker 用 `ListAgents` 反查并重新上报，详见 §二「反向寻址」）
 
 ## 逐点授权
 | 决策点 | 授权 | 条件 |
@@ -40,14 +43,19 @@
 【协调协议 — 必须遵守】
 1. 严格禁止使用 AskUserQuestion 工具。任何需要用户确认的点，一律用
    `orca orchestration ask --question "<问题>" --options "<选项逗号分隔>" --timeout-ms 600000`
-   转给协调者（替身），等待 reply 后再继续。
+   转给协调者（Jarvis），等待 reply 后再继续。
+   ⚠️ 须带鉴权参数 `--from` 与 `--dispatch-capability` —— 裸命令返回 `dispatch_capability_invalid`
+   （2026-09-12 实测）。两个值见你启动时收到的 preamble；无从获取时向 Jarvis 求助，**不要猜测**。
 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 启动时注入的值，**不要自行编造**。
+   `orca orchestration send --type worker_done --outcome <succeeded|failed> --subject "<状态>" --body "<三句话：做了什么、发现了什么、还剩什么>" --task-id <注入的 taskId> --dispatch-id <注入的 dispatchId> --json`
+   报告，随后结束本轮。**必须带 `--task-id` / `--dispatch-id`**——Orca 据此自动结算 task（不带则 task 不会自动完结）。两个 ID 使用 Orca 启动时注入的值，**不要自行编造**。
+5. **启动后主动联系 Jarvis**：用 SendMessage 向会话 `<Jarvis 会话名>` 发送
+   「worker 已就绪，工作目录 <路径>」。这一步让 Jarvis 得知你的会话名，
+   后续才能唤醒你（worker 会话名随机，Jarvis 无法预知 —— 反向寻址）。
 
 【红线 — 绝对禁止（违反即停）】
 - `push`（含 `tf publish --arch --push`）
@@ -61,22 +69,24 @@
 
 > 派发命令：`orca orchestration worker-start --task <task_id> --worktree "path:<项目根>" --agent claude --json`
 > `path:` 只能指向**项目根**（Orca 注册主 worktree）；`tf isolate` 建的 `.worktrees/...` 路径不可用（返回 `selector_not_found`）。
+> **派发失败的现场特征见 SKILL.md「硬约束」**——`agent_prompt_stalled` 多由 shell 启动期提示或目录未信任所致，**不是 Orca 故障**。
 
 ## 三、HOLD 协议（worker 侧六步）
 
 | 步骤 | 动作 |
 |------|------|
-| ① 替身裁决 | `orca orchestration reply --id <msg_id> --body "HOLD: <原因>"` |
+| ① Jarvis 裁决 | `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 记录 | **不写任何决策点字段**。两条禁令：① `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 个）**已于 v0.59.0 移出 `cmd-state.mjs` 的 `SETTABLE_FIELDS` 白名单**——写入即显式报错 `⛔ Field '...' is not settable` 并以非 0 退出（**原为「回显 ✅ 却零写入」的静默假成功，v0.59.0 P4 实测后改为 fail-loud**；`dp_0_decisions`/`dp_0_confirmed` 不在移除之列，二者确有序列化分支）。HOLD 的持久锚点 = 步④ 的 escalation 消息 + 步⑥ 的 Jarvis 决策日志 + change 的 `state` 仍停在门禁前（客观事实）。**约束**：不得新建 `changes/<name>/` 下任何文件（Artifact Ownership：「主会话」此处指 **worker 侧**的主会话——它 MUST NOT 直接 Edit/Write `changes/` 或 `.worktrees/`；与 Jarvis 侧会话无关） |
 | ④ 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） |
+| ⑤ worker 处置 | 用 `orca orchestration worker-retain --dispatch <id>` 标记保留（**不可用 `worker-release`**——官方禁止因 escalation/question/idle 释放）。**语义澄清**：`worker-retain` 的官方定位是 "keep one supervised worker terminal live for debugging"，**HOLD 保活属借用**该语义；保活效果与普通 settled 态的差异尚未实测（设计文档 §7.5 ⑪） |
+| ⑥ Jarvis | 写决策日志 + 早报「等你决定」段（问题/选项/Jarvis 倾向/依据/msg_id） |
 
 **多任务**：一个 HOLD 不阻塞其他 worker。
-**早上恢复**：用户批阅早报 → 给出裁决 → `orca orchestration send --to dispatch:<id> --subject "<裁决>"` 投递 → worker 解除 HOLD 继续。
+**早上恢复**：用户批阅早报 → 给出裁决 → **用 `SendMessage` 投递到该 worker 会话** → worker 解除 HOLD 继续。
 
-> ⚠️ **此路径依赖 §7.5 ⑧⑨（未实证）**：附录 D ⑧ 验证的是 `reply` 唤醒（ask→reply 通道），**与「向 dispatch 主动 `send`」不是同一条路径**。首次启用前必须实测；不通则退化为人工续跑（重新派发任务）。**不得据相邻机制的实测结论推断本路径可用**。
+> **为何不是 `send --to dispatch`**：2026-09-12 实测证明**该路径不可用**——HOLD 时 worker 已 settle（不在阻塞等待态），消息 `read=0` 永久滞留邮箱。改用 SendMessage（同场景实测可唤起 idle 会话）。
+> **⚠️ 待补验**：HOLD 的 `worker-retain` 保活态与实测的普通 settled 态**是否等价尚未验证**。补验前**先试 SendMessage，失败则退化为重新派发**（已实证可行，代价是上下文丢失）。
 
 ## 四、决策日志格式 → `state/decisions-<YYYY-MM-DD>.log`（append-only）
 
@@ -94,7 +104,7 @@ cost     | [HH:MM] | 累计:<token|时长>
 ## 五、早报格式 → `state/report-<YYYY-MM-DD>.md`
 
 ```
-# 替身早报 <日期>
+# Jarvis 早报 <日期>
 
 ## ① 夜间健康度
 心跳时间戳范围 / 是否卡过 / 有无告警
@@ -106,7 +116,7 @@ cost     | [HH:MM] | 累计:<token|时长>
 | 时间 | change | 决策点 | 选择 | 理由 | 依据 | 置信 |
 
 ## ④ 等你决定的（HOLD）
-| 决策点 | 问题 | 选项 | 替身倾向 | 依据 | 恢复命令 |
+| 决策点 | 问题 | 选项 | Jarvis 倾向 | 依据 | 恢复命令 |
 （逐条列全，便于批量裁决）
 
 ## ⑤ 试过但失败的

package/skills/workflow-orchestrator/SKILL.md

@@ -23,6 +23,18 @@ description: >-
 
 **设计哲学（v0.7）**：编排层**只编排**（状态判断、路由、阶段转换、用户确认），执行委托 subagent/会话 skill；从「固定管道」升级为「默认路径 + 任意时刻可重规划」；PRD vN = 一次迭代版本，迭代内变更不升版。
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认，含 S1 路径路由、S4 同步门禁）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（续版需求 / 重新计划 / 单 change 快速通道 / 聚合 / 限界上下文 等）下沉到 description，首次出现括注白话等价。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（走哪条路径 / 是否同步），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语。
+
+反例：S1 直接问 `单 change 快速通道 / 续版需求 / 重新计划` 不解释区别。
+正例：S1 问 `你这步想做什么？`；A「从头做新功能（推荐）」B「在已有版本上加功能」C「只调一下计划」——各自 desc 说明选了会怎样。
+
 ## Use This Skill When
 
 - 用户提出新的产品级需求：「我有个想法」「做一个 XX 功能」「从头开始」、模糊需求

package/skills/workflow-orchestrator/references/s1-path-router.md

@@ -24,7 +24,13 @@ S1 只做编排动作（需求选择、存在性检查、路径判断、阻塞
 | **重新计划** | PRD 已冻结，plan 需调整 | → S3 | 跳过 brainstorm；S3 完成后进 ARCH（产品级架构设计，v0.35.0）再拆 change |
 | **继续执行** | changes 已拆分，继续下一个 | → S4/S5 | 先输出状态恢复简报，用户确认后继续 |
 | **单 change 快速通道** | 需求极清晰，无需 PRD（仅限单一功能点、无 UI、无跨模块依赖的极小变更） | → 直接创建 change → workflow-start | 最轻量路径，无 PRD 锚点，**不可触发 S3→S2 回退** |
-| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 直接创建 change（type: hotfix，注入 bug 描述替代 PRD）→ workflow-start | closing 时强制补录复利 |
+| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 匹配源 change（见下「Hotfix 命中源 change」）→ 直接创建 change（type: hotfix，注入 bug 描述替代 PRD，带源 change 引用）→ workflow-start | closing 时强制补录复利 |
+
+**Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：用户报 bug / 线上问题时，先尝试把缺陷回溯到引入它的源 change，再做轻量修复：
+1. **匹配**：`git blame` 受影响文件 / 符号 → 定位引入 commit → 经 `change_dag` / `change-brief` / `learnings.md` 反查 `change_dir`；或按受影响 capability 在全局 `specs/` 检索归属 change。
+2. **命中** → 新建 hotfix change 时携带「源 change 引用」（写 `change-brief.md` 的 `source_change_ref`，无 brief 则记 `learnings.md`），workflow-start 路由时复用源 change 的 `design.md` / `specs` / `tests` 上下文做轻量修复，省去重复 scope 确认。
+3. **非命中**（独立缺陷 / 新文件）→ 走原 Hotfix，无源 change 引用。
+4. **必须用户确认匹配结果**；失准优雅降级 Hotfix，**绝不静默自动 reopen** 源 change。
 | **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做/重跑原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4） | PRD 不动，保留有效 S3 plan / S4 changes，闭环后恢复原 phase；`replan_log` 记往返 |
 
 **判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `requirement/` 目录（有 PRD → 「续版」候选；legacy: `prd/`），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -87,6 +87,7 @@ upstream_plan_ref: requirement/vN/plan.md      # hotfix/快速通道为 null
 upstream_arch_ref: docs/architecture/iterations/vN/architecture.md  # 产品级架构快照（v0.36.3）；ARCH skip 或 hotfix 为 null
 upstream_change_id: C2                 # 对应 change_dag.id
 plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
+source_change_ref: <change-dir>         # 可选：本 change 是对某已存在 change 缺陷的快速修复（v0.61.0 bugfix 增强，设计依据 v0.26 §203）；非 bugfix 留空
 ---
 # Change Brief: <change-name>
 

package/skills/workflow-start/SKILL.md

@@ -26,6 +26,18 @@ Do NOT invoke for: general coding tasks outside team-flow changes, casual questi
 3. **Overlay recovery scan**: Run `tf handoff list <change-dir> --json` and `tf checkpoint list <change-dir> --json`. A `result-ready` handoff requires explicit review and `tf 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 `tf 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.
 
+## 决策话术规范（人类化原则，v0.60.x 新增）
+
+本 skill 向用户提出的每一个决策问题（AskUserQuestion / 阻塞确认）必须遵守：
+
+1. **用大白话讲"结果"，不讲"机制"**：选项 label ≤ 12 字，描述"选了会怎样"；技术术语（SDD / Inline / 聚合 / 限界上下文 / CQRS 等）下沉到 description，且首次出现括注白话等价（如 `聚合（一组相关的业务数据，比如一张订单及其明细）`）。
+2. **选项是"你选哪个"的口吻**：给 2-3 个带取舍的候选 + 一项推荐，不抛单一路径让用户盲选。
+3. **决策点 = 帮你拍板的岔路口，不是考试**：只问用户有能力判断的事（范围 / 优先级 / 方向），不让他做机制选型。
+4. **术语精度保底在 description**：label 必须零术语；需要精确术语时在 description 内保留。
+
+反例：DP-4 label `执行模式选择：SDD / Inline / Batch Inline`。
+正例：DP-4 label `怎么推进这批改动？`；A「稳妥分批（推荐）」desc `每批带测试、可回退，最稳`；B「一口气写完」desc `快但出错难定位`；C「内联小改」desc `改动极小时用（术语 SDD=……）`。
+
 ## 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`.
@@ -184,6 +196,7 @@ work.
 **不合并**：`arch_design_decision == required` 时 DP-A 必须独立——用户需单独审架构产物。
 
 - **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`, and `specs/`, but it still requires a fresh minimal `execution-contract.md`, DP-3 approval, and a current execution plan before build. **`tasks.md` 不得静默缺失（v0.22 §85）**：hotfix 默认不产出该文件，但必须由 contract-builder 显式登记 `tasks_skipped=true` + `tasks_skip_reason`（或一并产出最小任务清单，归属 contract-builder）——`tasks-complete` 在 closing 考核该维度，静默缺失会死锁（修复前即此状态）。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门，快速判定是否涉及架构变更（hotfix 可能正是架构缺陷导致）
+- **Hotfix 命中源 change（v0.61.0 增强，设计依据 v0.26 §203）**：若 S1 已匹配到引入该缺陷的源 change（`source_change_ref`），本 change 路由时**复用源 change 的 `design.md` / `specs/` / `tests` 作为已知设计约束上下文**，省去重复 scope 确认——修复只针对缺陷点，不重做整体设计。消费方式：读取 `change-brief.md` 的 `source_change_ref`（或 `learnings.md` 记录）指向的源 change 目录，将其 design/specs 作为背景注入 contract-builder / build-executor。**门禁**：源 change 匹配结果由 S1 阶段用户确认；本层**绝不静默 reopen** 源 change，仅在本 hotfix change 内复用其上下文。匹配失准时退化为普通 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). **`tasks.md` 须显式 skip（v0.22 §85）**：tweak 跳过 spec-writer 与 contract-builder，故既无原生 `tasks.md` 也无人代写——由**主代理**经 `tf state set` 写入 `tasks_skipped=true` + `tasks_skip_reason`（`tf state set` 是 CLI 调用，不违反 Artifact Ownership 的 Edit/Write 禁令），否则 `tasks-complete` 在 closing 死锁。tweak 的 `executing:closing` 不含 `test-matrix-complete`（`guard.mjs:82`），矩阵豁免非 guard 必需。**architecture-design 不豁免**（v0.9 §26）：同样过 architecture-design 子代理判断门
 
 Post-transition: 💡 `tf inject <change-dir>` to update phase-guard artifacts.