cc-devflow 4.5.2 → 4.5.4

package/.claude/skills/cc-check/assets/REPORT_CARD_TEMPLATE.json

@@ -13,10 +13,17 @@
     "status": "blocked",
     "failureOwnership": [
       {
+        "errorName": "MissingSpecReviewProof",
         "failure": "missing spec review proof",
         "classification": "in-branch",
+        "owner": "branch",
         "touchedByDiff": true,
+        "artifactRefs": [
+          "planning/task-manifest.json",
+          "review/report-card.json"
+        ],
         "evidence": "planning/task-manifest.json tasks[T002].reviews.spec is empty",
+        "rescueAction": "record spec review proof for T002 or reroute to cc-do",
         "action": "reroute-cc-do",
         "status": "open"
       }
@@ -42,6 +49,32 @@
   ],
   "qa": {
     "status": "blocked",
+    "feedbackLoop": {
+      "status": "blocked",
+      "mode": "targeted-test",
+      "commandOrArtifact": "npm test -- src/feature/feature.test.ts",
+      "speed": "fast",
+      "determinism": "high",
+      "signalSharpness": "targeted failure would indicate the user-visible behavior regressed",
+      "reproductionRate": "not recorded",
+      "attempts": [
+        "targeted unit test"
+      ],
+      "blockedReason": "red/green reproduction is not recorded yet"
+    },
+    "behaviorEvidence": {
+      "status": "blocked",
+      "userFacingBoundary": "feature behavior",
+      "expectedBehavior": "target behavior succeeds for the user",
+      "actualBehavior": "not proven yet",
+      "reproductionSteps": [
+        "run the targeted verification command"
+      ],
+      "consistency": "not recorded",
+      "domainLanguage": [
+        "feature behavior"
+      ]
+    },
     "regressionProof": [
       {
         "behavior": "original symptom",
@@ -81,6 +114,33 @@
       "issues": [],
       "skipReason": "template example is not a UI browser QA scenario"
     },
+    "humanUat": {
+      "status": "skipped",
+      "required": false,
+      "scenario": "",
+      "tester": "",
+      "evidence": [],
+      "failure": "",
+      "reroute": "none",
+      "skipReason": "not required for this template scenario"
+    },
+    "architectureFollowUps": [
+      {
+        "summary": "Add the missing public test seam before widening coverage",
+        "currentBehavior": "review proof depends on task metadata instead of a direct behavior seam",
+        "desiredBehavior": "tests verify the behavior through a stable public interface",
+        "keyInterfaces": [
+          "feature public API"
+        ],
+        "acceptanceCriteria": [
+          "target behavior can be reproduced without private implementation hooks"
+        ],
+        "outOfScope": [
+          "rewriting unrelated modules"
+        ],
+        "status": "deferred-minor"
+      }
+    ],
     "tddException": null
   },
   "quickGates": [
@@ -140,6 +200,7 @@
           "summary": "T002 spec review proof is missing",
           "evidence": "planning/task-manifest.json tasks[T002].reviews.spec is empty",
           "action": "reroute-cc-do",
+          "rescueAction": "record spec review proof for T002 or return to cc-do",
           "triageStatus": "clarification-needed",
           "confidenceScore": 9,
           "fingerprint": "task-review:T002:missing-spec-review",

package/.claude/skills/cc-check/references/gate-contract.md

@@ -16,6 +16,17 @@
 
 所有通过结论都必须来自本次新鲜证据；旧输出只能当线索，不能直接继承 verdict。
 
+## QA Feedback Loop
+
+行为变更和 bugfix 的 evidence 还必须说明反馈环：
+
+- `mode`：failing test、curl / HTTP、CLI fixture、browser、trace replay、bisect、differential loop 等
+- `determinism`：反馈是否稳定，flaky 时复现率是多少
+- `signalSharpness`：失败是否指向目标行为，而不是语法、fixture 或 mock 问题
+- `blockedReason`：无法建立 loop 时缺少什么 artifact、权限、服务或输入
+
+没有可信 loop 的 bugfix 默认不能 `pass`。
+
 ## Reroute
 
 - `none`

package/.claude/skills/cc-check/references/review-contract.md

@@ -98,15 +98,29 @@ Review finding 不只是“发现过”，必须有处置结果：
 
 Review 必须判断测试是否证明行为：
 
+- 反馈环是否可信：速度、确定性、信号锋利度、复现率是否足够支撑结论
+- bugfix 是否复现并覆盖了用户描述的原始症状，而不是附近的另一个失败
+- expected / actual / reproduction steps 是否能让 reviewer 独立复现或判断缺件
 - 回归测试是否有 red/green 证据
 - red 是否因为目标行为缺失而失败
 - green 是否包含 targeted test 和必要的 broader gate
-- mock 是否必要，且没有断言 mock 本身
+- 测试是否通过公共接口覆盖行为
+- mock 是否只停在系统边界，且没有断言 mock 本身或内部调用顺序
 - 生产代码是否新增 test-only API
 - integration / contract test 是否比复杂 mock 更直接
+- 如果没有正确测试 seam，是否记录了架构 follow-up，而不是造易碎测试
 - coverage audit 是否映射真实 codepath / user flow / error state / edge case
 - UI 或用户路径变更是否有 browser evidence、截图、console 结果，或明确 skip reason
 
+## Durable Follow-Up Facts
+
+Review 产生的 QA issue 或 follow-up 必须可长期执行：
+
+- 用领域语言描述用户或系统行为，不把当前文件路径 / 行号当成唯一真相
+- 写清 current behavior、desired behavior、key interfaces、acceptance criteria、out of scope
+- 独立行为拆成独立条目；有依赖关系时写明顺序
+- `deferred-minor` 只能用于不阻塞本次交付的 minor 项，并且必须进入 `cc-act` follow-up writeback
+
 ## Failure Ownership
 
 失败归属必须结构化写入 `runtime.failureOwnership[]`：
@@ -125,6 +139,8 @@ Review 必须判断测试是否证明行为：
 - `important` / `critical` finding 未处理前，不算通过
 - `important` / `critical` finding 缺 triageStatus，不算通过
 - QA test quality 缺失且本次涉及行为变化，至少是 `blocked`
+- 行为变更缺 `qa.feedbackLoop` / `qa.behaviorEvidence` 且没有明确例外，至少是 `blocked`
+- bugfix 没有复现原始症状，也没有解释不可复现原因，不能通过
 - review freshness 缺失、过期或与当前 head 不一致，不能绿灯
 - UI / 用户路径变更缺 browser evidence 且无 skip reason，不能绿灯
 - `runtime.failureOwnership` 仍有 `in-branch` 或 `ambiguous` 未解释失败，不能绿灯

package/.claude/skills/cc-check/scripts/render-report-card.js

@@ -80,6 +80,22 @@ function deriveVerdict(manifest, quickGates, strictGates, review) {
     return 'blocked';
   }
 
+  if (['fail'].includes(review.qa?.feedbackLoop?.status)) {
+    return 'fail';
+  }
+
+  if (['blocked', 'pending'].includes(review.qa?.feedbackLoop?.status)) {
+    return 'blocked';
+  }
+
+  if (['fail'].includes(review.qa?.behaviorEvidence?.status)) {
+    return 'fail';
+  }
+
+  if (['blocked', 'pending'].includes(review.qa?.behaviorEvidence?.status)) {
+    return 'blocked';
+  }
+
   if (review.status === 'blocked') {
     return 'blocked';
   }
@@ -185,6 +201,26 @@ function buildClaimEvidence({ manifest, quickGates, strictGates, review }) {
 function buildQa(review) {
   return {
     status: review.qa?.status || 'skipped',
+    feedbackLoop: review.qa?.feedbackLoop || {
+      status: 'skipped',
+      mode: 'not-applicable',
+      commandOrArtifact: '',
+      speed: '',
+      determinism: '',
+      signalSharpness: '',
+      reproductionRate: '',
+      attempts: [],
+      blockedReason: 'not recorded'
+    },
+    behaviorEvidence: review.qa?.behaviorEvidence || {
+      status: 'skipped',
+      userFacingBoundary: '',
+      expectedBehavior: '',
+      actualBehavior: '',
+      reproductionSteps: [],
+      consistency: '',
+      domainLanguage: []
+    },
     regressionProof: review.qa?.regressionProof || [],
     testQuality: review.qa?.testQuality || [],
     coverageAudit: review.qa?.coverageAudit || {
@@ -207,6 +243,7 @@ function buildQa(review) {
       issues: [],
       skipReason: 'not recorded'
     },
+    architectureFollowUps: review.qa?.architectureFollowUps || [],
     tddException: review.qa?.tddException || null
   };
 }

package/.claude/skills/cc-check/scripts/verify-gate.sh

@@ -63,8 +63,15 @@ jq -e '
   ((.qa.coverageAudit.status? // "skipped") | IN("pass", "fail", "blocked", "skipped", "pending")) and
   ((.qa.browserEvidence? // {"status":"skipped"}) | type == "object") and
   ((.qa.browserEvidence.status? // "skipped") | IN("pass", "fail", "blocked", "skipped", "pending")) and
+  ((.qa.feedbackLoop? // {"status":"skipped"}) | type == "object") and
+  ((.qa.feedbackLoop.status? // "skipped") | IN("pass", "fail", "blocked", "skipped", "pending")) and
+  ((.qa.behaviorEvidence? // {"status":"skipped"}) | type == "object") and
+  ((.qa.behaviorEvidence.status? // "skipped") | IN("pass", "fail", "blocked", "skipped", "pending")) and
+  ((.qa.architectureFollowUps? // []) | type == "array") and
   ((.review.findings? // []) | all(.[]; ((.confidenceScore? // 7) | type == "number") and ((.displayTier? // "info") | IN("blocking", "warning", "info", "suppressed")))) and
   ((.verdict != "pass") or ((.review.freshness.status? // "unknown") | IN("fresh", "not-applicable"))) and
+  ((.verdict != "pass") or ((.qa.feedbackLoop.status? // "skipped") | IN("pass", "skipped"))) and
+  ((.verdict != "pass") or ((.qa.behaviorEvidence.status? // "skipped") | IN("pass", "skipped"))) and
   ((.verdict != "pass") or (((.runtime.failureOwnership? // []) | map(select(((.classification? // "") | IN("in-branch", "ambiguous")) and ((.status? // "open") | IN("open", "pending")))) | length) == 0)) and
   ((.verdict == "pass" and .reroute == "none") or (.verdict != "pass" and .reroute != "none"))
 ' "$REPORT" >/dev/null

package/.claude/skills/cc-do/CHANGELOG.md

@@ -1,5 +1,23 @@
 # CC-Do Skill Changelog
 
+## v1.6.1 - 2026-04-29
+
+- reject parent/child touched-path overlaps when selecting parallel execution surfaces
+- report submodule touches separately so unrelated tasks are not serialized by mere `.gitmodules` presence
+- document quick-lane and wave scheduling gates so small tasks still leave checkpoint, verification, and handoff truth
+
+## v1.6.0 - 2026-04-28
+
+- prohibit horizontal TDD execution by requiring one tracer bullet Red/Green/Refactor cycle per observable behavior
+- add test fixture discipline so partial fixtures, type assertions, generated stubs, and mocks must preserve public seam behavior
+- require checkpoints to record fixture risk when test data shortcuts could hide a seam or contract problem
+
+## v1.5.3 - 2026-04-28
+
+- require Red evidence to prove behavior through a public seam instead of private methods, internal call counts, or implementation-shaped tests
+- add mock-boundary and test-quality gates to the TDD execution contract so internal collaborators are not mocked as fake proof
+- allow `write-task-checkpoint.sh --tdd-json` and runtime checkpoint schema to preserve structured TDD evidence for recovery and review
+
 ## v1.5.2 - 2026-04-27
 
 - require execution evidence that adds human-readable summaries to resolve the runtime output policy first

package/.claude/skills/cc-do/PLAYBOOK.md

@@ -23,14 +23,15 @@
 
 ## Execution Loop
 
-1. 读取 `task-manifest.json`，先用 `scripts/select-ready-tasks.sh` 找出当前 ready tasks。
-2. 如果有多于一个 ready task，要先跑 `scripts/detect-file-conflicts.sh`；有共享触点或依赖关系就退回串行。
+1. 读取 `task-manifest.json`，先用 `scripts/select-ready-tasks.sh` 找出当前 ready tasks 和当前 wave。
+2. 如果有多于一个 ready task，要先跑 `scripts/detect-file-conflicts.sh`；有共享触点、父子路径触点或依赖关系就退回串行。
 3. 对每个要执行的 task，先用 `scripts/build-task-context.sh` 从 `planning/design.md`、`planning/tasks.md`、`planning/task-manifest.json` 组装上下文，再开始编码。
 4. 如果当前任务来自 `cc-investigate`，把 `planning/analysis.md` 当成上游合同，不准一边做一边重开调查。
 5. 进入 TDD 闭环：先红，再绿，再重构。
 6. 每个关键节点都写 runtime：失败测试、Green 通过、Refactor、Review 结论、阻塞原因。
 7. 任务实现后，先过 `spec review`，再过 `code review`，review 不通过就回到实现。
 8. 两道 review 门都通过后，才能把任务标成完成，并把结果留给 `cc-check`。
+9. quick lane 只允许减少叙事，不允许减少 current task、checkpoint、verification、handoff 和 review gates。
 
 ## Local Kit
 
@@ -50,10 +51,12 @@
 
 1. 先写失败测试，再运行到红。
 2. 确认红灯是预期失败，不是测试写错、fixture 缺失或环境没接上。
-3. 只写让当前测试转绿的最小实现。
-4. 绿后才允许重构。
-5. 重构后必须保持绿。
-6. 测试没先红过，就不能宣称这次变更受 TDD 保护。
+3. 确认红灯通过公共 seam 证明行为缺失，而不是测私有函数、内部调用次数或临时结构。
+4. 确认 mock 只发生在系统边界；内部协作者不 mock。
+5. 只写让当前测试转绿的最小实现。
+6. 绿后才允许重构。
+7. 重构后必须保持绿。
+8. 测试没先红过，或红灯不是公共 seam 上的行为失败，就不能宣称这次变更受 TDD 保护。
 
 ## TDD Exception Rule
 
@@ -78,11 +81,14 @@
 
 1. `red_failed`: 已观察到预期失败
 2. `red_reason_verified`: 红灯原因与目标行为缺失一致
-3. `green_passed`: 当前任务实现转绿
-4. `refactor_done` 或 `refactor_not_needed`
-5. `refactor_green`: 重构后相关测试仍绿
-6. `spec_review_pass`
-7. `code_review_pass`
+3. `red_seam_verified`: 红灯通过公共接口、调用方流程、CLI/API/UI 或真实边界进入系统
+4. `red_behavior_verified`: 测试断言用户或调用方可观察行为，不断言内部实现细节
+5. `mock_boundary_verified`: mock 只在系统边界，内部协作者没有被 mock
+6. `green_passed`: 当前任务实现转绿
+7. `refactor_done` 或 `refactor_not_needed`
+8. `refactor_green`: 重构后相关测试仍绿
+9. `spec_review_pass`
+10. `code_review_pass`
 
 任何一门失败，都回到实现，不准直接跨过去。
 
@@ -93,8 +99,9 @@
 1. 任务处于当前 active phase
 2. `dependsOn` 已全部满足
 3. 任务显式允许并行，例如 `[P]`
-4. `touches` / `files` 不冲突
-5. 每个 subagent 都拿到了自己的 task context
+4. `touches` / `files` 不冲突，且父路径 / 子路径也不重叠
+5. submodule touches 已被标出；触达 submodule 的任务不能默认拿普通 worktree 隔离
+6. 每个 subagent 都拿到了自己的 task context
 
 少一条，都按顺序执行。
 

package/.claude/skills/cc-do/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-do
-version: 1.5.2
+version: 1.6.1
 description: Use when implementing planned tasks, resuming interrupted work, applying a frozen investigation handoff, or landing review feedback after cc-plan or cc-investigate.
 triggers:
   - 开始做 T003
@@ -27,16 +27,21 @@ writes:
     durability: durable
     required: false
     when: execution mode uses delegated or team workers
+  - path: devflow/changes/<change-key>/meta/change-state.json
+    durability: durable
+    required: false
+    when: pause, resume, dispatch, or quick-lane state changes
 effects:
   - code changes
   - test changes
   - workspace scratch runtime updates
 entry_gate:
   - Read planning/design.md or planning/analysis.md, then planning/tasks.md, planning/task-manifest.json, change-meta.json, related capability specs, and the latest checkpoint before changing code.
-  - Select only ready tasks whose dependencies and file ownership are clear.
+  - Select only ready tasks whose dependencies, wave, touched paths, and file ownership are clear.
+  - Reject parallel execution when touched paths overlap by exact path or parent/child path; submodule touches must be isolated unless the task explicitly owns that submodule.
   - If the current task cannot be restated from canonical artifacts, run a context reset before coding.
 exit_criteria:
-  - The current task has red/green evidence, review evidence, and a resumable checkpoint trail.
+  - The current task has red/green evidence, public-seam test quality evidence, review evidence, and a resumable checkpoint trail.
   - Execution leaves the next verifier enough runtime truth to judge the task without chat memory.
   - The honest next step is cc-check or an explicit reroute.
 reroutes:
@@ -134,28 +139,38 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 3. Refactor：只有 Green 之后才能清理命名、重复、结构和坏味道。
 4. Record：每一站都写入 `checkpoint.json`，必要时写入 `events.jsonl`。
 
+Red 不是形式上的红，而是公共 seam 上的行为缺失证明。测试必须通过公共接口、调用方流程、CLI/API/UI 路径或其它真实边界进入系统；只验证私有函数、内部调用次数、临时数据结构或 mock 自己控制的内部协作者，不算 TDD 证据。
+
 例外只能用于 throwaway prototype、纯生成文件、纯配置改动；例外必须写进 checkpoint 的 `tddException`，包含原因、风险和替代验证命令。测试第一次就绿，说明测试没有证明新行为，必须修测试而不是继续写生产代码。
 
+禁止水平切片：不要先写一批测试，再写一批实现。每次只推进一个 tracer bullet：一个可观察行为的 Red -> 让它变绿的最小实现 -> 必要重构 -> 记录证据，然后再进入下一个行为。
+
+测试数据也必须诚实。fixture 只提供当前行为需要的最小输入；partial fixture、类型断言、mock payload 或 generated stub 必须写清哪些字段是真实 contract，哪些只是测试填充。不能用 `as`、`any`、双重 cast、缺字段 partial mock 或 test-only method 掩盖 seam 设计问题。
+
 ## Entry Gate
 
 1. 先读 `planning/design.md` 或 `planning/analysis.md`，再读 `planning/tasks.md`、`planning/task-manifest.json`；如果是恢复执行，再补读最近 checkpoint 或已有 `handoff/resume-index.md`。
 2. 先用 `scripts/select-ready-tasks.sh` 判断现在到底哪几个任务真的 ready。
-3. 只锁定当前 ready task，或一组经依赖与触点校验后可并行的 ready tasks。
+3. 只锁定当前 ready task，或一组经依赖、wave、精确触点与父子路径触点校验后可并行的 ready tasks。
 4. 如果这次来自 `cc-investigate`，必须把 `planning/analysis.md` 当成 canonical contract，而不是一边实现一边重新调查。
 5. 没有任务上下文，不准把任务扔给 subagent；先用 `scripts/build-task-context.sh` 从 `planning/design.md` 或 `planning/analysis.md`、`planning/tasks.md`、`planning/task-manifest.json`、`change-meta.json` 与相关 capability spec 组装上下文。
+6. 如果 `task-manifest.json.metadata.lane == "quick"`，仍然必须有 current task、verification、checkpoint 和 handoff；quick 只缩短文档密度，不跳过证据。
+7. 如果仓库含 `.gitmodules` 或 manifest 提供 `submodulePaths`，先用 `scripts/detect-file-conflicts.sh` 标出 `submoduleTouches`；只有触达该 submodule 的任务失去默认 worktree 隔离资格，未触达任务不能被无辜串行化。
 
 ## Loop
 
 1. 读取当前任务，而不是重新发明任务。
-2. 依赖没满足前，不准提前做下游任务。
-3. 没有明确并行资格，不准把多个实现任务同时推进。
+2. 依赖没满足前，不准提前做下游任务；不同 wave 之间不允许抢跑。
+3. 没有明确并行资格，不准把多个实现任务同时推进；`touches` 父子路径重叠也算同一执行表面。
 4. 先 `fail-first`：先写失败测试，先看见预期红，再写生产代码。
 5. 如果红灯不是预期失败（语法错、fixture 错、测试没连上），先修测试直到它正确失败。
-6. 按 `Red -> Green -> Refactor` 推进，Green 只允许最小实现。
-7. Refactor 后必须重跑相关测试，保持 Green。
-8. 每次推进都写 task runtime：`events.jsonl` + `checkpoint.json`。
-9. 任务实现后，先过 `spec review`，再过 `code review`，两道门都过才算任务收口；这里只验证 spec delta，不回写长期 spec。
-10. 当前任务完成后，把可验证证据留给 `cc-check`。
+6. 如果红灯通过错误 seam 得到，比如私有方法、内部调用次数、mock 内部协作者，先修测试 seam，不准进入 Green。
+7. 按 `Red -> Green -> Refactor` 推进，Green 只允许最小实现。
+8. 如果当前 Red 需要新的 fixture 或 mock，先证明它仍从公共 seam 触发真实行为；fixture 缺字段、类型强转或内部 mock 都要写入 `tdd.testQuality.fixtureRisk` 或先修 seam。
+9. Refactor 后必须重跑相关测试，保持 Green。
+10. 每次推进都写 task runtime：`events.jsonl` + `checkpoint.json`，并记录 `tdd.testQuality` 或 `tddException`。
+11. 任务实现后，先过 `spec review`，再过 `code review`，两道门都过才算任务收口；这里只验证 spec delta，不回写长期 spec。
+12. 当前任务完成后，把可验证证据留给 `cc-check`。
 
 ## Output
 
@@ -168,8 +183,11 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 ## Good Output
 
 - 当前 task 一眼可见，执行者不用从聊天记录里猜目标
-- 至少留下一次明确的 Red/Green/Refactor 证据，且 Red 是预期失败
+- 当前 wave、ready tasks、parallel candidates、touch conflict verdict 和 submoduleTouches 一眼可见
+- 至少留下一次明确的 tracer bullet Red/Green/Refactor 证据，且 Red 是公共 seam 上的预期行为失败
+- 测试 fixture 说明真实 contract 字段和测试填充字段，没有用类型欺骗或内部 mock 制造假绿
 - runtime / checkpoint 足够让下一位接手者无损恢复
+- quick lane 也有 mini manifest、checkpoint、verification 和唯一 next action，不靠聊天记录继续
 - reviewer 能顺着 review 记录和验证命令复盘这次实现
 
 ## Bundled Resources
@@ -194,11 +212,13 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 3. 没有失败测试，不准写生产代码。
 4. 测试如果第一次就绿，说明你没证明任何东西，先修测试。
 5. 红灯原因必须和目标行为缺失一致；红灯如果只是测试写错，不算 TDD 证据。
-6. 先过 `spec review`，再过 `code review`，顺序不能反。
-7. 不在 `cc-do` 里改 capability spec 正文；这里只产出实现证据和 spec 对齐证据。
-8. 失败和阻塞都要留下恢复证据。
-9. 给 subagent 的输入必须包含：当前进度、当前任务全文、依赖状态、必读文件、验收标准、可信命令。
-10. 三次失败修补后必须先质疑调查合同或设计合同，而不是继续堆补丁。
+6. 红灯必须验证公共接口上的行为；实现细节测试、私有方法测试、内部调用次数断言都要先退回 Red 修正。
+7. Mock 只能放在系统边界；如果必须 mock 内部协作者才能测试，说明 seam 或设计合同有问题。
+8. 先过 `spec review`，再过 `code review`，顺序不能反。
+9. 不在 `cc-do` 里改 capability spec 正文；这里只产出实现证据和 spec 对齐证据。
+10. 失败和阻塞都要留下恢复证据。
+11. 给 subagent 的输入必须包含：当前进度、当前任务全文、依赖状态、必读文件、验收标准、可信命令。
+12. 三次失败修补后必须先质疑调查合同或设计合同，而不是继续堆补丁。
 
 ## Exit Criteria
 

package/.claude/skills/cc-do/references/execution-recovery.md

@@ -7,6 +7,8 @@
 - 当前 task status
 - 当前 active phase
 - 当前 ready tasks
+- 当前 wave / parallel candidates / touch conflict verdict
+- submoduleTouches（如适用）
 - 当前 review gates（spec / code）
 - 已完成证据
 - 阻塞点
@@ -37,11 +39,14 @@
 1. `context_ready`
 2. `red_failed`
 3. `red_reason_verified`
-4. `green_passed`
-5. `refactor_done` 或 `refactor_not_needed`
-6. `refactor_green`
-7. `spec_review_pass`
-8. `code_review_pass`
+4. `red_seam_verified`
+5. `red_behavior_verified`
+6. `mock_boundary_verified`
+7. `green_passed`
+8. `refactor_done` 或 `refactor_not_needed`
+9. `refactor_green`
+10. `spec_review_pass`
+11. `code_review_pass`
 
 如果 `events.jsonl` 没开启，至少仍要有最新 `checkpoint.json` 和 manifest review verdict。
 
@@ -52,9 +57,17 @@
 - `red.command`
 - `red.exitStatus`
 - `red.expectedFailure`
+- `red.testSeam`
+- `red.behaviorAsserted`
+- `red.allowedMocks`
+- `red.implementationDetailRisk`
 - `green.command`
 - `green.exitStatus`
 - `refactor.status`
+- `testQuality.usesPublicInterface`
+- `testQuality.describesBehavior`
+- `testQuality.survivesInternalRefactor`
+- `testQuality.mocksOnlySystemBoundaries`
 - `review.spec.status`
 - `review.code.status`
 
@@ -84,3 +97,4 @@
 - 验收标准
 - 验证命令
 - 不做项 / 边界
+- quick lane 是否仍有 mini manifest、checkpoint、verification 和唯一 next action

package/.claude/skills/cc-do/references/parallel-dispatch.md

@@ -12,17 +12,18 @@
 
 1. 两个任务都在当前 active phase
 2. `dependsOn` 已满足，且互不依赖
-3. `touches` / `files` 没有交集
+3. `touches` / `files` 没有交集，且没有父路径 / 子路径重叠
 4. 不共享同一个可变资源，例如同一 schema、同一公共接口、同一全局状态
 5. 验证命令可以各自独立运行
 6. 每个任务都有完整上下文包，不需要靠别人的临场解释补脑
+7. submodule touches 已经被识别；只有实际触达 submodule 的任务失去普通 worktree 隔离资格
 
 ## Must Run Sequentially
 
 命中任一条，就必须串行：
 
 1. 一个任务依赖另一个任务的输出
-2. 两个任务会改同一个文件或同一抽象边界
+2. 两个任务会改同一个文件、父子路径或同一抽象边界
 3. 上游任务在定义契约，下游任务在消费契约
 4. 一个任务先改 schema / API，另一个任务基于它写实现
 5. 你还不能清楚说出每个任务各自的验收标准
@@ -50,8 +51,9 @@
 
 1. 先选当前 active phase 的 ready tasks
 2. 在 ready tasks 里优先选 `touches` 不重叠的任务
-3. 在不重叠任务里优先选验证面最小的任务
-4. 如果仍然不确定，退回串行
+3. 在不重叠任务里排除 submodule-touch 隔离风险
+4. 在剩余任务里优先选验证面最小的任务
+5. 如果仍然不确定，退回串行
 
 ## Good Example
 

package/.claude/skills/cc-do/scripts/detect-file-conflicts.sh

@@ -30,18 +30,41 @@ const sourceTasks = Array.isArray(parsed)
 const tasks = sourceTasks.filter((task) => task && task.parallel !== false);
 const fileConflicts = [];
 const dependencyConflicts = [];
+const submoduleTouches = [];
 const conflictedTaskIds = new Set();
 
 function touchesOf(task) {
-  return [...new Set([...(task.touches || []), ...(task.files || [])].filter(Boolean))];
+  return [...new Set([...(task.touches || []), ...(task.files || [])].filter(Boolean).map(normalizePath))];
+}
+
+function normalizePath(value) {
+  return String(value)
+    .replace(/\\/g, '/')
+    .replace(/\/+/g, '/')
+    .replace(/^\.\//, '')
+    .replace(/\/$/, '');
+}
+
+function overlaps(left, right) {
+  if (left === right) return left;
+  if (left && right.startsWith(`${left}/`)) return left;
+  if (right && left.startsWith(`${right}/`)) return right;
+  return '';
 }
 
 for (let index = 0; index < tasks.length; index += 1) {
   for (let offset = index + 1; offset < tasks.length; offset += 1) {
     const left = tasks[index];
     const right = tasks[offset];
-    const leftTouches = new Set(touchesOf(left));
-    const sharedTouches = touchesOf(right).filter((touch) => leftTouches.has(touch));
+    const leftTouches = touchesOf(left);
+    const rightTouches = touchesOf(right);
+    const sharedTouches = [
+      ...new Set(
+        leftTouches.flatMap((leftTouch) =>
+          rightTouches.map((rightTouch) => overlaps(leftTouch, rightTouch)).filter(Boolean)
+        )
+      )
+    ];
 
     if (sharedTouches.length > 0) {
       conflictedTaskIds.add(left.id);
@@ -68,6 +91,28 @@ for (let index = 0; index < tasks.length; index += 1) {
   }
 }
 
+const submodulePaths = (parsed.submodulePaths || [])
+  .map(normalizePath)
+  .filter(Boolean);
+
+if (submodulePaths.length > 0) {
+  for (const task of tasks) {
+    const taskTouches = touchesOf(task);
+
+    for (const submodulePath of submodulePaths) {
+      const matchedTouches = taskTouches.filter((touch) => overlaps(submodulePath, touch));
+
+      if (matchedTouches.length > 0) {
+        submoduleTouches.push({
+          task: task.id,
+          submodulePath,
+          touches: matchedTouches
+        });
+      }
+    }
+  }
+}
+
 const safeTaskIds = tasks
   .map((task) => task.id)
   .filter((taskId) => !conflictedTaskIds.has(taskId));
@@ -78,6 +123,7 @@ process.stdout.write(
       hasConflicts: fileConflicts.length > 0 || dependencyConflicts.length > 0,
       fileConflicts,
       dependencyConflicts,
+      submoduleTouches,
       safeTaskIds
     },
     null,

package/.claude/skills/cc-do/scripts/verify-task-gates.sh

@@ -82,12 +82,25 @@ if [[ -f "$events_file" ]]; then
       echo "-1"
     }
 
-    red_idx="$(first_index "red_failed")"
-    green_idx="$(first_index "green_passed")"
-    if [[ "$red_idx" != "-1" && "$green_idx" != "-1" && "$red_idx" -ge "$green_idx" ]]; then
-      echo "Task $TASK_ID gate order is invalid" >&2
-      exit 1
-    fi
+    assert_before() {
+      local before="$1"
+      local after="$2"
+      local before_idx after_idx
+      before_idx="$(first_index "$before")"
+      after_idx="$(first_index "$after")"
+      if [[ "$before_idx" != "-1" && "$after_idx" != "-1" && "$before_idx" -ge "$after_idx" ]]; then
+        echo "Task $TASK_ID gate order is invalid: $before must precede $after" >&2
+        exit 1
+      fi
+    }
+
+    assert_before "red_failed" "red_reason_verified"
+    assert_before "red_reason_verified" "red_seam_verified"
+    assert_before "red_seam_verified" "red_behavior_verified"
+    assert_before "red_behavior_verified" "mock_boundary_verified"
+    assert_before "mock_boundary_verified" "green_passed"
+    assert_before "red_failed" "green_passed"
+    assert_before "green_passed" "refactor_green"
   fi
 fi