cc-devflow 4.5.2 → 4.5.3

package/.claude/skills/cc-plan/assets/DESIGN_TEMPLATE.md

@@ -40,6 +40,16 @@
 - Intentional gaps:
 - Spec sync target:
 
+## Domain Language & Durable Decisions
+
+- Language sources loaded:
+- Canonical terms used:
+- Terms avoided / aliases:
+- Language conflicts:
+- Native decision sources loaded:
+- Capability spec / roadmap decision conflicts:
+- Decisions worth long-term capability spec sync:
+
 ## Requirement Snapshot
 
 - Raw ask:
@@ -101,6 +111,14 @@
 - Error handling:
 - Rollout / migration:
 
+## Interface / Deep Module Check
+
+| Surface | Callers | Public operations | Complexity hidden | Misuse risk | Shape decision |
+|---------|---------|-------------------|-------------------|-------------|----------------|
+|  |  |  |  |  |  |
+
+> 新增或改动公共接口时，优先小接口深模块。若有两个合理形态，写清为什么没有选择另一个。
+
 ## Implementation Decision Horizon
 
 | Phase | Decision `cc-do` would otherwise hit | Frozen answer | Evidence / owner |
@@ -142,6 +160,11 @@
 
 - Test framework source:
 - First failing tests:
+- Test seams / public interfaces:
+- Behavior assertions:
+- Mock boundaries:
+- Feedback loop types:
+- Tracer bullet order:
 - Red/Green/Refactor task chain:
 - TDD exceptions:
 - Regression tests required:
@@ -154,9 +177,9 @@
 
 ## Test Coverage Map
 
-| Code path / user flow | Existing coverage | Quality | Required test | Level | Regression? |
-|-----------------------|-------------------|---------|---------------|-------|-------------|
-|  |  | strong / happy-path-only / smoke-only / missing |  | unit / integration / e2e / eval | Yes / No |
+| Code path / user flow | Public seam | Behavior asserted | Existing coverage | Quality | Required test | Level | Mock boundary | Implementation-detail risk | Regression? |
+|-----------------------|-------------|-------------------|-------------------|---------|---------------|-------|---------------|----------------------------|-------------|
+|  |  |  |  | strong / happy-path-only / smoke-only / missing |  | unit / integration / e2e / eval | none / system boundary | low / medium / high | Yes / No |
 
 ## Error & Rescue Map
 
@@ -200,10 +223,14 @@
 - Ambiguity scan:
 - Feasibility scan:
 - Source alignment:
+- Domain language scan:
 - Implementation surface scan:
+- Interface depth scan:
 - Decision horizon scan:
 - Error & rescue scan:
 - Test framework / regression scan:
+- Test seam / mock boundary scan:
+- Tracer bullet scan:
 - UI / interaction review summary:
 - DX / operator review summary:
 - Test-first readiness:

package/.claude/skills/cc-plan/assets/TASKS_TEMPLATE.md

@@ -17,10 +17,15 @@
 - Execution mode: `single-path` | `parallel-ready`
 - Frozen decisions:
 - Capability specs:
+- Canonical language / terms:
 - Read first:
 - Commands to trust:
 - Test framework source:
+- Test seam policy: Red tasks verify behavior through public interfaces, caller flows, CLI/API/UI paths, or other real seams.
+- Mock boundary policy: mock only system boundaries; do not mock internal collaborators owned by this codebase.
+- Feedback loop ladder: automated test -> HTTP/curl -> CLI fixture -> browser script -> trace replay -> harness -> property/fuzz -> differential -> HITL.
 - TDD plan: `Red -> Green -> Refactor`
+- Tracer bullet plan: one observable behavior at a time; no horizontal "all tests first, all code later" slice
 - TDD exceptions: none | list exception reason, risk, replacement evidence, follow-up
 - Regression tests: required | not applicable, with reason
 - Do not re-decide:
@@ -36,6 +41,14 @@
 
 > 这张表是执行边界，不是装饰。任务拆分必须沿着这些职责走，不能让 `cc-do` 临场重切文件归属。
 
+## Tracer Bullet Map
+
+| Slice | Observable behavior | Public test seam | Feedback loop | Red task | Green task | Refactor / evidence | Why vertical |
+|-------|---------------------|------------------|---------------|----------|------------|---------------------|--------------|
+| Slice 1 |  |  | automated test | T001 | T002 | T005 |  |
+
+> 每个 slice 必须能独立证明一个端到端行为，不要按“只改数据层 / 只改 UI 层”横切。
+
 ## Phase 1: Foundation
 
 - [ ] T001 [TEST] Write the first failing test (dependsOn:none) `path/to/test`
@@ -46,6 +59,11 @@
   Verification: `npm test -- path/to/test`
   Evidence: failing output
   Coverage: unit / integration / e2e / eval; regression: yes / no
+  Test seam: public interface / caller flow / CLI / API / UI / trace replay / harness
+  Behavior asserted: 描述用户或调用方可观察行为，不描述内部实现步骤
+  Allowed mocks: none / external API / time / randomness / filesystem / database boundary
+  Test quality guard: no private methods, no internal call-count assertions, no internal collaborator mocks
+  Vertical slice: Slice 1
   Ready when: 没有上游依赖，且测试路径已经确定
 
 - [ ] T002 [IMPL] Make the first test pass (dependsOn:T001) `path/to/file`
@@ -55,6 +73,7 @@
   Read first: `design.md`, `path/to/test`
   Verification: `npm test -- path/to/test`
   Evidence: passing output + checkpoint
+  Vertical slice: Slice 1
   Ready when: T001 已经见红，且当前 touched files 不和其他并行任务冲突
 
 ## Phase 2: Build
@@ -67,6 +86,11 @@
   Verification: `npm test -- path/to/other.test`
   Evidence: failing output
   Coverage: unit / integration / e2e / eval; regression: yes / no
+  Test seam: public interface / caller flow / CLI / API / UI / trace replay / harness
+  Behavior asserted: 描述用户或调用方可观察行为，不描述内部实现步骤
+  Allowed mocks: none / external API / time / randomness / filesystem / database boundary
+  Test quality guard: no private methods, no internal call-count assertions, no internal collaborator mocks
+  Vertical slice: Slice 2
   Ready when: T002 完成，且该测试覆盖的是独立行为
 
 - [ ] T004 [P] [IMPL] Make the independent test pass (dependsOn:T003) `path/to/other-file`
@@ -76,6 +100,7 @@
   Read first: `design.md`, `path/to/other.test`
   Verification: `npm test -- path/to/other.test`
   Evidence: passing output + review notes
+  Vertical slice: Slice 2
   Ready when: T003 已经见红，且文件触点与其他 `[P]` 任务不冲突
 
 ## Phase 3: Verify
@@ -110,3 +135,6 @@
 - 要留下什么证据给 `cc-check`
 - 它处于 Red、Green、Refactor，还是明确的 TDD exception
 - 测试框架依据来自哪里，回归测试是否被明确处理
+- Red task 通过哪个公共 seam 证明行为缺失，允许 mock 的边界是什么
+- 测试是否会在内部重构后继续成立，而不是绑定私有函数、调用次数或临时结构
+- 它属于哪个 tracer bullet 垂直切片，完成后哪个可观察行为被证明

package/.claude/skills/cc-plan/assets/TASK_MANIFEST_TEMPLATE.json

@@ -20,16 +20,41 @@
     ]
   },
   "planningMeta": {
-    "reqPlanSkillVersion": "3.5.6",
+    "reqPlanSkillVersion": "3.7.0",
     "designVersion": "design.v1",
     "approvedAt": "2026-04-15T12:00:00.000Z",
     "approvedBy": "user",
     "basedOnOption": "Option A"
   },
+  "languageAndDecisions": {
+    "languageSources": [],
+    "canonicalTerms": [],
+    "languageConflicts": [],
+    "decisionDocs": [],
+    "adrOrSpecConflicts": []
+  },
   "executionDiscipline": {
     "default": "red-green-refactor",
+    "taskShape": "vertical-tracer-bullets",
     "testFirstRequired": true,
     "testFrameworkSource": "",
+    "testQualityPolicy": {
+      "publicInterfaceRequired": true,
+      "behaviorAssertionRequired": true,
+      "mockBoundary": "system-boundaries-only",
+      "implementationDetailTests": "blocked",
+      "feedbackLoopPreference": [
+        "automated-test",
+        "http-curl",
+        "cli-fixture",
+        "browser-script",
+        "trace-replay",
+        "throwaway-harness",
+        "property-fuzz",
+        "differential-loop",
+        "hitl-script"
+      ]
+    },
     "regressionTestsRequired": [],
     "tddExceptions": []
   },
@@ -67,6 +92,26 @@
       "phase": 1,
       "status": "pending",
       "tddPhase": "red",
+      "verticalSlice": "Slice 1",
+      "testSeam": {
+        "entry": "public interface / caller flow / CLI / API / UI / trace replay / harness",
+        "behaviorAsserted": "The user or caller observable behavior that should exist",
+        "implementationDetailRisk": "low"
+      },
+      "feedbackLoop": {
+        "type": "automated-test",
+        "determinism": "deterministic",
+        "expectedFailure": "Fails because the target behavior is missing"
+      },
+      "allowedMocks": [
+        "external API / time / randomness / filesystem / database boundary"
+      ],
+      "testQuality": {
+        "usesPublicInterface": true,
+        "describesBehavior": true,
+        "survivesInternalRefactor": true,
+        "mocksOnlySystemBoundaries": true
+      },
       "dependsOn": [],
       "parallel": false,
       "touches": [

package/.claude/skills/cc-plan/assets/TINY_DESIGN_TEMPLATE.md

@@ -32,6 +32,13 @@
 - Current gaps:
 - Spec sync target:
 
+## Domain Language & Decisions
+
+- Language sources loaded:
+- Canonical terms used:
+- Language / spec decision conflicts:
+- Decisions worth long-term spec sync:
+
 ## Frozen Design Card
 
 - Change:
@@ -45,6 +52,14 @@
 
 > `tiny-design` 是短设计，不是免设计。没有明确批准状态、验证证据和升级触发条件，就不能继续拆任务。
 
+## Interface Shape
+
+- Callers:
+- Public operations:
+- Complexity hidden:
+- Misuse risk:
+- Why this stays simple:
+
 ## Implementation Surface Map
 
 | Surface | Responsibility | Why here | Coupling risk |
@@ -55,6 +70,11 @@
 
 - Test framework source:
 - First failing test:
+- Test seam / public interface:
+- Behavior asserted:
+- Mock boundary:
+- Feedback loop type:
+- Tracer bullet order:
 - Green implementation check:
 - Refactor checkpoint:
 - TDD exceptions:
@@ -84,8 +104,12 @@
 - Scope scan:
 - Ambiguity scan:
 - Feasibility scan:
+- Domain language scan:
 - Implementation surface scan:
+- Interface depth scan:
 - Test framework / regression scan:
+- Test seam / mock boundary scan:
+- Tracer bullet scan:
 - Test-first readiness:
 - Review calibration:
 - Final recommendation:

package/.claude/skills/cc-plan/references/planning-contract.md

@@ -15,8 +15,12 @@
 11. 每个计划必须先找 existing leverage，再决定新增实现；重复已有能力属于 planning 失败。
 12. 同 blast radius 内的完整边界默认纳入，defer 必须写入 `NOT in scope` 和原因。
 13. 如果推荐方案挑战用户原始方向，必须标成 `user challenge`，不能自动改写用户意图。
-14. 行为变更的具体任务默认采用测试先行；没有 Red/Green/Refactor 链或 TDD exception，不允许交给 `cc-do`。
+14. 行为变更的具体任务默认采用测试先行；没有 Red/Green/Refactor 链、公共测试 seam、行为断言、mock 边界或 TDD exception，不允许交给 `cc-do`。
 15. 新 change 目录必须是 `REQ-<number>-<description>` 或 `FIX-<number>-<description>`，不能用小写 `req-*` / `bug-*` 或纯描述目录。
+16. 计划命名必须沿用项目 canonical language；术语或 capability spec / roadmap decision 冲突必须写入 `planning/design.md`，不能在任务里发明第二套语言。
+17. 行为变更任务必须按 tracer bullet 垂直切片组织：一个可观察行为对应一组 Red/Green/Refactor 任务。
+18. Red 任务必须通过公共接口、调用方流程、CLI/API/UI 路径或其它真实 seam 证明行为缺失。
+19. Mock 只能发生在系统边界；mock 内部协作者、私有方法或调用次数属于测试设计失败。
 
 ## Design Modes
 
@@ -43,11 +47,17 @@
 
 - 目标
 - TDD phase：`red` / `green` / `refactor` / `exception`
+- Vertical slice / tracer bullet
+- Test seam / public interface
+- Behavior asserted
+- Mock boundary
+- Feedback loop type
 - 涉及文件
 - 验证方式
 - 完成证据
 
 行为变更任务必须先有 `[TEST]` 红灯任务，再有 `[IMPL]` 绿灯任务，最后有 `[REFACTOR]` 或明确 refactor checkpoint。纯文档、纯配置、纯生成文件、throwaway prototype 可以例外，但必须写明原因、风险和替代验证。
+不要把计划拆成水平层：一批测试、一批服务、一批 UI。每个切片完成后都应该能证明一个真实行为。
 
 ## Review Gate
 
@@ -62,9 +72,13 @@
 7. Existing leverage map
 8. Scope / complexity challenge
 9. Test diagram and failure modes
-10. NOT in scope
-11. Test-first readiness
-12. Final recommendation
+10. Domain language / spec decision conflict scan
+11. Interface depth scan
+12. Test seam / mock boundary scan
+13. Tracer bullet scan
+14. NOT in scope
+15. Test-first readiness
+16. Final recommendation
 
 如有 UI scope，再补 design review 结论。
 如有 developer-facing scope，再补 DX review 结论。

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

@@ -1,5 +1,19 @@
 # Roadmap Skill Changelog
 
+## v4.4.1 - 2026-04-28
+
+- clarify that roadmap language and durable decisions come from cc-devflow native sources: `devflow/specs/`, roadmap/backlog, historical design/analysis, and change metadata
+- remove external context/architecture-decision files from the standard roadmap contract so non-native documentation ecosystems stay optional rather than canonical
+- update roadmap/backlog templates and dialogue prompts to route durable decisions into capability spec deltas, roadmap decision notes, and downstream design handoff
+
+## v4.4.0 - 2026-04-28
+
+- absorb strategic grilling discipline into roadmap work: one route-changing question at a time, recommended answer with evidence, and no user question when repo evidence can answer
+- require domain language and durable decision scans before naming stages, capabilities, roadmap items, or backlog handoffs
+- add language / spec decision conflict gates so route recommendations expose terminology and decision drift instead of creating a second conceptual system
+- update roadmap and backlog templates with domain-language and durable-decision handoff sections for downstream `cc-plan`
+- update tracking template skill version to match the enhanced roadmap contract
+
 ## v4.3.4 - 2026-04-28
 
 - add planning posture and evidence maturity routing so roadmap questions match idea, user, paying, infra, or recovery contexts

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

@@ -19,6 +19,7 @@
 7. 多个独立子系统混在一个目标里时，先拆阶段和 `RM` 候选，不要继续追问实现细节。
 8. 先判断 planning posture 和 evidence maturity，再决定追问哪些问题；不要用同一套问题硬套 idea、已有用户、付费客户、infra 和 recovery 场景。
 9. developer-facing / operator-facing 路线必须写清 target user、time to first value、magic moment 和 adoption bottleneck。
+10. 先对齐 `devflow/specs/`、roadmap/backlog 和历史 design decision，再命名 stage、capability、RM 和 backlog；术语或决策冲突必须成为显式路线风险。
 
 ## Local Kit
 
@@ -37,12 +38,13 @@
 
 1. 现有 `devflow/ROADMAP.md` / `devflow/BACKLOG.md`
 2. `CLAUDE.md`、`README*`、`TODOS.md`
-3. 最近相关 docs / specs / plans
-4. 最近相关提交、当前工作树状态、正在推进的 requirement
-5. 现实 forcing functions：deadline、distribution、资源、依赖、当前卡点
-6. planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure
-7. evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery
-8. developer / operator adoption 线索：目标人、first success path、TTHW / time to first value、debug / upgrade 卡点
+3. 项目语言和持久决策：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog、历史 `planning/design.md` / `planning/analysis.md`、`change-meta.json`、长期 design decision
+4. 最近相关 docs / specs / plans
+5. 最近相关提交、当前工作树状态、正在推进的 requirement
+6. 现实 forcing functions：deadline、distribution、资源、依赖、当前卡点
+7. planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure
+8. evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery
+9. developer / operator adoption 线索：目标人、first success path、TTHW / time to first value、debug / upgrade 卡点
 
 先把这些材料压成 `Context Snapshot`，再追问用户。
 
@@ -63,7 +65,7 @@
 8. 当前最大的 adoption / trust / delivery 卡点是什么
 9. 成功与失败的判断信号是什么
 
-第一轮答案之后做 framing check：术语是否具体、用户是否可命名、pain 是否来自真实行为、status quo 是否明确、需求证据是否强过“感兴趣”。如果答案虚，先收紧问题，不要急着定路线。
+第一轮答案之后做 framing check：术语是否具体、是否沿用项目 canonical language、用户是否可命名、pain 是否来自真实行为、status quo 是否明确、需求证据是否强过“感兴趣”。如果答案虚，先收紧问题，不要急着定路线。
 
 ## Evidence-Maturity Routing
 
@@ -146,6 +148,7 @@
 6. 本次版本相比上一版到底改了什么
 7. 问题路由是否匹配 planning posture / evidence maturity
 8. developer-facing / operator-facing item 是否能说明 first value 为什么会发生
+9. stage / RM / capability 命名是否沿用项目语言，或明确记录了需要重开的 language / spec / roadmap decision 冲突
 
 ## Versioning
 

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

@@ -1,6 +1,6 @@
 ---
 name: cc-roadmap
-version: 4.3.4
+version: 4.4.1
 description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
 triggers:
   - "帮我定路线图"
@@ -31,6 +31,7 @@ writes:
     when: "roadmap/backlog tracking is maintained through bundled helper scripts"
 entry_gate:
   - "Read current roadmap, backlog, related capability specs, and surrounding repo context before proposing direction."
+  - "Load cc-devflow native language and durable-decision sources (`devflow/specs/`, current roadmap/backlog, prior `planning/design.md` or `planning/analysis.md`, and `change-meta.json`) before naming stages, capabilities, users, or backlog items."
   - "Confirm this is a project-direction problem, not a single requirement execution problem."
   - "Classify planning posture and evidence maturity before selecting the route or forcing questions."
   - "If the ask contains multiple independent subsystems, decompose them into stages and RM candidates before refining any implementation detail."
@@ -114,7 +115,8 @@ tool_budget:
 2. 先判断这是“项目方向问题”还是“单 requirement 执行问题”。
 3. 如果输入是多个独立子系统的混合目标，先拆成阶段和 `RM` 候选；不要继续追问某个子系统的实现细节。
 4. 先做一次上下文扫描，不能跳过现有事实直接写愿景。
-5. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
+5. 先读取 cc-devflow 原生项目语言与持久决策：`devflow/specs/INDEX.md`、相关 capability specs、`devflow/ROADMAP.md`、`devflow/BACKLOG.md`、历史 `planning/design.md` / `planning/analysis.md` 和 `change-meta.json`；不存在时静默跳过，但术语或决策冲突必须写进 roadmap。
+6. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
 
 ## Context Sweep
 
@@ -122,13 +124,14 @@ tool_budget:
 
 1. 当前 `devflow/ROADMAP.md` / `devflow/BACKLOG.md` 的主线、版本、已停放事项。
 2. `devflow/specs/INDEX.md` 与相关 capability specs 的边界、状态、open gaps。
-3. `CLAUDE.md`、`README*`、`TODOS.md`、最近相关 docs / specs / plans。
-4. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
-5. 真实 forcing functions：deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。
-6. 当前项目最强的现实证据，以及仍然只能靠假设的空白。
-7. Planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure。
-8. Evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery。
-9. 如果是 developer-facing 或 operator-facing 能力，补齐 target developer/operator、time to first value、magic moment、install / run / debug / upgrade 卡点。
+3. 项目语言 / 决策上下文：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog、历史 `planning/design.md` / `planning/analysis.md`、`change-meta.json` 和长期 design decision。
+4. `CLAUDE.md`、`README*`、`TODOS.md`、最近相关 docs / specs / plans。
+5. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
+6. 真实 forcing functions：deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。
+7. 当前项目最强的现实证据，以及仍然只能靠假设的空白。
+8. Planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure。
+9. Evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery。
+10. 如果是 developer-facing 或 operator-facing 能力，补齐 target developer/operator、time to first value、magic moment、install / run / debug / upgrade 卡点。
 
 先把这些材料压成一个 `Context Snapshot`，再开始追问用户。
 
@@ -144,7 +147,18 @@ tool_budget:
 | infra-only | 当前瓶颈、调用方、现有 workaround、复用边界、迁移/回滚约束 | 伪装成用户访谈的问题 |
 | recovery / trust gap | 事故证据、恢复路径、最小可信修复、停止继续扩张的 kill signal | 新功能愿景 |
 
-第一轮回答后必须做 framing check：术语是否具体、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
+第一轮回答后必须做 framing check：术语是否具体、是否沿用项目 canonical language、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
+
+## Strategic Grilling Protocol
+
+`cc-roadmap` 的 brainstorm 不是开放式聊天，而是路线决策树压缩：
+
+1. 一次只推进一个会改变阶段顺序或 backlog 优先级的关键未知点。
+2. 每个问题必须附带推荐答案、证据来源、以及如果用户反对会改变哪条路线。
+3. 能从 repo、roadmap/backlog、capability spec、历史 design/analysis、最近提交、真实运行证据里得到答案时，先查证，不问用户。
+4. 模糊或冲突的术语要压成 canonical term；如果 `devflow/specs/`、roadmap/backlog 或历史 design/analysis 已有定义，路线图必须沿用。
+5. 每条路线都要用一个具体 scenario 压测：谁在什么约束下，今天如何绕路，Stage 1 完成后哪一步不再发生。
+6. 硬决策才沉淀：只有 hard to reverse、surprising without context、real trade-off 三者同时成立，才进入 capability spec delta、roadmap decision note 或本次 design decision log。
 
 ## Session Protocol
 
@@ -156,7 +170,7 @@ tool_budget:
 6. 如果一个方向里有多个可独立交付的子系统，先写清 decomposition：哪些合并为同一阶段，哪些拆成独立 `RM`，为什么。
 7. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals。
 8. 把 `RM` 之间的硬依赖压成显式 dependency graph，并标出 parallel-ready wave；不要把“最好按这个顺序做”伪装成 blocker。
-9. backlog 只保留会真的进入下一轮 `cc-plan` 的事项，每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、`Depends On` 与 `Parallel With`。
+9. backlog 只保留会真的进入下一轮 `cc-plan` 的事项，每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、canonical language handoff、`Depends On` 与 `Parallel With`。
 10. 用户没批准，不进入 `cc-plan`。
 
 ## Route Selection Rule
@@ -194,25 +208,27 @@ tool_budget:
 7. deadline / team / budget / dependency / distribution 的硬约束是什么
 8. 当前最大的 adoption、trust、delivery 卡点是什么
 9. 这个 roadmap 成功与失败各自用什么信号判断
+10. 当前路线里哪些核心名词已经有 canonical definition，哪些术语仍然冲突或含糊
 
 如果这是 developer-facing / operator-facing roadmap，再补 4 件事：
 
-10. 目标开发者 / 操作者是谁
-11. 从第一次接触到第一次成功输出需要多久
-12. 让他们觉得“这东西真的有用”的 magic moment 是什么
-13. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
+11. 目标开发者 / 操作者是谁
+12. 从第一次接触到第一次成功输出需要多久
+13. 让他们觉得“这东西真的有用”的 magic moment 是什么
+14. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
 
 ## Approval Gates
 
 1. 没有 `Context Snapshot`，不准给路线推荐。
 2. 没有 planning posture、evidence maturity 和 framing check，不准给路线推荐。
-3. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
-4. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
-5. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
-6. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
-7. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
-8. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
-9. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
+3. 没有 native language / durable decision scan，不准给路线推荐；如果缺少 `devflow/specs/` 或历史决策材料，写成 `not present`，不要假装已对齐。
+4. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
+5. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
+6. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
+7. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
+8. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
+9. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
+10. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
 
 ## Review Loop
 
@@ -228,6 +244,8 @@ tool_budget:
 8. Handoff scan：第一批 roadmap item 是否已经自然长成可进入 `cc-plan` 的对象。
 9. Evidence maturity scan：问题路由是否匹配 idea / user / paying / infra / recovery 状态，还是拿同一套问题硬套所有项目。
 10. Adoption scan：developer-facing / operator-facing item 是否写清目标人、time to first value、magic moment 和 adoption bottleneck。
+11. Domain language scan：stage、capability、RM title、backlog handoff 是否沿用项目语言；冲突是否显式交给下一轮决策。
+12. Durable decision scan：路线是否违背既有 capability spec、roadmap decision 或历史 design decision；如需重开，是否说明为什么值得重开。
 
 ## Output
 
@@ -244,6 +262,7 @@ tool_budget:
 3. 哪个 signal 说明这一仗赢了
 4. 哪些 backlog 项已经真的 ready for `cc-plan`
 5. 哪些 `RM` 必须串行，哪些已经可以并行开会话
+6. 哪些项目术语 / capability spec / roadmap decision 会随第一批 backlog 传给 `cc-plan`
 
 ## Versioning
 
@@ -285,7 +304,8 @@ tool_budget:
 2. 没有现实证据时必须明确写成 assumption，而不是偷偷当事实。
 3. `devflow/ROADMAP.md` 是方向真相源，`devflow/BACKLOG.md` 是进入下一轮规划的缓冲区。
 4. 决策理由必须保留下来，方便以后重跑时比较版本差异。
-5. 不要为了显得完整而写 6 个阶段，能打赢下一仗比画完整战争图更重要。
+5. 路线图里的术语必须沿用项目语言；没有 canonical term 时写 assumption，不要创造第二套概念系统。
+6. 不要为了显得完整而写 6 个阶段，能打赢下一仗比画完整战争图更重要。
 
 ## Do Not
 

package/.claude/skills/cc-roadmap/assets/BACKLOG_TEMPLATE.md

@@ -31,6 +31,14 @@
 - Magic moment:
 - Adoption bottleneck:
 
+## Domain Handoff
+
+- Language sources loaded:
+- Canonical terms for next `cc-plan`:
+- Terms to avoid:
+- Capability spec / roadmap decisions to preserve:
+- Language / decision conflicts to resolve:
+
 ## Ready For Req-Plan
 
 - RM-001:
@@ -48,6 +56,8 @@
   - Time to first value:
   - Magic moment:
   - Adoption bottleneck:
+  - Canonical terms:
+  - Capability spec / roadmap context:
   - Required context to load:
   - Depends On:
   - Parallel With:

package/.claude/skills/cc-roadmap/assets/ROADMAP_TEMPLATE.md

@@ -33,6 +33,11 @@
 - Time to first value:
 - Magic moment:
 - Install / run / debug / upgrade bottleneck:
+- Language sources loaded:
+- Canonical terms:
+- Language conflicts:
+- Durable decision sources loaded:
+- Spec / roadmap decision conflicts:
 - Known unknowns:
 - Relevant capabilities:
 
@@ -72,6 +77,15 @@
 - What we refuse to build yet:
 - 6-12 month pull:
 
+## Native Language & Durable Decisions
+
+- Canonical terms this roadmap uses:
+- Terms avoided / aliases:
+- Existing capability spec / roadmap decisions preserved:
+- Capability spec / roadmap decisions reopened:
+- Decisions worth capability spec sync:
+- Handoff notes for `cc-plan`:
+
 ## Evidence-Maturity Routing
 
 - Planning posture:
@@ -176,6 +190,7 @@ flowchart LR
 - Rejected path A:
 - Rejected path B:
 - Rejected maturity route:
+- Language / spec decision conflicts:
 - Developer / operator adoption assumptions:
 - Open assumptions to verify next:
 - What changed in this version:

package/.claude/skills/cc-roadmap/assets/TRACKING_TEMPLATE.json

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

package/.claude/skills/cc-roadmap/references/roadmap-dialogue.md

@@ -2,23 +2,26 @@
 
 ## Order
 
-0. 先做 `Context Snapshot`：现有 roadmap / backlog、文档、最近提交、forcing functions
+0. 先做 `Context Snapshot`：现有 roadmap / backlog、capability specs、历史 design/analysis、最近提交、forcing functions、项目语言 / durable decisions
 1. 用户是谁
 2. 今天靠什么笨办法活着
 3. 最强需求证据是什么
 4. 为什么现在必须解决
 5. deadline / capacity / dependency / distribution 约束是什么
 6. 当前最大的 adoption / trust / delivery 卡点是什么
-7. 最窄突破口是什么
-8. 6-12 个月后会长成什么
-9. 给出 2-3 条路线图形状并明确推荐
-10. 冻结 1-3 个阶段，写 exit signal / kill signal / non-goals
-11. 画出 `RM dependency graph`，标出串行主链和 parallel-ready wave
-12. 标出哪些事项真的 ready for `cc-plan`
+7. 核心术语是否已有 canonical definition，是否和现有 capability spec / roadmap decision 冲突
+8. 最窄突破口是什么
+9. 6-12 个月后会长成什么
+10. 给出 2-3 条路线图形状并明确推荐
+11. 冻结 1-3 个阶段，写 exit signal / kill signal / non-goals
+12. 画出 `RM dependency graph`，标出串行主链和 parallel-ready wave
+13. 标出哪些事项真的 ready for `cc-plan`
 
 ## Question Rules
 
 - 一次只推进一个关键未知点
+- 每个问题附带推荐答案、证据来源，以及用户反对时会改变哪条路线
+- 能从 repo / capability spec / roadmap / design / git history 得到答案时先查证，不问用户
 - 没证据时明确写 assumption
 - 用户没批准前，不把事项偷下放成 requirement
 
@@ -35,3 +38,4 @@
 - `RM` 必须带 `Depends On`，并在 roadmap 里显式画出 dependency graph
 - backlog 只收下一轮真会进入 `cc-plan` 的事项
 - ready 项必须带成功信号、下一决策、`Depends On`、`Parallel With`
+- ready 项必须带 canonical terms、capability spec context 或明确的 language / decision conflict

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

@@ -1,5 +1,11 @@
 # CC-Simplify Skill Changelog
 
+## v1.4.0 - 2026-04-28
+
+- add deep-module architecture review checks for shallow wrappers, hypothetical seams, and complexity that should move behind a smaller interface
+- require architecture findings to pass a deletion test before cleanup deletes, keeps, or reshapes a module or helper
+- preserve capability invariants and public contracts when evaluating pass-through abstractions
+
 ## v1.3.0 - 2026-04-28
 
 - add scope-aware Codex reviewer dispatch with small-diff skip rules and conditional security, API contract, release, frontend performance, and red-team facets