cc-devflow 4.4.1 → 4.5.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (75) hide show
  1. package/.claude/skills/cc-act/CHANGELOG.md +6 -0
  2. package/.claude/skills/cc-act/SKILL.md +9 -1
  3. package/.claude/skills/cc-act/assets/PR_BRIEF_TEMPLATE.md +4 -0
  4. package/.claude/skills/cc-act/assets/RELEASE_NOTE_TEMPLATE.md +4 -0
  5. package/.claude/skills/cc-act/scripts/cc-act-common.sh +5 -0
  6. package/.claude/skills/cc-act/scripts/render-pr-brief.sh +5 -0
  7. package/.claude/skills/cc-act/scripts/sync-act-docs.sh +14 -1
  8. package/.claude/skills/cc-check/CHANGELOG.md +5 -0
  9. package/.claude/skills/cc-check/SKILL.md +9 -1
  10. package/.claude/skills/cc-check/assets/REPORT_CARD_TEMPLATE.json +3 -0
  11. package/.claude/skills/cc-do/CHANGELOG.md +5 -0
  12. package/.claude/skills/cc-do/SKILL.md +9 -1
  13. package/.claude/skills/cc-investigate/CHANGELOG.md +5 -0
  14. package/.claude/skills/cc-investigate/SKILL.md +9 -1
  15. package/.claude/skills/cc-investigate/assets/ANALYSIS_TEMPLATE.md +1 -0
  16. package/.claude/skills/cc-investigate/assets/TASKS_TEMPLATE.md +1 -0
  17. package/.claude/skills/cc-investigate/assets/TASK_MANIFEST_TEMPLATE.json +3 -0
  18. package/.claude/skills/cc-plan/CHANGELOG.md +19 -0
  19. package/.claude/skills/cc-plan/PLAYBOOK.md +19 -2
  20. package/.claude/skills/cc-plan/SKILL.md +60 -20
  21. package/.claude/skills/cc-plan/assets/DESIGN_TEMPLATE.md +71 -1
  22. package/.claude/skills/cc-plan/assets/TASKS_TEMPLATE.md +14 -0
  23. package/.claude/skills/cc-plan/assets/TASK_MANIFEST_TEMPLATE.json +6 -1
  24. package/.claude/skills/cc-plan/assets/TINY_DESIGN_TEMPLATE.md +23 -0
  25. package/.claude/skills/cc-roadmap/CHANGELOG.md +17 -0
  26. package/.claude/skills/cc-roadmap/PLAYBOOK.md +24 -1
  27. package/.claude/skills/cc-roadmap/SKILL.md +58 -15
  28. package/.claude/skills/cc-roadmap/assets/BACKLOG_TEMPLATE.md +16 -0
  29. package/.claude/skills/cc-roadmap/assets/ROADMAP_TEMPLATE.md +38 -0
  30. package/.claude/skills/cc-roadmap/assets/TRACKING_TEMPLATE.json +5 -1
  31. package/.claude/skills/cc-spec-init/CHANGELOG.md +5 -0
  32. package/.claude/skills/cc-spec-init/SKILL.md +9 -1
  33. package/.claude/skills/cc-spec-init/assets/CAPABILITY_TEMPLATE.md +1 -0
  34. package/.claude/skills/cc-spec-init/assets/CHANGE_META_TEMPLATE.json +3 -0
  35. package/.claude/skills/cc-spec-init/assets/INDEX_TEMPLATE.md +1 -0
  36. package/CHANGELOG.md +39 -0
  37. package/CODE_OF_CONDUCT.md +39 -0
  38. package/CODE_OF_CONDUCT.zh-CN.md +39 -0
  39. package/CONTRIBUTING.md +195 -0
  40. package/CONTRIBUTING.zh-CN.md +195 -0
  41. package/README.md +154 -120
  42. package/README.zh-CN.md +156 -117
  43. package/SECURITY.md +56 -0
  44. package/SECURITY.zh-CN.md +56 -0
  45. package/bin/cc-devflow-cli.js +226 -0
  46. package/config/schema/cc-devflow-config.schema.json +45 -0
  47. package/config/user-config.template.yml +16 -0
  48. package/docs/examples/example-bindings.json +8 -8
  49. package/docs/examples/full-design-blocked/BACKLOG.md +1 -1
  50. package/docs/examples/full-design-blocked/README.md +1 -1
  51. package/docs/examples/full-design-blocked/ROADMAP.md +1 -1
  52. package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/design.md +1 -1
  53. package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/tasks.md +1 -1
  54. package/docs/examples/full-design-blocked/roadmap-tracking.json +1 -1
  55. package/docs/examples/local-handoff/BACKLOG.md +1 -1
  56. package/docs/examples/local-handoff/README.md +1 -1
  57. package/docs/examples/local-handoff/ROADMAP.md +1 -1
  58. package/docs/examples/local-handoff/changes/REQ-003-audit-log-export/planning/design.md +1 -1
  59. package/docs/examples/local-handoff/changes/REQ-003-audit-log-export/planning/tasks.md +1 -1
  60. package/docs/examples/local-handoff/roadmap-tracking.json +1 -1
  61. package/docs/examples/pdca-loop/BACKLOG.md +1 -1
  62. package/docs/examples/pdca-loop/README.md +1 -1
  63. package/docs/examples/pdca-loop/ROADMAP.md +1 -1
  64. package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/design.md +1 -1
  65. package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/task-manifest.json +2 -2
  66. package/docs/examples/pdca-loop/changes/REQ-001-copy-invite-link/planning/tasks.md +1 -1
  67. package/docs/examples/pdca-loop/roadmap-tracking.json +1 -1
  68. package/docs/guides/getting-started.md +5 -0
  69. package/docs/guides/getting-started.zh-CN.md +5 -0
  70. package/lib/skill-runtime/__tests__/cli-bootstrap.integration.test.js +112 -2
  71. package/lib/skill-runtime/__tests__/config.test.js +161 -0
  72. package/lib/skill-runtime/__tests__/runtime.integration.test.js +2 -0
  73. package/lib/skill-runtime/config.js +379 -0
  74. package/lib/skill-runtime/index.js +2 -0
  75. package/package.json +7 -1
@@ -5,6 +5,7 @@
5
5
  - Requirement version:
6
6
  - Design version:
7
7
  - CC-Plan skill version:
8
+ - Output language:
8
9
  - Requirement ID:
9
10
  - Design mode: `full-design`
10
11
  - Why not `tiny-design`:
@@ -60,20 +61,29 @@
60
61
 
61
62
  ### Option A
62
63
 
64
+ - Role: `minimal viable` | `ideal architecture` | `hybrid`
63
65
  - Shape:
64
66
  - Reuses:
67
+ - Completeness:
65
68
  - Pros:
66
69
  - Cons:
67
70
  - Risks:
68
71
 
69
72
  ### Option B
70
73
 
74
+ - Role: `minimal viable` | `ideal architecture` | `hybrid`
71
75
  - Shape:
72
76
  - Reuses:
77
+ - Completeness:
73
78
  - Pros:
74
79
  - Cons:
75
80
  - Risks:
76
81
 
82
+ ### Eliminated Options
83
+
84
+ - Option:
85
+ - Why eliminated:
86
+
77
87
  ## Approved Direction
78
88
 
79
89
  - Approved option:
@@ -91,6 +101,15 @@
91
101
  - Error handling:
92
102
  - Rollout / migration:
93
103
 
104
+ ## Implementation Decision Horizon
105
+
106
+ | Phase | Decision `cc-do` would otherwise hit | Frozen answer | Evidence / owner |
107
+ |-------|--------------------------------------|---------------|------------------|
108
+ | Foundation | | | |
109
+ | Core logic | | | |
110
+ | Integration | | | |
111
+ | Polish / tests | | | |
112
+
94
113
  ## Invariant Impact
95
114
 
96
115
  - Affected invariants:
@@ -111,16 +130,62 @@
111
130
 
112
131
  > 如果文件计划超过 5-8 个文件,先问自己:这是不是已经逼近 `full-design` 之外的需求膨胀。
113
132
 
133
+ ## Implementation Surface Map
134
+
135
+ | Surface | Responsibility | Why here | Coupling risk | Split / merge decision |
136
+ |---------|----------------|----------|---------------|------------------------|
137
+ | | | | | |
138
+
139
+ > 先锁定文件职责,再拆任务。执行者不应该在 `cc-do` 阶段重新决定代码该放哪里。
140
+
114
141
  ## Validation Strategy
115
142
 
143
+ - Test framework source:
116
144
  - First failing tests:
117
145
  - Red/Green/Refactor task chain:
118
146
  - TDD exceptions:
147
+ - Regression tests required:
119
148
  - Unit:
120
149
  - Integration:
150
+ - E2E:
151
+ - Eval:
121
152
  - Manual:
122
153
  - Observability / evidence:
123
154
 
155
+ ## Test Coverage Map
156
+
157
+ | Code path / user flow | Existing coverage | Quality | Required test | Level | Regression? |
158
+ |-----------------------|-------------------|---------|---------------|-------|-------------|
159
+ | | | strong / happy-path-only / smoke-only / missing | | unit / integration / e2e / eval | Yes / No |
160
+
161
+ ## Error & Rescue Map
162
+
163
+ | Codepath | What can fail | Rescue action | User sees | Test evidence |
164
+ |----------|---------------|---------------|-----------|---------------|
165
+ | | | | | |
166
+
167
+ ## UI Design Gate
168
+
169
+ - Applies: Yes / No
170
+ - Design completeness score:
171
+ - What 10/10 means here:
172
+ - Existing design patterns to reuse:
173
+ - State coverage:
174
+
175
+ | Feature | Loading | Empty | Error | Success | Partial |
176
+ |---------|---------|-------|-------|---------|---------|
177
+ | | | | | | |
178
+
179
+ ## DX / Operator Gate
180
+
181
+ - Applies: Yes / No
182
+ - Target developer / operator:
183
+ - Current first-success path:
184
+ - Target time to first value:
185
+ - Magic moment:
186
+ - Install / run / debug / upgrade risks:
187
+ - Required docs / examples / entrypoints:
188
+
124
189
  ## Risks
125
190
 
126
191
  | Risk | Impact | Mitigation |
@@ -135,9 +200,14 @@
135
200
  - Ambiguity scan:
136
201
  - Feasibility scan:
137
202
  - Source alignment:
203
+ - Implementation surface scan:
204
+ - Decision horizon scan:
205
+ - Error & rescue scan:
206
+ - Test framework / regression scan:
138
207
  - UI / interaction review summary:
139
- - DX review summary:
208
+ - DX / operator review summary:
140
209
  - Test-first readiness:
210
+ - Review calibration:
141
211
  - Auto-decided items:
142
212
  - Taste decisions:
143
213
  - User challenges:
@@ -5,6 +5,7 @@
5
5
  - Requirement version:
6
6
  - Design version:
7
7
  - CC-Plan skill version:
8
+ - Output language:
8
9
  - Source roadmap item:
9
10
  - Source roadmap version:
10
11
  - Change meta: `change-meta.json`
@@ -18,13 +19,23 @@
18
19
  - Capability specs:
19
20
  - Read first:
20
21
  - Commands to trust:
22
+ - Test framework source:
21
23
  - TDD plan: `Red -> Green -> Refactor`
22
24
  - TDD exceptions: none | list exception reason, risk, replacement evidence, follow-up
25
+ - Regression tests: required | not applicable, with reason
23
26
  - Do not re-decide:
24
27
  - Parallel boundaries:
25
28
 
26
29
  > 顶部 handoff 只保留执行者必须知道的现实,不重复讲背景故事。
27
30
 
31
+ ## Implementation Surface Map
32
+
33
+ | Surface | Responsibility | Tasks | Coupling risk |
34
+ |---------|----------------|-------|---------------|
35
+ | | | | |
36
+
37
+ > 这张表是执行边界,不是装饰。任务拆分必须沿着这些职责走,不能让 `cc-do` 临场重切文件归属。
38
+
28
39
  ## Phase 1: Foundation
29
40
 
30
41
  - [ ] T001 [TEST] Write the first failing test (dependsOn:none) `path/to/test`
@@ -34,6 +45,7 @@
34
45
  Read first: `design.md`, `tasks.md`
35
46
  Verification: `npm test -- path/to/test`
36
47
  Evidence: failing output
48
+ Coverage: unit / integration / e2e / eval; regression: yes / no
37
49
  Ready when: 没有上游依赖,且测试路径已经确定
38
50
 
39
51
  - [ ] T002 [IMPL] Make the first test pass (dependsOn:T001) `path/to/file`
@@ -54,6 +66,7 @@
54
66
  Read first: `design.md`, `tasks.md`
55
67
  Verification: `npm test -- path/to/other.test`
56
68
  Evidence: failing output
69
+ Coverage: unit / integration / e2e / eval; regression: yes / no
57
70
  Ready when: T002 完成,且该测试覆盖的是独立行为
58
71
 
59
72
  - [ ] T004 [P] [IMPL] Make the independent test pass (dependsOn:T003) `path/to/other-file`
@@ -96,3 +109,4 @@
96
109
  - 用哪条命令证明它完成
97
110
  - 要留下什么证据给 `cc-check`
98
111
  - 它处于 Red、Green、Refactor,还是明确的 TDD exception
112
+ - 测试框架依据来自哪里,回归测试是否被明确处理
@@ -2,6 +2,9 @@
2
2
  "changeId": "REQ-XXX",
3
3
  "requirementId": "REQ-XXX",
4
4
  "requirementVersion": "REQ-XXX.v1",
5
+ "outputPolicy": {
6
+ "documentLanguage": ""
7
+ },
5
8
  "sourceRoadmap": {
6
9
  "itemId": "RM-001",
7
10
  "roadmapVersion": "1.0",
@@ -17,7 +20,7 @@
17
20
  ]
18
21
  },
19
22
  "planningMeta": {
20
- "reqPlanSkillVersion": "3.5.2",
23
+ "reqPlanSkillVersion": "3.5.6",
21
24
  "designVersion": "design.v1",
22
25
  "approvedAt": "2026-04-15T12:00:00.000Z",
23
26
  "approvedBy": "user",
@@ -26,6 +29,8 @@
26
29
  "executionDiscipline": {
27
30
  "default": "red-green-refactor",
28
31
  "testFirstRequired": true,
32
+ "testFrameworkSource": "",
33
+ "regressionTestsRequired": [],
29
34
  "tddExceptions": []
30
35
  },
31
36
  "status": "planned",
@@ -5,6 +5,7 @@
5
5
  - Requirement version:
6
6
  - Design version:
7
7
  - CC-Plan skill version:
8
+ - Output language:
8
9
  - Requirement ID:
9
10
  - Design mode: `tiny-design`
10
11
  - Why this stays `tiny-design`:
@@ -42,16 +43,35 @@
42
43
  - Key decisions that `cc-do` must not re-decide:
43
44
  - Upgrade trigger to `full-design`:
44
45
 
46
+ > `tiny-design` 是短设计,不是免设计。没有明确批准状态、验证证据和升级触发条件,就不能继续拆任务。
47
+
48
+ ## Implementation Surface Map
49
+
50
+ | Surface | Responsibility | Why here | Coupling risk |
51
+ |---------|----------------|----------|---------------|
52
+ | | | | |
53
+
45
54
  ## Validation
46
55
 
56
+ - Test framework source:
47
57
  - First failing test:
48
58
  - Green implementation check:
49
59
  - Refactor checkpoint:
50
60
  - TDD exceptions:
61
+ - Regression test required:
51
62
  - Primary check:
52
63
  - Secondary checks:
53
64
  - Evidence to collect:
54
65
 
66
+ ## Conditional Design Checks
67
+
68
+ - UI / interaction scope: Yes / No
69
+ - UI state coverage if applicable:
70
+ - Developer / operator-facing scope: Yes / No
71
+ - Target developer / operator if applicable:
72
+ - Time to first value if applicable:
73
+ - Magic moment if applicable:
74
+
55
75
  ## Main Risk
56
76
 
57
77
  - Risk:
@@ -64,7 +84,10 @@
64
84
  - Scope scan:
65
85
  - Ambiguity scan:
66
86
  - Feasibility scan:
87
+ - Implementation surface scan:
88
+ - Test framework / regression scan:
67
89
  - Test-first readiness:
90
+ - Review calibration:
68
91
  - Final recommendation:
69
92
 
70
93
  ## Approval
@@ -1,5 +1,22 @@
1
1
  # Roadmap Skill Changelog
2
2
 
3
+ ## v4.3.4 - 2026-04-28
4
+
5
+ - add planning posture and evidence maturity routing so roadmap questions match idea, user, paying, infra, or recovery contexts
6
+ - require a framing check before route recommendation so vague users, hypothetical demand, and undefined status quo do not pass as evidence
7
+ - add developer/operator adoption handoff fields for target user, time to first value, magic moment, and install/run/debug/upgrade bottlenecks
8
+
9
+ ## v4.3.3 - 2026-04-28
10
+
11
+ - add a decomposition-first route for asks that bundle multiple independently shippable subsystems
12
+ - require roadmap entry and approval gates to split over-broad goals into stages and RM candidates before implementation detail discovery
13
+ - add subsystem decomposition and handoff notes to roadmap/backlog templates
14
+
15
+ ## v4.3.2 - 2026-04-27
16
+
17
+ - require roadmap outputs to resolve the runtime output policy before writing durable roadmap/backlog documents
18
+ - record `Output language` as the machine-enforced language contract while treating `agent_preferences` as advisory style input
19
+
3
20
  ## v4.3.1 - 2026-04-19
4
21
 
5
22
  - refactor `scripts/roadmap-tracking.js` into focused schema / markdown / store helpers so the CLI stops carrying parsing, rendering, upgrade, and persistence in one 1000-line file
@@ -16,6 +16,9 @@
16
16
  4. 通过 `roadmap` 只能产出方向,不能偷拆实现任务。
17
17
  5. 没有证据时写 assumption,不准冒充事实。
18
18
  6. 每次都必须明确推荐一条路线,不准只列选项不下判断。
19
+ 7. 多个独立子系统混在一个目标里时,先拆阶段和 `RM` 候选,不要继续追问实现细节。
20
+ 8. 先判断 planning posture 和 evidence maturity,再决定追问哪些问题;不要用同一套问题硬套 idea、已有用户、付费客户、infra 和 recovery 场景。
21
+ 9. developer-facing / operator-facing 路线必须写清 target user、time to first value、magic moment 和 adoption bottleneck。
19
22
 
20
23
  ## Local Kit
21
24
 
@@ -37,6 +40,9 @@
37
40
  3. 最近相关 docs / specs / plans
38
41
  4. 最近相关提交、当前工作树状态、正在推进的 requirement
39
42
  5. 现实 forcing functions:deadline、distribution、资源、依赖、当前卡点
43
+ 6. planning posture:startup / internal / hackathon / OSS / research / learning / side-project / infrastructure
44
+ 7. evidence maturity:idea / has users / paying users / internal sponsor / infra-only / recovery
45
+ 8. developer / operator adoption 线索:目标人、first success path、TTHW / time to first value、debug / upgrade 卡点
40
46
 
41
47
  先把这些材料压成 `Context Snapshot`,再追问用户。
42
48
 
@@ -57,11 +63,22 @@
57
63
  8. 当前最大的 adoption / trust / delivery 卡点是什么
58
64
  9. 成功与失败的判断信号是什么
59
65
 
66
+ 第一轮答案之后做 framing check:术语是否具体、用户是否可命名、pain 是否来自真实行为、status quo 是否明确、需求证据是否强过“感兴趣”。如果答案虚,先收紧问题,不要急着定路线。
67
+
68
+ ## Evidence-Maturity Routing
69
+
70
+ - `idea / pre-product`: 先追真实用户、现状替代方案、最窄 wedge、需求证据。
71
+ - `has users`: 先追现有路径、失败/绕路场景、使用保留信号、下一阶段 wedge。
72
+ - `paying users / internal sponsor`: 先追付费/赞助动机、扩张边界、信任信号、组织风险。
73
+ - `infra-only`: 先追调用方、瓶颈、复用边界、迁移/回滚约束。
74
+ - `recovery / trust gap`: 先追事故证据、恢复路径、最小可信修复、停止扩张的 kill signal。
75
+
60
76
  ## Route Shapes
61
77
 
62
78
  - `wedge-first`: 用一个极窄切口先打穿真实需求
63
79
  - `platform-first`: 先搭通后续阶段复用的关键底座
64
80
  - `rescue-first`: 先解决当前最大的 adoption / trust / delivery 卡点
81
+ - `decompose-first`: 先把多个可独立交付的子系统拆成阶段和 `RM`,再选择主线
65
82
 
66
83
  推荐时必须回答:为什么这条主线比其他两条更值得先打。
67
84
 
@@ -73,6 +90,7 @@
73
90
  2. 有没有明确说“不先做另外两条”的原因?
74
91
  3. Stage 1 的 win signal 能不能在 1-2 个周期内看到?
75
92
  4. 如果 Stage 1 输了,kill signal 是不是具体到可以止损?
93
+ 5. 当前问题路由是否匹配 evidence maturity,而不是为了完整感把所有问题都问一遍?
76
94
 
77
95
  ## Stage Contract
78
96
 
@@ -84,7 +102,8 @@
84
102
  4. `Exit signal`
85
103
  5. `Kill signal`
86
104
  6. `Non-goals`
87
- 7. 可以自然长成下一轮 `cc-plan` 的候选事项
105
+ 7. 子系统 / `RM` 边界,说明哪些合并、哪些拆开
106
+ 8. 可以自然长成下一轮 `cc-plan` 的候选事项
88
107
 
89
108
  ## Dependency Contract
90
109
 
@@ -98,6 +117,7 @@
98
117
  `devflow/ROADMAP.md`
99
118
  - version / skill version / context snapshot / evidence ledger
100
119
  - 1-3 个阶段
120
+ - 独立子系统拆分判断
101
121
  - 每阶段目标
102
122
  - 每阶段存在原因
103
123
  - 每阶段 dependencies
@@ -111,6 +131,7 @@
111
131
  `devflow/BACKLOG.md`
112
132
  - 只保留会真的进入下一轮 `cc-plan` 的事项
113
133
  - 每项注明来源阶段、优先级、证据、`Depends On`、`Parallel With`、当前未知点、下一决策、是否 ready
134
+ - developer-facing / operator-facing 条目要带 target user、time to first value、magic moment 和 adoption bottleneck,方便 `cc-plan` 继续做 DX 设计
114
135
  - `Backlog Meta`、`Queue`、`Dependency Handoff`、`Ready For Req-Plan`、`Parked` 可由 `devflow/roadmap-tracking.json` 回渲染,避免 roadmap truth 和 backlog handoff 分叉
115
136
 
116
137
  ## Review Loop
@@ -123,6 +144,8 @@
123
144
  4. `RM Dependency Graph` 是否只有硬依赖、没有环
124
145
  5. ready 项是否真能进入 `cc-plan`
125
146
  6. 本次版本相比上一版到底改了什么
147
+ 7. 问题路由是否匹配 planning posture / evidence maturity
148
+ 8. developer-facing / operator-facing item 是否能说明 first value 为什么会发生
126
149
 
127
150
  ## Versioning
128
151
 
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: cc-roadmap
3
- version: 4.3.1
3
+ version: 4.3.4
4
4
  description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
5
5
  triggers:
6
6
  - "帮我定路线图"
@@ -32,6 +32,8 @@ writes:
32
32
  entry_gate:
33
33
  - "Read current roadmap, backlog, related capability specs, and surrounding repo context before proposing direction."
34
34
  - "Confirm this is a project-direction problem, not a single requirement execution problem."
35
+ - "Classify planning posture and evidence maturity before selecting the route or forcing questions."
36
+ - "If the ask contains multiple independent subsystems, decompose them into stages and RM candidates before refining any implementation detail."
35
37
  - "Do not decompose implementation tasks while the roadmap is still being decided."
36
38
  exit_criteria:
37
39
  - "The next 1-3 stages are frozen with goal, why now, dependencies, exit signal, kill signal, and non-goals."
@@ -61,6 +63,14 @@ tool_budget:
61
63
 
62
64
  它先尽可能收集真实上下文,再逼出真实用户、真实痛点、真实紧迫性,最后把这些现实压成一条能落地、能进入 `cc-plan` 的主线。
63
65
 
66
+ ## Runtime Output Policy
67
+
68
+ 写入任何 durable Markdown 或 JSON metadata 前,先运行 `cc-devflow config resolve --format policy`。
69
+
70
+ - `Output language` 是机器约束,`devflow/ROADMAP.md`、`devflow/BACKLOG.md` 和 tracking metadata 必须记录并遵守它。
71
+ - `agent_preferences` 是用户偏好建议,只影响表达方式和结构选择,不覆盖本 Skill 的工作流边界。
72
+ - 如果配置解析失败,先修配置或向用户说明阻塞,不要用默认语言继续生成正式文档。
73
+
64
74
  ## Read First
65
75
 
66
76
  1. `PLAYBOOK.md`
@@ -87,12 +97,13 @@ tool_budget:
87
97
  | “不知道下一步做什么” | 主线不清 | `wedge-first` |
88
98
  | “后面几阶段都会重复碰同一底座” | 底座风险 | `platform-first` |
89
99
  | “增长/交付/信任卡住了” | 当前最大瓶颈 | `rescue-first` |
100
+ | “一个目标里塞了多个可独立交付系统” | 边界过宽 | `decompose-first` |
90
101
 
91
102
  先给一个**默认推荐**,再解释为什么,不要把用户扔进开放式战略讨论。
92
103
 
93
104
  ## Harness Contract
94
105
 
95
- - 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.
106
+ - 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.
96
107
  - Forbidden actions: decompose implementation tasks, invent hidden context, or jump into `cc-plan` before the roadmap is approved.
97
108
  - Required evidence: every stage and backlog item must point back to explicit repo facts, user constraints, or observed market signals.
98
109
  - Reroute rule: once the conversation collapses to one concrete requirement, stop strategic expansion and hand off to `cc-plan`.
@@ -101,8 +112,9 @@ tool_budget:
101
112
 
102
113
  1. 如果 `devflow/ROADMAP.md` / `devflow/BACKLOG.md` 已存在,先读现状再重写。
103
114
  2. 先判断这是“项目方向问题”还是“单 requirement 执行问题”。
104
- 3. 先做一次上下文扫描,不能跳过现有事实直接写愿景。
105
- 4. 方向没被批准前,不准把 roadmap 偷偷下放成实现任务。
115
+ 3. 如果输入是多个独立子系统的混合目标,先拆成阶段和 `RM` 候选;不要继续追问某个子系统的实现细节。
116
+ 4. 先做一次上下文扫描,不能跳过现有事实直接写愿景。
117
+ 5. 方向没被批准前,不准把 roadmap 偷偷下放成实现任务。
106
118
 
107
119
  ## Context Sweep
108
120
 
@@ -114,20 +126,38 @@ tool_budget:
114
126
  4. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
115
127
  5. 真实 forcing functions:deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。
116
128
  6. 当前项目最强的现实证据,以及仍然只能靠假设的空白。
129
+ 7. Planning posture:startup / internal / hackathon / OSS / research / learning / side-project / infrastructure。
130
+ 8. Evidence maturity:idea / has users / paying users / internal sponsor / infra-only / recovery。
131
+ 9. 如果是 developer-facing 或 operator-facing 能力,补齐 target developer/operator、time to first value、magic moment、install / run / debug / upgrade 卡点。
117
132
 
118
133
  先把这些材料压成一个 `Context Snapshot`,再开始追问用户。
119
134
 
135
+ ## Evidence-Maturity Routing
136
+
137
+ 不要对所有项目套同一组问题。先用 `planning posture` 和 `evidence maturity` 决定追问深度:
138
+
139
+ | Evidence maturity | 优先追问 | 不要浪费时间在 |
140
+ | --- | --- | --- |
141
+ | idea / pre-product | 真实用户、status quo、最窄 wedge、需求证据 | 远期平台架构细节 |
142
+ | has users | 现有使用路径、失败/绕路场景、保留率或复用信号、下一阶段 wedge | 假想 persona |
143
+ | paying users / internal sponsor | 付费/赞助动机、扩张边界、不可丢的信任信号、组织风险 | 泛泛市场教育 |
144
+ | infra-only | 当前瓶颈、调用方、现有 workaround、复用边界、迁移/回滚约束 | 伪装成用户访谈的问题 |
145
+ | recovery / trust gap | 事故证据、恢复路径、最小可信修复、停止继续扩张的 kill signal | 新功能愿景 |
146
+
147
+ 第一轮回答后必须做 framing check:术语是否具体、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚,要先收紧问题,再谈路线。
148
+
120
149
  ## Session Protocol
121
150
 
122
151
  1. 先探索上下文,不靠默认上下文注入替代阅读。
123
152
  2. 先问现实,不先写愿景。
124
153
  3. 一次只推进一个关键未知点,不要一口气抛一串问题。
125
- 4. 先写 `Context Snapshot`、证据、约束、非目标,再讨论阶段。
154
+ 4. 先写 `Context Snapshot`、planning posture、evidence maturity、证据、约束、非目标,再讨论阶段。
126
155
  5. 给出 2-3 种路线图形状,再明确推荐一种,并说明为什么其他路线现在不值得打。
127
- 6. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals。
128
- 7. `RM` 之间的硬依赖压成显式 dependency graph,并标出 parallel-ready wave;不要把“最好按这个顺序做”伪装成 blocker
129
- 8. backlog 只保留会真的进入下一轮 `cc-plan` 的事项,每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、`Depends On` 与 `Parallel With`。
130
- 9. 用户没批准,不进入 `cc-plan`。
156
+ 6. 如果一个方向里有多个可独立交付的子系统,先写清 decomposition:哪些合并为同一阶段,哪些拆成独立 `RM`,为什么。
157
+ 7. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals
158
+ 8. `RM` 之间的硬依赖压成显式 dependency graph,并标出 parallel-ready wave;不要把“最好按这个顺序做”伪装成 blocker。
159
+ 9. backlog 只保留会真的进入下一轮 `cc-plan` 的事项,每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、`Depends On` 与 `Parallel With`。
160
+ 10. 用户没批准,不进入 `cc-plan`。
131
161
 
132
162
  ## Route Selection Rule
133
163
 
@@ -165,14 +195,24 @@ tool_budget:
165
195
  8. 当前最大的 adoption、trust、delivery 卡点是什么
166
196
  9. 这个 roadmap 成功与失败各自用什么信号判断
167
197
 
198
+ 如果这是 developer-facing / operator-facing roadmap,再补 4 件事:
199
+
200
+ 10. 目标开发者 / 操作者是谁
201
+ 11. 从第一次接触到第一次成功输出需要多久
202
+ 12. 让他们觉得“这东西真的有用”的 magic moment 是什么
203
+ 13. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
204
+
168
205
  ## Approval Gates
169
206
 
170
207
  1. 没有 `Context Snapshot`,不准给路线推荐。
171
- 2. 没有 2-3 条路线对比,不准直接拍脑袋定主线。
172
- 3. 没有 exit signal / kill signal / non-goals,不算阶段冻结。
173
- 4. 没有明确成功信号和下一决策,不准把事项放进 `Ready For Req-Plan`。
174
- 5. 没有 `RM dependency graph` 或 parallel-ready wave,不准宣称事项可以并发推进。
175
- 6. 没有用户批准,不准把 roadmap item 下放到 `cc-plan`。
208
+ 2. 没有 planning posture、evidence maturity 和 framing check,不准给路线推荐。
209
+ 3. 没有 2-3 条路线对比,不准直接拍脑袋定主线。
210
+ 4. 没有 exit signal / kill signal / non-goals,不算阶段冻结。
211
+ 5. 没有明确成功信号和下一决策,不准把事项放进 `Ready For Req-Plan`。
212
+ 6. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck,不准标成 ready。
213
+ 7. 没有 `RM dependency graph` 或 parallel-ready wave,不准宣称事项可以并发推进。
214
+ 8. 没有独立子系统拆分判断,不准把大而混杂的方向伪装成单一主线。
215
+ 9. 没有用户批准,不准把 roadmap item 下放到 `cc-plan`。
176
216
 
177
217
  ## Review Loop
178
218
 
@@ -184,7 +224,10 @@ tool_budget:
184
224
  4. Feasibility scan:阶段目标与团队容量、依赖、distribution 约束是否接得上。
185
225
  5. Graph scan:`Depends On` 是否只包含硬阻塞,图里有没有环,parallel-ready wave 是否真的共享同一前置。
186
226
  6. Spec scan:每个 roadmap item 是否都落到某个 capability,而不是悬空需求。
187
- 7. Handoff scan:第一批 roadmap item 是否已经自然长成可进入 `cc-plan` 的对象。
227
+ 7. Decomposition scan:多个独立子系统是否已拆成阶段 / `RM` 候选,而不是塞进一个含糊阶段。
228
+ 8. Handoff scan:第一批 roadmap item 是否已经自然长成可进入 `cc-plan` 的对象。
229
+ 9. Evidence maturity scan:问题路由是否匹配 idea / user / paying / infra / recovery 状态,还是拿同一套问题硬套所有项目。
230
+ 10. Adoption scan:developer-facing / operator-facing item 是否写清目标人、time to first value、magic moment 和 adoption bottleneck。
188
231
 
189
232
  ## Output
190
233
 
@@ -4,6 +4,7 @@
4
4
 
5
5
  - Roadmap version:
6
6
  - Skill version:
7
+ - Output language:
7
8
  - Last synced:
8
9
  - Current focus stage:
9
10
  - Tracking source: `devflow/roadmap-tracking.json`
@@ -18,8 +19,18 @@
18
19
 
19
20
  - Serial spine:
20
21
  - Parallel-ready next wave:
22
+ - Decomposition notes:
21
23
  - Notes on blockers:
22
24
 
25
+ ## Adoption Handoff
26
+
27
+ - Planning posture:
28
+ - Evidence maturity:
29
+ - Target developer / operator:
30
+ - Time to first value:
31
+ - Magic moment:
32
+ - Adoption bottleneck:
33
+
23
34
  ## Ready For Req-Plan
24
35
 
25
36
  - RM-001:
@@ -32,6 +43,11 @@
32
43
  - Expected spec delta:
33
44
  - Open risks:
34
45
  - First planning question:
46
+ - Evidence maturity:
47
+ - Target developer / operator:
48
+ - Time to first value:
49
+ - Magic moment:
50
+ - Adoption bottleneck:
35
51
  - Required context to load:
36
52
  - Depends On:
37
53
  - Parallel With:
@@ -4,6 +4,7 @@
4
4
 
5
5
  - Roadmap version:
6
6
  - Skill version:
7
+ - Output language:
7
8
  - Status:
8
9
  - Last updated:
9
10
  - Owner / decider:
@@ -14,17 +15,24 @@
14
15
  ## Context Snapshot
15
16
 
16
17
  - Product / repo:
18
+ - Planning posture:
17
19
  - Project stage:
20
+ - Evidence maturity:
18
21
  - Users:
19
22
  - Pain:
20
23
  - Existing workaround:
21
24
  - Strongest demand evidence:
25
+ - Framing check:
22
26
  - Why now:
23
27
  - Distribution path:
24
28
  - Deadline / forcing function:
25
29
  - Team / capacity:
26
30
  - Hard constraints:
27
31
  - Adoption / trust bottleneck:
32
+ - Target developer / operator:
33
+ - Time to first value:
34
+ - Magic moment:
35
+ - Install / run / debug / upgrade bottleneck:
28
36
  - Known unknowns:
29
37
  - Relevant capabilities:
30
38
 
@@ -44,6 +52,7 @@
44
52
  | wedge-first | | | Recommended / Rejected |
45
53
  | platform-first | | | Rejected |
46
54
  | rescue-first | | | Rejected |
55
+ | decompose-first | | | Recommended / Rejected |
47
56
 
48
57
  ## Recommended Route
49
58
 
@@ -63,6 +72,33 @@
63
72
  - What we refuse to build yet:
64
73
  - 6-12 month pull:
65
74
 
75
+ ## Evidence-Maturity Routing
76
+
77
+ - Planning posture:
78
+ - Evidence maturity:
79
+ - Questions selected:
80
+ - Questions intentionally skipped:
81
+ - Reason this route matches maturity:
82
+ - Evidence that would change the route:
83
+
84
+ ## DX / Operator Adoption Context
85
+
86
+ - Applies: Yes / No
87
+ - Target developer / operator:
88
+ - Current first-success path:
89
+ - Target time to first value:
90
+ - Magic moment:
91
+ - Install / run / debug / upgrade risks:
92
+ - Adoption bottleneck:
93
+
94
+ ## Subsystem Decomposition
95
+
96
+ | Subsystem / RM candidate | User value | Can ship independently? | Merge / split decision | Reason |
97
+ |--------------------------|------------|-------------------------|------------------------|--------|
98
+ | RM-001 | | Yes / No | Merge / Split | |
99
+
100
+ > 如果一个目标里塞了多个独立子系统,先拆阶段和 `RM`,再谈优先级。不要把大杂烩写成一个阶段。
101
+
66
102
  ## Stage Overview
67
103
 
68
104
  | Stage | Goal | Why now | Primary capabilities | Dependencies | Exit signal | Kill signal | Non-goals |
@@ -139,6 +175,8 @@ flowchart LR
139
175
 
140
176
  - Rejected path A:
141
177
  - Rejected path B:
178
+ - Rejected maturity route:
179
+ - Developer / operator adoption assumptions:
142
180
  - Open assumptions to verify next:
143
181
  - What changed in this version:
144
182
 
@@ -1,14 +1,18 @@
1
1
  {
2
2
  "version": 2,
3
+ "outputPolicy": {
4
+ "documentLanguage": ""
5
+ },
3
6
  "lastSyncedAt": "2026-04-19",
4
7
  "backlogMeta": {
5
8
  "roadmapVersion": "roadmap.v1",
6
- "skillVersion": "4.3.1",
9
+ "skillVersion": "4.3.4",
7
10
  "currentFocusStage": "Stage 1"
8
11
  },
9
12
  "dependencyHandoff": {
10
13
  "serialSpine": "RM-001",
11
14
  "parallelReadyNextWave": "-",
15
+ "decompositionNotes": "-",
12
16
  "notesOnBlockers": "-"
13
17
  },
14
18
  "items": [
@@ -1,5 +1,10 @@
1
1
  # CC-Spec-Init Skill Changelog
2
2
 
3
+ ## v1.0.1 - 2026-04-27
4
+
5
+ - require capability specs, spec indexes, and change metadata to resolve the runtime output policy before writing durable artifacts
6
+ - record `Output language` as the machine-enforced language contract while treating `agent_preferences` as advisory style input
7
+
3
8
  ## v1.0.0 - 2026-04-19
4
9
 
5
10
  - 初始版 `cc-spec-init`,用于 capability-centered spec 初始化、能力真相源维护和 `change-meta.json` 链路收口。