cc-devflow 4.5.1 → 4.5.3

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

@@ -1,6 +1,6 @@
 ---
 name: cc-roadmap
-version: 4.3.4
+version: 4.4.1
 description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
 triggers:
   - "帮我定路线图"
@@ -31,6 +31,7 @@ writes:
     when: "roadmap/backlog tracking is maintained through bundled helper scripts"
 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."
   - "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."
@@ -114,7 +115,8 @@ tool_budget:
 2. 先判断这是“项目方向问题”还是“单 requirement 执行问题”。
 3. 如果输入是多个独立子系统的混合目标，先拆成阶段和 `RM` 候选；不要继续追问某个子系统的实现细节。
 4. 先做一次上下文扫描，不能跳过现有事实直接写愿景。
-5. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
+5. 先读取 cc-devflow 原生项目语言与持久决策：`devflow/specs/INDEX.md`、相关 capability specs、`devflow/ROADMAP.md`、`devflow/BACKLOG.md`、历史 `planning/design.md` / `planning/analysis.md` 和 `change-meta.json`；不存在时静默跳过，但术语或决策冲突必须写进 roadmap。
+6. 方向没被批准前，不准把 roadmap 偷偷下放成实现任务。
 
 ## Context Sweep
 
@@ -122,13 +124,14 @@ tool_budget:
 
 1. 当前 `devflow/ROADMAP.md` / `devflow/BACKLOG.md` 的主线、版本、已停放事项。
 2. `devflow/specs/INDEX.md` 与相关 capability specs 的边界、状态、open gaps。
-3. `CLAUDE.md`、`README*`、`TODOS.md`、最近相关 docs / specs / plans。
-4. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
-5. 真实 forcing functions：deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。
-6. 当前项目最强的现实证据，以及仍然只能靠假设的空白。
-7. Planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure。
-8. Evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery。
-9. 如果是 developer-facing 或 operator-facing 能力，补齐 target developer/operator、time to first value、magic moment、install / run / debug / upgrade 卡点。
+3. 项目语言 / 决策上下文：`devflow/specs/INDEX.md`、相关 capability specs、当前 roadmap/backlog、历史 `planning/design.md` / `planning/analysis.md`、`change-meta.json` 和长期 design decision。
+4. `CLAUDE.md`、`README*`、`TODOS.md`、最近相关 docs / specs / plans。
+5. 最近相关提交、当前分支脏状态、正在进行中的 requirement。
+6. 真实 forcing functions：deadline、发布窗口、资源上限、依赖、distribution、adoption / trust / delivery 卡点。
+7. 当前项目最强的现实证据，以及仍然只能靠假设的空白。
+8. Planning posture：startup / internal / hackathon / OSS / research / learning / side-project / infrastructure。
+9. Evidence maturity：idea / has users / paying users / internal sponsor / infra-only / recovery。
+10. 如果是 developer-facing 或 operator-facing 能力，补齐 target developer/operator、time to first value、magic moment、install / run / debug / upgrade 卡点。
 
 先把这些材料压成一个 `Context Snapshot`，再开始追问用户。
 
@@ -144,7 +147,18 @@ tool_budget:
 | infra-only | 当前瓶颈、调用方、现有 workaround、复用边界、迁移/回滚约束 | 伪装成用户访谈的问题 |
 | recovery / trust gap | 事故证据、恢复路径、最小可信修复、停止继续扩张的 kill signal | 新功能愿景 |
 
-第一轮回答后必须做 framing check：术语是否具体、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
+第一轮回答后必须做 framing check：术语是否具体、是否沿用项目 canonical language、用户是否可命名、痛点是否有行为证据、status quo 是否真实、需求是否只是兴趣。发现答案虚，要先收紧问题，再谈路线。
+
+## Strategic Grilling Protocol
+
+`cc-roadmap` 的 brainstorm 不是开放式聊天，而是路线决策树压缩：
+
+1. 一次只推进一个会改变阶段顺序或 backlog 优先级的关键未知点。
+2. 每个问题必须附带推荐答案、证据来源、以及如果用户反对会改变哪条路线。
+3. 能从 repo、roadmap/backlog、capability spec、历史 design/analysis、最近提交、真实运行证据里得到答案时，先查证，不问用户。
+4. 模糊或冲突的术语要压成 canonical term；如果 `devflow/specs/`、roadmap/backlog 或历史 design/analysis 已有定义，路线图必须沿用。
+5. 每条路线都要用一个具体 scenario 压测：谁在什么约束下，今天如何绕路，Stage 1 完成后哪一步不再发生。
+6. 硬决策才沉淀：只有 hard to reverse、surprising without context、real trade-off 三者同时成立，才进入 capability spec delta、roadmap decision note 或本次 design decision log。
 
 ## Session Protocol
 
@@ -156,7 +170,7 @@ tool_budget:
 6. 如果一个方向里有多个可独立交付的子系统，先写清 decomposition：哪些合并为同一阶段，哪些拆成独立 `RM`，为什么。
 7. 只冻结 1-3 个阶段。每个阶段都必须有 goal、why now、dependencies、exit signal、kill signal、non-goals。
 8. 把 `RM` 之间的硬依赖压成显式 dependency graph，并标出 parallel-ready wave；不要把“最好按这个顺序做”伪装成 blocker。
-9. backlog 只保留会真的进入下一轮 `cc-plan` 的事项，每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、`Depends On` 与 `Parallel With`。
+9. backlog 只保留会真的进入下一轮 `cc-plan` 的事项，每项都要带成功信号、下一决策、`Primary Capability`、`Secondary Capabilities`、`Expected Spec Delta`、canonical language handoff、`Depends On` 与 `Parallel With`。
 10. 用户没批准，不进入 `cc-plan`。
 
 ## Route Selection Rule
@@ -194,25 +208,27 @@ tool_budget:
 7. deadline / team / budget / dependency / distribution 的硬约束是什么
 8. 当前最大的 adoption、trust、delivery 卡点是什么
 9. 这个 roadmap 成功与失败各自用什么信号判断
+10. 当前路线里哪些核心名词已经有 canonical definition，哪些术语仍然冲突或含糊
 
 如果这是 developer-facing / operator-facing roadmap，再补 4 件事：
 
-10. 目标开发者 / 操作者是谁
-11. 从第一次接触到第一次成功输出需要多久
-12. 让他们觉得“这东西真的有用”的 magic moment 是什么
-13. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
+11. 目标开发者 / 操作者是谁
+12. 从第一次接触到第一次成功输出需要多久
+13. 让他们觉得“这东西真的有用”的 magic moment 是什么
+14. install / run / debug / upgrade / handoff 中哪个环节最可能让 adoption 失败
 
 ## Approval Gates
 
 1. 没有 `Context Snapshot`，不准给路线推荐。
 2. 没有 planning posture、evidence maturity 和 framing check，不准给路线推荐。
-3. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
-4. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
-5. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
-6. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
-7. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
-8. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
-9. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
+3. 没有 native language / durable decision scan，不准给路线推荐；如果缺少 `devflow/specs/` 或历史决策材料，写成 `not present`，不要假装已对齐。
+4. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
+5. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
+6. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
+7. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
+8. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
+9. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
+10. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
 
 ## Review Loop
 
@@ -228,6 +244,8 @@ tool_budget:
 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；如需重开，是否说明为什么值得重开。
 
 ## Output
 
@@ -244,6 +262,7 @@ tool_budget:
 3. 哪个 signal 说明这一仗赢了
 4. 哪些 backlog 项已经真的 ready for `cc-plan`
 5. 哪些 `RM` 必须串行，哪些已经可以并行开会话
+6. 哪些项目术语 / capability spec / roadmap decision 会随第一批 backlog 传给 `cc-plan`
 
 ## Versioning
 
@@ -285,7 +304,8 @@ tool_budget:
 2. 没有现实证据时必须明确写成 assumption，而不是偷偷当事实。
 3. `devflow/ROADMAP.md` 是方向真相源，`devflow/BACKLOG.md` 是进入下一轮规划的缓冲区。
 4. 决策理由必须保留下来，方便以后重跑时比较版本差异。
-5. 不要为了显得完整而写 6 个阶段，能打赢下一仗比画完整战争图更重要。
+5. 路线图里的术语必须沿用项目语言；没有 canonical term 时写 assumption，不要创造第二套概念系统。
+6. 不要为了显得完整而写 6 个阶段，能打赢下一仗比画完整战争图更重要。
 
 ## Do Not
 

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

@@ -31,6 +31,14 @@
 - Magic moment:
 - Adoption bottleneck:
 
+## Domain Handoff
+
+- Language sources loaded:
+- Canonical terms for next `cc-plan`:
+- Terms to avoid:
+- Capability spec / roadmap decisions to preserve:
+- Language / decision conflicts to resolve:
+
 ## Ready For Req-Plan
 
 - RM-001:
@@ -48,6 +56,8 @@
   - Time to first value:
   - Magic moment:
   - Adoption bottleneck:
+  - Canonical terms:
+  - Capability spec / roadmap context:
   - Required context to load:
   - Depends On:
   - Parallel With:

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

@@ -33,6 +33,11 @@
 - Time to first value:
 - Magic moment:
 - Install / run / debug / upgrade bottleneck:
+- Language sources loaded:
+- Canonical terms:
+- Language conflicts:
+- Durable decision sources loaded:
+- Spec / roadmap decision conflicts:
 - Known unknowns:
 - Relevant capabilities:
 
@@ -72,6 +77,15 @@
 - What we refuse to build yet:
 - 6-12 month pull:
 
+## Native Language & Durable Decisions
+
+- Canonical terms this roadmap uses:
+- Terms avoided / aliases:
+- Existing capability spec / roadmap decisions preserved:
+- Capability spec / roadmap decisions reopened:
+- Decisions worth capability spec sync:
+- Handoff notes for `cc-plan`:
+
 ## Evidence-Maturity Routing
 
 - Planning posture:
@@ -176,6 +190,7 @@ flowchart LR
 - Rejected path A:
 - Rejected path B:
 - Rejected maturity route:
+- Language / spec decision conflicts:
 - Developer / operator adoption assumptions:
 - Open assumptions to verify next:
 - What changed in this version:

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

@@ -6,7 +6,7 @@
   "lastSyncedAt": "2026-04-19",
   "backlogMeta": {
     "roadmapVersion": "roadmap.v1",
-    "skillVersion": "4.3.4",
+    "skillVersion": "4.4.1",
     "currentFocusStage": "Stage 1"
   },
   "dependencyHandoff": {

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

@@ -2,23 +2,26 @@
 
 ## Order
 
-0. 先做 `Context Snapshot`：现有 roadmap / backlog、文档、最近提交、forcing functions
+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. 最窄突破口是什么
-8. 6-12 个月后会长成什么
-9. 给出 2-3 条路线图形状并明确推荐
-10. 冻结 1-3 个阶段，写 exit signal / kill signal / non-goals
-11. 画出 `RM dependency graph`，标出串行主链和 parallel-ready wave
-12. 标出哪些事项真的 ready for `cc-plan`
+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`
 
 ## Question Rules
 
 - 一次只推进一个关键未知点
+- 每个问题附带推荐答案、证据来源，以及用户反对时会改变哪条路线
+- 能从 repo / capability spec / roadmap / design / git history 得到答案时先查证，不问用户
 - 没证据时明确写 assumption
 - 用户没批准前，不把事项偷下放成 requirement
 
@@ -35,3 +38,4 @@
 - `RM` 必须带 `Depends On`，并在 roadmap 里显式画出 dependency graph
 - backlog 只收下一轮真会进入 `cc-plan` 的事项
 - ready 项必须带成功信号、下一决策、`Depends On`、`Parallel With`
+- ready 项必须带 canonical terms、capability spec context 或明确的 language / decision conflict

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

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

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

@@ -1,55 +1,284 @@
 ---
 name: cc-simplify
-version: 1.1.0
-description: Review changed code for reuse, quality, efficiency, and spec drift, then fix any issues found or flag the drift for the user.
+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."
 ---
-Simplify: Code Review and Cleanup
 
-Review all changed files for reuse, quality, and efficiency. Fix any issues found.
+# CC-Simplify
 
-## Phase 1: Identify Changes
+`cc-simplify` 是 ship 前的坏味道清理关口。
 
-Run \`git diff\` (or \`git diff HEAD\` if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
+它不是“顺手重构”。它只做一件事：基于当前 diff 找到已经存在的重复、过度设计、低效路径、测试假象、spec drift，并修掉已经确认的坏味道。
 
-## Phase 2: Launch Three Review Agents in Parallel
+## Iron Law
 
-Use the ${AGENT_TOOL_NAME} tool to launch all three agents concurrently in a single message. Pass each agent the full diff so it has the complete context.
+```text
+ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
+```
 
-### Agent 1: Code Reuse Review
+没有证据的 reviewer finding 只是线索，不是命令。先验证，再修改。
 
-For each change:
+## Phase 1: 识别变更
 
-1. **Search for existing utilities and helpers** that could replace newly written code. Look for similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones.
-2. **Flag any new function that duplicates existing functionality.** Suggest the existing function to use instead.
-3. **Flag any inline logic that could use an existing utility** — hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.
+1. 优先读取当前变更：
+   - 有 staged diff：跑 `git diff --cached` 和 `git diff`
+   - 无 staged diff：跑 `git diff HEAD`
+   - 如果没有 git diff，审查本轮对话中用户点名或你刚编辑过的文件
+2. 记录 diff 范围：
+   - changed files
+   - affected modules
+   - stack signals: `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / etc.
+   - test framework signals: `jest` / `vitest` / `pytest` / `go test` / etc.
+   - scope flags: API / auth / backend / frontend / migration / docs / release
+   - related `planning/tasks.md` / `change-meta.json` / capability specs
+   - already-run verification, if any
+3. 如果变更跨多个互不相关模块，先按模块分组；不要让一个 cleanup pass 变成大扫除。
+4. 只审当前 diff 新增或本次改动扩大后的坏味道。历史债只在它阻挡当前交付或被本次 diff 放大时进入清理范围。
 
-### Agent 2: Code Quality Review
+## Phase 2: Codex 智能体评审
 
-Review the same changes for hacky patterns:
+如果当前环境支持 Codex 多智能体，并且用户已经明确触发 `cc-simplify` 或要求并行评审，可以构建只读评审智能体。
 
-1. **Redundant state**: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
-2. **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones
-3. **Copy-paste with slight variation**: near-duplicate code blocks that should be unified with a shared abstraction
-4. **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
-5. **Stringly-typed code**: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
-6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior
-7. **Unnecessary comments**: comments explaining WHAT the code does (well-named identifiers already do that), narrating the change, or referencing the task/caller — delete; keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)
-8. **Spec drift**: behavior, boundary, or invariant changed but no matching `change-meta.json` / capability spec delta was updated — flag it explicitly and propose the missing spec sync
+### 调度原则
 
-### Agent 3: Efficiency Review
+- Codex 中优先使用 `spawn_agent(agent_type="explorer")` 创建只读评审智能体。
+- 如果当前环境没有 `explorer`，使用默认智能体也必须在 prompt 里写明：只读审查，不编辑文件。
+- 只把只读评审交给智能体；主线程负责最终判断和实际编辑。
+- 每个智能体拿到同一份完整 diff、相关任务/设计/spec 路径、当前 repo 根目录。
+- 智能体不能改文件，只输出结构化 findings。
+- 如果没有多智能体能力，主线程按同样清单顺序执行。
+- 小 diff 不强制开智能体：少于约 50 行且只触碰单一文件时，主线程执行同一清单即可。
+- 条件 specialist 只在对应 scope 出现时启用；不要为了“完整”启动无关评审。
 
-Review the same changes for efficiency:
+智能体 prompt 必须自包含：
 
-1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
-2. **Missed concurrency**: independent operations run sequentially when they could run in parallel
-3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths
-4. **Recurring no-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally — add a change-detection guard so downstream consumers aren't notified when nothing changed. Also: if a wrapper function takes an updater/reducer callback, verify it honors same-reference returns (or whatever the "no change" signal is) — otherwise callers' early-return no-ops are silently defeated
-5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU anti-pattern) — operate directly and handle the error
-6. **Memory**: unbounded data structures, missing cleanup, event listener leaks
-7. **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one
+```text
+你是 cc-simplify 的只读评审智能体。不要编辑文件。
+输入：repo root、完整 diff、相关任务/spec 路径、你的评审维度。
+输出：每行一个 JSON finding；没有发现时只输出 NO FINDINGS。
+没有证据的猜测不要输出为 finding。
+```
 
-## Phase 3: Fix Issues
+Finding JSONL schema：
 
-Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on — do not argue with the finding, just skip it.
+```json
+{"severity":"critical|important|minor","confidence":8,"path":"file","line":12,"category":"reuse|scope|quality|efficiency|testing|security|api-contract|release","summary":"...","evidence":"...","fix":"...","fingerprint":"file:12:category","specialist":"name","test_stub":"optional"}
+```
 
-When done, briefly summarize what was fixed (or confirm the code was already clean).
+字段要求：
+
+- 必填：`severity`、`confidence`、`path`、`category`、`summary`、`evidence`、`fix`、`specialist`
+- 可选：`line`、`fingerprint`、`test_stub`
+- `confidence` 用 1-10；低于 5 的 finding 不能进入自动修复列表。
+- `test_stub` 只给能用一个小测试抓住的问题；架构判断不要伪造测试。
+
+### 推荐三个智能体
+
+#### Agent A: Spec / Scope Reviewer
+
+目标：确认实现是否仍然符合冻结的需求边界。
+
+检查：
+
+1. 是否遗漏了任务要求。
+2. 是否多做了未要求功能。
+3. 是否改变行为、边界或 invariant，却没有同步 `change-meta.json` 或 capability spec。
+4. 是否把 bug 修复伪装成新需求，或把新需求伪装成 cleanup。
+5. 是否应该 reroute：
+   - 设计范围变了 -> `cc-plan`
+   - 根因故事失效 -> `cc-investigate`
+   - 需要重新验证 -> `cc-check`
+
+#### Agent B: Reuse / Structure Reviewer
+
+目标：删除重复和无意义抽象。
+
+检查：
+
+1. 新增函数是否重复现有 helper、utility、shared module、邻近文件里的模式。
+2. 是否手写了已有能力：路径处理、字符串解析、env 检测、类型 guard、schema 验证、错误包装。
+3. 是否出现 copy-paste with slight variation，应该合并为已有 helper 或一个更小的局部函数。
+4. 是否有 parameter sprawl：为了一个场景继续给函数加参数，而不是整理输入对象或拆出职责。
+5. 是否泄漏抽象边界：调用方知道了内部状态、文件布局、协议细节或测试专用机制。
+6. 文件是否因为本次改动开始承担多个职责；如果只是历史遗留，不在本轮扩大范围。
+7. 新增模块是否是浅包装：接口复杂度几乎等于实现复杂度，删除它只是把同样复杂度搬到调用方。
+8. seam 是否真实：只有一个 adapter 且没有明确第二个调用场景时，先当作 hypothetical seam；不要为了假扩展性制造抽象。
+9. deep module 机会：如果一个小接口能隐藏大量重复调用顺序、错误处理、配置或状态转换，优先让复杂度集中到该模块，而不是散落在调用方。
+
+#### Agent C: Quality / Efficiency / Test Reviewer
+
+目标：找出会变成维护成本或运行成本的坏味道。
+
+检查：
+
+1. 冗余状态：缓存可派生值、重复状态源、无意义 observer/effect。
+2. 热路径膨胀：启动、请求、渲染、轮询、事件处理里新增阻塞工作。
+3. 重复 IO / 网络 / API 调用、N+1、整文件读取但只需要局部数据。
+4. missed concurrency：互不依赖的读文件、搜索、请求、验证命令被串行执行。
+5. recurring no-op update：轮询或 reducer 明明没有变化却通知下游。
+6. TOCTOU：先检查文件存在再操作；应直接操作并处理错误。
+7. 内存和生命周期：无界数组/map/cache、listener 未清理、timer 未释放。
+8. 测试坏味道：
+   - 测 mock 存在，不测真实行为
+   - 为测试给生产类加 test-only method
+   - 不理解依赖副作用就 mock
+   - partial mock 缺少真实响应字段
+   - 只补测试后验通过，没有证明测试会抓住 bug
+   - 缺少错误路径、权限拒绝、空值、边界值、单元素集合、并发访问测试
+   - 测试共享全局状态、依赖系统时间/时区/locale、真实网络或随机数据但没有 seed
+   - 断言无序结果的顺序，或使用过紧 timeout 造成 flaky
+
+### 条件 specialist
+
+当 diff 命中对应范围时，额外启用这些只读维度；没有命中就跳过：
+
+- `security`：auth/backend 大改、用户输入、文件路径、命令执行、HTML escape hatch、token/secret 处理
+- `api-contract`：endpoint、请求/响应字段、状态码、鉴权要求、分页、OpenAPI/SDK 文档
+- `release`：VERSION、CHANGELOG、发布脚本、CI artifact、tag 格式、publish idempotency
+- `frontend-performance`：渲染循环、列表查找、重复 style 注入、bundle/懒加载边界
+
+如果任一 specialist 发现 `critical`，再做一次 Red Team 只读复查：它只找遗漏的跨边界失败模式，不重复前面 finding。
+
+## Phase 3: 汇总和去重 findings
+
+先解析 JSONL；非 JSON 行丢弃，`NO FINDINGS` 表示该 source 没有发现。
+
+Fingerprint 规则：
+
+1. 优先使用 finding 自带 `fingerprint`。
+2. 否则用 `{path}:{line}:{category}`。
+3. 没有 `line` 时用 `{path}:{category}:{summary}`。
+
+同一 fingerprint 的 finding 合并：
+
+- 保留 confidence 最高的版本。
+- 如果多个 specialist 命中同一问题，标记 `multi-specialist`，confidence +1，最高 10。
+- 合并后按 `critical -> important -> minor`，再按 confidence 降序排序。
+
+Confidence gate：
+
+- `7-10`：进入主 findings 表。
+- `5-6`：进入主表，但 Decision 初始为 `verify-first`。
+- `3-4`：放到 appendix，只在主线程读代码后确认时升级。
+- `1-2`：抑制，不输出为行动项。
+
+主表格式：
+
+| ID | Source | Severity | File:line | Claim | Evidence | Proposed fix | Decision |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| S1 | spec | critical | | | | | pending |
+
+Severity：
+
+- `critical`: 会破坏功能、安全、数据、发布真实性
+- `important`: 明显坏味道、spec drift、测试假象、性能风险
+- `minor`: 可读性、局部重复、小优化
+
+Decision：
+
+- `auto-fix`: 已确认、机械、低风险，主线程可直接修
+- `ask`: 需要用户判断或会改变用户可见行为
+- `fix`: 已确认且在当前 cleanup 边界内
+- `verify-first`: 线索合理但证据不足，修前必须读代码确认
+- `skip-false-positive`: 和代码事实不符
+- `skip-not-worth-it`: 成本高于收益，且不影响当前交付
+- `reroute`: 已经不是 simplify 范围
+
+### Fix-First 决策表
+
+默认自动修：
+
+- dead code、unused variable/import、明显 stale comment
+- 简单重复 helper、路径/版本/changelog 不一致
+- 局部 magic value 提取为已存在常量或邻近常量
+- 明显 O(n*m) 查找可改为 map/index，且行为不变
+- 缺少轻量输入 shape 校验，且已有本地校验模式可复用
+
+默认 ask 或 reroute：
+
+- auth、XSS、注入、secret、权限、安全边界
+- race condition、数据迁移、事务语义、enum/value completeness
+- 需要超过约 20 行的新设计，或触碰超过 5 个文件
+- 删除功能、改变公共 API、改变用户可见行为
+- finding 证明 frozen plan、root cause、acceptance 已经失效
+
+## Phase 4: 验证 finding 是否成立
+
+不要盲信 reviewer。
+
+每条 finding 修复前先做四个检查：
+
+1. **代码事实**：打开对应文件和相邻实现，确认问题真实存在。
+2. **使用事实**：用 `rg` 查调用方，确认不是 reviewer 缺上下文。
+3. **需求事实**：对照 `planning/tasks.md`、`change-meta.json`、capability spec，确认没有误删必要行为。
+4. **验证事实**：明确修复后用什么命令或检查证明没有回归。
+
+架构类 finding 还必须过删除测试：想象删除这个模块、helper、wrapper 或 seam。
+
+- 如果复杂度只是原样散回多个调用方，它可能是有价值的 deep module。
+- 如果复杂度消失或只留下一个直接调用，它多半是 pass-through / fake seam。
+- 如果删除会违反 capability invariant 或 public contract，就不能当作 cleanup 直接删。
+
+如果 reviewer 建议“更专业”的能力，先做 YAGNI 检查：没有调用方、没有需求、没有 acceptance，就不要新增。
+
+这些情况不要报成 finding：
+
+- 为可读性保留的轻微重复。
+- 已有断言已经覆盖真实行为，只是“不够漂亮”。
+- 输入域受约束，所谓边界值在产品里不可能出现。
+- 测试一次覆盖多个 guard；只要行为清楚，不必强拆。
+- 当前 diff 已经修掉的问题。
+- shutdown/emergency/fire-and-forget 路径里有意吞掉错误。
+- pass-through wrapper 只是稳定 API 层，内部委托到真实实现。
+
+## Phase 5: 只修 confirmed smells
+
+修复顺序：
+
+1. Critical
+2. Simple important fixes
+3. Complex important fixes
+4. Minor fixes only if low-risk
+
+边界：
+
+- 不做 unrelated refactor。
+- 不改公共 API，除非 finding 证明当前 API 本身就是坏味道。
+- 不把多个架构方向揉进一个 cleanup。
+- 不为了消灭 3 行重复制造 50 行抽象。
+- 如果预计触碰超过 5 个文件，先停下说明：拆分、reroute，还是只修 critical path。
+
+如果某条 finding 需要重新设计，停止并交给 `cc-plan`。如果 finding 证明根因不明，交给 `cc-investigate`。
+
+## Phase 6: 新鲜验证
+
+完成修改后必须运行和本次 cleanup 相关的最小验证：
+
+1. 格式/结构：例如 `git diff --check`、JSON/YAML parse、脚本 `bash -n`。
+2. 目标测试：覆盖被修改模块的单测或 smoke。
+3. 必要时运行更高层 gate：`npm test`、`npm run verify:*`、项目本地等价命令。
+
+不能用旧结果声称现在通过。智能体报告也不能替代主线程验证。
+
+## 输出格式
+
+结束时输出简短 `Simplify Report`：
+
+- Reviewed diff:
+- Agents used: `yes` / `no`
+- Findings fixed:
+- Findings skipped:
+- Reroutes / blockers:
+- Verification run:
+- Next step: `cc-check` / `cc-act` / `cc-plan` / `cc-investigate`
+
+如果 `cc-simplify` 修改了代码或验证口径，下一步必须回 `cc-check`，不能带旧 report-card 继续 `cc-act`。
+
+## Do Not
+
+- 不把 cleanup 当成重写入口。
+- 不因为 reviewer 说了就盲改。
+- 不把风格偏好升级成 critical。
+- 不跳过 spec drift。
+- 不用 mock 通过来证明真实行为正确。
+- 不在没有新鲜验证时声称“已简化完成”。

package/.claude/skills/cc-spec-init/CHANGELOG.md

@@ -1,5 +1,11 @@
 # CC-Spec-Init Skill Changelog
 
+## v1.1.0 - 2026-04-28
+
+- add a language boundary gate for canonical capability terms, aliases to avoid, flagged ambiguity, and relationship constraints
+- require new capability specs to include a minimal language block before registration in `INDEX.md`
+- prevent implementation names from becoming capability truth unless they already represent stable public domain language
+
 ## v1.0.1 - 2026-04-27
 
 - require capability specs, spec indexes, and change metadata to resolve the runtime output policy before writing durable artifacts