cc-devflow 4.5.0 → 4.5.2

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

@@ -61,20 +61,29 @@
 
 ### Option A
 
+- Role: `minimal viable` | `ideal architecture` | `hybrid`
 - Shape:
 - Reuses:
+- Completeness:
 - Pros:
 - Cons:
 - Risks:
 
 ### Option B
 
+- Role: `minimal viable` | `ideal architecture` | `hybrid`
 - Shape:
 - Reuses:
+- Completeness:
 - Pros:
 - Cons:
 - Risks:
 
+### Eliminated Options
+
+- Option:
+- Why eliminated:
+
 ## Approved Direction
 
 - Approved option:
@@ -92,6 +101,15 @@
 - Error handling:
 - Rollout / migration:
 
+## Implementation Decision Horizon
+
+| Phase | Decision `cc-do` would otherwise hit | Frozen answer | Evidence / owner |
+|-------|--------------------------------------|---------------|------------------|
+| Foundation |  |  |  |
+| Core logic |  |  |  |
+| Integration |  |  |  |
+| Polish / tests |  |  |  |
+
 ## Invariant Impact
 
 - Affected invariants:
@@ -112,16 +130,62 @@
 
 > 如果文件计划超过 5-8 个文件，先问自己：这是不是已经逼近 `full-design` 之外的需求膨胀。
 
+## Implementation Surface Map
+
+| Surface | Responsibility | Why here | Coupling risk | Split / merge decision |
+|---------|----------------|----------|---------------|------------------------|
+|  |  |  |  |  |
+
+> 先锁定文件职责，再拆任务。执行者不应该在 `cc-do` 阶段重新决定代码该放哪里。
+
 ## Validation Strategy
 
+- Test framework source:
 - First failing tests:
 - Red/Green/Refactor task chain:
 - TDD exceptions:
+- Regression tests required:
 - Unit:
 - Integration:
+- E2E:
+- Eval:
 - Manual:
 - Observability / evidence:
 
+## 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 |
+
+## Error & Rescue Map
+
+| Codepath | What can fail | Rescue action | User sees | Test evidence |
+|----------|---------------|---------------|-----------|---------------|
+|  |  |  |  |  |
+
+## UI Design Gate
+
+- Applies: Yes / No
+- Design completeness score:
+- What 10/10 means here:
+- Existing design patterns to reuse:
+- State coverage:
+
+| Feature | Loading | Empty | Error | Success | Partial |
+|---------|---------|-------|-------|---------|---------|
+|  |  |  |  |  |  |
+
+## DX / Operator Gate
+
+- Applies: Yes / No
+- Target developer / operator:
+- Current first-success path:
+- Target time to first value:
+- Magic moment:
+- Install / run / debug / upgrade risks:
+- Required docs / examples / entrypoints:
+
 ## Risks
 
 | Risk | Impact | Mitigation |
@@ -136,9 +200,14 @@
 - Ambiguity scan:
 - Feasibility scan:
 - Source alignment:
+- Implementation surface scan:
+- Decision horizon scan:
+- Error & rescue scan:
+- Test framework / regression scan:
 - UI / interaction review summary:
-- DX review summary:
+- DX / operator review summary:
 - Test-first readiness:
+- Review calibration:
 - Auto-decided items:
 - Taste decisions:
 - User challenges:

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

@@ -19,13 +19,23 @@
 - Capability specs:
 - Read first:
 - Commands to trust:
+- Test framework source:
 - TDD plan: `Red -> Green -> Refactor`
 - TDD exceptions: none | list exception reason, risk, replacement evidence, follow-up
+- Regression tests: required | not applicable, with reason
 - Do not re-decide:
 - Parallel boundaries:
 
 > 顶部 handoff 只保留执行者必须知道的现实，不重复讲背景故事。
 
+## Implementation Surface Map
+
+| Surface | Responsibility | Tasks | Coupling risk |
+|---------|----------------|-------|---------------|
+|  |  |  |  |
+
+> 这张表是执行边界，不是装饰。任务拆分必须沿着这些职责走，不能让 `cc-do` 临场重切文件归属。
+
 ## Phase 1: Foundation
 
 - [ ] T001 [TEST] Write the first failing test (dependsOn:none) `path/to/test`
@@ -35,6 +45,7 @@
   Read first: `design.md`, `tasks.md`
   Verification: `npm test -- path/to/test`
   Evidence: failing output
+  Coverage: unit / integration / e2e / eval; regression: yes / no
   Ready when: 没有上游依赖，且测试路径已经确定
 
 - [ ] T002 [IMPL] Make the first test pass (dependsOn:T001) `path/to/file`
@@ -55,6 +66,7 @@
   Read first: `design.md`, `tasks.md`
   Verification: `npm test -- path/to/other.test`
   Evidence: failing output
+  Coverage: unit / integration / e2e / eval; regression: yes / no
   Ready when: T002 完成，且该测试覆盖的是独立行为
 
 - [ ] T004 [P] [IMPL] Make the independent test pass (dependsOn:T003) `path/to/other-file`
@@ -97,3 +109,4 @@
 - 用哪条命令证明它完成
 - 要留下什么证据给 `cc-check`
 - 它处于 Red、Green、Refactor，还是明确的 TDD exception
+- 测试框架依据来自哪里，回归测试是否被明确处理

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

@@ -20,7 +20,7 @@
     ]
   },
   "planningMeta": {
-    "reqPlanSkillVersion": "3.5.2",
+    "reqPlanSkillVersion": "3.5.6",
     "designVersion": "design.v1",
     "approvedAt": "2026-04-15T12:00:00.000Z",
     "approvedBy": "user",
@@ -29,6 +29,8 @@
   "executionDiscipline": {
     "default": "red-green-refactor",
     "testFirstRequired": true,
+    "testFrameworkSource": "",
+    "regressionTestsRequired": [],
     "tddExceptions": []
   },
   "status": "planned",

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

@@ -43,16 +43,35 @@
 - Key decisions that `cc-do` must not re-decide:
 - Upgrade trigger to `full-design`:
 
+> `tiny-design` 是短设计，不是免设计。没有明确批准状态、验证证据和升级触发条件，就不能继续拆任务。
+
+## Implementation Surface Map
+
+| Surface | Responsibility | Why here | Coupling risk |
+|---------|----------------|----------|---------------|
+|  |  |  |  |
+
 ## Validation
 
+- Test framework source:
 - First failing test:
 - Green implementation check:
 - Refactor checkpoint:
 - TDD exceptions:
+- Regression test required:
 - Primary check:
 - Secondary checks:
 - Evidence to collect:
 
+## Conditional Design Checks
+
+- UI / interaction scope: Yes / No
+- UI state coverage if applicable:
+- Developer / operator-facing scope: Yes / No
+- Target developer / operator if applicable:
+- Time to first value if applicable:
+- Magic moment if applicable:
+
 ## Main Risk
 
 - Risk:
@@ -65,7 +84,10 @@
 - Scope scan:
 - Ambiguity scan:
 - Feasibility scan:
+- Implementation surface scan:
+- Test framework / regression scan:
 - Test-first readiness:
+- Review calibration:
 - Final recommendation:
 
 ## Approval

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

@@ -1,5 +1,17 @@
 # Roadmap Skill Changelog
 
+## v4.3.4 - 2026-04-28
+
+- add planning posture and evidence maturity routing so roadmap questions match idea, user, paying, infra, or recovery contexts
+- require a framing check before route recommendation so vague users, hypothetical demand, and undefined status quo do not pass as evidence
+- add developer/operator adoption handoff fields for target user, time to first value, magic moment, and install/run/debug/upgrade bottlenecks
+
+## v4.3.3 - 2026-04-28
+
+- add a decomposition-first route for asks that bundle multiple independently shippable subsystems
+- require roadmap entry and approval gates to split over-broad goals into stages and RM candidates before implementation detail discovery
+- add subsystem decomposition and handoff notes to roadmap/backlog templates
+
 ## v4.3.2 - 2026-04-27
 
 - require roadmap outputs to resolve the runtime output policy before writing durable roadmap/backlog documents

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

@@ -16,6 +16,9 @@
 4. 通过 `roadmap` 只能产出方向，不能偷拆实现任务。
 5. 没有证据时写 assumption，不准冒充事实。
 6. 每次都必须明确推荐一条路线，不准只列选项不下判断。
+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。
 
 ## Local Kit
 
@@ -37,6 +40,9 @@
 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 卡点
 
 先把这些材料压成 `Context Snapshot`，再追问用户。
 
@@ -57,11 +63,22 @@
 8. 当前最大的 adoption / trust / delivery 卡点是什么
 9. 成功与失败的判断信号是什么
 
+第一轮答案之后做 framing check：术语是否具体、用户是否可命名、pain 是否来自真实行为、status quo 是否明确、需求证据是否强过“感兴趣”。如果答案虚，先收紧问题，不要急着定路线。
+
+## Evidence-Maturity Routing
+
+- `idea / pre-product`: 先追真实用户、现状替代方案、最窄 wedge、需求证据。
+- `has users`: 先追现有路径、失败/绕路场景、使用保留信号、下一阶段 wedge。
+- `paying users / internal sponsor`: 先追付费/赞助动机、扩张边界、信任信号、组织风险。
+- `infra-only`: 先追调用方、瓶颈、复用边界、迁移/回滚约束。
+- `recovery / trust gap`: 先追事故证据、恢复路径、最小可信修复、停止扩张的 kill signal。
+
 ## Route Shapes
 
 - `wedge-first`: 用一个极窄切口先打穿真实需求
 - `platform-first`: 先搭通后续阶段复用的关键底座
 - `rescue-first`: 先解决当前最大的 adoption / trust / delivery 卡点
+- `decompose-first`: 先把多个可独立交付的子系统拆成阶段和 `RM`，再选择主线
 
 推荐时必须回答：为什么这条主线比其他两条更值得先打。
 
@@ -73,6 +90,7 @@
 2. 有没有明确说“不先做另外两条”的原因？
 3. Stage 1 的 win signal 能不能在 1-2 个周期内看到？
 4. 如果 Stage 1 输了，kill signal 是不是具体到可以止损？
+5. 当前问题路由是否匹配 evidence maturity，而不是为了完整感把所有问题都问一遍？
 
 ## Stage Contract
 
@@ -84,7 +102,8 @@
 4. `Exit signal`
 5. `Kill signal`
 6. `Non-goals`
-7. 可以自然长成下一轮 `cc-plan` 的候选事项
+7. 子系统 / `RM` 边界，说明哪些合并、哪些拆开
+8. 可以自然长成下一轮 `cc-plan` 的候选事项
 
 ## Dependency Contract
 
@@ -98,6 +117,7 @@
 `devflow/ROADMAP.md`
 - version / skill version / context snapshot / evidence ledger
 - 1-3 个阶段
+- 独立子系统拆分判断
 - 每阶段目标
 - 每阶段存在原因
 - 每阶段 dependencies
@@ -111,6 +131,7 @@
 `devflow/BACKLOG.md`
 - 只保留会真的进入下一轮 `cc-plan` 的事项
 - 每项注明来源阶段、优先级、证据、`Depends On`、`Parallel With`、当前未知点、下一决策、是否 ready
+- developer-facing / operator-facing 条目要带 target user、time to first value、magic moment 和 adoption bottleneck，方便 `cc-plan` 继续做 DX 设计
 - `Backlog Meta`、`Queue`、`Dependency Handoff`、`Ready For Req-Plan`、`Parked` 可由 `devflow/roadmap-tracking.json` 回渲染，避免 roadmap truth 和 backlog handoff 分叉
 
 ## Review Loop
@@ -123,6 +144,8 @@
 4. `RM Dependency Graph` 是否只有硬依赖、没有环
 5. ready 项是否真能进入 `cc-plan`
 6. 本次版本相比上一版到底改了什么
+7. 问题路由是否匹配 planning posture / evidence maturity
+8. developer-facing / operator-facing item 是否能说明 first value 为什么会发生
 
 ## Versioning
 

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

@@ -1,6 +1,6 @@
 ---
 name: cc-roadmap
-version: 4.3.2
+version: 4.3.4
 description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
 triggers:
   - "帮我定路线图"
@@ -32,6 +32,8 @@ writes:
 entry_gate:
   - "Read current roadmap, backlog, related capability specs, and surrounding repo context before proposing direction."
   - "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."
   - "Do not decompose implementation tasks while the roadmap is still being decided."
 exit_criteria:
   - "The next 1-3 stages are frozen with goal, why now, dependencies, exit signal, kill signal, and non-goals."
@@ -95,12 +97,13 @@ tool_budget:
 | “不知道下一步做什么” | 主线不清 | `wedge-first` |
 | “后面几阶段都会重复碰同一底座” | 底座风险 | `platform-first` |
 | “增长/交付/信任卡住了” | 当前最大瓶颈 | `rescue-first` |
+| “一个目标里塞了多个可独立交付系统” | 边界过宽 | `decompose-first` |
 
 先给一个**默认推荐**，再解释为什么，不要把用户扔进开放式战略讨论。
 
 ## Harness Contract
 
-- Allowed actions: read current strategy files, repo context, and recent reality; compare route shapes; write `devflow/ROADMAP.md`, `devflow/BACKLOG.md`, and the optional `devflow/roadmap-tracking.json` sidecar used by bundled helpers as the shared roadmap/backlog truth source.
+- Allowed actions: read current strategy files, repo context, and recent reality; compare route shapes; decompose independent subsystems into stages and RM candidates; write `devflow/ROADMAP.md`, `devflow/BACKLOG.md`, and the optional `devflow/roadmap-tracking.json` sidecar used by bundled helpers as the shared roadmap/backlog truth source.
 - Forbidden actions: decompose implementation tasks, invent hidden context, or jump into `cc-plan` before the roadmap is approved.
 - Required evidence: every stage and backlog item must point back to explicit repo facts, user constraints, or observed market signals.
 - Reroute rule: once the conversation collapses to one concrete requirement, stop strategic expansion and hand off to `cc-plan`.
@@ -109,8 +112,9 @@ tool_budget:
 
 1. 如果 `devflow/ROADMAP.md` / `devflow/BACKLOG.md` 已存在，先读现状再重写。
 2. 先判断这是“项目方向问题”还是“单 requirement 执行问题”。
-3. 先做一次上下文扫描，不能跳过现有事实直接写愿景。
-4. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
+3. 如果输入是多个独立子系统的混合目标，先拆成阶段和 `RM` 候选；不要继续追问某个子系统的实现细节。
+4. 先做一次上下文扫描，不能跳过现有事实直接写愿景。
+5. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
 
 ## Context Sweep
 
@@ -122,20 +126,38 @@ tool_budget:
 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 卡点。
 
 先把这些材料压成一个 `Context Snapshot`，再开始追问用户。
 
+## Evidence-Maturity Routing
+
+不要对所有项目套同一组问题。先用 `planning posture` 和 `evidence maturity` 决定追问深度：
+
+| Evidence maturity | 优先追问 | 不要浪费时间在 |
+| --- | --- | --- |
+| idea / pre-product | 真实用户、status quo、最窄 wedge、需求证据 | 远期平台架构细节 |
+| has users | 现有使用路径、失败/绕路场景、保留率或复用信号、下一阶段 wedge | 假想 persona |
+| paying users / internal sponsor | 付费/赞助动机、扩张边界、不可丢的信任信号、组织风险 | 泛泛市场教育 |
+| infra-only | 当前瓶颈、调用方、现有 workaround、复用边界、迁移/回滚约束 | 伪装成用户访谈的问题 |
+| recovery / trust gap | 事故证据、恢复路径、最小可信修复、停止继续扩张的 kill signal | 新功能愿景 |
+
+第一轮回答后必须做 framing check：术语是否具体、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
+
 ## Session Protocol
 
 1. 先探索上下文，不靠默认上下文注入替代阅读。
 2. 先问现实，不先写愿景。
 3. 一次只推进一个关键未知点，不要一口气抛一串问题。
-4. 先写 `Context Snapshot`、证据、约束、非目标，再讨论阶段。
+4. 先写 `Context Snapshot`、planning posture、evidence maturity、证据、约束、非目标，再讨论阶段。
 5. 给出 2-3 种路线图形状，再明确推荐一种，并说明为什么其他路线现在不值得打。
-6. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals。
-7. 把 `RM` 之间的硬依赖压成显式 dependency graph，并标出 parallel-ready wave；不要把“最好按这个顺序做”伪装成 blocker。
-8. backlog 只保留会真的进入下一轮 `cc-plan` 的事项，每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、`Depends On` 与 `Parallel With`。
-9. 用户没批准，不进入 `cc-plan`。
+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`。
+10. 用户没批准，不进入 `cc-plan`。
 
 ## Route Selection Rule
 
@@ -173,14 +195,24 @@ tool_budget:
 8. 当前最大的 adoption、trust、delivery 卡点是什么
 9. 这个 roadmap 成功与失败各自用什么信号判断
 
+如果这是 developer-facing / operator-facing roadmap，再补 4 件事：
+
+10. 目标开发者 / 操作者是谁
+11. 从第一次接触到第一次成功输出需要多久
+12. 让他们觉得“这东西真的有用”的 magic moment 是什么
+13. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
+
 ## Approval Gates
 
 1. 没有 `Context Snapshot`，不准给路线推荐。
-2. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
-3. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
-4. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
-5. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
-6. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
+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`。
 
 ## Review Loop
 
@@ -192,7 +224,10 @@ tool_budget:
 4. Feasibility scan：阶段目标与团队容量、依赖、distribution 约束是否接得上。
 5. Graph scan：`Depends On` 是否只包含硬阻塞，图里有没有环，parallel-ready wave 是否真的共享同一前置。
 6. Spec scan：每个 roadmap item 是否都落到某个 capability，而不是悬空需求。
-7. Handoff scan：第一批 roadmap item 是否已经自然长成可进入 `cc-plan` 的对象。
+7. Decomposition scan：多个独立子系统是否已拆成阶段 / `RM` 候选，而不是塞进一个含糊阶段。
+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。
 
 ## Output
 

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

@@ -19,8 +19,18 @@
 
 - Serial spine:
 - Parallel-ready next wave:
+- Decomposition notes:
 - Notes on blockers:
 
+## Adoption Handoff
+
+- Planning posture:
+- Evidence maturity:
+- Target developer / operator:
+- Time to first value:
+- Magic moment:
+- Adoption bottleneck:
+
 ## Ready For Req-Plan
 
 - RM-001:
@@ -33,6 +43,11 @@
   - Expected spec delta:
   - Open risks:
   - First planning question:
+  - Evidence maturity:
+  - Target developer / operator:
+  - Time to first value:
+  - Magic moment:
+  - Adoption bottleneck:
   - Required context to load:
   - Depends On:
   - Parallel With:

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

@@ -15,17 +15,24 @@
 ## Context Snapshot
 
 - Product / repo:
+- Planning posture:
 - Project stage:
+- Evidence maturity:
 - Users:
 - Pain:
 - Existing workaround:
 - Strongest demand evidence:
+- Framing check:
 - Why now:
 - Distribution path:
 - Deadline / forcing function:
 - Team / capacity:
 - Hard constraints:
 - Adoption / trust bottleneck:
+- Target developer / operator:
+- Time to first value:
+- Magic moment:
+- Install / run / debug / upgrade bottleneck:
 - Known unknowns:
 - Relevant capabilities:
 
@@ -45,6 +52,7 @@
 | wedge-first |  |  | Recommended / Rejected |
 | platform-first |  |  | Rejected |
 | rescue-first |  |  | Rejected |
+| decompose-first |  |  | Recommended / Rejected |
 
 ## Recommended Route
 
@@ -64,6 +72,33 @@
 - What we refuse to build yet:
 - 6-12 month pull:
 
+## Evidence-Maturity Routing
+
+- Planning posture:
+- Evidence maturity:
+- Questions selected:
+- Questions intentionally skipped:
+- Reason this route matches maturity:
+- Evidence that would change the route:
+
+## DX / Operator Adoption Context
+
+- Applies: Yes / No
+- Target developer / operator:
+- Current first-success path:
+- Target time to first value:
+- Magic moment:
+- Install / run / debug / upgrade risks:
+- Adoption bottleneck:
+
+## Subsystem Decomposition
+
+| Subsystem / RM candidate | User value | Can ship independently? | Merge / split decision | Reason |
+|--------------------------|------------|-------------------------|------------------------|--------|
+| RM-001 |  | Yes / No | Merge / Split |  |
+
+> 如果一个目标里塞了多个独立子系统，先拆阶段和 `RM`，再谈优先级。不要把大杂烩写成一个阶段。
+
 ## Stage Overview
 
 | Stage | Goal | Why now | Primary capabilities | Dependencies | Exit signal | Kill signal | Non-goals |
@@ -140,6 +175,8 @@ flowchart LR
 
 - Rejected path A:
 - Rejected path B:
+- Rejected maturity route:
+- Developer / operator adoption assumptions:
 - Open assumptions to verify next:
 - What changed in this version:
 

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

@@ -6,12 +6,13 @@
   "lastSyncedAt": "2026-04-19",
   "backlogMeta": {
     "roadmapVersion": "roadmap.v1",
-    "skillVersion": "4.3.2",
+    "skillVersion": "4.3.4",
     "currentFocusStage": "Stage 1"
   },
   "dependencyHandoff": {
     "serialSpine": "RM-001",
     "parallelReadyNextWave": "-",
+    "decompositionNotes": "-",
     "notesOnBlockers": "-"
   },
   "items": [

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

@@ -1,5 +1,20 @@
 # CC-Simplify Skill Changelog
 
+## 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
+- require reviewer agents to emit JSONL findings with confidence, evidence, fingerprint, specialist, and optional test stubs
+- add finding deduplication, multi-specialist confidence boost, confidence gates, and a Fix-First auto-fix vs ask/reroute decision table
+- expand testing smell coverage for negative paths, edge cases, isolation, flaky tests, and security enforcement tests
+- add false-positive suppressions and a "new diff smells only" boundary so cleanup does not become historical debt sweeping
+
+## v1.2.0 - 2026-04-28
+
+- translate the skill body into Chinese and remove the non-Codex `${AGENT_TOOL_NAME}` placeholder
+- define a Codex-native simplification workflow that can use read-only reviewer agents for spec/scope, reuse/structure, and quality/efficiency/test findings
+- require findings to be verified against code, usage, requirements, and fresh validation evidence before any cleanup edit is made
+- add explicit YAGNI, test-anti-pattern, reroute, and cc-check return rules for cleanup changes
+
 ## v1.1.0 - 2026-04-19
 
 - expand `cc-simplify` review scope to catch spec drift alongside reuse, quality, and efficiency issues