# GC 式审计路由

> 平台无关的决策表。各平台适配器根据自身机制执行，不依赖 Claude Code 特定的 agent() 调用。

## 问题

Phase 式分步开发（DEV-PLAN.md）是线性切割，但代码逻辑不是线性的。Phase N 改了接口或打破了一个隐式假设，Phase N-1 可能坏掉而不自知。

## 决策表

每个 Phase 完成后，根据变更范围和影响度决定审计深度：

```
影响范围 = 0（纯新增，不修改任何已有接口/状态）
  → 跳过审计。只做编译验证。

影响范围 ≤ 2 个 Phase（改了局部接口，依赖方可数）
  → Minor GC：自审 + 反向审计直接依赖方。
    反向审计只查一件事：「我改的东西，你受影响吗？」

影响范围 ≤ 5 个 Phase（改了共享模块/工具函数）
  → Major GC：所有受影响 Phase 全量审查。

改了全局状态（全局变量/配置/数据库 schema/认证逻辑）
  → Full GC：全量回归。
```

## 变更跟踪卡（Card Table）

为了回答「影响范围是多少」，每个 Phase 完成后需要先输出一张变更卡：

```
Phase N 变更卡
  ├─ 新接口/类型: ...
  ├─ 改接口/类型: ...（涉及返回类型变化/参数增减）
  ├─ 改文件: ...
  ├─ 改了全局状态？是/否
  └─ 依赖方（已知）: Phase ...
```

这张卡是审计路由的输入，也是反向审计的上下文压缩——不需要全量 diff，只看依赖关系。

## 假设注册表

Phase 完成时强制回答三个问题，追加到项目的假设注册表：

```
1. 我写了什么「我假设它不会发生」的事情？
2. 如果这个假设被打破，哪些地方会坏？
3. 哪些接口/状态/行为被我改变了？
```

后续 Phase 写代码前先读假设注册表——如果新功能打破了旧假设，必须主动处理冲突。

## 执行方式（平台无关）

```yaml
# 可在 DEV-PLAN.md 的 Phase 定义中配置
Phase 3:
  audit_level: full_gc       # 改写基础设施 → 全量审计
  dependencies: [Phase 1, Phase 2]
  changed_interfaces:        # 人工标注（可选，辅助变更跟踪卡）
    - userService.getProfile
```

初次不准没关系——当一个 Minor GC 通过但后续发现冲突时，自动升级审计级别。

## 实际文件

- 变更卡：`.forge/phase-track/<phase-name>.md`（持久化，跨 session）
- 假设注册表：`.forge/assumption-registry.md`
- 决策表：本文（`gc-audit-routing.md`）
