大型改造分阶段 + 完成报告规范

判定标准：什么算「大型改造」

满足任一即触发分阶段流程：

• 涉及 3 个以上文件的改动
• 跨越 2 个以上模块/子系统（前后端、共享库、数据库迁移等）
• 改动核心共享代码（路由、数据通道、公共组件、构建链）
• 预期 2 个以上逻辑变更点（非单点修 bug）
• 高风险：影响现有数据、破坏兼容、不可简单回滚

一、大型改造分阶段规范

规划阶段（动手前先给计划）

大型任务：DSH 下走原生 plan mode（/plan → exit_plan_mode 交用户审批）；改规则/技能体系时按 plan-review 走「子代理出计划 → 主代理复核通过 → 再执行」，本节拆分原则即其复核清单 A 组的依据。小任务按下列步骤直接出计划即可。

1. 先完整分析现状，输出《改造计划》：整体目标 + 阶段拆分。
2. 拆分原则：
   • 每阶段可独立测试、可独立提交、失败可独立回滚。
   • 每阶段尽量只做一类变更（先改结构/后改行为，先加后删）。
   • 阶段粒度不宜过大：理想情况每阶段 1 次 commit。
3. 计划中写明每阶段的：目标、涉及文件、验收风险与场景、验证方式（真实命令/手动步骤）、成功标准和证据。

执行阶段（每阶段固定循环）

每阶段按 实现 → 测试 → 提交 顺序推进（「测试」由 test-verification 总控：直接路径起步、具体风险追加、实际执行与证据判定）：

1. 实现本阶段范围，不越界带入下阶段内容。
2. 测试：执行该阶段直接相关验证与项目必要门禁；专项由具体风险触发，通过后结束验证。失败按 test-verification P5 处理，关键客观项受阻时报告阻塞。
3. 提交：所选关键验证及必要门禁通过后提交 git，信息标注阶段（如 feat: 阶段1/3 - 数据层迁移）。主观视觉与体验可随已验证交付列为待人工验收，整体验收状态如实保留。
4. 提交点的受影响验证与项目必要门禁保持通过，既有基线异常单独披露并附归因证据；随时可从该 commit 继续，出问题可回退到上一阶段。

中途发现计划外事项

• 发现计划外需求/阻塞：暂停，向用户说明并更新计划，不擅自扩阶段。
• 阶段需要重排/合并/新增：先更新计划再继续。

二、任务完成报告规范

非平凡任务（含全部大型改造）完成后，最终回复包含五要素报告：

「验收指引」写用户可照做的步骤（界面 → 点什么 → 看到什么），让用户不读代码也能验收本次改动。报告「实际」列若涉及页面/模块/命令/架构变更，附一句「技能同步情况」（已更新 xxx / 无需更新）——见 auto-skill-creator 技能同步更新规范。

小型任务（单文件小改动、纯问答）可豁免，给一句话结果说明即可。

关键命令 / 模式

• 每阶段提交前执行直接相关检查和项目明确的必要门禁；lint/typecheck/test 按实际改动与门禁选择（入口查 AGENTS.md / 项目配置）。
• 提交粒度：一阶段一 commit，commit message 带阶段标识。
• 涉文档/技能改动：完成前跑文档审计（项目内 node ~/.dsh/rules/audit-docs.mjs --changed；共享规则库 node ~/.dsh/rules/check-rules.mjs；DSH 经 ~/.dsh/rules 联接，OpenCode 用 ~/.config/opencode/），高置信命中清零并把结果写进报告「实际」列（判级见 docs-stale-audit）。
• 回滚：git log 定位阶段 commit，git revert <commit> 精确回退单阶段。

红线兜底

• 大型改造先拆阶段、先出计划并经用户确认（用户明确指示直接做除外），保证每阶段可独立测试/提交/回滚。
• 每阶段所选关键客观验证与项目必要门禁通过后再提交，提交后仓库保持可运行；基线异常和待人工项目如实披露，必要客观验证受阻时不得把该阶段标为完成。
• 完成报告五要素齐全，「验收指引」须给用户可照做的界面/操作步骤（用户要求豁免除外）。