cc-devflow 4.5.2 → 4.5.3

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

@@ -1,6 +1,6 @@
 ---
 name: cc-simplify
-version: 1.3.0
+version: 1.4.0
 description: "Use when changed code needs a Codex-native simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
 ---
 
@@ -101,6 +101,9 @@ Finding JSONL schema：
 4. 是否有 parameter sprawl：为了一个场景继续给函数加参数，而不是整理输入对象或拆出职责。
 5. 是否泄漏抽象边界：调用方知道了内部状态、文件布局、协议细节或测试专用机制。
 6. 文件是否因为本次改动开始承担多个职责；如果只是历史遗留，不在本轮扩大范围。
+7. 新增模块是否是浅包装：接口复杂度几乎等于实现复杂度，删除它只是把同样复杂度搬到调用方。
+8. seam 是否真实：只有一个 adapter 且没有明确第二个调用场景时，先当作 hypothetical seam；不要为了假扩展性制造抽象。
+9. deep module 机会：如果一个小接口能隐藏大量重复调用顺序、错误处理、配置或状态转换，优先让复杂度集中到该模块，而不是散落在调用方。
 
 #### Agent C: Quality / Efficiency / Test Reviewer
 
@@ -210,6 +213,12 @@ Decision：
 3. **需求事实**：对照 `planning/tasks.md`、`change-meta.json`、capability spec，确认没有误删必要行为。
 4. **验证事实**：明确修复后用什么命令或检查证明没有回归。
 
+架构类 finding 还必须过删除测试：想象删除这个模块、helper、wrapper 或 seam。
+
+- 如果复杂度只是原样散回多个调用方，它可能是有价值的 deep module。
+- 如果复杂度消失或只留下一个直接调用，它多半是 pass-through / fake seam。
+- 如果删除会违反 capability invariant 或 public contract，就不能当作 cleanup 直接删。
+
 如果 reviewer 建议“更专业”的能力，先做 YAGNI 检查：没有调用方、没有需求、没有 acceptance，就不要新增。
 
 这些情况不要报成 finding：

package/.claude/skills/cc-spec-init/CHANGELOG.md

@@ -1,5 +1,11 @@
 # CC-Spec-Init Skill Changelog
 
+## v1.1.0 - 2026-04-28
+
+- add a language boundary gate for canonical capability terms, aliases to avoid, flagged ambiguity, and relationship constraints
+- require new capability specs to include a minimal language block before registration in `INDEX.md`
+- prevent implementation names from becoming capability truth unless they already represent stable public domain language
+
 ## v1.0.1 - 2026-04-27
 
 - require capability specs, spec indexes, and change metadata to resolve the runtime output policy before writing durable artifacts

package/.claude/skills/cc-spec-init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cc-spec-init
-version: 1.0.1
+version: 1.1.0
 description: Use when you need to initialize capability specs under `devflow/specs/`, create or evolve capability truth sources, generate `change-meta.json`, or validate roadmap/change/spec links before roadmap, planning, or closeout work continues.
 ---
 
@@ -67,6 +67,7 @@ description: Use when you need to initialize capability specs under `devflow/spe
 2. 先判断你是在做 `bootstrap`、`create`、`update-links`、`split`、`merge` 还是 `deprecate`。
 3. 先锁定 capability 边界，再写模板；不要先写 prose 再猜结构。
 4. 先明确 primary capability，再允许 secondary capabilities 存在。
+5. 先检查命名是否已经有 canonical term；同义词、歧义词和关系约束没收口前，不要新建第二套 capability 名称。
 
 ## Session Protocol
 
@@ -80,6 +81,7 @@ description: Use when you need to initialize capability specs under `devflow/spe
    - 为当前已知 capability 写最小 spec
 3. 如果是新 capability：
    - 先写 capability 边界、约束、当前 truth、gaps
+   - 再写最小 language block：canonical term、definition、aliases to avoid、relationships、flagged ambiguities
    - 再登记到 `INDEX.md`
 4. 如果是 change 绑定：
    - 生成或更新 `change-meta.json`
@@ -91,6 +93,17 @@ description: Use when you need to initialize capability specs under `devflow/spe
    - `INDEX.md` 引到的 capability 文件都存在
    - `change-meta.json` 里的 capability 都能落到 spec
    - roadmap / backlog 里的 capability 引用仍可追踪
+   - 新 capability 的名称、aliases、relationships 没有和已有 spec 冲突
+
+## Language Boundary Gate
+
+capability spec 是长期 truth source，命名必须比一次需求更稳定：
+
+- canonical term：只选一个主名，优先沿用 roadmap、历史 design/analysis、代码公共接口和用户领域语言里已经稳定的词。
+- aliases to avoid：记录容易混用的别名，说明为什么不能继续用。
+- flagged ambiguity：同一个词指向两个概念时，必须写清拆分边界，必要时拆 capability。
+- relationships：用一句话写清 capability 之间的拥有、依赖、生命周期、输入输出或互斥关系。
+- implementation names：类名、文件名、函数名只有在它们已经是公共领域语言时才进入 spec；否则留在 change 设计里。
 
 ## Output
 

package/CHANGELOG.md

@@ -9,6 +9,27 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [4.5.3] - 2026-04-29
+
+### Skill Strategy Integration
+
+v4.5.3 absorbs the useful strategies from an external skill library into native
+cc-devflow contracts, keeping the public workflow cohesive instead of adding
+parallel skill surfaces.
+
+### Changed
+
+- Added an external skill strategy audit and migrated the useful patterns into native cc-devflow contracts instead of copying external skill prose.
+- Updated `cc-plan` to capture glossary deltas, compare non-trivial interface shapes, mark `AFK` / `HITL` vertical slices, and keep durable handoffs behavior-focused.
+- Updated `cc-investigate` to sharpen feedback loops as investigation products and record prevention handoffs after root-cause freeze.
+- Updated `cc-do` and `cc-check` to enforce tracer-bullet execution and review test fixture honesty around partial data, casts, stubs, and mocks.
+- Updated `cc-simplify` to apply deep-module, deletion-test, and real-seam checks before accepting architecture cleanup findings.
+- Updated `cc-act`, `cc-spec-init`, and `docs-sync` to harden issue handoffs, dangerous git action safety, capability language boundaries, and skill contract quality gates.
+- Updated `cc-check` to require QA feedback-loop and behavior evidence for bugfix and user-visible behavior verification, including reproduction mode, determinism, expected/actual behavior, and test seam follow-ups.
+- Updated `cc-act` to carry QA behavior evidence into PR briefs, handoffs, and release notes, and to write follow-ups as durable behavior briefs before roadmap/backlog writeback.
+- Updated `cc-roadmap`, `cc-plan`, and `cc-investigate` to keep canonical language and durable decisions in cc-devflow-native sources: `devflow/specs/`, roadmap/backlog, design/analysis, and change metadata.
+- Refreshed public examples and skill binding metadata for `cc-roadmap@4.4.1`, `cc-plan@3.7.0`, `cc-investigate@1.2.0`, `cc-do@1.6.0`, `cc-check@1.10.0`, `cc-act@1.8.0`, and `cc-spec-init@1.1.0`.
+
 ## [4.5.2] - 2026-04-28
 
 ### Skill Review Hardening

package/README.md

@@ -76,9 +76,17 @@ Maintenance skills are shipped with the pack:
 
 ## Planning Quality Gates
 
-`cc-roadmap` now records planning posture and evidence maturity before recommending a route. That keeps idea-stage, active-user, paying-customer, infrastructure, and recovery work from being forced through the same questions. Developer-facing or operator-facing roadmap items also carry target user, time to first value, magic moment, and adoption bottleneck into `cc-plan`.
+`cc-roadmap` now records planning posture, evidence maturity, canonical project language, and durable decision context before recommending a route. That keeps idea-stage, active-user, paying-customer, infrastructure, and recovery work from being forced through the same questions, and prevents roadmap items from inventing a second vocabulary. Developer-facing or operator-facing roadmap items also carry target user, time to first value, magic moment, adoption bottleneck, and domain handoff into `cc-plan`.
 
-`cc-plan` freezes more implementation decisions before `cc-do` starts. Non-trivial plans compare minimal viable and ideal architecture options, full designs include decision horizon plus error/rescue mapping, and test-first plans record test framework evidence, coverage quality, and mandatory regression tests when existing behavior changes.
+Canonical language and durable decisions stay inside cc-devflow-native sources: `devflow/specs/`, `devflow/ROADMAP.md`, `devflow/BACKLOG.md`, `planning/design.md`, `planning/analysis.md`, and `change-meta.json`.
+
+`cc-plan` freezes more implementation decisions before `cc-do` starts. Non-trivial plans compare minimal viable and ideal architecture options, full designs include decision horizon plus error/rescue mapping, and test-first plans record test framework evidence, public test seams, behavior assertions, mock boundaries, coverage quality, mandatory regression tests, interface depth, and vertical tracer-bullet slices when existing behavior changes.
+
+## Verification And Ship Gates
+
+`cc-check` now treats QA as a feedback-loop problem, not only a green-test problem. Bugfix and behavior work records the loop used to prove reality, expected versus actual behavior, reproduction steps, test boundary quality, and architecture follow-ups when no clean public test seam exists.
+
+`cc-act` carries that evidence into PR briefs, handoffs, and release notes. Follow-ups must be durable behavior briefs with current behavior, desired behavior, key interfaces, acceptance criteria, and explicit out-of-scope notes before they are written back to roadmap or backlog.
 
 ## Installation Modes
 

package/README.zh-CN.md

@@ -76,9 +76,17 @@ npx cc-devflow@latest adapt --cwd /path/to/your/project --all
 
 ## 计划质量门禁
 
-`cc-roadmap` 现在会先记录 planning posture 和 evidence maturity，再推荐路线。idea、已有用户、付费客户、infra、recovery 场景不会被套进同一组问题。面向开发者或操作者的 roadmap item 还会把目标用户、time to first value、magic moment 和 adoption bottleneck 交给 `cc-plan`。
+`cc-roadmap` 现在会先记录 planning posture、evidence maturity、项目 canonical language 和持久决策上下文，再推荐路线。idea、已有用户、付费客户、infra、recovery 场景不会被套进同一组问题，也不会让 roadmap item 发明第二套词汇。面向开发者或操作者的 roadmap item 还会把目标用户、time to first value、magic moment、adoption bottleneck 和 domain handoff 交给 `cc-plan`。
 
-`cc-plan` 会在 `cc-do` 开始前冻结更多实现决策。非 trivial 计划需要比较 minimal viable 和 ideal architecture，full-design 需要包含 implementation decision horizon 和 error/rescue map；测试计划要记录测试框架证据、覆盖质量，并在修改既有行为时强制规划 regression test。
+Canonical language 和 durable decisions 只收敛到 cc-devflow 原生真相源：`devflow/specs/`、`devflow/ROADMAP.md`、`devflow/BACKLOG.md`、`planning/design.md`、`planning/analysis.md` 和 `change-meta.json`。
+
+`cc-plan` 会在 `cc-do` 开始前冻结更多实现决策。非 trivial 计划需要比较 minimal viable 和 ideal architecture，full-design 需要包含 implementation decision horizon 和 error/rescue map；测试计划要记录测试框架证据、public test seam、behavior assertion、mock boundary、覆盖质量、强制 regression test、interface depth 和 vertical tracer-bullet slices。
+
+## 验证与交付门禁
+
+`cc-check` 现在把 QA 当成反馈环问题，而不是只看测试是否绿。Bugfix 和行为变更需要记录证明现实的 loop、expected / actual、复现步骤、测试边界质量；如果没有干净的 public test seam，要留下架构 follow-up。
+
+`cc-act` 会把这些证据带进 PR brief、handoff 和 release note。Follow-up 必须写成 durable behavior brief，包含 current behavior、desired behavior、key interfaces、acceptance criteria 和 out-of-scope，再回写 roadmap 或 backlog。
 
 ## 安装方式
 

package/docs/examples/example-bindings.json

@@ -1,13 +1,13 @@
 {
   "updatedAt": "2026-04-28",
   "skills": {
-    "cc-roadmap": "4.3.4",
-    "cc-plan": "3.5.6",
-    "cc-investigate": "1.1.4",
-    "cc-do": "1.5.2",
-    "cc-check": "1.8.4",
-    "cc-act": "1.6.4",
-    "cc-spec-init": "1.0.1"
+    "cc-roadmap": "4.4.1",
+    "cc-plan": "3.7.0",
+    "cc-investigate": "1.2.0",
+    "cc-do": "1.6.0",
+    "cc-check": "1.10.0",
+    "cc-act": "1.8.0",
+    "cc-spec-init": "1.1.0"
   },
   "examples": [
     {

package/docs/examples/full-design-blocked/BACKLOG.md

@@ -3,7 +3,7 @@
 ## Backlog Meta
 
 - Roadmap version: `roadmap.v2`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Last synced: `2026-04-19`
 - Current focus stage: `Stage 2`
 - Tracking source: `roadmap-tracking.json`

package/docs/examples/full-design-blocked/README.md

@@ -4,7 +4,7 @@
 
 - Example version: `1.0.0`
 - Last reviewed: `2026-04-17`
-- Bound skills: `cc-roadmap@4.3.4`, `cc-plan@3.5.6`, `cc-do@1.5.2`, `cc-check@1.8.4`
+- Bound skills: `cc-roadmap@4.4.1`, `cc-plan@3.7.0`, `cc-do@1.6.0`, `cc-check@1.10.0`
 
 This example shows a requirement that **looked executable**, but `cc-check` correctly stopped it and sent it back to `cc-plan`.
 

package/docs/examples/full-design-blocked/ROADMAP.md

@@ -3,7 +3,7 @@
 ## Roadmap Meta
 
 - Roadmap version: `roadmap.v2`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Status: `active`
 - Last updated: `2026-04-16`
 - Owner / decider: `product-owner`

package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/design.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-002.v2`
 - Design version: `design.v2`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Requirement ID: `REQ-002`
 - Design mode: `full-design`
 - Why not `tiny-design`: the feature crosses import parsing, invite rules, billing limits, duplicate handling, and audit logging

package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/tasks.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-002.v2`
 - Design version: `design.v2`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Source roadmap item: `RM-010`
 - Source roadmap version: `roadmap.v2`
 

package/docs/examples/full-design-blocked/roadmap-tracking.json

@@ -3,7 +3,7 @@
   "lastSyncedAt": "2026-04-19",
   "backlogMeta": {
     "roadmapVersion": "roadmap.v2",
-    "skillVersion": "4.3.4",
+    "skillVersion": "4.4.1",
     "currentFocusStage": "Stage 2"
   },
   "dependencyHandoff": {

package/docs/examples/local-handoff/BACKLOG.md

@@ -3,7 +3,7 @@
 ## Backlog Meta
 
 - Roadmap version: `roadmap.v2`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Last synced: `2026-04-19`
 - Current focus stage: `Stage 2`
 - Tracking source: `roadmap-tracking.json`

package/docs/examples/local-handoff/README.md

@@ -4,7 +4,7 @@
 
 - Example version: `1.0.0`
 - Last reviewed: `2026-04-17`
-- Bound skills: `cc-roadmap@4.3.4`, `cc-plan@3.5.6`, `cc-do@1.5.2`, `cc-check@1.8.4`, `cc-act@1.6.4`
+- Bound skills: `cc-roadmap@4.4.1`, `cc-plan@3.7.0`, `cc-do@1.6.0`, `cc-check@1.10.0`, `cc-act@1.8.0`
 
 This example shows verified work that is **ready to move forward**, but `cc-act` still chooses `local-handoff`.
 

package/docs/examples/local-handoff/ROADMAP.md

@@ -3,7 +3,7 @@
 ## Roadmap Meta
 
 - Roadmap version: `roadmap.v3`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Status: `active`
 - Last updated: `2026-04-16`
 - Owner / decider: `product-owner`

package/docs/examples/local-handoff/changes/REQ-003-audit-log-export/planning/design.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-003.v1`
 - Design version: `design.v1`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Requirement ID: `REQ-003`
 - Design mode: `tiny-design`
 - Why this stays `tiny-design`: the patch adds one export action inside the existing admin audit UI without changing data contracts

package/docs/examples/local-handoff/changes/REQ-003-audit-log-export/planning/tasks.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-003.v1`
 - Design version: `design.v1`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Source roadmap item: `RM-020`
 - Source roadmap version: `roadmap.v3`
 

package/docs/examples/local-handoff/roadmap-tracking.json

@@ -3,7 +3,7 @@
   "lastSyncedAt": "2026-04-19",
   "backlogMeta": {
     "roadmapVersion": "roadmap.v2",
-    "skillVersion": "4.3.4",
+    "skillVersion": "4.4.1",
     "currentFocusStage": "Stage 2"
   },
   "dependencyHandoff": {

package/docs/examples/pdca-loop/BACKLOG.md

@@ -3,7 +3,7 @@
 ## Backlog Meta
 
 - Roadmap version: `roadmap.v1`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Last synced: `2026-04-19`
 - Current focus stage: `Stage 1`
 - Tracking source: `roadmap-tracking.json`

package/docs/examples/pdca-loop/README.md

@@ -4,7 +4,7 @@
 
 - Example version: `1.0.0`
 - Last reviewed: `2026-04-17`
-- Bound skills: `cc-roadmap@4.3.4`, `cc-plan@3.5.6`, `cc-do@1.5.2`, `cc-check@1.8.4`, `cc-act@1.6.4`
+- Bound skills: `cc-roadmap@4.4.1`, `cc-plan@3.7.0`, `cc-do@1.6.0`, `cc-check@1.10.0`, `cc-act@1.8.0`
 
 This folder shows one minimal but complete `cc-roadmap -> cc-plan -> cc-do -> cc-check -> cc-act` loop.
 

package/docs/examples/pdca-loop/ROADMAP.md

@@ -3,7 +3,7 @@
 ## Roadmap Meta
 
 - Roadmap version: `roadmap.v1`
-- Skill version: `4.3.4`
+- Skill version: `4.4.1`
 - Status: `active`
 - Last updated: `2026-04-15`
 - Owner / decider: `product-owner`

package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/design.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-001.v1`
 - Design version: `design.v1`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Requirement ID: `REQ-001`
 - Design mode: `tiny-design`
 - Why this stays `tiny-design`: the patch is limited to an existing dialog and test file, with no API or data model changes

package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/task-manifest.json

@@ -9,7 +9,7 @@
   "sourceRoadmap": {
     "itemId": "RM-001",
     "roadmapVersion": "roadmap.v1",
-    "roadmapSkillVersion": "4.3.4",
+    "roadmapSkillVersion": "4.4.1",
     "sourceStage": "Stage 1",
     "successSignal": "Users can copy the invite link with one click",
     "killSignal": "The patch requires backend or permission changes",
@@ -22,7 +22,7 @@
     ]
   },
   "planningMeta": {
-    "reqPlanSkillVersion": "3.5.6",
+    "reqPlanSkillVersion": "3.7.0",
     "designVersion": "design.v1",
     "approvedAt": "2026-04-15T10:05:00.000Z",
     "approvedBy": "user",

package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/tasks.md

@@ -4,7 +4,7 @@
 
 - Requirement version: `REQ-001.v1`
 - Design version: `design.v1`
-- CC-Plan skill version: `3.5.6`
+- CC-Plan skill version: `3.7.0`
 - Source roadmap item: `RM-001`
 - Source roadmap version: `roadmap.v1`
 

package/docs/examples/pdca-loop/roadmap-tracking.json

@@ -3,7 +3,7 @@
   "lastSyncedAt": "2026-04-19",
   "backlogMeta": {
     "roadmapVersion": "roadmap.v1",
-    "skillVersion": "4.3.4",
+    "skillVersion": "4.4.1",
     "currentFocusStage": "Stage 1"
   },
   "dependencyHandoff": {

package/docs/skill-strategy-audit.md

@@ -0,0 +1,48 @@
+# External Skill Strategy Audit
+
+本审计覆盖 `/Users/dimon/001Area/80-CodeWorld/003-project/skills` 下的 22 个
+`SKILL.md`。目标不是复制外部 skill，而是抽取能让 cc-devflow 原生 workflow
+更稳的策略，并把不适合迁移的部分明确跳过。
+
+## Migration Summary
+
+| Source skill | Good strategy | cc-devflow target | Decision |
+| --- | --- | --- | --- |
+| `deprecated/design-an-interface` | "design it twice"，用不同接口形态比较 depth、易用错点和隐藏复杂度 | `cc-plan` | 迁移为接口备选比较 gate，不迁移 parallel subagent 强制要求 |
+| `deprecated/qa` | 用户视角 issue、轻量澄清、按可独立验证行为拆分 | `cc-act` / `cc-plan` | 迁移为 follow-up / issue handoff 的行为化规则 |
+| `deprecated/request-refactor-plan` | 重构计划拆成 tiny commits，每步保持可运行 | `cc-plan` / `cc-act` | 迁移为 refactor slicing 和 bisectable commit 规则 |
+| `deprecated/triage-issue` | 先查根因，再写 TDD fix plan，issue 不绑定易腐烂文件行号 | `cc-investigate` / `cc-plan` | 迁移为 repair contract 和 durable issue brief 规则 |
+| `deprecated/ubiquitous-language` | canonical terms、aliases to avoid、ambiguity flag | `cc-spec-init` / `cc-plan` | 迁移为 capability/domain language glossary gate |
+| `engineering/diagnose` | 反馈回路优先级、提高 flaky 复现率、假设必须可证伪、debug tag cleanup | `cc-investigate` | 已有大部分；补强 loop sharpening 和 postmortem handoff |
+| `engineering/github-triage` | label state machine、needs-info 保留已确认事实、resume triage notes | `cc-act` | 迁移为远端 issue/PR closeout 的状态一致性规则 |
+| `engineering/grill-with-docs` | 术语冲突立即叫停、具体场景压测、ADR 只记难逆/意外/真实取舍 | `cc-plan` | 已有大部分；补强 glossary update 和 ADR sparsity |
+| `engineering/improve-codebase-architecture` | deep module、deletion test、one adapter vs two adapters、locality/leverage | `cc-simplify` / `cc-plan` | 迁移为架构坏味道确认清单 |
+| `engineering/tdd` | 禁止水平切片，使用 tracer bullet 垂直 Red/Green 循环 | `cc-do` / `cc-plan` | 已有 planning 规则；补强执行阶段逐条 task 的 tracer bullet guard |
+| `engineering/to-issues` | 独立可领的 vertical slices，HITL/AFK 标注，依赖顺序创建 | `cc-plan` / `cc-act` | 迁移为 task / follow-up 切片规则 |
+| `engineering/to-prd` | 从现有上下文合成 PRD，测试决策只写行为和模块，不写短期文件路径 | `cc-plan` | 迁移为 design durable output 规则，不迁移 GitHub issue 自动创建 |
+| `engineering/zoom-out` | 不熟悉区域时先上升一层，画模块和调用方地图 | `cc-roadmap` / `cc-plan` | 已被 context sweep 覆盖；仅作为审计备注 |
+| `misc/git-guardrails-claude-code` | 阻断危险 git 动作，保留用户确认边界 | `cc-act` | 迁移为 destructive / publish action guard，不迁移 Claude hook 实现 |
+| `misc/migrate-to-shoehorn` | 测试里的 partial fixture 要显式表达，不用不透明 cast 掩盖类型事实 | `cc-do` / `cc-check` | 迁移为通用 test fixture discipline，不绑定 shoehorn 依赖 |
+| `misc/scaffold-exercises` | 生成目录后必须跑专用 lint，移动用 `git mv` 保留历史 | `cc-act` | 仅迁移验证/移动原则；课程目录规则不迁移 |
+| `misc/setup-pre-commit` | 根据实际包管理器和已有 scripts 装配 hook，最后用真实 hook smoke | `cc-act` | 仅作为工具链变更验证参考，不迁移 Husky 方案 |
+| `personal/edit-article` | 文档结构按依赖顺序组织，段落短、信息先后可追踪 | `docs-sync` | 迁移为 docs-sync 叙事顺序规则 |
+| `personal/obsidian-vault` | index note、wikilink、反向查找的知识图谱维护 | none | 个人知识库规则，不迁移到 cc-devflow |
+| `productivity/caveman` | 压缩沟通但保留精确技术事实，复杂步骤暂时恢复完整表达 | `cc-act` / output style | 作为输出风格参考，不写进 workflow 合约 |
+| `productivity/grill-me` | 一次一个问题；能查代码就别问用户 | `cc-plan` | 已有规则；审计确认不重复迁移 |
+| `productivity/write-a-skill` | description 是触发真相源；SKILL.md 要短，复杂内容下沉到 references/scripts | `docs-sync` | 迁移为 skill contract quality gate |
+
+## Implementation Order
+
+1. `cc-plan`: 吸收接口备选、领域语言、垂直切片和 durable design 输出规则。
+2. `cc-investigate`: 补强 feedback loop sharpening、flaky rate、postmortem handoff。
+3. `cc-do`: 补强 tracer bullet 执行和 test fixture discipline。
+4. `cc-simplify`: 增加 deep module / deletion test / adapter reality 检查。
+5. `cc-act`: 增加 issue/PR 状态、危险 git 动作、工具链验证和 durable follow-up 规则。
+6. `docs-sync`: 增加 skill 合约质量 gate 和文档依赖顺序检查。
+
+## Skip Rules
+
+- 不迁移个人路径、个人 vault、课程目录命名、具体第三方测试依赖。
+- 不把 deprecated skill 的 GitHub issue 自动创建行为搬进主流程；cc-devflow 仍以
+  durable local artifact 和可选 remote handoff 为主。
+- 不新增一套平行 skill；所有迁移必须落回现有 `cc-*` workflow 语义。

package/lib/skill-runtime/__tests__/runtime.integration.test.js

@@ -204,7 +204,22 @@ describe('Skill runtime', () => {
       '--status',
       'passed',
       '--summary',
-      'task finished'
+      'task finished',
+      '--tdd-json',
+      JSON.stringify({
+        red: {
+          testSeam: 'public helper command',
+          behaviorAsserted: 'checkpoint is written under execution/tasks',
+          allowedMocks: [],
+          implementationDetailRisk: 'low'
+        },
+        testQuality: {
+          usesPublicInterface: true,
+          describesBehavior: true,
+          survivesInternalRefactor: true,
+          mocksOnlySystemBoundaries: true
+        }
+      })
     ], { encoding: 'utf8' });
     expect(checkpoint.status).toBe(0);
 
@@ -245,6 +260,9 @@ describe('Skill runtime', () => {
     expect(verify.status).toBe(0);
 
     expect(fs.existsSync(path.join(change.tasksDir, 'T001', 'checkpoint.json'))).toBe(true);
+    const checkpointJson = JSON.parse(fs.readFileSync(path.join(change.tasksDir, 'T001', 'checkpoint.json'), 'utf8'));
+    expect(checkpointJson.tdd.red.testSeam).toBe('public helper command');
+    expect(checkpointJson.tdd.testQuality.usesPublicInterface).toBe(true);
     expect(fs.existsSync(path.join(repoRoot, '.harness', 'runtime', changeId))).toBe(false);
     expect(fs.existsSync(path.join(change.tasksDir, 'T001', 'checkpoint.md'))).toBe(false);
     expect(fs.existsSync(path.join(change.tasksDir, 'T001', 'review-spec.md'))).toBe(false);

package/lib/skill-runtime/schemas.js

@@ -247,6 +247,14 @@ const ManifestSchema = z.object({
   }
 });
 
+const TddCheckpointEvidenceSchema = z.object({
+  red: z.record(z.any()).optional(),
+  green: z.record(z.any()).optional(),
+  refactor: z.record(z.any()).optional(),
+  feedbackLoop: z.record(z.any()).optional(),
+  testQuality: z.record(z.any()).optional()
+}).passthrough();
+
 const CheckpointSchema = z.object({
   changeId: ChangeIdSchema,
   taskId: z.string().regex(TASK_ID_PATTERN),
@@ -257,7 +265,9 @@ const CheckpointSchema = z.object({
   error: z.string().default(''),
   outputExcerpt: z.string().default(''),
   timestamp: z.string().datetime(),
-  attempt: z.number().int().min(0).default(0)
+  attempt: z.number().int().min(0).default(0),
+  tdd: TddCheckpointEvidenceSchema.optional(),
+  tddException: z.record(z.any()).optional()
 });
 
 const GateResultSchema = z.object({

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "cc-devflow",
-    "version": "4.5.2",
+    "version": "4.5.3",
     "description": "Multi-platform CLI and skill pack for agent coding",
     "main": "bin/cc-devflow.js",
     "bin": {