业务调整（需求 / 行为变更）

归属：docs/guides/sops/ 触发：既有已交付功能的行为、字段、交互、规则调整 关联概念：Flow Record、Planning Baseline、flow-requirements、flow-review

场景定义

对已存在（可能已发布）功能的增量调整：改字段、改交互、改业务规则、改默认值等。它既不是全新功能（需新 Flow），也可能不是缺陷（不是 01-bug-fix），而是对既有行为的有意变更。

目标与不做什么

• 目标：清晰界定变更边界、评估影响、保证向后兼容（或显式迁移），并更新验收标准。
• 不做：把「调整」塞进已完成的 Flow 里静默改验收；不评估影响就动手。

标准方法论（行业通行）

借鉴变更管理（Change Management）与敏捷范围管理的通行做法：

1. 变更请求：把调整书面化为一条变更请求，明确「改什么、为什么改、期望结果」。
2. 影响分析：列出受影响模块、调用方、数据结构、文档、测试与潜在破坏点。
3. 评审与批准：按影响范围决定是否需评审/批准（高风险：兼容性破坏、公共接口变更）。
4. 兼容与迁移：区分「新增能力（向后兼容）」与「破坏性变更（需迁移/版本化）」；对破坏性变更给出迁移路径。
5. 需求可追溯：变更后的验收标准清晰可核验，并关联到对应 Flow Record / Task Record。

本项目落地流程

1. 分诊变更类型：
   • 新增能力 / 独立扩展 → 开新 Flow（走主流程）。
   • 既有功能微调 / 原意澄清 → 复用或重开原 Flow Record，更新验收标准。
   • 对已发布版本的破坏性变更 → 显式评估迁移，必要时补 ADR。
2. 影响分析：列出受影响模块、调用方、接口、文档、测试；评估是否破坏向后兼容。
3. 澄清变更（复用 flow-requirements 的渐进式澄清）：一次确认一个关键决策（改什么、谁判断做对了、是否破坏兼容）。
4. 更新验收标准：在 Flow Record / Task Record 中更新 Acceptance Criteria，作为后续 review 的规格轴依据。
5. 设计/实现：若涉及技术方案变化，按 flow-design 产出设计基线并合入；否则直接按 flow-code 实现。
6. 审查与合并：复用 flow-review 双轴审查——规格轴对照更新后的验收标准，确认变更忠实实现。
7. 文档同步：涉及 guides/api/db 变更随 PR 更新；新领域术语写回 CONTEXT.md。

验证与门禁

• [ ] 变更边界与期望结果书面明确
• [ ] 影响分析完成（模块、调用方、兼容性）
• [ ] 验收标准已更新且可核验
• [ ] 向后兼容性或迁移方案已验证
• [ ] 全量回归通过 + CI 绿 + 双轴审查通过

产出物

• 变更请求 / 影响分析（可并入 Flow Record body）
• 更新后的验收标准
• 合并的变更 PR（含必要的 docs 同步）

复用与新增资产

• 复用：flow-requirements（澄清）、flow-design（如需设计基线）、flow-code、flow-review、goal 工具。
• 新增（缺口）：变更分诊与影响分析的轻量入口；「复用 vs 新建 Flow」的决策规则。

反模式 / 注意事项

• 静默修改已合并功能的验收而不留痕。
• 破坏性变更不做迁移与兼容评估。
• 不区分「新增能力」与「既有调整」，一律开新 Flow 或一律复用。
• 变更后不更新文档与验收标准，导致 review 无规格可依。