change

/change 命令

核心理念

先设计再实现，先影响分析再动手。 在已有 checkpoint + 运行中代码库上做增量变更，不是从零开始。 每次变更都经过 G-E 收敛循环验证设计质量，再通过 RALPH 循环实现。

与 /implement 的关系

/implement = 从 checkpoint 出发，全量实现（Phase 0→1→2→3）
/change    = 在已实现的项目上，增量变更（分析→设计→实现→回归）

/implement 建造房子
/change    改造房间

/change 复用 /implement 的全部基础设施（agents、hooks、rules、scripts）， 但增加了影响分析和增量设计两个前置阶段。

---

使用方式

# 完整流程（4 阶段）
/change 新增 whale alert：检测大额交易推送 webhook 通知

# 仅分析影响（不实现）
/change analyze 新增 whale alert 功能

# 从设计结果继续实现（已有 change-request）
/change implement CR-003

# 查看变更历史
/change log

# bug fix 快捷模式（跳过完整设计，但仍有影响分析）
/change fix 钱包初始化超时未重试

---

变更类型

类型	触发词	设计深度	示例
feature	新增、添加、支持	完整（4 阶段）	"新增 whale alert 功能"
enhance	修改、优化、改进	中等（影响分析 + 增量设计）	"优化钱包初始化并发数"
refactor	重构、拆分、合并	中等（影响分析 + 架构评审）	"拆分 ingestion 模块"
fix	修复、bug、问题	轻量（影响分析 + 直接实现）	"修复扫链 reorg 处理"

---

4 阶段流程

Stage A: ANALYZE（影响分析）
  │ 主 session 执行，可与用户交互
  │
  │ 1. 读取变更描述 → 分类（feature/enhance/refactor/fix）
  │ 2. 扫描现有 checkpoint-1~5 → 找到相关 FR、聚合、API、DDL
  │ 3. 扫描现有代码库 → 找到受影响的文件和模块
  │ 4. 检测新增环境依赖（新 infra / 新 API / 新 RPC）
  │ 5. 生成影响报告 → 展示给用户确认
  │
  │ 产出：change-request-{N}.yaml（影响范围 + 变更计划 + 新增环境依赖）
  │
Stage B: DESIGN（增量设计）
  │ Agent(change-analyst) — G-E 收敛循环
  │
  │ 1. 根据变更类型，增量更新相关 checkpoint：
  │    - feature → 追加 FR 到 checkpoint-1，可能更新 2/3/4
  │    - enhance → 修改已有 FR，更新 checkpoint-4
  │    - refactor → 更新 checkpoint-2/3，可能更新 4
  │    - fix → 通常不更新 checkpoint（除非是设计缺陷）
  │ 2. Generator 提出 checkpoint 变更 → Evaluator 评审一致性
  │ 3. 用户确认 checkpoint 变更
  │
  │ 产出：更新后的 checkpoint 文件 + change-request 状态更新
  │
    ──── 如果有新增环境依赖 → 环境询问（见下方） ────

Stage C: IMPLEMENT（增量实现）
  │ 复用 impl-lead + RALPH 循环
  │
  │ 1. impl-lead 只处理 change-request 中的变更范围
  │ 2. 如果需要新 DDL → impl-skeleton 执行增量迁移
  │ 3. 如果需要新 verify scripts → impl-deploy 更新脚本
  │ 4. RALPH 内层循环：RED → GREEN → REVIEW → DEPLOY → COMMIT
  │ 5. 每个变更功能一个 commit（Conventional Commits）
  │
  │ commit 格式根据变更类型：
  │   feature → feat({module}): {description}
  │   enhance → feat({module}): {description}
  │   refactor → refactor({module}): {description}
  │   fix → fix({module}): {description}
  │
Stage D: REGRESS（回归验证）
  │ 主 session + impl-reviewer
  │
  │ 1. 全量测试（不仅仅是变更部分）
  │ 2. 全量 smoke test
  │ 3. impl-reviewer 对变更代码做独立评审
  │ 4. 检查未被变更但被影响的模块是否仍通过
  │ 5. 更新 change-request 状态 → completed