maintain-context

维护 agent 上下文

上下文文件的失效方式不是报错，而是安静地说谎：命令改了它还写着旧的，描述的架构已经不存在。而 agent 会照着旧信息自信地干活。所以需要定期体检。

流程

- [ ] 1. 跑自动检查脚本
- [ ] 2. 合并学习收件箱
- [ ] 3. 核对"事实类"内容
- [ ] 4. 核对"规则类"内容
- [ ] 5. 找缺口（孵化）
- [ ] 6. 删掉过期内容
- [ ] 7. 修文件并汇报

1. 自动检查

node scripts/audit-context.mjs

脚本查的是机械问题：AGENTS.md 行数与字节数、文档链接是否有效、技能 frontmatter 是否完整、TODO(init) 残留、上下文文件与代码的更新时间差、敏感文件是否被忽略、学习收件箱是积压还是长期闲置。

先把 error 全部修掉，warning 逐条判断。 其中 TODO(init) 是欠账：完整初始化应归零；轻量初始化留下的、带「轻量初始化未覆盖」的 TODO(init) 可以保留，由 /ship-change 按需补齐——体检会把轻量欠账单独计数，但它同样必须一直出现在 warning 里，不能被忘记。

2. 合并学习收件箱

把项目根目录的 docs/learning-inbox.md 里的条目逐条处理。对每条问同一个问题：「模型本来就猜得到吗？」 猜得到就删掉不合并——收件箱里塞进「要写测试」这种废话，是蒸馏环节的失误。

留下的，按条目类型分流，不要一律立即合并：

• 已确认事实（澄清、坑）：直接写进「建议去向」指向的文件，然后从收件箱里删掉这条。
• 待观察模式（纠正、流程）：先在收件箱里找有没有同类候选。没有 → 留在原地，等第二次出现再晋升；有 → 两条一起晋升为铁律或新技能，再删掉这两条。
• 纠正里违反后果不可逆或不可发现的高风险规则：不必等第二次，立即升级为 AGENTS.md 铁律，并删掉该条。

合并时别照单全收：一条「纠正」如果和现有铁律重复，就强化现有那条而不是新增；一条「坑」如果只是环境一次性问题，记在 troubleshooting 但别升级成铁律。

这就是本体系唯一的数据来源——纠正信号，不靠自觉统计。 技能触发次数、文档读取频率没有可靠的 hooks 能自动记录，任何统计文件都只会漂移；而「agent 哪里不懂、被纠正了什么、卡了多久」是任务里自然产生的，天然可靠。

3. 核对事实类内容

拿 AGENTS.md 逐行对照真实仓库：

声称	用什么核对
命令表	包管理文件里的 scripts / Makefile；并且真的跑一遍
目录地图	实际目录，看有没有新增顶层目录没写进去
术语表	代码里的实际命名
架构描述	docs/architecture.md 与实际的 import 关系
当前状态	docs/roadmap.md 与最近的提交

任何不一致，改文件，而不是改口径去迁就文件。

4. 核对规则类内容

对每一条铁律问三个问题：

1. 还成立吗？ 描述的模式代码里还在用吗？换掉的技术要删掉对应规则，不要留着"历史参考"。
2. 可执行吗？ "注意性能"没法验证；"金额出现浮点数就是错的"可以验证。不可执行的改写或删掉。
3. 值这个位置吗？ AGENTS.md 每条铁律每次对话都花钱。只有"违反了会造成事故"的才配留下，其余降级进 docs/。

对每个技能问：description 里有用户真实会说的话吗？ 宿主只靠 name 和 description 决定要不要加载正文，描述写成"帮助分析数据"这种，它永远不会被触发。

改动过任何一条铁律，就必须抽查 .agents/evals/behavior-cases.md。 宿主不会加载 evals，没有任何脚本会跑它——人工抽查是它唯一的生效路径，不做它就只是一份没人读的散文。挑 3 条与本次改动最相关的用例，把「输入」原样发一遍，看反应是否落在「期望」里。用例已经被新铁律推翻的，当场改掉或删掉；铁律新增却没有对应用例的，补一条。这一步的结果写进汇报的「已修」。

5. 找缺口（孵化）

下面的阈值与第 2 步是同一套规则：同一个信号第二次出现，就从对话升级成文件。 第 2 步已经把「纠正 / 流程」类的待观察候选留在收件箱里，这里回顾的是那些还没进收件箱、只在对话里出现过的信号。