cc-devflow 4.5.6 → 4.5.8

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)
     },

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

@@ -1,5 +1,11 @@
 # CC-Simplify Skill Changelog
 
+## v1.4.1 - 2026-05-10
+
+- make `cc-simplify` itself the explicit trigger for automatic read-only subagent review in ClaudeCode and Codex environments
+- prefer ClaudeCode `Task` / subAgent support or Codex built-in `explorer` / `default` agents without requiring an extra user prompt
+- require a truthful fallback report when the host does not expose any subagent tool, instead of pretending subagents ran
+
 ## 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

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

@@ -1,7 +1,7 @@
 ---
 name: cc-simplify
-version: 1.4.0
-description: "Use when changed code needs a Codex-native simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
+version: 1.4.1
+description: "Use when changed code needs an automatic subagent-backed simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
 ---
 
 # CC-Simplify
@@ -35,21 +35,32 @@ ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
 3. 如果变更跨多个互不相关模块，先按模块分组；不要让一个 cleanup pass 变成大扫除。
 4. 只审当前 diff 新增或本次改动扩大后的坏味道。历史债只在它阻挡当前交付或被本次 diff 放大时进入清理范围。
 
-## Phase 2: Codex 智能体评审
+## Phase 2: 自动子智能体评审
 
-如果当前环境支持 Codex 多智能体，并且用户已经明确触发 `cc-simplify` 或要求并行评审，可以构建只读评审智能体。
+触发 `cc-simplify` 本身就构成用户对子智能体 / subAgent 评审的明确授权。不要要求用户在 `[$cc-simplify]` 之外再补一句“请开启子智能体”。
+
+只要当前宿主支持子智能体，必须自动启动只读评审智能体；主线程只负责汇总、验证 finding、实际修复和最终验证。
 
 ### 调度原则
 
-- Codex 中优先使用 `spawn_agent(agent_type="explorer")` 创建只读评审智能体。
-- 如果当前环境没有 `explorer`，使用默认智能体也必须在 prompt 里写明：只读审查，不编辑文件。
+- ClaudeCode 环境：使用可用的 `Task` / subAgent 机制自动创建只读评审 subAgent。
+- Codex App / Codex 工具环境：优先使用内置 `explorer` 子智能体做只读评审；不要假设 ClaudeCode 的 `Task` / `subAgent` 语义存在。
+- 在暴露 `spawn_agent` 工具的 Codex 环境里，使用 `spawn_agent(agent_type="explorer", fork_context=false, ...)`；如果没有 `explorer`，使用 `default` 也必须在 prompt 里写明：只读审查，不编辑文件。
+- `cc-simplify` 的触发就是对子智能体的明确请求；不要再等待用户二次授权。
+- 不依赖 repo-local `.codex/agents/*.toml` 自定义 agent 名称来完成核心流程。自定义 agent 可以作为增强，但主流程必须能依赖 Codex 内置 `explorer` / `default` 或宿主内置 subAgent 机制。
 - 只把只读评审交给智能体；主线程负责最终判断和实际编辑。
 - 每个智能体拿到同一份完整 diff、相关任务/设计/spec 路径、当前 repo 根目录。
 - 智能体不能改文件，只输出结构化 findings。
-- 如果没有多智能体能力，主线程按同样清单顺序执行。
-- 小 diff 不强制开智能体：少于约 50 行且只触碰单一文件时，主线程执行同一清单即可。
+- 如果当前运行时没有子智能体工具，或工具调用被上层策略禁止，主线程按同样清单顺序执行，并在报告里写 `Agents used: no (subagent tool unavailable)`；不要伪造子智能体结果。
+- 小 diff 也要尝试启动子智能体；如果资源或宿主限制不适合三路并行，至少启动一个合并维度的只读 reviewer。
 - 条件 specialist 只在对应 scope 出现时启用；不要为了“完整”启动无关评审。
 
+默认调度：
+
+- 大 diff / 多文件 diff：启动 Agent A、Agent B、Agent C 三个只读评审智能体。
+- 小 diff / 单文件 diff：至少启动一个 combined reviewer，覆盖 A/B/C 三组检查。
+- 命中 security / api-contract / release / frontend-performance 时，再启动对应 specialist；如果 specialist 发现 `critical`，再启动 Red Team 只读复查。
+
 智能体 prompt 必须自包含：
 
 ```text

package/CHANGELOG.md

@@ -9,6 +9,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [4.5.8] - 2026-05-11
+
+### Changed
+
+- Updated `cc-review` with a risk-lane review swarm profile so broad implementation and PR-landing reviews separate intent/regression, security/privacy, performance/reliability, and contracts/coverage findings before main-thread triage.
+- Added the PR Harness skill lane: `cc-next` selects roadmap-aware next work, `cc-dev` drives current-worktree PDCA/IDCA goals to a remote PR, `cc-pr-review` reviews remote PRs in a separate session, and `cc-pr-land` lands reviewed PRs with rebase-first main parity proof.
+
+## [4.5.7] - 2026-05-10
+
+### Changed
+
+- Added public `cc-review` as an optional deep review skill that branches between plan-stage and implementation-stage review, builds a stateful review plan, dispatches read-only reviewer subAgents when available, records per-node review ledger entries, checks in-scope code smells, and records Browser/Computer Use plus log evidence when UI or runtime behavior is involved.
+- Updated `cc-roadmap` and `cc-plan` with AI Leverage Route/Decision Lens gates that require real user/operator, status quo workaround, human-vs-agent effort, complete-lake boundary, ocean boundary, and boil-lake/sharp-wedge/needs-evidence/pivot verdicts before work becomes implementation-ready.
+- Updated `cc-plan` with an opt-in External Best-Practice Validation gate that records generalized search approval, source trust, repo-fit verdicts, and skip reasons in durable planning artifacts.
+- Updated `cc-plan` Decision Question options to require `A/B/C` lettered choices while keeping `D1` / `D2` as question IDs.
+
 ## [4.5.6] - 2026-05-08
 
 ### Changed

package/README.md

@@ -14,13 +14,42 @@ CC-DevFlow is a small, explicit workflow system for agent coding. It gives an AI
 ```text
 cc-roadmap
 
-PDCA: cc-plan        -> cc-do -> cc-check -> cc-act
-IDCA: cc-investigate -> cc-do -> cc-check -> cc-act
+PR Harness: cc-next -> cc-dev -> cc-pr-review -> cc-pr-land
+
+PDCA: cc-plan        -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
+IDCA: cc-investigate -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
+```
+
+```mermaid
+flowchart TD
+  Roadmap["cc-roadmap\nProduct direction and staged truth"] --> Next["cc-next\nPick next ready Goal Packet"]
+  Next --> Dev["cc-dev\nDrive current worktree to PR"]
+
+  Dev --> Route{"Route"}
+  Route -->|Feature or change| Plan["cc-plan\nFreeze scope and tasks"]
+  Route -->|Bug or regression| Investigate["cc-investigate\nFreeze root cause and repair boundary"]
+
+  Plan --> PlanReview["cc-review\nOptional plan review"]
+  Investigate --> PlanReview
+  PlanReview --> Do["cc-do\nImplement with evidence"]
+  Plan --> Do
+  Investigate --> Do
+
+  Do --> ImplReview["cc-review\nOptional implementation review"]
+  ImplReview --> Check["cc-check\nFresh verification verdict"]
+  Do --> Check
+  Check --> Act["cc-act\nCreate or update remote PR"]
+  Act --> PRReview["cc-pr-review\nSeparate PR review session"]
+  PRReview --> PRLand["cc-pr-land\nRebase, land, prove main parity"]
+  PRReview -->|Fixes required| Dev
+  PRLand --> Main["main\nLocal and remote parity"]
 ```
 
+![CC-DevFlow PR Harness visual workflow](./docs/assets/cc-devflow-pr-harness-en.svg)
+
 ## Why cc-devflow
 
-- **Small public surface**: six visible workflow skills plus a CLI for installation and platform adaptation.
+- **Small public surface**: core workflow skills, a PR Harness lane, one optional deep review skill, plus a CLI for installation and platform adaptation.
 - **Evidence before done**: implementation must pass through verification proof before shipping or handoff.
 - **Skill-first distribution**: the public contract lives in `.claude/skills/<skill>/SKILL.md` and `PLAYBOOK.md`, not in hidden runtime behavior.
 - **Multi-platform output**: install once, then adapt for Codex, Cursor, Qwen, Antigravity, and related agent environments.
@@ -56,16 +85,21 @@ Refresh every supported platform output:
 npx cc-devflow@latest adapt --cwd /path/to/your/project --all
 ```
 
-After installation, ask your agent to use the workflow skills directly. Start with `cc-roadmap` for product direction, use `cc-plan` for new work, use `cc-investigate` for bugs, then continue through `cc-do`, `cc-check`, and `cc-act`.
+After installation, ask your agent to use the workflow skills directly. Start with `cc-roadmap` for product direction. Use `cc-next` to select the next roadmap-aware target, `cc-dev` to drive the current worktree through PDCA or IDCA until a remote PR is opened, `cc-pr-review` to review that PR in a separate session, and `cc-pr-land` to land reviewed PRs into main. For manual core workflow work, use `cc-plan` for new work, use `cc-investigate` for bugs, optionally run `cc-review` on complex frozen plans or investigations, then continue through `cc-do`, optional implementation `cc-review`, `cc-check`, and `cc-act`.
 
 ## Workflow Skills
 
 | Skill | Use it when | Main output |
 | --- | --- | --- |
 | `cc-roadmap` | You need product direction, staged scope, or backlog order | `devflow/roadmap.json`, `devflow/ROADMAP.md`, deprecated `devflow/BACKLOG.md` |
+| `cc-next` | You need to pick the next roadmap-aware ready target from roadmap and issue truth | one Goal Packet for `cc-dev` |
+| `cc-dev` | A selected objective should be driven in the current worktree to a remote PR | PDCA/IDCA artifacts plus a PR or handoff |
 | `cc-plan` | A feature or change needs scope, design, and task freezing | `planning/design.md`, `planning/tasks.md`, `task-manifest.json` |
 | `cc-investigate` | A bug needs symptom, reproduction, root cause, and repair boundary | `planning/analysis.md`, `planning/tasks.md`, `task-manifest.json` |
 | `cc-do` | Planned or investigated work needs implementation | code, tests, checkpoints, scratch runtime |
+| `cc-review` | Complex plans, investigations, or diffs need optional deep multi-round review before implementation or verification | `cc-review-report.md`, optional `cc-review-findings.json` |
+| `cc-pr-review` | A remote PR needs an independent review session before landing | PR review packet, findings, and landing verdict |
+| `cc-pr-land` | Reviewed PRs need rebase-first landing into main with parity proof | integrated main plus local/remote parity evidence |
 | `cc-check` | Work needs fresh verification evidence | `report-card.json` |
 | `cc-act` | Verified work needs a PR, local handoff, release note, or closeout | one final handoff file |
 
@@ -82,6 +116,8 @@ Canonical language and durable decisions stay inside cc-devflow-native sources:
 
 `cc-plan` freezes more implementation decisions before `cc-do` starts. Non-trivial plans compare minimal viable and ideal architecture options, full designs include decision horizon plus error/rescue mapping, and test-first plans record test framework evidence, public test seams, spec-style test names, public verification paths, behavior assertions, mock boundaries, coverage quality, mandatory regression tests, interface depth, Green minimality guards, refactor candidates, and vertical tracer-bullet slices when existing behavior changes. Before handoff, `cc-plan` and `cc-investigate` also reconcile the source roadmap item so RM status, REQ/FIX binding, progress, and spec diagnosis do not drift from the frozen change artifacts.
 
+`cc-review` is optional and deeper than `cc-check`. It can run immediately after `cc-plan` / `cc-investigate` to review the frozen plan or root-cause contract, or after `cc-do` to review the implementation. It first reads prior review records and current git/artifact delta, writes a review plan, then checks review nodes one by one with ledger entries. When the host supports subagents, selected nodes can be dispatched to independent read-only reviewers so strategy, engineering, design, DX, smell, test, and runtime checks do not share one contaminated context. Broad implementation reviews can use separate risk lanes for intent/regression, security/privacy, performance/reliability, and contracts/coverage before the main thread triages raw findings. Plan reviews borrow strategy/design/engineering/DX methods through progressive references, while implementation reviews inspect diff scope, code smells, tests, UI/runtime behavior, Browser/Computer Use evidence, and logs when applicable. Findings route back to `cc-plan` or `cc-do`; clean implementation reviews continue to `cc-check`.
+
 ## Verification And Ship Gates
 
 `cc-check` now treats QA as a feedback-loop problem, not only a green-test problem. Bugfix and behavior work records the loop used to prove reality, expected versus actual behavior, reproduction steps, test boundary quality, and architecture follow-ups when no clean public test seam exists.
@@ -117,9 +153,14 @@ node bin/cc-devflow-cli.js adapt --cwd /tmp/example-project --platform codex
 
 ```bash
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-roadmap
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-next
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-dev
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-plan
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-investigate
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-do
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-land
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-check
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-act
 ```
@@ -182,9 +223,14 @@ Each shipped skill keeps its runtime contract local:
 The currently distributed skill folders are:
 
 - `.claude/skills/cc-roadmap/`
+- `.claude/skills/cc-next/`
+- `.claude/skills/cc-dev/`
 - `.claude/skills/cc-plan/`
 - `.claude/skills/cc-investigate/`
 - `.claude/skills/cc-do/`
+- `.claude/skills/cc-review/`
+- `.claude/skills/cc-pr-review/`
+- `.claude/skills/cc-pr-land/`
 - `.claude/skills/cc-check/`
 - `.claude/skills/cc-act/`
 - `.claude/skills/cc-spec-init/`
@@ -218,6 +264,14 @@ npm run verify:publish
 
 The main contributor guide is [`CONTRIBUTING.md`](./CONTRIBUTING.md). It explains the public surface rules, local CLI smoke tests, documentation rules, and PR expectations.
 
+## Discussion
+
+Scan the QR code to join the cc-devflow WeChat group for feedback, usage notes, and feature requests.
+
+<img src="./docs/assets/wechat-group-qr.jpg" alt="cc-devflow WeChat group QR code" width="320" />
+
+If the QR code expires, please open an issue so the maintainers can refresh it.
+
 ## Community
 
 - Star the project if the workflow is useful: [GitHub stars](https://github.com/Dimon94/cc-devflow/stargazers)