# 归档规则

## 1. 什么内容值得归档

只有具有中长期复用价值的信息，才值得进入长期记忆。

通常应归档的内容包括：

- 已确认的项目范围
- 里程碑结果
- 关键决策与取舍
- 重要风险与阻塞
- 验收结论
- 复盘结论
- 可复用 lesson
- 候选 engineering standard

通常不应归档的内容包括：

- 随意闲聊
- 情绪表达
- 低信息量进度噪音
- 未确认猜测
- 临时协调碎片
- 已经在别处明确保存过的重复内容

## 2. 先判断是否值得归档

归档前必须先回答：

1. 这份内容是否对未来有帮助？
2. 这份内容是否已经在现有文档中存在？
3. 这份内容是否只是短期沟通噪音？
4. 这份内容是否已经形成相对稳定结论？

若答案偏向“否”，则不归档。

## 3. 提升层级规则

### 项目层
适用于仅与某一个项目相关的信息。

应优先写入：
- `context.md`
- `roadmap.md`
- `reports.md`
- `decisions.md`
- `risks.md`

### lesson 层
适用于对未来项目可复用的团队经验。

满足以下条件时可提升为 lesson：

- 不是单个项目的偶然细节
- 对 Team Alpha 后续项目有指导意义
- 能归纳成“下次该怎么做”的规则

### engineering standard 层
只有在以下条件都满足时，才可升级到工程规范：

- 该规则具有跨项目复用价值
- 该规则具备稳定性，不是临时 workaround
- 该规则能明确降低后续项目出错概率
- 该规则应被团队长期遵守

## 4. 信息不足时的处理

若材料本身可能有价值，但不能明确归属到某个项目，则：

- 不归档
- 不猜测项目归属
- 不强行写到 lessons 或 standards

必须明确返回：

`信息不足，暂不归档；请补充 project-id 或项目名称。`

## 5. 项目优先原则

只要能明确归属某个项目，就优先写入该项目 initiative 目录。  
不要轻易越过项目层，直接写 lesson 或 engineering-standards。

顺序必须是：

1. 项目层
2. lesson 层
3. engineering standard 层

## 6. 边界规则

必须严格遵守以下边界：

- 禁止将项目代码写入 memory repo
- 禁止将公司级规范写入项目代码目录
- 禁止将原始大段聊天直接倾倒进长期记忆
- 能写摘要就不要写全量噪音
- 能追加就不要反复重写整个文档
- 未确认结论不要写成既定事实

## 7. 写入策略

默认优先：

- `append`：适合 reports / decisions / risks / lessons
- `create`：适合新建文件
- `overwrite`：除非明确修正错误，否则不建议使用

在没有充分理由时，不要覆盖已有长期记忆。

## 8. 常见错误模式

以下情况应视为归档错误：

- 把项目脚手架初始化到知识库路径
- 把会议闲聊原样写进 reports.md
- 把尚未确认的用户想法写成项目边界
- 把一次偶发问题直接升级成 engineering standard
- 把项目级经验写到 company/engineering-standards.md
- 把 lesson 写到错误层级，例如多一层无意义目录

## 9. 推荐判断口径

可以优先按以下口径判断：

### 归档
这份内容：
- 有明确事实
- 有未来复用价值
- 已形成稳定结论
- 可归类到某个项目或长期规则

### 不归档
这份内容：
- 只是过程噪音
- 只是临时讨论
- 信息不完整
- 没有明确归属
- 没有中长期价值