事故归档（INCIDENTS）

制度来源：统一整备路线图.md U0 #3（承接三语化整备计划 S2.5-④）。制度动因：第二次 seek 泄漏事故（2026-09-12 补录前）零留痕——无报告、无 CHANGELOG、 无复现用例，防线对宿主 RSS/磁盘零观测。没被记录的事故，连"发生过"都不存在。

归档规则

1. 任何 GB 级资源事故必须归档（内存/RSS/页面文件/磁盘），无论是否已修复；
2. 事故发现后当天建档（状态可为"未修复"），修复后回填"修复验证"小节；
3. 归档不粉饰：峰值数字、留痕缺口、根因不确定性都必须如实记录；
4. 与 CHANGELOG 的分工：CHANGELOG 记"修复了什么"，本目录记"发生过什么"——修复未完成的事故只在这里。

归档模板

# INCIDENT-YYYY-MM-<短名>：<一句话标题>

| 字段 | 内容 |
|------|------|
| 状态 | 未修复（排期：<批次>）/ 已修复（<commit>）/ 已缓解（<说明>） |
| 发现方式 | <防线拦截 / 用户观察 / 人肉感知 / 巡检> |
| 影响面 | <内存 / 磁盘 / 可用性 / 数据正确性> |

## 现象
<用户或工具观察到什么，何时，什么条件下>

## 峰值与量级
<实测数字；没有实测就写"未测量"+ 为什么。禁止编造。>

## 最小复现
<代码/操作序列；工具脚本路径（如 scripts/replay/*.py）>

## 根因
<机制层面为什么，file:line；不确定性如实说明>

## 修复验证
<修复 commit、回归用例、复跑证据；未修复则写排期>

## 留痕缺口复盘
<当时为什么没被防线/流程拦住，制度上补了什么>

归档索引