---
name: fullstack-flowheal
when: '流程修复, 全栈诊断, E2E修复, 修复流程, FlowHeal, 诊断修复, 跨层修复, 流程异常'
scope:
  - backend
  - frontend
products:
  - '*'
id: ka-pattern-fullstack-flowheal
asset_kind: pattern
lifecycle_status: active
owner_mechanism_id: mc-general-pattern
authority: supporting
routes:
  - '*'
primary_triggers:
  - 流程修复
  - 全栈诊断
  - E2E修复
  - 修复流程
  - FlowHeal
  - 诊断修复
  - 跨层修复
  - 流程异常
priority: P2
specificity: 3
version: 1.1.0
last_reviewed: '2026-06-01'
consumes: []
emits: []
secondary_triggers: []
negative_triggers: []
type: pattern
stages: ["编码与单元测试", "联调验证"]
---

## 决策规则
- 必须严格遵循 5 步顺序：定义用例 → 收集证据 → 诊断 → 补丁计划 → 验证，禁止跳步
- 证据优先、流程优先、浏览器证据优先、最小补丁、分层验证
- 禁止将不稳定测试视为业务失败，先稳定复现再判断
- 禁止删除断言、增加 sleep、降低覆盖率、增加 mock 来制造通过
- 禁止用 SQL 直接写业务测试数据
- 禁止自动修改事务/权限/金额/库存/安全策略
- 一次只修一个问题，禁止跨层大重构同时进行
- 高风险/低置信度/跨多服务的复杂变更上报人工决策
- 端到端测试必须从浏览器页面出发，禁止绕过前端
- 前后端联调必须基于接口文档（OpenAPI），禁止口头约定字段
- 前后端字段命名不一致时以后端为准，前端通过映射层适配
- 接口变更必须同步更新文档和前端调用，禁止只改一侧
- 联调问题必须在缺陷系统记录根因（文档不完整/需求不明确/理解偏差），持续改进

## 验收项
- [AC-01] 遵循 5 步顺序（用例→证据→诊断→补丁→验证）
- [AC-02] 证据包含 UI 追踪/API 调用/后端 traceId/数据状态
- [AC-03] 修复后重新构建再验证
- [AC-04] 最终状态显式声明（ready_to_commit/escalated/reverted）
- [AC-05] 联调基于接口文档
- [AC-06] 接口变更同步更新文档和前端
- [AC-07] 联调问题记录根因
