Bug 修复工作法

这份文档只约束 bug 修复，不用于扩需求或做无关重构。

基本原则

1. 先确认现象，再改代码。
2. 只修造成 bug 的最小决策点。
3. 不借修 bug 扩需求，不顺手重构无关模块。
4. 修复必须能被验证，至少跑类型检查或构建。
5. 保留已有脏工作树，不回滚不相关改动。

标准流程

1. 定边界

   • 明确用户报错的“表现”和“预期”。
   • 对照当前文档和代码，确认这次修复不越界。

2. 找状态链

   • 追触发条件。
   • 追状态写入。
   • 追状态推进。
   • 追状态清理。
   • 追 UI / 展示层是否还在读旧状态。

3. 做最小修复

   • 优先补状态机收口。
   • 优先修分支判断、清理逻辑、边界条件。
   • 只有当现有结构挡不住问题时，才增加最小新函数。

4. 做验证

   • 跑 npm run lint。
   • 跑 npm run build。
   • 需要时补一个最短复现路径。

5. 做复盘

   • 记录根因类型。
   • 记录这次修复可复用的判断方式。
   • 下次遇到同类问题先查同类链路。

常见根因

• 只暂停了推进，没有清理已存在状态。
• 只改了 UI，没有改状态源头。
• 只改了一个时段判断，漏了跨时段收口。
• 夜间/闭店/结束态被当成“继续挂着”的普通状态。
• 读档或离线回流补齐了时间，却没补齐活动实体的结算。

本仓库执行口径

• 昼夜、营业、结账、离席这类问题，优先看时间状态和客流状态的交界。
• 如果夜间进入闭店，已在场的活动实体必须被结算、转场或清理。
• 任何修复都应尽量只影响一个流程，不把问题扩散成系统改造。