提供轻量级大版本内迭代工具，填补 /genesis 与 /change 之间的空白

[moyu12-ae]

问题描述

Anws 当前的版本迭代工具体系存在一个明显的"重量断层"：

工具	创建新 v{N}	流程重量	适用场景
/genesis	是	重（6 步 + 4 技能链 + 多重人类检查点）	从 0 创世 / 重大架构重写
/change	否	轻（十问闸门 + 签名写盘）	当前版本内的受控微调
/upgrade	否	—	路由器，仅分发到上述两者

真实的用户场景

架构基线稳定（ADR 核心决策不变、系统边界不变、技术栈不变），但需要一个新版本目录 v{N+1} 来承接新一轮功能迭代。例如：

• 从 v7 → v8，目标矩阵要再扩几个 IDE，但核心架构不变
• 同一架构下新增一个中型功能模块，需要新的任务清单和验证计划
• PRD 有增量需求，但不涉及 ADR 核心前提变更

这些场景下：

• 用 /genesis：太"重"——被迫全量重跑概念建模 → 技术评估 → 系统拆解 → ADR 全链路，大量重复劳动，而且人类检查点多到影响效率
• 用 /change：不够——/change 只能修改当前 v{N} 内的文件，不创建新版本目录，无法满足"开新版本做新迭代"的需求

本质矛盾

当前版本管理模型是二元的："要么原地修（change），要么重塑一切（genesis）"。缺少"同一架构基线下的轻量版本演进"这一中间态。

期望方案

提供一个介于 /genesis 和 /change 之间的工作流（例如命名为 /evolve），用于大版本内的小版本迭代。

核心行为

1. Copy & Evolve：从当前 v{N} 复制目录结构到 v{N+1}（与 /genesis 的 Step 0 一致）
2. 流程聚焦增量：
   • 更新 PRD 中变更/新增的需求条目（不改已有 REQ 的 ID 和语义）
   • 更新架构总览中受影响的系统描述（不改系统边界）
   • 仅在核心 ADR 前提变化时才追加/修订 ADR（否则直接复用）
   • 清空旧版本的任务文件（05A/05B），新建本版任务清单
3. 不跑全量技能链：
   • 不调用 concept-modeler（除非用户明确要求重新建模）
   • 不调用 tech-evaluator（除非技术栈变更）
   • 不调用 system-architect（除非系统拆解变化）
   • 仅当新需求触发时才选择性调用对应技能
4. 减少检查点：仅在 ADR 前提变更或公共契约变更时设人类检查点
5. 溢出保护：当检测到变更超出"大版本内迭代"边界时（如核心 ADR 被推翻），自动拒绝并引导用户使用完整 /genesis

与 /genesis / /change 的职责边界

	/evolve（新）	/genesis	/change
创建新 v{N}	是	是	否
全量技能链	否（按需选调）	是（4 技能串行）	否
适用前提	ADR 不变 / 微调	从 0 或前提演进	当前版本内
人类检查点	1-2 个	2+ 个	1 个（签名）

与 /upgrade 的关系

/upgrade 的 Minor 路由目前指向 /change，但 /change 不创建新版本目录。如果有了 /evolve，/upgrade 的 Minor 路由可以改为指向 /evolve（当需要新 v{N} 时）或 /change（当不需要新 v{N} 时），使升级编排更加精细。

受益场景

• 架构稳定期的高效迭代：不重复造轮子，只写增量
• 中等规模的 feature 开发：比 /genesis 快，比 /change 有版本边界
• 减少"假 genesis"：避免因没有更好工具而被迫跑完整 genesis 流程