cc-devflow 4.5.6 → 4.5.7

package/.claude/skills/cc-review/references/plan-review-branch.md

@@ -0,0 +1,116 @@
+# Plan Review Branch
+
+Use this reference when the review target is a plan, investigation handoff, or mixed branch whose plan contract may be wrong.
+
+## Intake
+
+Read, in order:
+
+1. `planning/design.md` or `planning/analysis.md`
+2. `planning/tasks.md`
+3. `planning/task-manifest.json`
+4. `change-meta.json`
+5. related roadmap/spec/docs/code referenced by the plan
+
+If no change directory exists, review the user-provided plan text and clearly mark missing durable artifacts.
+
+## Review Shape
+
+Run only applicable facets. Do not load every facet when the plan is small.
+
+### 1. Strategy Facet
+
+Use a native strategy review question set:
+
+- Is this the right problem?
+- Is the stated user/business outcome direct or a proxy?
+- What happens if we do nothing?
+- What does the 12-month ideal look like?
+- What existing code or workflow already solves part of this?
+
+Output:
+
+```text
+CURRENT -> THIS PLAN -> 12-MONTH IDEAL
+```
+
+### 2. Engineering Facet
+
+Review:
+
+- component boundaries
+- data flow and shadow paths
+- state transitions
+- security boundaries
+- rollback shape
+- testability seam
+- parallelization risk
+
+Required diagram for non-trivial plans:
+
+```text
+Entry -> validate -> transform -> persist -> output
+  |        |            |            |          |
+ nil     invalid      exception    conflict   stale
+ empty   wrong type   timeout      duplicate  partial
+```
+
+### 3. Design Facet
+
+Run only for user-facing UI or interaction flows.
+
+Check:
+
+- first, second, third thing the user sees
+- loading / empty / error / success / partial states
+- responsive and accessibility intent
+- generic UI or AI slop risk
+- whether live design review will be needed after implementation
+
+### 4. DX Facet
+
+Run only for API, CLI, SDK, package, docs, agent skill, MCP, or developer/operator surfaces.
+
+Check:
+
+- target developer/operator persona
+- time to first value
+- install/run/debug/upgrade path
+- actionable errors: problem + cause + fix
+- copy-paste examples and escape hatches
+
+## TOC Root-Cause Pass
+
+For complex bugs, use:
+
+1. Current reality tree: symptoms, causes, enabling conditions.
+2. Conflict diagram: why the obvious fix conflicts with a real need.
+3. Future reality tree: what the proposed fix changes and what it may break.
+
+If the root cause is not proven, reroute to `cc-investigate`, not `cc-do`.
+
+## Code Smell Pass In Planning
+
+Plans can contain smells before code exists:
+
+- repeated implementation steps with slight variations
+- parallel data sources
+- task split by technical layer instead of behavior
+- fake abstraction or one-adapter seam
+- missing owner for shared state
+- hand-wavy "handle edge cases" or "add validation"
+
+Each planning smell must become a plan finding and route to `cc-plan`.
+
+## Output Requirements
+
+Add to `cc-review-report.md`:
+
+- plan artifacts read
+- strategy/engineering/design/DX facets used
+- diagrams produced
+- in-scope bad smells
+- decisions needed
+- reroute recommendation
+
+If any plan facet changes the task list or implementation contract, route to `cc-plan`.

package/.claude/skills/cc-review/references/review-methods.md

@@ -0,0 +1,126 @@
+# CC-Review Methods
+
+Use this reference for every `cc-review` run. It defines the shared method library. Load branch-specific references for concrete workflow steps.
+
+## Method Selection
+
+Use only methods that fit the risk:
+
+| Risk | Method |
+| --- | --- |
+| unclear goal | goal tree |
+| repeated symptom | current reality tree |
+| hidden tradeoff | conflict diagram |
+| uncertain fix impact | future reality tree |
+| implementation complexity | logic tree and smell scan |
+| UI/runtime mismatch | E2E/plugin verification |
+
+## Thinking Tools
+
+### Goal Tree
+
+Use when the plan has too many proposed actions and not enough outcome clarity.
+
+```text
+GOAL
+├── necessary condition A
+│   ├── measurable signal
+│   └── blocked by
+├── necessary condition B
+└── NOT IN SCOPE
+```
+
+### Current Reality Tree
+
+Use for bugs and recurring failures.
+
+```text
+SYMPTOM
+├── direct cause
+│   └── deeper cause
+├── enabling condition
+└── missing control
+```
+
+### Conflict Diagram
+
+Use when two requirements appear incompatible.
+
+```text
+Objective
+├── Need A -> Want X
+└── Need B -> Want not-X
+Assumption to break: ...
+```
+
+### Future Reality Tree
+
+Use before recommending a non-trivial redesign.
+
+```text
+CHANGE
+├── desired effect
+├── possible negative branch
+│   └── prevention
+└── verification signal
+```
+
+### Logic Tree
+
+Use for implementation reviews.
+
+```text
+Entry point
+├── path A
+│   ├── happy
+│   ├── empty
+│   └── error
+└── path B
+```
+
+## Code Smell Taxonomy
+
+Only report smells inside the current requirement blast radius or smells made worse by the current work.
+
+| Smell | Review question | Preferred fix shape |
+| --- | --- | --- |
+| rigidity | Does a small change force unrelated edits? | move decision to one owner |
+| duplication | Is the same logic repeated with small variations? | reuse existing helper or make one narrow helper |
+| cycle | Do modules know each other's internals? | invert dependency or extract boundary |
+| fragility | Can one change break unrelated behavior? | isolate side effects and add focused tests |
+| obscurity | Is intent hidden behind clever names or control flow? | rename, split, or make data shape explicit |
+| data-clump | Do fields always travel together? | group them into one object/value |
+| unnecessary-complexity | Is abstraction solving a hypothetical future? | delete seam or collapse to direct code |
+
+## Severity
+
+- `critical`: ships wrong behavior, data/security risk, silent failure, broken root cause, or impossible verification.
+- `important`: likely maintenance, test, UX, DX, performance, or operability problem in current scope.
+- `advisory`: good improvement but not required for this change.
+
+## Confidence
+
+- `9-10`: directly verified in code, artifact, command output, UI run, or log.
+- `7-8`: strong evidence from nearby patterns and diff.
+- `5-6`: plausible but needs confirmation; mark as verify-first.
+- `<5`: do not put in main findings unless critical impact.
+
+## Decision Questions
+
+Ask only when a finding requires user judgment.
+
+Use:
+
+```text
+D<N> - <decision title>
+Evidence: <concrete artifact/path/line/log/UI action>
+Risk: <what breaks if ignored>
+Recommendation: A because <principle>
+Options:
+A) <fix now> (recommended) - impact
+B) <defer> - impact
+C) <skip> - impact
+STOP: wait for the user answer before continuing.
+```
+
+Do not batch unrelated issues. One issue, one decision.

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

@@ -1,5 +1,11 @@
 # Roadmap Skill Changelog
 
+## v5.2.0 - 2026-05-09
+
+- add project-direction routing and brand-neutral founder guardrails
+- add the AI Leverage Route Lens so roadmap recommendations must name the real user/operator, current workaround, human-vs-agent effort, complete-lake boundary, ocean boundary, first success signal, kill signal, and boil-lake/sharp-wedge/needs-evidence/pivot verdict
+- update roadmap and tracking templates so AI-era scope choices can choose complete same-blast-radius lakes instead of timid MVP slices
+
 ## v5.0.0 - 2026-05-01
 
 - replace the roadmap/backlog/tracking split with `devflow/roadmap.json` as the single editable roadmap state

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

@@ -1,6 +1,6 @@
 ---
 name: cc-roadmap
-version: 5.0.0
+version: 5.2.0
 description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
 triggers:
   - "帮我定路线图"
@@ -37,14 +37,19 @@ 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."
+  - "Run the Project Direction Gate before evidence-maturity routing: classify the user's goal as founder/business, internal company project, hackathon/demo, open-source/research, learning, side project, infrastructure, or recovery."
   - "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."
+  - "Apply the AI Leverage Route Lens before route approval: name the reachable user/operator, current workaround, human-vs-agent effort, complete-lake boundary, ocean boundary, first success signal, and kill signal."
+  - "If AI makes a complete same-blast-radius route cheap and verifiable, prefer boil-lake over a timid MVP slice."
+  - "If the route cannot name a real user/operator and current workaround, mark it as needs-evidence instead of producing implementation-ready RM handoff."
 exit_criteria:
   - "The next 1-3 stages are frozen with goal, why now, dependencies, exit signal, kill signal, and non-goals."
   - "The first backlog items can naturally enter cc-plan without extra strategic guessing, including explicit capability links and expected spec delta."
   - "The roadmap shows an explicit RM dependency graph so serial blockers and parallel-ready work are obvious."
   - "The user-approved recommendation is explicit and grounded in current evidence."
+  - "Each Stage 1 or ready-for-cc-plan item records an AI Leverage Route Lens verdict: boil-lake, sharp-wedge, needs-evidence, or pivot."
 reroutes:
   - when: "The user is already discussing one concrete requirement, bug, or execution task."
     target: "cc-plan"
@@ -107,6 +112,35 @@ tool_budget:
 
 先给一个**默认推荐**，再解释为什么，不要把用户扔进开放式战略讨论。
 
+## Project Direction Gate
+
+`cc-roadmap` 的第一道门不是功能优先级，而是项目目标。目标不同，问题就不同；问题问错，后面的路线图全都会偏。
+
+先用 repo 事实和用户原话判断 `project_direction_mode`。能判断就写入 `Context Snapshot`；不能判断才问一次：
+
+> 这次 roadmap 的目标是什么：做成业务、公司内部项目、限时 demo、开源/研究、学习、兴趣副项目、基础设施，还是事故恢复？
+
+不要让用户在 8 个选项里填表。先给默认判断和理由，再问用户是否纠正。
+
+| Mode | 用来判断的信号 | 追问重点 | 默认路线偏好 |
+| --- | --- | --- | --- |
+| `founder-business` | 用户提到客户、收入、市场、获客、创业、商业化 | 需求真实性、现状替代方案、具体人、最窄付费 wedge、观察到的行为、未来 6-12 个月为何更重要 | `wedge-first` |
+| `internal-company` | 用户提到老板、VP、团队落地、内部流程、审批、交付窗口 | sponsor 是谁、最小可批准 demo、组织依赖、reorg 风险、上线后的维护责任 | `rescue-first` 或 `wedge-first` |
+| `hackathon-demo` | 用户提到比赛、演示、deadline、惊艳效果 | 最快可展示路径、单一 wow moment、失败兜底、demo 环境和分发方式 | `wedge-first` |
+| `open-source-research` | 用户提到社区、论文、协议、benchmark、开源生态 | 贡献者是谁、现有替代品、可复现实验、维护边界、adoption path | `platform-first` 或 `wedge-first` |
+| `learning` | 用户提到学习、练手、理解框架、能力提升 | 要学会什么、最小练习闭环、可观察反馈、不要用过度架构遮住学习目标 | `wedge-first` |
+| `side-project` | 用户提到兴趣、好玩、创意表达、自用工具 | 最酷可分享版本、自己会不会每天用、最快可用路径、哪些想法可以 later | `wedge-first` |
+| `infrastructure` | 用户提到底座、运行时、CI、发布、安全、稳定性 | 调用方、当前 workaround、迁移/回滚、复用边界、失败成本 | `platform-first` 或 `rescue-first` |
+| `recovery` | 用户提到事故、信任、质量、回归、坏味道 | 事故证据、最小可信修复、停止扩张条件、恢复信任的验收信号 | `rescue-first` |
+
+Founder/business 模式可以给 brand-neutral 的创业建议，但只能作为路线判断，不准变成广告：
+
+- 可以建议：先和真实用户谈、验证付费或强行为、缩小到本周能交付的 wedge、观察用户不用帮助时怎么失败、把资源放在最强需求证据上。
+- 不可以建议：申请某个机构、加入某个项目、引用某个品牌权威、输出推广链接、把路线图写成融资材料。
+- 如果要推荐外部学习材料，必须先走隐私与外部查找 gate，只搜索泛化主题，并把结果写成 `external-evidence`；不要把任何品牌背书写进 roadmap 合同。
+
+Builder 模式（hackathon、open-source/research、learning、side-project）不要套创业拷问。它要逼清楚“什么值得展示 / 使用 / 复现 / 学会”，然后把路线压到最快能产生真实反馈的阶段。
+
 ## Harness Contract
 
 - 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.json` as the editable roadmap state, then generate `devflow/ROADMAP.md` and the deprecated `devflow/BACKLOG.md` compatibility projection from that state.
@@ -140,6 +174,23 @@ tool_budget:
 
 先把这些材料压成一个 `Context Snapshot`，再开始追问用户。
 
+## Direction-Specific Question Routing
+
+Project Direction Gate 先决定问哪组问题，Evidence-Maturity Routing 再决定问多深。不要对 founder、学习项目、基础设施和事故恢复使用同一套问题。
+
+| Direction mode | 必问问题 | 可跳过问题 |
+| --- | --- | --- |
+| `founder-business` | 谁今天真的痛；他们现在怎么绕路；最强 demand evidence 是行为、钱还是 workflow 绑定；本周最窄可付费 wedge 是什么；用户不被引导时会在哪里卡住；6-12 个月后为什么更需要它 | 长期平台组件、宽泛市场口号、还没有证据的增长规划 |
+| `internal-company` | sponsor 或决策人是谁；最小 demo 如何换来绿灯；上线后谁维护；依赖哪个团队；如果 champion 离开是否还成立 | 对外市场叙事、消费者增长、无 owner 的平台愿景 |
+| `hackathon-demo` | 评委或观众先看到什么；30-90 秒内的 wow moment；demo 失败时的备用路径；哪些功能必须假装不存在 | 完整权限体系、长期迁移、复杂可观测性 |
+| `open-source-research` | 现有替代品是什么；可复现实验或 benchmark 是什么；贡献者 first success path；维护者不想承担什么 | 商业销售漏斗、封闭分发、无法复现的主观评价 |
+| `learning` | 学会哪个概念；最小练习闭环；如何知道自己学会了；哪些抽象会遮住学习目标 | 生产级平台、过早优化、团队流程 |
+| `side-project` | 自己会不会反复用；最酷可分享版本；最快可用路径；哪些点只是好玩但不该阻塞 Stage 1 | 商业化压力、企业级集成、长期治理 |
+| `infrastructure` | 调用方是谁；今天的 workaround；失败成本；迁移与回滚；复用边界；谁会被 breaking change 影响 | 虚构 persona、营销故事、未证明的功能扩张 |
+| `recovery` | 哪个事故或坏味道触发；最小可信修复；防回归证据；继续扩张的 kill signal；用户信任如何恢复 | 新功能愿景、平台升级、没有事故证据的重构 |
+
+如果用户后续回答改变了 direction mode，必须重算 route shape，不要沿用旧问题继续问。
+
 ## Evidence-Maturity Routing
 
 不要对所有项目套同一组问题。先用 `planning posture` 和 `evidence maturity` 决定追问深度：
@@ -154,6 +205,30 @@ tool_budget:
 
 第一轮回答后必须做 framing check：术语是否具体、是否沿用项目 canonical language、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
 
+## AI Leverage Route Lens
+
+路线图不是愿望清单，也不是小 MVP 限制器。AI 时代的正确问题是：真实需求边界在哪里，AI 杠杆能不能把同一片 lake 一次煮沸。
+
+必须记录这 8 件事：
+
+1. Real user/operator：谁会在 Stage 1 里立刻受益。不能写 “users” / “developers” 这种空词。
+2. Status quo workaround：没有这项能力时，他们今天怎么绕路；如果没人绕路，默认需求证据不足。
+3. Human vs agent effort：同一范围按人类团队要多久，按 CC/agent 要多久；让 AI 压缩率显性进入路线选择。
+4. Complete-lake boundary：同一业务链路、同一 blast radius、可验证、可回滚、少于约 1 天 agent 工作量的完整范围。
+5. Ocean boundary：跨系统重写、多季度迁移、用户还没证实、验收不可闭合或会制造第二套平台的范围。
+6. Scope recommendation：`boil-lake` 还是 `sharp-wedge`；小不是默认，完整也不是默认，证据和验证成本决定。
+7. First success signal：第一个可观察信号，证明这条路线真的赢了。
+8. Kill signal：如果信号没出现，什么时候停止、转向或拆小。
+
+Verdict 只允许四种：
+
+- `boil-lake`：已有真实用户 / operator 和 workaround，同一 blast radius 内完整做完的 agent 成本低、验证闭合、维护收益高。此时不要畏缩成小 MVP。
+- `sharp-wedge`：需求真实，但完整 lake 仍有未证实假设、验证成本过高或会碰 ocean boundary；先打最锋利的一段。
+- `needs-evidence`：方向可能对，但缺真实用户、绕路、成功信号或可验证边界；先补证据，不生成 ready RM。
+- `pivot`：当前路线服务错对象、解决错痛点、过早平台化，或 kill signal 已经触发。
+
+这个 lens 不替代 evidence maturity；它把 evidence maturity 和 AI leverage 合在一起做路线裁决。证据决定该不该做，AI 杠杆决定该做多完整。
+
 ## Strategic Grilling Protocol
 
 `cc-roadmap` 的 brainstorm 不是开放式聊天，而是路线决策树压缩：
@@ -165,12 +240,25 @@ tool_budget:
 5. 每条路线都要用一个具体 scenario 压测：谁在什么约束下，今天如何绕路，Stage 1 完成后哪一步不再发生。
 6. 硬决策才沉淀：只有 hard to reverse、surprising without context、real trade-off 三者同时成立，才进入 capability spec delta、roadmap decision note 或本次 design decision log。
 
+## Founder Advice Guardrail
+
+创业建议只能服务于 roadmap 质量，不是推广内容。遇到 `founder-business` 或 `internal-company`：
+
+1. 强制把泛泛“有市场 / 用户感兴趣”改写为可观察证据：付费、强复用、工作流绑定、停机时焦虑、主动催上线。
+2. 强制找 status quo：手工流程、表格、脚本、外包、人肉客服、现有竞品、内部工具。没有现状替代方案时，先怀疑痛点不够痛。
+3. 强制命名具体人或具体角色，不接受“企业客户”“开发者”“内容团队”这类类别词作为用户。
+4. 强制压出最窄 wedge：本周能让一个真实用户付出钱、时间、迁移成本或组织信用的版本。
+5. 强制保留观察任务：如果还没看用户独立使用，Stage 1 必须包含观察或真实反馈信号。
+6. 严禁输出品牌广告、申请建议、推广链接或“某机构会喜欢”之类的权威背书。
+
+如果用户明确要创业方向资源，也只能给 source-neutral 的行动建议：找 3 个具体用户、看一次真实使用、验证一次付费或强行为、把 Stage 1 缩到一周内可交付。外部材料必须走外部查找 gate。
+
 ## Session Protocol
 
 1. 先探索上下文，不靠默认上下文注入替代阅读。
-2. 先问现实，不先写愿景。
+2. 先跑 Project Direction Gate，再问现实，不先写愿景。
 3. 一次只推进一个关键未知点，不要一口气抛一串问题。
-4. 先写 `Context Snapshot`、planning posture、evidence maturity、证据、约束、非目标，再讨论阶段。
+4. 先写 `Context Snapshot`、project direction mode、planning posture、evidence maturity、证据、约束、非目标，再讨论阶段。
 5. 给出 2-3 种路线图形状，再明确推荐一种，并说明为什么其他路线现在不值得打。
 6. 如果一个方向里有多个可独立交付的子系统，先写清 decomposition：哪些合并为同一阶段，哪些拆成独立 `RM`，为什么。
 7. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals。
@@ -199,7 +287,11 @@ tool_budget:
 
 ## Ask
 
-至少要逼清这 5 件事：
+至少要先逼清这 1 件事：
+
+0. 这次 roadmap 的目标模式是什么，以及为什么不是其它模式
+
+再逼清这 5 件事：
 
 1. 这个项目真正服务谁
 2. 用户今天用什么笨办法解决
@@ -225,7 +317,7 @@ tool_budget:
 ## Approval Gates
 
 1. 没有 `Context Snapshot`，不准给路线推荐。
-2. 没有 planning posture、evidence maturity 和 framing check，不准给路线推荐。
+2. 没有 project direction mode、planning posture、evidence maturity 和 framing check，不准给路线推荐。
 3. 没有 native language / durable decision scan，不准给路线推荐；如果缺少 `devflow/specs/` 或历史决策材料，写成 `not present`，不要假装已对齐。
 4. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
 5. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
@@ -248,9 +340,11 @@ tool_budget:
 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。
-11. Domain language scan：stage、capability、RM title、backlog handoff 是否沿用项目语言；冲突是否显式交给下一轮决策。
-12. Durable decision scan：路线是否违背既有 capability spec、roadmap decision 或历史 design decision；如需重开，是否说明为什么值得重开。
+10. Project direction scan：问题和路线是否匹配 founder-business / internal / demo / OSS / learning / side-project / infra / recovery；是否错误套用了创业问题或 builder 问题。
+11. Promotional scan：roadmap 是否没有品牌广告、申请建议、推广链接或外部权威背书；创业建议是否只保留 source-neutral 行动和证据要求。
+12. Adoption scan：developer-facing / operator-facing item 是否写清目标人、time to first value、magic moment 和 adoption bottleneck。
+13. Domain language scan：stage、capability、RM title、backlog handoff 是否沿用项目语言；冲突是否显式交给下一轮决策。
+14. Durable decision scan：路线是否违背既有 capability spec、roadmap decision 或历史 design decision；如需重开，是否说明为什么值得重开。
 
 ## Output
 

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

@@ -26,6 +26,9 @@
 
 ## Adoption Handoff
 
+- Project direction mode:
+- Direction-specific first question:
+- Founder / builder / infra guardrail:
 - Planning posture:
 - Evidence maturity:
 - Target developer / operator:

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

@@ -16,6 +16,8 @@
 ## Context Snapshot
 
 - Product / repo:
+- Project direction mode:
+- Direction mode rationale:
 - Planning posture:
 - Project stage:
 - Evidence maturity:
@@ -51,6 +53,21 @@
 | Feasibility |  | High / Med / Low |  |  |
 | Distribution |  | High / Med / Low |  |  |
 
+## AI Leverage Route Lens
+
+- Real user / operator:
+- Status quo workaround:
+- Human-team effort for full scope:
+- CC / agent effort for full scope:
+- AI compression ratio:
+- Complete-lake boundary:
+- Ocean boundary:
+- Scope recommendation: `boil-lake` | `sharp-wedge`
+- First success signal:
+- Kill signal:
+- Verdict: `boil-lake` | `sharp-wedge` | `needs-evidence` | `pivot`
+- Missing evidence before ready-for-cc-plan:
+
 ## Route Options
 
 | Shape | Why this could work | Why this may fail | Decision |
@@ -89,6 +106,10 @@
 
 ## Evidence-Maturity Routing
 
+- Project direction mode:
+- Direction-specific questions selected:
+- Direction-specific questions skipped:
+- Founder / builder / infra guardrails applied:
 - Planning posture:
 - Evidence maturity:
 - Questions selected:
@@ -200,6 +221,8 @@ flowchart TD
 - Rejected path A:
 - Rejected path B:
 - Rejected maturity route:
+- Project direction mode decision:
+- Promotional / brand-neutrality check:
 - Language / spec decision conflicts:
 - Developer / operator adoption assumptions:
 - Open assumptions to verify next:

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

@@ -5,14 +5,33 @@
   },
   "meta": {
     "roadmapVersion": "roadmap.v1",
-    "skillVersion": "5.0.0",
+    "skillVersion": "5.2.0",
     "status": "active",
     "lastUpdated": "2026-05-01",
     "currentFocusStage": "Stage 1"
   },
   "context": {
+    "projectDirectionMode": "",
+    "projectDirectionRationale": "",
+    "directionQuestionsSelected": [],
+    "directionQuestionsSkipped": [],
+    "directionGuardrailsApplied": [],
     "planningPosture": "",
     "evidenceMaturity": "",
+    "aiLeverageRouteLens": {
+      "realUserOrOperator": "",
+      "statusQuoWorkaround": "",
+      "humanTeamEffortForFullScope": "",
+      "ccAgentEffortForFullScope": "",
+      "aiCompressionRatio": "",
+      "completeLakeBoundary": "",
+      "oceanBoundary": "",
+      "scopeRecommendation": "sharp-wedge",
+      "firstSuccessSignal": "",
+      "killSignal": "",
+      "verdict": "needs-evidence",
+      "missingEvidence": []
+    },
     "canonicalTerms": [],
     "durableDecisionSources": []
   },

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

@@ -3,19 +3,20 @@
 ## Order
 
 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. 核心术语是否已有 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`
+1. 先判断 project direction mode：founder-business / internal-company / hackathon-demo / open-source-research / learning / side-project / infrastructure / recovery
+2. 用户是谁
+3. 今天靠什么笨办法活着
+4. 最强需求证据是什么
+5. 为什么现在必须解决
+6. deadline / capacity / dependency / distribution 约束是什么
+7. 当前最大的 adoption / trust / delivery 卡点是什么
+8. 核心术语是否已有 canonical definition，是否和现有 capability spec / roadmap decision 冲突
+9. 最窄突破口是什么
+10. 6-12 个月后会长成什么
+11. 给出 2-3 条路线图形状并明确推荐
+12. 冻结 1-3 个阶段，写 exit signal / kill signal / non-goals
+13. 画出 `RM dependency graph`，标出串行主链和 parallel-ready wave
+14. 标出哪些事项真的 ready for `cc-plan`
 
 ## Question Rules
 
@@ -25,11 +26,25 @@
 - 没证据时明确写 assumption
 - 用户没批准前，不把事项偷下放成 requirement
 
+## Project Direction Modes
+
+- `founder-business`: 问 demand reality、status quo、specific human、narrowest paid wedge、observed behavior、future fit。允许给创业行动建议，但必须 source-neutral：找具体用户、看真实使用、验证付费或强行为、缩小本周 wedge。禁止品牌广告、申请建议、推广链接和外部权威背书。
+- `internal-company`: 问 sponsor、最小可批准 demo、组织依赖、维护 owner、reorg 风险。不要写对外市场叙事。
+- `hackathon-demo`: 问 wow moment、demo path、fallback、时间盒。不要先设计长期平台。
+- `open-source-research`: 问替代品、可复现 benchmark、贡献者 first success、维护边界。不要套商业销售漏斗。
+- `learning`: 问要学会什么、最小练习闭环、反馈方式。不要让生产级架构遮住学习目标。
+- `side-project`: 问自己会不会反复用、最酷可分享版本、最快可用路径。不要强行商业化。
+- `infrastructure`: 问调用方、workaround、失败成本、迁移/回滚、复用边界。不要虚构用户访谈。
+- `recovery`: 问事故证据、最小可信修复、防回归、kill signal、信任恢复。不要扩张新功能。
+
+如果 direction mode 变了，回到 route selection 重新算，不要沿用前一组问题。
+
 ## Route Shapes
 
 - `wedge-first`: 先用一个窄切口打穿真实需求
 - `platform-first`: 先做后面几阶段都会反复复用的底座
 - `rescue-first`: 先解决 adoption、trust、delivery 里最大的卡点
+- `decompose-first`: 先拆多个可独立交付系统，再决定每个系统的路线
 
 ## Output Rules
 

package/.claude/skills/cc-roadmap/scripts/lib/roadmap-tracking/markdown.js

@@ -621,6 +621,20 @@ function renderParked(tracking) {
     .join('\n\n');
 }
 
+function renderProjectDirectionHandoff(tracking) {
+  const context = tracking.context || {};
+
+  return [
+    `- Project direction mode: ${formatBacklogValue(context.projectDirectionMode)}`,
+    `- Direction mode rationale: ${formatBacklogValue(context.projectDirectionRationale)}`,
+    `- Direction-specific questions selected: ${formatList(context.directionQuestionsSelected || [])}`,
+    `- Direction-specific questions skipped: ${formatList(context.directionQuestionsSkipped || [])}`,
+    `- Direction guardrails applied: ${formatList(context.directionGuardrailsApplied || [])}`,
+    `- Planning posture: ${formatBacklogValue(context.planningPosture)}`,
+    `- Evidence maturity: ${formatBacklogValue(context.evidenceMaturity)}`
+  ].join('\n');
+}
+
 function renderBacklogDocument({ backlogFile, trackingFile, tracking }) {
   const relativePath = path.relative(path.dirname(backlogFile), trackingFile).replace(/\\/g, '/');
   const displayPath = relativePath || path.basename(trackingFile);
@@ -651,6 +665,10 @@ function renderBacklogDocument({ backlogFile, trackingFile, tracking }) {
     `- Parallel-ready next wave: ${formatBacklogValue(tracking.dependencyHandoff.parallelReadyNextWave)}`,
     `- Notes on blockers: ${formatBacklogValue(tracking.dependencyHandoff.notesOnBlockers)}`,
     '',
+    '## Project Direction Handoff',
+    '',
+    renderProjectDirectionHandoff(tracking),
+    '',
     '## Ready For Req-Plan',
     '',
     renderReadyForReqPlan(tracking),

package/.claude/skills/cc-roadmap/scripts/lib/roadmap-tracking/schema.js

@@ -78,6 +78,11 @@ const DEFAULT_ROADMAP_STATE = {
     currentFocusStage: ''
   },
   context: {
+    projectDirectionMode: '',
+    projectDirectionRationale: '',
+    directionQuestionsSelected: [],
+    directionQuestionsSkipped: [],
+    directionGuardrailsApplied: [],
     planningPosture: '',
     evidenceMaturity: '',
     canonicalTerms: [],
@@ -282,6 +287,9 @@ function normalizeRoadmapState(raw = {}) {
     context: {
       ...DEFAULT_ROADMAP_STATE.context,
       ...context,
+      directionQuestionsSelected: normalizeStringList(context.directionQuestionsSelected),
+      directionQuestionsSkipped: normalizeStringList(context.directionQuestionsSkipped),
+      directionGuardrailsApplied: normalizeStringList(context.directionGuardrailsApplied),
       canonicalTerms: normalizeStringList(context.canonicalTerms),
       durableDecisionSources: normalizeStringList(context.durableDecisionSources)
     },