cc-devflow 4.5.14 → 4.5.16

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

@@ -1,6 +1,6 @@
 ---
 name: cc-investigate
-version: 1.6.2
+version: 1.6.5
 description: Use when a bug, regression, broken task, or unexpected behavior needs root-cause investigation before coding resumes.
 triggers:
   - 帮我查这个 bug
@@ -15,6 +15,8 @@ reads:
   - docs/guides/project-postmortem.md
   - assets/TASKS_TEMPLATE.md
   - ../cc-dev/scripts/resolve-cc-devflow.sh
+  - ../cc-dev/scripts/prepare-change-worktree.sh
+  - ../cc-dev/scripts/ensure-work-branch.sh
   - ../cc-roadmap/scripts/locate-roadmap-item.sh
   - ../cc-roadmap/scripts/sync-roadmap-progress.sh
 writes:
@@ -25,9 +27,10 @@ effects:
   - roadmap progress sync when a source item exists
   - Git commit after the Investigate stage is complete
 entry_gate:
-  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require query workflow-context next-change-key config`.
+  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require next-change-key config`.
   - Assign a FIX change key through `next-change-key --prefix FIX --description "<short bug name>"`.
-  - Enforce the Worktree Branch Contract before writing `task.md`.
+  - Prepare an isolated FIX worktree before writing `task.md`; keep the main checkout on `main`.
+  - Enforce the Worktree Branch Contract inside the returned FIX worktree.
   - Reproduce or build the closest honest feedback loop before naming root cause.
   - Classify the investigation mode before tracing: reproduce-first, diff-trace, boundary-probe, backward-trace, reference-compare, condition-wait, workflow-forensics, performance, or diagnose-only.
   - Search relevant code, logs, recent history, and project postmortems before declaring the bug novel.
@@ -35,6 +38,7 @@ entry_gate:
 exit_criteria:
   - "`task.md#Root Cause Contract` proves symptom site, first bad state, violated contract, original trigger, counterfactual proof, and escape reason."
   - "`task.md#Root Cause Contract` records investigation mode, feedback loop, evidence chain, tested hypotheses, boundary/backward/reference evidence when applicable, correct test seam, and diagnose-only boundary when applicable."
+  - "`task.md#Root Cause Contract` contains ASCII Branch Chain Analysis trees for problem chain, solution chain, and impact chain, tracing upstream root cause and downstream blast radius to the deepest proven prompt/code/provider/data source; tree connector characters stay ASCII while node text follows the configured output language."
   - "`task.md` contains the repair tasks needed by `cc-do`."
   - "Evidence gaps produce Evidence Request, diagnose-only, or reroute tasks instead of fake repair tasks."
   - "No process file is created beyond `task.md`."
@@ -74,12 +78,13 @@ NO REPAIR WITHOUT A FROZEN ROOT-CAUSE CONTRACT
 ## Investigation Loop
 
 1. Classify：复现优先、diff trace、boundary probe、flaky、performance、workflow forensics 或 diagnose-only。
-2. Reproduce：用测试、脚本、日志、浏览器路径或最小 harness 证明同一个症状。
-3. Trace：找到 first bad state，而不是只给 symptom guard。
-4. Hypothesize：列候选，写证伪方法，逐个打掉。
-5. Prove：完成 Root Cause Proof Ladder。
-6. Freeze：把根因、修复边界、测试 seam、allowed/forbidden files 写进 `task.md`。
-7. Commit：提交 Investigate 阶段，再交给 `cc-do`。
+2. Anchor：分配 FIX change key 后运行 `../cc-dev/scripts/prepare-change-worktree.sh --change-key <FIX-...>`，从主 checkout 创建或复用独立 FIX worktree；进入返回的 `WORKTREE_PATH` 后必须得到 exact-case `FIX/...` 分支。大小写碰撞或目标分支不匹配都是 setup blocker。
+3. Reproduce：用测试、脚本、日志、浏览器路径或最小 harness 证明同一个症状。
+4. Trace：找到 first bad state，而不是只给 symptom guard。
+5. Hypothesize：列候选，写证伪方法，逐个打掉。
+6. Prove：完成 Root Cause Proof Ladder。
+7. Freeze：把根因、ASCII Branch Chain Analysis、修复边界、测试 seam、allowed/forbidden files 写进 `task.md`。
+8. Commit：提交 Investigate 阶段，再交给 `cc-do`。
 
 ## Investigation Modes
 
@@ -111,6 +116,78 @@ NO REPAIR WITHOUT A FROZEN ROOT-CAUSE CONTRACT
 9. Correct Test Seam：说明 regression test 是否覆盖真实触发链；只能测私有实现时，先记录设计缺口或 reroute。
 10. Repair Boundary：affected module、allowed files、forbidden files、blast radius、split-or-reroute decision。
 
+## ASCII Branch Chain Analysis
+
+`task.md#Root Cause Contract` 必须包含 ASCII 分叉树代码块。调查要先向上追坏状态来源，再向下追影响面，最后把修复路径也画出来。
+
+Language rule:
+
+- Tree structure tokens must stay ASCII: `|--`, `` `-- ``, `|`, spaces, and plain punctuation.
+- Node labels, placeholder text, explanations, and evidence summaries must follow `Output language` in `task.md`.
+- If `Output language` is unset, use the current conversation language and record the assumption.
+- Do not hard-code English labels such as `Problem Chain` when the configured output language is not English.
+- Use the Label table as the shared source for chain titles, node labels, and placeholder text.
+
+Label table:
+
+| Semantic slot | en | zh-CN |
+| --- | --- | --- |
+| problemChain | Problem Chain | 问题链 |
+| symptomMarker | SYMPTOM | 症状 |
+| failureSite | Failure site | 失败位置 |
+| directCaller | direct caller | 直接调用方 |
+| badValueState | bad value/state | 错误值或状态 |
+| upstreamOrigin | Upstream origin | 上游源头 |
+| codeSource | code source | 代码来源 |
+| promptSource | prompt source | 提示词来源 |
+| trigger | trigger | 触发条件 |
+| rejectedSymptomFix | Rejected symptom fix | 已拒绝的症状修补 |
+| solutionChain | Solution Chain | 解决链 |
+| fixMarker | FIX | 修复 |
+| firstBadStateRepair | First bad state repair | 首个错误状态修复 |
+| contractRestored | Contract restored | 恢复的合同 |
+| regressionSeam | Regression seam | 回归缝隙 |
+| escapePrevention | Escape prevention | 逃逸预防 |
+| impactChain | Impact Chain | 影响链 |
+| blastRadiusMarker | BLAST RADIUS | 影响范围 |
+| upstreamPreserved | Upstream preserved | 保持不变的上游 |
+| downstreamAffected | Downstream affected | 受影响下游 |
+| riskBranch | Risk branch | 风险分支 |
+| verificationBranch | Verification branch | 验证分支 |
+
+```text
+<problemChain>
+<symptomMarker>: <observed failure>
+|-- <failureSite>: <file / command / UI / artifact>
+|   |-- <directCaller>: <caller>
+|   `-- <badValueState>: <first observed bad state>
+|-- <upstreamOrigin>: <earliest proven creator>
+|   |-- <codeSource>: <file / function / config>
+|   |-- <promptSource>: <prompt / instruction / provider contract, or N/A>
+|   `-- <trigger>: <input / event / race / migration>
+`-- <rejectedSymptomFix>: <why guard-at-failure is insufficient>
+
+<solutionChain>
+<fixMarker>: <minimal repair>
+|-- <firstBadStateRepair>: <change>
+|-- <contractRestored>: <invariant>
+|-- <regressionSeam>: <test / harness / replay>
+`-- <escapePrevention>: <guard / assertion / operator check>
+
+<impactChain>
+<blastRadiusMarker>: <affected behavior>
+|-- <upstreamPreserved>: <contracts that must stay unchanged>
+|-- <downstreamAffected>: <callers / artifacts / docs / release>
+|-- <riskBranch>: <possible regression>
+`-- <verificationBranch>: <commands / evidence>
+```
+
+规则：
+
+- `Upstream origin` 必须追到最早被证据支持的制造点；如果最早点可能是提示词，必须写出精确 prompt / provider 合同位置。
+- `Impact Chain` 必须覆盖下游调用方、artifact、operator 或用户可见行为；只列修复文件不合格。
+- 缺 L2、L4 或 L5 时，树里写 `unknown -> Evidence Request`，并进入 diagnose-only / reroute。
+
 ## Root Cause Proof Ladder
 
 - L1 Symptom Site

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

@@ -96,6 +96,62 @@ Correct Test Seam:
 - Mock boundary:
 - Private implementation assertions avoided:
 
+ASCII Branch Chain Analysis:
+Language rule: keep connector tokens ASCII; write node labels and evidence text in `Output language`.
+
+Label table:
+| Semantic slot | en | zh-CN |
+| --- | --- | --- |
+| problemChain | Problem Chain | 问题链 |
+| symptomMarker | SYMPTOM | 症状 |
+| failureSite | Failure site | 失败位置 |
+| directCaller | direct caller | 直接调用方 |
+| badValueState | bad value/state | 错误值或状态 |
+| upstreamOrigin | Upstream origin | 上游源头 |
+| codeSource | code source | 代码来源 |
+| promptSource | prompt source | 提示词来源 |
+| trigger | trigger | 触发条件 |
+| rejectedSymptomFix | Rejected symptom fix | 已拒绝的症状修补 |
+| solutionChain | Solution Chain | 解决链 |
+| fixMarker | FIX | 修复 |
+| firstBadStateRepair | First bad state repair | 首个错误状态修复 |
+| contractRestored | Contract restored | 恢复的合同 |
+| regressionSeam | Regression seam | 回归缝隙 |
+| escapePrevention | Escape prevention | 逃逸预防 |
+| impactChain | Impact Chain | 影响链 |
+| blastRadiusMarker | BLAST RADIUS | 影响范围 |
+| upstreamPreserved | Upstream preserved | 保持不变的上游 |
+| downstreamAffected | Downstream affected | 受影响下游 |
+| riskBranch | Risk branch | 风险分支 |
+| verificationBranch | Verification branch | 验证分支 |
+
+```text
+<problemChain>
+<symptomMarker>: <observed failure>
+|-- <failureSite>: <file / command / UI / artifact>
+|   |-- <directCaller>: <caller>
+|   `-- <badValueState>: <first observed bad state>
+|-- <upstreamOrigin>: <earliest proven creator>
+|   |-- <codeSource>: <file / function / config>
+|   |-- <promptSource>: <prompt / instruction / provider contract, or N/A>
+|   `-- <trigger>: <input / event / race / migration>
+`-- <rejectedSymptomFix>: <why guard-at-failure is insufficient>
+
+<solutionChain>
+<fixMarker>: <minimal repair>
+|-- <firstBadStateRepair>: <change>
+|-- <contractRestored>: <invariant>
+|-- <regressionSeam>: <test / harness / replay>
+`-- <escapePrevention>: <guard / assertion / operator check>
+
+<impactChain>
+<blastRadiusMarker>: <affected behavior>
+|-- <upstreamPreserved>: <contracts that must stay unchanged>
+|-- <downstreamAffected>: <callers / artifacts / docs / release>
+|-- <riskBranch>: <possible regression>
+`-- <verificationBranch>: <commands / evidence>
+```
+
 Verification:
 -
 
@@ -114,7 +170,7 @@ Risk / Escalate If:
 
 Codex / ClaudeCode must treat this `task.md` as the only repair contract.
 
-- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `query workflow-context` and `next-change-key`, stop blocked.
+- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `next-change-key`, stop blocked.
 - Do not generate process files beyond this `task.md`.
 - Complete tasks with `scripts/mark-task-complete.sh --tasks devflow/changes/<change-key>/task.md --task <task-id>`.
 - Stage commit rule: when PDCA or IDCA finishes in the current environment, commit the completed stage to Git.

package/.claude/skills/cc-investigate/references/investigation-contract.md

@@ -26,6 +26,7 @@
 - repair boundary
 - correct test seam
 - verification command
+- ASCII branch-chain connector tokens stay ASCII, but labels, evidence, and explanatory text follow `Output language`.
 
 ## Investigation Modes
 

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

@@ -1,5 +1,28 @@
 # CC-Plan Skill Changelog
 
+## v3.10.7 - 2026-05-17
+
+- require new plans to prepare an isolated change worktree before writing `task.md`
+- keep the main checkout bound to `main` instead of treating it as a branch-switching work surface
+
+## v3.10.6 - 2026-05-17
+
+- require ASCII branch-chain node labels and evidence text to follow `Output language` while keeping tree connector tokens ASCII
+- replace hard-coded English branch-chain examples with an `en` / `zh-CN` label table and semantic slots
+
+## v3.10.5 - 2026-05-17
+
+- require ASCII Branch Chain Analysis in `task.md#Contract Summary` so requirement plans trace upstream sources, deepest affected code or prompt/provider layer, downstream business impact, and verification seams
+- add the branch-chain section to the plan task template
+
+## v3.10.4 - 2026-05-14
+
+- require product discovery before engineering planning
+
+## v3.10.3 - 2026-05-14
+
+- add Second-Move Review before plan approval
+
 ## v3.10.2 - 2026-05-14
 
 - restore the planning flow that was over-pruned during artifact minimization: requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, and final approval

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

@@ -14,10 +14,12 @@
 2. Git commits record Plan completion; do not create process files beyond `task.md`.
 3. Current branch must bind to the full change key before writing durable output.
 4. The task list must let `cc-do` continue without chat memory.
-5. Ask only decisions that change scope, design, task split, interface, or verification; otherwise choose from repo evidence.
-6. Preserve planning thought inside `task.md#Contract Summary`: requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, and final approval.
-7. Non-trivial plans compare `minimal viable` and `ideal architecture`; tiny plans still record why the short path is enough.
-8. User-facing decisions use `D<N>` questions with recommendation, options, impact, and STOP.
+5. Ask only decisions that change product value, product shape, scope, design, task split, interface, or verification; otherwise choose from repo evidence.
+6. Product/creative questions come before engineering questions when worth or shape is unclear.
+7. Preserve planning thought inside `task.md#Contract Summary`: product/creative discovery, requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, Second-Move Review, and final approval.
+8. Non-trivial plans complete Second-Move Review: first good move, simpler move, better architecture, selected move, and rejected tradeoff. Tiny plans still record why the short path is enough.
+9. Non-trivial plans use at least two confirmation rounds unless source evidence already answers one: product/creative confirmation, then engineering/task confirmation.
+10. User-facing decisions use `D<N>` questions with recommendation, options, impact, and STOP.
 
 ## Required Task Fields
 
@@ -37,10 +39,11 @@ Each task block includes:
 `task.md#Contract Summary` includes:
 
 - Source handoff and repo evidence
+- Product/creative discovery: worth doing, desired product shape, narrowest wedge, 10x/better version, do-nothing consequence
 - Requirement reality
 - Decision questions and answers
 - Planning flow table
-- Minimal viable / ideal architecture comparison when non-trivial
+- Second-Move Review when non-trivial
 - Approved direction and non-goals
 - User stories and edge stories
 - Engineering review gate

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

@@ -1,6 +1,6 @@
 ---
 name: cc-plan
-version: 3.10.2
+version: 3.10.7
 description: Use when a requirement, roadmap item, or bug needs scope clarification, design decisions, and executable task breakdown before coding starts.
 triggers:
   - 帮我规划这个需求
@@ -15,6 +15,8 @@ reads:
   - assets/TASKS_TEMPLATE.md
   - references/planning-contract.md
   - ../cc-dev/scripts/resolve-cc-devflow.sh
+  - ../cc-dev/scripts/prepare-change-worktree.sh
+  - ../cc-dev/scripts/ensure-work-branch.sh
   - ../cc-roadmap/scripts/locate-roadmap-item.sh
   - ../cc-roadmap/scripts/sync-roadmap-progress.sh
 writes:
@@ -25,16 +27,19 @@ effects:
   - roadmap progress sync when a source item exists
   - Git commit after the Plan stage is complete
 entry_gate:
-  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require query workflow-context next-change-key config` before workflow commands.
+  - Resolve the CLI with `../cc-dev/scripts/resolve-cc-devflow.sh require next-change-key config` before workflow commands.
   - Assign a canonical REQ/FIX change key through `next-change-key` before writing `task.md`.
-  - Enforce the Worktree Branch Contract immediately after the change key exists.
+  - Prepare an isolated change worktree immediately after the change key exists; keep the main checkout on `main`.
+  - Enforce the Worktree Branch Contract inside the returned change worktree before writing `task.md`.
   - Read repo evidence before asking the user: roadmap handoff, specs, relevant code/tests/docs, recent commits, and existing task truth when present.
-  - Run the planning flow before task generation: requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, and final approval.
+  - Run the planning flow before task generation: product/creative discovery, requirement reality, system shape, interface/data contract, abstraction boundary, execution architecture, task contract, Second-Move Review, and final approval.
   - Ask with the Decision Question Protocol when the answer changes scope, design, implementation boundary, or verification.
 exit_criteria:
   - "`task.md#Contract Summary` states the approved solution, non-goals, frozen decisions, work branch, user stories, decision questions, planning-flow results, review gate, verification expectations, and open assumptions."
+  - "`task.md#Contract Summary` contains an ASCII Branch Chain Analysis for requirement impact and business impact, tracing upstream sources, current code path, deepest affected layer, downstream blast radius, and prompt/provider contracts when involved; tree connector characters stay ASCII while node text follows the configured output language."
   - "`task.md` contains executable task blocks generated from `assets/TASKS_TEMPLATE.md`."
-  - "Non-trivial plans compare `minimal viable` and `ideal architecture` before approval."
+  - "Non-trivial plans complete product/creative discovery before engineering design: worth doing, desired product shape, narrowest wedge, 10x/better version, and do-nothing consequence."
+  - "Non-trivial plans complete Second-Move Review before approval: first good move, simpler move, better architecture, selected move, and rejected tradeoff."
   - "User decisions that changed the plan were asked as D<N> questions and recorded in `task.md`."
   - "No process file is created beyond `task.md`."
   - "Source roadmap progress is synced or explicitly skipped in the final response."
@@ -60,12 +65,13 @@ tool_budget:
 
 ## Operating Contract
 
-1. 先用 resolver 找到当前仓库的 `cc-devflow`，并确认支持 `query workflow-context`、`next-change-key`、`config`。
+1. 先用 resolver 找到当前仓库的 `cc-devflow`，并确认支持 `next-change-key`、`config`。
 2. 用 `next-change-key --prefix REQ|FIX --description "..."` 生成 `changeId` 和完整 `changeKey`，不要手动扫描编号。
-3. 分配 change key 后立刻锚定分支：`REQ-003-copy-link` 对应 `REQ/003-copy-link`，`FIX-014-auth-race` 对应 `FIX/014-auth-race`。当前在 default branch 时停止并报告 setup blocker。
-4. 写 task blocks 前先确认方案。tiny 计划仍要过 planning flow，只是更短。
-5. `task.md` 必须包含 `Contract Summary`、决策问题、planning flow、review gate、任务列表、验证命令、完成证据、禁止重决策事项和阶段 commit 要求。
-6. 完成 Plan 后提交 Git commit。下一阶段从 Git history 和 `task.md` 恢复，不靠过程文件。
+3. 分配 change key 后立刻运行 `../cc-dev/scripts/prepare-change-worktree.sh --change-key <REQ/FIX-...>`，从主 checkout 创建或复用独立 change worktree；主目录必须继续绑定 `main`。
+4. 进入脚本返回的 `WORKTREE_PATH` 后，再由 `../cc-dev/scripts/ensure-work-branch.sh --change-key <REQ/FIX-...>` 锚定 exact-case 分支：`REQ-003-copy-link` 对应 `REQ/003-copy-link`，`FIX-014-auth-race` 对应 `FIX/014-auth-race`。大小写碰撞或目标分支不匹配都是 setup blocker。
+5. 写 task blocks 前先确认方案。tiny 计划仍要过 planning flow，只是更短。
+6. `task.md` 必须包含 `Contract Summary`、ASCII Branch Chain Analysis、决策问题、planning flow、review gate、任务列表、验证命令、完成证据、禁止重决策事项和阶段 commit 要求。
+7. 完成 Plan 后提交 Git commit。下一阶段从 Git history 和 `task.md` 恢复，不靠过程文件。
 
 ```bash
 DEVFLOW=".claude/skills/cc-dev/scripts/resolve-cc-devflow.sh"
@@ -76,8 +82,11 @@ bash "$DEVFLOW" config resolve --format policy
 
 - 用最小可逆方案解决真实需求，不扩张到假想未来。
 - 缺证据就写 assumption，不伪装成事实。
-- 非 trivial 方案比较 `minimal viable` 和 `ideal architecture`，但推荐必须落到当前仓库可执行边界。
+- 工程计划前先做产品/创意确认：这个问题值不值得做，用户想得到什么体验，最窄可交付楔子是什么，10x / better version 是什么，不做会损失什么。
+- 非 trivial 计划至少经过两轮用户确认：先确认产品价值和形态，再确认工程方案和任务合同；只有 roadmap / spec 已经给出等价证据时才能记录 skip reason。
+- 第一手好方案不能直接冻结；非 trivial 计划必须过 Second-Move Review：先写 first good move，再找 simpler move 和 better architecture，最后选择一个当前可执行的 move。
 - 计划先做上下文和设计判断，再拆 task；不能把架构、接口、字段、测试缝隙留给 `cc-do` 猜。
+- 需求链路必须画成 ASCII 分叉树：从用户需求追到现有入口、调用方、状态/数据流、最深底层影响点，再向下游展开业务影响、风险和验证面。
 - 用户视角必须清楚：真实用户 / operator、status quo、最痛失败场景、最小成功信号和非目标。
 - 行为变更任务按 tracer bullet 写：`[TEST] -> [IMPL] -> [REFACTOR]`，不要水平切层。
 - 每个任务写清目标、文件、依赖、TDD phase、读什么、怎么验证、完成证据。
@@ -87,19 +96,81 @@ bash "$DEVFLOW" config resolve --format policy
 
 先把调查和引导结果写进 `task.md#Contract Summary`，再生成任务。不要把这些内容拆成其它过程文件。
 
-1. Requirement Reality：确认真实用户 / operator、当前 workaround、最痛失败场景、最小成功信号、非目标。
-2. System Shape：确认现有代码链路、模块归属、状态 / 数据流、复用点、边界外系统和必须保留的不变量。
-3. Interface / Data Contract：确认 public interface、调用方、输入输出、关键字段、错误形态、权限 / 边界和命名来源。
-4. Abstraction Boundary：确认复杂度藏在哪个模块，哪些抽象被拒绝，哪些公共方法必须保持小而深。
-5. Execution Architecture：确认 foundation、core logic、integration、polish/tests 阶段的冻结决策、文件职责、耦合风险和失败恢复。
-6. Task Contract：确认每条 tracer bullet 的 user / edge story、Red test name、public seam、Green minimality guard、refactor candidates 和 2-5 分钟任务粒度。
-7. Final Approval：展示冻结方案和任务合同摘要；用户批准前不生成执行 task blocks。
+1. Product / Creative Discovery：确认这个问题值不值得做、目标体验、最窄楔子、10x / better version、do-nothing consequence；证据不足时先问用户，不先谈实现。
+2. Requirement Reality：确认真实用户 / operator、当前 workaround、最痛失败场景、最小成功信号、非目标。
+3. System Shape：确认现有代码链路、模块归属、状态 / 数据流、复用点、边界外系统和必须保留的不变量。
+4. Interface / Data Contract：确认 public interface、调用方、输入输出、关键字段、错误形态、权限 / 边界和命名来源。
+5. Abstraction Boundary：确认复杂度藏在哪个模块，哪些抽象被拒绝，哪些公共方法必须保持小而深。
+6. Execution Architecture：确认 foundation、core logic、integration、polish/tests 阶段的冻结决策、文件职责、耦合风险和失败恢复。
+7. Task Contract：确认每条 tracer bullet 的 user / edge story、Red test name、public seam、Green minimality guard、refactor candidates 和 2-5 分钟任务粒度。
+8. Second-Move Review：记录 first good move、simpler move、better architecture、selected move 和 rejected tradeoff；tiny 计划可压成一句，非 trivial 计划必须说明为什么没有选择另一个好走法。
+9. Final Approval：展示冻结方案和任务合同摘要；用户批准前不生成执行 task blocks。
+
+`tiny-design` 可以把每轮压成一句话；`full-design` 必须保留足够证据让执行者不二次设计。任一轮 `blocked` 时，只能问一个 blocking question、拆回 roadmap / 多个 REQ/FIX，或记录用户明确接受的人工边界。非 trivial 计划的产品/创意确认和工程方案确认必须分成至少两次确认，不能一次性把所有问题塞给用户。
+
+## ASCII Branch Chain Analysis
+
+`task.md#Contract Summary` 必须包含一个 ASCII 分叉树代码块。它不是插图，是执行合同的一部分。
+
+Language rule:
+
+- Tree structure tokens must stay ASCII: `|--`, `` `-- ``, `|`, spaces, and plain punctuation.
+- Node labels, placeholder text, explanations, and evidence summaries must follow `Output language` in `task.md`.
+- If `Output language` is unset, use the current conversation language and record the assumption.
+- Do not hard-code English labels such as `Requirement Impact Chain` when the configured output language is not English.
+- Use the Label table as the shared source for chain titles, node labels, and placeholder text.
+
+Label table:
+
+| Semantic slot | en | zh-CN |
+| --- | --- | --- |
+| requirementChain | Requirement Impact Chain | 需求影响链 |
+| requirementMarker | REQ | 需求 |
+| upstreamSource | Upstream source | 上游来源 |
+| currentCodePath | Current code path | 当前代码路径 |
+| caller | caller | 调用方 |
+| dataOrState | data or state | 数据或状态 |
+| deepestAffectedLayer | deepest affected layer | 最深影响层 |
+| requiredChange | Required change | 必要变更 |
+| verificationSeam | Verification seam | 验证缝隙 |
+| businessChain | Business Impact Chain | 业务影响链 |
+| outcomeMarker | OUTCOME | 结果 |
+| directBehaviorImpact | Direct behavior impact | 直接行为影响 |
+| downstreamImpact | Downstream impact | 下游影响 |
+| riskBranch | Risk branch | 风险分支 |
+| nonGoalBranch | Non-goal branch | 非目标分支 |
 
-`tiny-design` 可以把每轮压成一句话；`full-design` 必须保留足够证据让执行者不二次设计。任一轮 `blocked` 时，只能问一个 blocking question、拆回 roadmap / 多个 REQ/FIX，或记录用户明确接受的人工边界。
+```text
+<requirementChain>
+<requirementMarker>: <user-visible change>
+|-- <upstreamSource>: <roadmap / issue / user request / existing task>
+|-- <currentCodePath>: <entry>
+|   |-- <caller>: <file / command / UI / API>
+|   |-- <dataOrState>: <field / config / artifact>
+|   `-- <deepestAffectedLayer>: <module / prompt / provider contract / storage>
+|-- <requiredChange>: <smallest behavior delta>
+`-- <verificationSeam>: <public test / command / artifact>
+
+<businessChain>
+<outcomeMarker>: <operator / user value>
+|-- <directBehaviorImpact>: <what changes for user>
+|-- <downstreamImpact>: <consumers / docs / examples / release>
+|-- <riskBranch>: <regression / migration / support / cost>
+`-- <nonGoalBranch>: <explicitly not changed>
+```
+
+规则：
+
+- 先向上追来源，再向下追影响面；不要只写目标文件列表。
+- 必须找到“最深底层会影响的链路”：数据模型、状态机、CLI/runtime、prompt、provider contract、存储或外部边界。
+- 若需求影响提示词、agent 指令、provider 参数、生成 artifact，树里必须写出精确 prompt/provider 合同位置。
+- 没有证据的分支写 `unknown -> Evidence Request`，不能伪装成已确认。
 
 ## Decision Question Protocol
 
 只在答案会改变范围、方案、接口、任务切分或验证口径时提问。能从 repo evidence、roadmap、spec、测试或 git history 确认的，不问用户。
+提问前先做一次 Second-Move Review：这个问题是否能由 repo evidence 回答，是否把用户拉进实现细节，是否有更高质量的问题能一次冻结更多下游决策。
+产品/创意问题优先于工程问题。若“值不值得做”或“做成什么样”仍不清楚，只问产品/创意层 D<N>；不要提前问文件、接口、字段、测试实现。
 
 固定格式：
 
@@ -131,7 +202,7 @@ STOP: wait for the user answer before continuing.
 
 1. Existing leverage map：每个子问题先映射到现有代码、脚本、spec、模板或测试。
 2. Scope challenge：超过 8 个文件、2 个新 service/class、或跨模块连锁时，说明为什么不是过度设计。
-3. Option role check：非 trivial 方案比较 `minimal viable`、`ideal architecture`，必要时加 `hybrid`。
+3. Second-Move Review：非 trivial 方案必须比较 first good move、simpler move、better architecture，并说明 selected move 与 rejected tradeoff。
 4. Domain language check：核心名词、文件名、测试名、任务标题对齐项目真相；没有来源就写 assumption。
 5. Interface depth check：公共面小而深，复杂度藏进模块内部，边界 adapter 是具体操作而不是 generic catch-all。
 6. Test seam check：Red 任务从公共接口、调用方流程或用户可见路径证明行为；不要测私有实现细节。

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

@@ -26,6 +26,14 @@ Source Handoff:
 - Existing leverage:
 - Canonical language:
 
+Product / Creative Discovery:
+- Worth doing because:
+- Desired product shape:
+- Narrowest wedge:
+- 10x / better version:
+- Do-nothing consequence:
+- Product confirmation rounds:
+
 Requirement Reality:
 - User / operator:
 - Status quo workaround:
@@ -41,19 +49,22 @@ Decision Questions:
 Planning Flow:
 | Round | Status | Evidence / decision | Opens task? |
 |-------|--------|---------------------|-------------|
+| Product / Creative Discovery | confirmed |  |  |
 | Requirement Reality | confirmed |  |  |
 | System Shape | confirmed |  |  |
 | Interface / Data Contract | confirmed |  |  |
 | Abstraction Boundary | confirmed |  |  |
 | Execution Architecture | confirmed |  |  |
 | Task Contract | confirmed |  |  |
+| Second-Move Review | confirmed |  |  |
 | Final Approval | confirmed |  | yes |
 
-Options:
-- Minimal viable:
-- Ideal architecture:
-- Recommended:
-- Why not the other option:
+Second-Move Review:
+- First good move:
+- Simpler move:
+- Better architecture:
+- Selected move:
+- Rejected tradeoff:
 
 Approved Direction:
 -
@@ -71,6 +82,47 @@ Engineering Review Gate:
 - Mock boundary:
 - Feedback loop:
 
+ASCII Branch Chain Analysis:
+Language rule: keep connector tokens ASCII; write node labels and evidence text in `Output language`.
+
+Label table:
+| Semantic slot | en | zh-CN |
+| --- | --- | --- |
+| requirementChain | Requirement Impact Chain | 需求影响链 |
+| requirementMarker | REQ | 需求 |
+| upstreamSource | Upstream source | 上游来源 |
+| currentCodePath | Current code path | 当前代码路径 |
+| caller | caller | 调用方 |
+| dataOrState | data or state | 数据或状态 |
+| deepestAffectedLayer | deepest affected layer | 最深影响层 |
+| requiredChange | Required change | 必要变更 |
+| verificationSeam | Verification seam | 验证缝隙 |
+| businessChain | Business Impact Chain | 业务影响链 |
+| outcomeMarker | OUTCOME | 结果 |
+| directBehaviorImpact | Direct behavior impact | 直接行为影响 |
+| downstreamImpact | Downstream impact | 下游影响 |
+| riskBranch | Risk branch | 风险分支 |
+| nonGoalBranch | Non-goal branch | 非目标分支 |
+
+```text
+<requirementChain>
+<requirementMarker>: <user-visible change>
+|-- <upstreamSource>: <roadmap / issue / user request / existing task>
+|-- <currentCodePath>: <entry>
+|   |-- <caller>: <file / command / UI / API>
+|   |-- <dataOrState>: <field / config / artifact>
+|   `-- <deepestAffectedLayer>: <module / prompt / provider contract / storage>
+|-- <requiredChange>: <smallest behavior delta>
+`-- <verificationSeam>: <public test / command / artifact>
+
+<businessChain>
+<outcomeMarker>: <operator / user value>
+|-- <directBehaviorImpact>: <what changes for user>
+|-- <downstreamImpact>: <consumers / docs / examples / release>
+|-- <riskBranch>: <regression / migration / support / cost>
+`-- <nonGoalBranch>: <explicitly not changed>
+```
+
 Acceptance:
 -
 
@@ -84,7 +136,7 @@ Risk / Escalate If:
 
 ClaudeCode / Codex 执行本计划时，必须把 `task.md` 当成唯一任务合同。
 
-- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `query workflow-context` and `next-change-key`, stop blocked.
+- CLI resolver: all workflow commands must run through `.claude/skills/cc-dev/scripts/resolve-cc-devflow.sh` or `.codex/skills/cc-dev/scripts/resolve-cc-devflow.sh`; if it cannot prove `next-change-key`, stop blocked.
 - Task selection: use `scripts/select-ready-tasks.sh --tasks devflow/changes/<change-key>/task.md`.
 - Completion: after Red/Green/Refactor evidence and review pass, run `scripts/mark-task-complete.sh --tasks devflow/changes/<change-key>/task.md --task <task-id>`.
 - Stage commit rule: when PDCA or IDCA finishes in the current environment, commit the completed stage to Git.
@@ -95,8 +147,7 @@ DEVFLOW=".claude/skills/cc-dev/scripts/resolve-cc-devflow.sh"
 if [[ ! -f "$DEVFLOW" && -f ".codex/skills/cc-dev/scripts/resolve-cc-devflow.sh" ]]; then
   DEVFLOW=".codex/skills/cc-dev/scripts/resolve-cc-devflow.sh"
 fi
-bash "$DEVFLOW" require query workflow-context next-change-key
-bash "$DEVFLOW" query workflow-context --change <changeId> --change-key <changeKey> --cwd <repo-root> --data-only --no-trace --compact
+bash "$DEVFLOW" require next-change-key
 SCRIPT_ROOT=".claude/skills/cc-do/scripts"
 if [[ ! -d "$SCRIPT_ROOT" && -d ".codex/skills/cc-do/scripts" ]]; then
   SCRIPT_ROOT=".codex/skills/cc-do/scripts"

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

@@ -13,24 +13,30 @@
 9. Placeholder tasks are invalid.
 10. Behavior work uses tracer bullets and TDD unless an exception is recorded.
 11. Roadmap sync, when needed, happens through roadmap files and Git commit, not change metadata.
+12. Non-trivial plans complete Second-Move Review before approval; the first workable plan is not frozen until a simpler move and a better-architecture move have both been considered.
+13. Non-trivial plans complete product/creative discovery before engineering design; if worth, shape, wedge, or 10x/better version is unclear, ask product questions before implementation questions.
+14. Product/creative confirmation and engineering confirmation are separate rounds unless roadmap/spec evidence already answers one of them and `task.md` records the skip reason.
+15. ASCII branch-chain connector tokens stay ASCII, but labels, evidence, and explanatory text follow `Output language`.
 
 ## Planning Flow
 
 Every non-trivial plan confirms these rounds before task generation:
 
-1. Requirement Reality: real user/operator, workaround, painful failure, smallest success signal, non-goals.
-2. System Shape: existing code path, module owner, state/data flow, reuse point, boundary systems.
-3. Interface/Data Contract: public seam, caller, input/output, fields, error shape, permission/boundary.
-4. Abstraction Boundary: where complexity lives, rejected abstractions, public/private method split.
-5. Execution Architecture: foundation/core/integration/polish decisions, file responsibility, failure recovery.
-6. Task Contract: tracer bullets, Red test names, public seams, Green minimality, refactor candidates.
-7. Final Approval: approved option and task contract summary.
+1. Product/Creative Discovery: worth doing, desired product shape, narrowest wedge, 10x/better version, do-nothing consequence.
+2. Requirement Reality: real user/operator, workaround, painful failure, smallest success signal, non-goals.
+3. System Shape: existing code path, module owner, state/data flow, reuse point, boundary systems.
+4. Interface/Data Contract: public seam, caller, input/output, fields, error shape, permission/boundary.
+5. Abstraction Boundary: where complexity lives, rejected abstractions, public/private method split.
+6. Execution Architecture: foundation/core/integration/polish decisions, file responsibility, failure recovery.
+7. Task Contract: tracer bullets, Red test names, public seams, Green minimality, refactor candidates.
+8. Second-Move Review: first good move, simpler move, better architecture, selected move, and rejected tradeoff.
+9. Final Approval: approved option and task contract summary.
 
 Tiny plans may compress a round to one evidence-backed line. Full designs must preserve enough detail that `cc-do` does not invent architecture, fields, interfaces, or tests.
 
 ## Decision Questions
 
-Ask only when the answer changes scope, design, task split, interface, or verification. Use `D<N>` with known evidence, recommendation, 2-3 mutually exclusive options, impact, and a stop point. Record the answer in `task.md#Contract Summary`.
+Ask only when the answer changes product value, product shape, scope, design, task split, interface, or verification. Before asking, run Second-Move Review on the question itself: can repo evidence answer it, is it too implementation-shaped for the user, and would a better question freeze more downstream decisions? Product/creative questions come before engineering questions when worth or shape is unclear. Use `D<N>` with known evidence, recommendation, 2-3 mutually exclusive options, impact, and a stop point. Record the answer in `task.md#Contract Summary`.
 
 ## Required Task Fields
 
@@ -47,4 +53,4 @@ Ask only when the answer changes scope, design, task split, interface, or verifi
 
 ## Review Gate
 
-Before exit, check scope, existing leverage, option role, domain language, interface depth, test seam, mock boundary, feedback loop, and failure modes. If the plan is not executable from `task.md`, it is not done.
+Before exit, check product/creative discovery, scope, existing leverage, Second-Move Review, domain language, interface depth, test seam, mock boundary, feedback loop, and failure modes. If the plan is not executable from `task.md`, it is not done.

package/.claude/skills/cc-pr-review/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 1.1.3
+
+- require ASCII PR Review Chain labels, findings, and evidence summaries to follow the PR/task/handoff output language while keeping connectors ASCII
+- replace hard-coded English PR Review Chain examples with an `en` / `zh-CN` label table and semantic slots
+
+## 1.1.2
+
+- require ASCII PR Review Chains for non-trivial remote PR findings without creating local process files
+
 ## 1.1.1
 
 - simplify PR review output persistence to a no-process-files rule