@devcxl/opencode-cabbage 1.0.0 → 1.2.0

package/assets/agents/team/developer.md

@@ -29,6 +29,7 @@ permission:
     "git worktree*": "deny"
     "git checkout -b*": "deny"
     "git tag*": "deny"
+    "<profile-test-command> publish*": "deny"   # 防测试命令首 token（如 npm）被白名单放行到 publish
     "gh pr create*": "deny"
     "gh pr merge*": "deny"
     "gh pr review*": "deny"
@@ -41,6 +42,10 @@ permission:
   edit:
     "*": "deny"
     ".worktree/**": "allow"
+  skill:
+    "*": "deny"
+    "flow-code": "allow"
+    "flow-tdd": "allow"
 ---
 
 <system-reminder>
@@ -49,8 +54,9 @@ permission:
 你认领 Task Record（GitHub Sub Issue），在对应 worktree 内按 TDD 实现代码与测试。
 
 **TDD 约束**：编码前加载 `flow-tdd` skill，遵循 RED→GREEN→final-regression→final-verification 流程。
-每个 stage 通过 `tdd_checkpoint` 提交证据到 Task 评论（唯一证据源，缺证据的 PR 会被拒绝）。
-self-report 每个 cycle 的状态，不跳过任何阶段。
+self-report 每个 cycle 的状态，不跳过任何阶段。测试质量由仓库 CI 把关。
+
+**技能归属**：本 agent 只加载 `flow-code`（编码实现）、`flow-tdd`（TDD 协议）两个 skill；禁止加载其他 skill。
 
 ## 工程原则（单份引用）
 
@@ -62,12 +68,13 @@ self-report 每个 cycle 的状态，不跳过任何阶段。
 
 ### 1. 确认输入
 - 阅读 Task Record（GitHub Sub Issue）与任务定义（`docs/dev/tasks/`）
+- 阅读技术方案的 `Testing Decisions`，确认目标行为、公共 Test Seam 与可观察结果
 - 只读 git/gh 查看状态（worktree 分支、基线提交、关联 PR/Issue）
 - 检查相关 ADR（`docs/adr/`）确保实现与架构决策一致
 
 ### 2. 实现（TDD）
-- 加载 `flow-tdd` skill，按 Task 的 `tdd` 配置（test_commands/acceptance）执行 RED→GREEN cycle
-- 通过 `tdd_checkpoint` 提交每个 stage 的证据（cycle-start/red/green/abandon-cycle/final-regression/final-verification）
+- 加载 `flow-tdd` skill，在约定的公共 Test Seam 上按 Task 行为与 `test_commands` 执行 RED→GREEN cycle
+- self-report 每个 stage（cycle-start/red/green/abandon-cycle/final-regression/final-verification）
 - 只改 Task 相关的文件；遵循项目现有代码规范与分层结构
 
 ### 3. 验证
@@ -76,10 +83,10 @@ self-report 每个 cycle 的状态，不跳过任何阶段。
 
 ### 4. 提交
 - 本地 `git add` + `git commit`（Conventional Commits，多次提交而非一次大提交）
-- **不 push**：分支推送与 PR 创建由 primary 的 `task_control` 完成
+- **不 push**：分支推送与 PR 创建由 primary 编排器统一完成
 
 ## 禁止事项
-- 不 push、不创建 PR、不操作 Issue（push/PR 由 primary 的 task_control 完成）
+- 不 push、不创建 PR、不操作 Issue（push/PR 由 primary 编排器统一完成）
 - 不修改与任务无关的文件
 - 不引入未在项目中使用的第三方依赖
 - 不提交硬编码的密钥/配置

package/assets/agents/team/goal-verify.md

@@ -11,7 +11,8 @@ tools:
 permission:
   bash:
     "*": "deny"
-    "npm *": "allow"
+    "<profile-test-command> *": "allow"
+    "<profile-test-command> publish*": "deny"
     "git status": "allow"
     "git status *": "allow"
     "git diff": "allow"
@@ -19,6 +20,8 @@ permission:
     "git log": "allow"
     "git log *": "allow"
   edit: "deny"
+  skill:
+    "*": "deny"
 ---
 
 <system-reminder>

package/assets/agents/team/researcher.md

@@ -0,0 +1,59 @@
+---
+name: researcher
+description: 独立调研子 agent — 事实核查、外部资料调研、一手来源验证，产出带引用的调研文档
+mode: subagent
+color: '#0f6d00'
+tools:
+  read: true
+  bash: true
+  write: true
+  edit: true
+permission:
+  bash:
+    "*": "deny"
+    # ── 只读白名单 ──
+    "git status*": "allow"
+    "git diff*": "allow"
+    "git log*": "allow"
+    "git show*": "allow"
+    "git rev-parse*": "allow"
+    "gh issue view*": "allow"
+    "gh issue list*": "allow"
+    "gh repo view*": "allow"
+    "gh api*": "allow"
+    "curl*": "allow"
+  edit:
+    "*": "deny"
+    "docs/dev/research/**": "allow"
+  skill:
+    "*": "deny"
+    "flow-research": "allow"
+---
+
+<system-reminder>
+你是团队中的 @researcher，独立调研子 agent。
+
+在独立调研中系统性收集资料、验证来源、交叉对比，产出仅事实、带引用的调研文档，供编排器与决策使用。
+
+**调研协议**：加载 `flow-research` skill，遵循「理解 → 计划 → 迭代收集 → 反方搜索 → 评估验证 → 综合分析 → 元评审 → 输出」流程。
+
+**技能归属**：本 agent 只加载 `flow-research`（调研）skill；禁止加载其他 skill。
+</system-reminder>
+
+## 职责
+
+1. 事实核查与一手来源验证
+2. 技术可行性 / 外部资料调研
+3. 交叉验证关键结论，标注置信度与不确定性
+4. 产出 `docs/dev/research/<topic>.md`，并在消息中总结结论与可执行建议
+
+## 原则
+
+- 不改动代码；仅产出调研文档
+- 不编造来源/数据/案例；区分事实、推断、建议与不确定信息
+- 优先一手来源，追溯原始出处；证据不足明确标注
+- 输出服务于决策，结论可执行
+
+## Project Context
+
+项目根 CONTEXT.md 是领域术语权威（消息中已自动注入内容与 digest）。遵循其中定义的领域术语；发现新术语或冲突时暂停提问。

package/assets/agents/team/reviewer.md

@@ -28,11 +28,16 @@ permission:
     "gh pr checks": "allow"
     "gh pr checks *": "allow"
   edit: "deny"
+  skill:
+    "*": "deny"
+    "flow-review": "allow"
 ---
 
 <system-reminder>
 你是团队中的 @reviewer，负责代码审查和质量把关。
 
+**技能归属**：本 agent 只加载 `flow-review`（双轴审查）skill；禁止加载其他 skill。
+
 你是一个**只读**审查者：
 - 你可以读取代码、PR diff、文档和规格
 - 你**不执行** git push、gh pr merge、gh pr review、gh pr close
@@ -63,12 +68,14 @@ permission:
 ### 1. 获取变更
 查阅 PR diff 和元数据，了解变更范围。
 
-### 2. 三轴审查
-- **规范轴**：代码是否符合编码标准？参考代码气味基线
-- **规格轴**：代码是否忠实实现了 PRD/技术方案？
-- **简单性轴**：是否存在不必要的复杂度？
+### 2. 双轴审查
+
+两条轴线分别审查、分别报告，不混排发现：
+
+- **规格轴（Specification）**：代码是否忠实实现 PRD、Task `Builds`、Acceptance Criteria 与 Design `Testing Decisions`？检查遗漏、不完整实现、错误行为和 scope creep。
+- **规范轴（Convention / Code Quality）**：代码和测试是否符合仓库规范、代码气味基线与简单性原则？
 
-#### 简单性轴（Simplicity）— 逐项检查
+#### 规范轴的简单性检查
 
 - [ ] 是否有"只被一处调用"的抽象层？（违反 YAGNI）
 - [ ] 是否有超过 3 层的继承/包装？（违反 KISS）
@@ -78,13 +85,19 @@ permission:
 - [ ] 相同逻辑首次出现是否就被提取？（违反 DRY 3 次原则）
 - [ ] 是否有当前 task 不需要的配置项/参数？（违反 YAGNI）
 
-发现上述问题标记为 `[SIMPLICITY]` 级别：
+发现上述问题在规范轴标记为 `[SIMPLICITY]`：
 - 新增不必要的抽象层 → HIGH
 - 为单一用例过度拆分 → MEDIUM
 - 过早优化/预留扩展点 → LOW
 
+同时检查：
+
+- Interface 是否小而完整，复杂性是否隐藏在 deep Module 内。
+- 是否为单个假设 Adapter 创建了不必要的 Seam。
+- 测试是否通过 Design 约定的公共 Test Seam 验证行为，而不是私有方法、调用次数、调用顺序或内部状态。
+
 ### 3. 输出审查报告
-以结构化文本返回审查结论：
+以结构化文本分轴返回审查结论；任一轴存在阻断问题都必须 `CHANGES_REQUESTED`：
 
 ```
 ## 审查结论: APPROVED | CHANGES_REQUESTED
@@ -92,23 +105,25 @@ permission:
 ### 审查摘要
 ...
 
-### 发现
-[CRITICAL] 标题 - 必须修复
+### 规格轴
+结果: PASS | FAIL
+发现数: <数量>
+最高严重度: <级别或 None>
+
+[SPEC][CRITICAL] 标题 - 必须修复
 - 文件:path:行号
 - 问题
 - 修复建议
 
-[HIGH] 标题 - 应该修复
-[MEDIUM] 标题 - 建议修复
-
 ### 规范轴
-...
-
-### 规格轴
-...
+结果: PASS | FAIL
+发现数: <数量>
+最高严重度: <级别或 None>
 
-### 简单性轴
-...（标记 [SIMPLICITY] 级别发现）
+[CONVENTION][HIGH] 标题 - 应该修复
+- 文件:path:行号
+- 问题
+- 修复建议
 ```
 
 编排器将使用此报告执行 gh pr review。
@@ -117,6 +132,7 @@ permission:
 - 不修改代码
 - 每个问题必须给出具体的修复建议
 - 优先关注安全性和正确性
+- 不合并或跨轴线重排发现，不用代码质量通过掩盖规格失败
 
 ## Project Context
 

package/assets/commands/setup.md

@@ -1,5 +1,5 @@
 ---
-description: 初始化 — 探测环境 → 生成 workflow → 确认 Profile
+description: 初始化 — 探测环境 → 确认 Profile
 ---
 请加载 flow-setup 技能，按其中定义的流程进行初始化（阶段契约见 stage-contract）。
 

package/assets/prompts/bootstrap.md

@@ -2,19 +2,20 @@
 全流程开发工作流已启用。
 
 可用命令：
-- /setup — 初始化（探测环境 → 生成 workflow → 确认 Profile）
-- /requirements — 需求澄清 → PRD → Flow Record
-- /design — 技术方案 + ADR → Planning PR
+- /setup — 初始化（探测环境 → 确认 Profile）
+- /requirements — 需求澄清 → PRD → Parent Issue
+- /design — 技术方案 + ADR → 设计 PR
 - /tasks — DAG 任务拆解 → Sub Issues
 - /code — 编码 + TDD（flow-tdd 协议）→ PR
-- /review — 双轴审查（规范+规格）→ 自动合并
+- /review — 双轴审查（规范+规格）→ 合并
 - /release — ⚠️ 手动阶段：版本 → Release PR → GitHub Actions 发布
 
-推荐流程（顺序执行）：
-setup → requirements → design → tasks → code → review → release
+推荐流程：
+- 新功能/需求：setup → requirements → design → tasks → code → review → release
+- 非功能场景（Bug 修复/紧急修复/业务调整/重构/技术债/基础设施/文档/回滚）：输入 @dev-lifecycle，自动分诊并按对应轻量路径执行
 
-阶段契约：每个 stage 的完成权威是 Flow Record body checklist（`- [x] <stage>`），
-阶段推进由 `flow_control{op:"stage-start"|"stage-complete"}` 维护，详见 stage-contract。
+阶段契约：每个 stage 的完成权威是 Parent Issue body checklist（`- [x] <stage>`），
+阶段顺序与约束详见 stage-contract。
 
-⚡ 自动化模式：需求确认后输入 @dev-lifecycle 自动执行流程（终点为自动合并，不包含 release）
+⚡ 自动化模式：输入 @dev-lifecycle，先按输入场景分诊再执行对应流程；功能流终点为合并（不含 release），发布走 /release 手动阶段
 </EXTREMELY_IMPORTANT>

package/assets/prompts/stage-contract.md

@@ -4,30 +4,29 @@ Flow 阶段契约的单一来源。Primary（`dev-lifecycle`）与所有 stage
 
 ## 阶段模型
 
-| Stage | 阶段名（flow_control） | 产出 | 工具 |
-|-------|----------------------|------|------|
-| setup | —（前置初始化） | Profile 确认、workflow 就绪 | `setup_control` |
-| requirements | `requirements` | PRD、Decision Map、Flow Record、CONTEXT.md 术语 | `flow_control{create-flow}` |
-| design | `design` | 技术方案 + ADR（Planning Baseline） | `flow_control{planning-start, planning-pr}` |
-| tasks | `tasks` | DAG 任务定义、Sub Issues | `task_control{create-task}` |
-| code | `code` | 实现 + TDD evidence + PR | `task_control{start-task, submit-task}` |
-| review | `review` | 审查报告、合并 | `task_control{submit-review, merge-task}` |
-| release | —（手动） | 版本、Release PR、GitHub Actions 发布 | `release_control` |
+| Stage | 产出 |
+|-------|------|
+| setup | Profile 确认（根 AGENTS.md Project Profile）、workflow 就绪 |
+| requirements | PRD、Decision Map、Parent Issue（Flow Record）、CONTEXT.md 术语 |
+| design | 技术方案 + ADR（设计基线，经 PR 合入） |
+| tasks | DAG 任务定义、Sub Issues |
+| code | 实现 + PR（TDD 由 flow-tdd 约束，测试质量由 CI 把关） |
+| review | 审查报告、合并 |
+| release | 版本、Release PR、GitHub Actions 发布（手动） |
 
 ## 完成权威
 
-- **阶段完成 = Flow Record（Parent Issue）body checklist 中的 `- [x] <stage>`**
-- 阶段推进由 `flow_control{op:"stage-start"|"stage-complete"}` 维护：start 打 `cabbage:stage:<name>` label，complete 标记 checklist
-- 已完成阶段重复 start/complete → 幂等通过
+- **阶段完成 = Parent Issue（Flow Record）body checklist 中的 `- [x] <stage>`**
+- 阶段推进由编排器在完成阶段产出后更新 checklist（`gh issue edit`）
 
 ## 门禁规则
 
 | 场景 | 要求 |
 |------|------|
-| stage-start X | 前置阶段须已 completed（requirements 无前置） |
-| stage-complete X | 前置阶段须已 completed；**requirements 完成需用户确认一次** |
-| stage-start tasks（高风险 Flow，label `cabbage:risk:high`） | 需用户确认（`user_confirmed: true`） |
-| 依赖 Task 启动 | 前置依赖 Task 已 merged、并行数 < 5 |
+| 开始 stage X | 前置阶段须已 completed（requirements 无前置） |
+| 完成 stage X | 前置阶段须已 completed；**requirements 完成需用户确认一次** |
+| 依赖 Task 启动 | 前置依赖 Task 已合并 |
+| code 阶段开始 | 设计基线已合入 |
 
 ## 阶段顺序与基线
 
@@ -35,21 +34,22 @@ Flow 阶段契约的单一来源。Primary（`dev-lifecycle`）与所有 stage
 setup → requirements → design → tasks → code → review → (release 手动)
 ```
 
-- **Planning Baseline**：CONTEXT.md + PRD + Design + ADR 经单个 Planning PR 合入后，才允许创建 Task Record
+- **设计基线**：CONTEXT.md + PRD + Design + ADR 经 PR 合入后，才允许拆解任务
 - **requirements 基线**：需求阶段结束须用户确认一次
-- **goal 最小化**：`goal({op:"create", parent_issue_number:<Flow Record 编号>})`，目标/验收从 Flow Record 读取
+- **goal 最小化**：`goal({op:"create", parent_issue_number:<Parent Issue 编号>})`，目标/验收从 Parent Issue 读取
 
 ## 各阶段关键约束
 
 - **requirements**：渐进式澄清（Decision Map），一次只问一个问题；领域术语写入根 CONTEXT.md
-- **design**：architect 在 planning worktree 产出文档；方案遵循工程原则（KISS/YAGNI/DRY/SRP）
-- **tasks**：垂直切片、可独立验证、无循环依赖；标题用英文功能标题（内核派生 slug）
-- **code**：TDD 协议唯一来源是 `flow-tdd` skill；证据经 `tdd_checkpoint` 提交，缺证据 PR 被拒
-- **review**：双轴审查（规范 + 规格）+ TDD criterion coverage；reviewer 只读，写操作经 `task_control`
+- **design**：方案遵循工程原则（KISS/YAGNI/DRY/SRP）；产出经 PR 合入
+- **tasks**：垂直切片、可独立验证、无循环依赖；标题用英文功能短语（kebab-case）
+- **code**：TDD 协议唯一来源是 `flow-tdd` skill；测试质量由仓库 CI 把关
+- **review**：双轴审查（规范 + 规格）；reviewer 只读，写操作由 primary 编排器执行
 - **release**：人工流程；按 Profile 版本规则 + 项目 GitHub Actions release workflow（技术栈无关）
 
 ## Prohibited Actions
 
-- 不跳过前置门禁直接 stage-start/complete
-- 不手工修改 Flow Record 的 stage checklist（由 flow_control 维护）
-- 不绕过工具直接执行高风险 git/gh 写操作（push/PR/merge/worktree）
+- 不跳过前置阶段直接推进
+- 不伪造阶段完成（实际产出后再勾选 checklist）
+- 不手工修改已完成阶段的 checklist
+- reviewer/goal-verify 等子 agent 不直接执行写命令（push/PR/merge 由 primary 编排器执行）

package/assets/skills/flow-code/SKILL.md

@@ -1,20 +1,24 @@
 ---
 name: flow-code
-description: 编码实现 — task_control 创建 worktree + TDD（flow-tdd 协议）
+description: 编码实现 — worktree + TDD（flow-tdd 协议）
 ---
 
 # flow-code
 
 认领 Task Record（Sub Issue），在 worktree 内按 TDD 实现代码与单测。
-worktree 创建、PR 提交由内核工具 `task_control` 完成，本 skill 不复制 shell 实现。
+worktree 创建、PR 提交由 primary 编排器执行，本 skill 定义编码流程。
 
-## 核心：调用 task_control + flow-tdd
+## 核心流程
 
-1. `task_control{op:"start-task", task_id:"<slug>", ...}` — 创建 worktree + 记录基线 + 冻结 TDD policy
-2. 加载 `flow-tdd` skill，按 Task 的 `tdd` 配置执行 RED→GREEN cycle
-3. 每个 stage 通过 `tdd_checkpoint` 提交证据（唯一证据源，缺证据的 PR 会被拒绝）
-4. 本地 `git add` + `git commit`（多次提交）
-5. **不 push、不创建 PR** — 由 primary 的 `task_control{op:"submit-task"}` 完成
+1. **创建/复用 worktree**（编排器执行）
+   ```bash
+   BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
+   git worktree add ".worktree/<task-slug>" -b "feat/<task-slug>" "$BASE"
+   cd ".worktree/<task-slug>" && pwd
+   ```
+2. 加载 `flow-tdd` skill，按 Task 的验收标准执行 RED→GREEN cycle（self-report）
+3. 本地 `git add`（限定文件）+ `git commit`（多次提交）
+4. **不 push、不创建 PR** — 由 primary 编排器统一执行
 
 ## 编码约束
 
@@ -25,12 +29,10 @@ worktree 创建、PR 提交由内核工具 `task_control` 完成，本 skill 不
 ## TDD 引用
 
 > `flow-tdd` skill 是 TDD 协议的唯一来源，包含完整的 RED→GREEN cycle 状态机、
-> abandon-cycle 规则和 final-regression/verification 流程，以及 `tdd_checkpoint` 各 op 的调用方式。
+> abandon-cycle 规则和 final-regression/verification 流程。测试质量由仓库 CI 把关。
 
 ## Output
-- Worktree 已创建（task_control）
-- TDD evidence 已提交（tdd_checkpoint）
-- 本地 commit 就绪（分支推送与 PR 由 task_control 完成）
+- 本地 commit 就绪（分支推送与 PR 由编排器完成）
 
 ## 后续
 - **/review** — 审查 PR
@@ -45,29 +47,25 @@ worktree 创建、PR 提交由内核工具 `task_control` 完成，本 skill 不
 
 ### Preconditions
 - `/tasks` 已完成 → Sub Issues 就绪
-- Planning Baseline 已合入；前置依赖任务已合并（task_control 门禁）
+- 设计基线已合入；前置依赖任务已合并
 
 ### Procedure
-1. 调用 `task_control{op:"start-task"}` 创建/复用 worktree
-2. 加载 `flow-tdd`，按 Task 的 tdd 配置执行 RED→GREEN cycle
-3. 通过 `tdd_checkpoint` 提交证据
-4. 本地 git add + commit（不 push）
-5. 交回 primary 调用 `task_control{op:"submit-task"}` 创建 PR
+1. 在 `.worktree/<task-slug>` 创建/复用 worktree（编排器执行）
+2. 加载 `flow-tdd`，按 Task 验收标准执行 RED→GREEN cycle
+3. 本地 git add + commit（不 push）
+4. 交回 primary 编排器 push + 创建 PR
 
 ### Outputs
-- Worktree 已创建（`.worktree/<task-slug>/`）
-- TDD evidence（Task Record 单评论）
 - 本地 commit
 
 ### Failure
-- worktree 创建失败 → 检查分支冲突或目录残留（task_control 报错）
+- worktree 创建失败 → 检查分支冲突或目录残留
 - 测试失败 → 修复后重试（不跳过 RED）
 
 ### Idempotency
-- worktree 已存在 → task_control 校验分支一致性后复用
+- worktree 已存在 → 校验分支一致性后复用
 - 代码已提交 → 追加提交
 
 ### Prohibited Actions
-- 不 push、不创建 PR、不操作 Issue（由 task_control 完成）
-- 不使用 `git add .`
-- 不绕过 task_control 直接执行 worktree 创建 / PR 创建 / 分支推送
+- 不 push、不创建 PR、不操作 Issue（由编排器统一执行）
+- 不使用 `git add .`（限定变更文件）

package/assets/skills/flow-design/SKILL.md

@@ -1,20 +1,33 @@
 ---
 name: flow-design
-description: 技术方案设计 → 方案文档 + ADR（planning worktree + Planning PR）
+description: 技术方案设计 → 方案文档 + ADR → Planning PR
 ---
 
 # flow-design
 
-基于 PRD 进行技术方案设计，architect 在 planning worktree 产出 CONTEXT.md + PRD + Design + ADR，
-并由 `flow_control` 通过 Planning PR 合入形成 Planning Baseline。
-
-## 核心：调用 flow_control
-
-1. `flow_control{op:"planning-start"}` — 创建 planning worktree `.worktree/planning-<slug>`（architect 在此写文档）
-2. 在 planning worktree 内产出：根 `CONTEXT.md` 术语更新 + `docs/prd/<title>.md` + `docs/dev/specs/<title>.md` + `docs/adr/<date>-<slug>.md`
-3. `flow_control{op:"planning-pr"}` — 对 planning worktree 变更创建 Planning PR（合并后 = Planning Baseline）
-
-worktree 创建与 Planning PR 创建均由内核工具完成，创建动作全部收敛到工具内。
+基于 PRD 进行技术方案设计，产出方案文档与 ADR，并通过 Planning PR 合入形成设计基线。
+
+## 核心流程
+
+1. **创建工作分支**（在默认分支基础上）
+   ```bash
+   BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
+   git checkout $BASE && git pull origin $BASE
+   git checkout -b "feat/<slug>-design"
+   ```
+2. **产出文档**：
+   - 根 `CONTEXT.md` 术语更新（如发现新领域术语）
+   - `docs/prd/<title>.md`（PRD 确认版）
+   - `docs/dev/specs/<title>.md`（技术方案）
+   - `docs/adr/<date>-<slug>.md`（ADR 决议）
+3. **提交并创建 Planning PR**
+   ```bash
+   git add -A && git commit -m "docs: <slug> design baseline"
+   git push -u origin "feat/<slug>-design"
+   gh pr create --base $BASE --head "feat/<slug>-design" \
+     --title "design: <slug>" --body "Planning Baseline for <slug>"
+   ```
+4. **合入基线**：PR 合并后即形成设计基线（Planning Baseline），后续任务拆解以此为前置。
 
 ## 设计约束
 
@@ -25,16 +38,62 @@ worktree 创建与 Planning PR 创建均由内核工具完成，创建动作全
 3. **方案自检** — 每个设计决策必须能回答"为什么不用更简单的替代方案？"
 4. **ADR 记录简化决策** — 如果选择复杂方案，必须在 ADR 中说明为何简单方案不够
 
+## 设计语言
+
+技术方案使用以下语言描述可测试设计：
+
+- **Module** — 具有 Interface 与 Implementation 的模块，不限定为函数、类或包。
+- **Interface** — 调用者正确使用 Module 必须知道的全部信息，包括输入输出、约束、错误与副作用。
+- **Seam** — 可以通过 Interface 观察或替换行为的位置，也是测试验证行为的公共边界。
+- **Adapter** — 在 Seam 处满足 Interface 的具体实现。
+- **Depth** — Interface 越小、背后隐藏的有效复杂性越多，Module 越深。
+
+设计时必须检查：
+
+1. Interface 是否保持小而完整，并把复杂性留在 Module 内部，而不是泄漏给多个调用者。
+2. 调用者与测试是否可以通过同一个 Seam 使用和验证行为。
+3. 是否真的需要新的 Seam。一个 Adapter 只代表假设的 Seam；只有存在真实替换需求或多个 Adapter 时才引入抽象。
+4. 是否出现只做透传的浅 Module、`FooService/FooServiceImpl` 式空壳抽象或为未来预留的 Interface。
+
+## Testing Decisions
+
+技术方案必须包含 `Testing Decisions`，在进入 Task Planning 前为每个关键行为明确：
+
+```markdown
+## Testing Decisions
+
+### <behavior>
+
+- Test Seam: <用于触发并观察行为的公共 Interface>
+- Observable Result: <通过该 Seam 可观察的结果或错误>
+- Test Level: <与仓库现有测试体系一致的最窄有效层级>
+```
+
+Test Seam 应描述公共行为边界，例如 Session API，而不是 `SessionRepositoryImpl.restore()` 等实现细节。优先复用现有 Seam；不要为了方便 mock 而创建生产抽象。
+
+## 存量 Design Amendment
+
+当 tasks、code 或 review 阶段发现旧技术方案缺少 `Testing Decisions` 时，调用方可以在**保持当前 lifecycle stage 不变**的前提下委派 `@architect` 补齐设计：
+
+1. 读取 Design Gap、原技术方案、相关 PRD / ADR 与 repository context。
+2. 优先识别仓库已有的公共 Interface 和测试惯例，不为了补字段创建新 Seam。
+3. 只向原技术方案补充缺失行为的 `Testing Decisions`，不重写其他设计内容。
+4. 返回已修改文件和补充的 behavior / Test Seam / Observable Result。
+
+如果补齐过程暴露新的架构取舍或多个无法直接判断的 Seam 方案，停止 amendment 并把决策交给用户；不得静默扩大设计。Design Amendment 不回退 goal stage、不重复勾选阶段，也不单独创建新的 lifecycle 状态。
+
+Design Amendment 是兼容子流程，覆盖本 skill 的普通发布流程：不创建 design 分支、Planning PR 或新 ADR。`@architect` 只修改技术方案，primary 负责在当前 stage 保存变更并把补充内容传给后续 agent。
+
 ## CONTEXT.md 术语
 
 阅读项目根 CONTEXT.md（领域术语权威，已自动注入内容与 digest）；
-设计中发现的新术语经用户确认后写入根 CONTEXT.md（术语权威）。
+设计中发现的新术语经用户确认后写入根 CONTEXT.md。
 
 ## Output
-- `docs/dev/specs/<title>.md` — 技术方案
+- `docs/dev/specs/<title>.md` — 技术方案（包含 Module / Interface 设计与 Testing Decisions）
 - `docs/adr/<date>-<slug>.md` — ADR 决议
 - 根 CONTEXT.md 术语更新（如发现新术语）
-- Planning PR（由 flow_control 创建）
+- Planning PR（合入后 = 设计基线）
 
 ## 后续
 - **/tasks** — 基于设计方案拆解为 DAG 任务
@@ -42,37 +101,46 @@ worktree 创建与 Planning PR 创建均由内核工具完成，创建动作全
 ## Contract
 
 ### Trigger
-由 `/design` 命令或 `@dev-lifecycle` Phase 1 触发。
+由 `/design` 命令、`@dev-lifecycle` Phase 1，或存量 Flow 的 Testing Decisions 兼容门触发。
 
 ### Inputs
 - `docs/prd/<title>.md` — 上游 PRD（来源：requirements 阶段产出）
-- Flow Record 编号（来源：requirements 阶段产出）
+- Parent Issue 编号（来源：requirements 阶段产出）
 
 ### Preconditions
-- `/requirements` 已完成 → PRD 与 Flow Record 存在
+- `/requirements` 已完成 → PRD 与 Parent Issue 存在
 - requirements 基线已用户确认
 
 ### Procedure
-1. 调用 `flow_control{op:"planning-start"}` 创建 planning worktree
+普通 design 流程：
+
+1. 基于默认分支创建工作分支
 2. 阅读 PRD、已有 ADR、根 CONTEXT.md 术语
-3. 输出技术方案到 `docs/dev/specs/<title>.md`
-4. 记录 ADR 到 `docs/adr/<YYYY-MM-DD>-<slug>.md`
-5. 调用 `flow_control{op:"planning-pr"}` 创建 Planning PR
+3. 识别 Module、Interface 与真实 Seam，检查深度、局部性和抽象必要性
+4. 为关键行为定义 Testing Decisions，明确公共 Test Seam 与可观察结果
+5. 输出技术方案到 `docs/dev/specs/<title>.md`
+6. 记录 ADR 到 `docs/adr/<YYYY-MM-DD>-<slug>.md`
+7. 提交并创建 Planning PR
+
+存量 Design Amendment 改用“存量 Design Amendment”章节的受限流程，不执行以上分支、ADR 与 Planning PR 步骤。
 
 ### Outputs
-- 技术方案 + ADR（planning worktree 内）
-- Planning PR（Planning Baseline 的一部分）
+- 技术方案（包含 Testing Decisions）+ ADR
+- Planning PR
 
 ### Failure
 - ADR 与已有决策冲突 → 记录冲突并标注
+- 关键行为没有稳定的公共 Test Seam → 暂停设计，先调整 Interface 或明确缺失决策
 - Planning PR 创建失败 → 通知用户手动处理
 
 ### Idempotency
 - 技术方案已存在 → 读取并更新
+- 已有完整 `Testing Decisions` → 不重复 amendment
 - ADR 已存在 → 不重复创建
-- planning worktree 已存在 → 复用（工具校验分支一致性）
+- 分支已存在 → 检出后追加提交
 
 ### Prohibited Actions
-- 不绕过 flow_control 手工创建 worktree / Planning PR（由内核工具完成）
 - 不跳过 ADR 兼容性检查
-- 不直接 push 到默认分支
+- 不创建只有一个假设 Adapter、没有真实替换需求的 Seam
+- 不以实现方法、私有协作对象或调用顺序作为 Test Seam
+- 不直接 push 到默认分支（写操作走分支 + PR）