# 项目文档重写流程

项目文档依据的规范变了，需要把**已有文档**迁移到新规范。

**按顺序执行，不要跳步。** 这个流程唯一不可违背的约束是：**不得因格式迁移而丢失信息。**

## 一、完整阅读新规范

读取本次注入给出的规范文件**全文**。

- **不要凭记忆**——规范可能已改动，你记忆里的是旧版
- 弄清它要求的结构、字段、书写单位、状态取值
- 特别注意它**新增**了什么、**去掉**了什么

## 二、完整阅读现有文档

读取项目文档**全文**，完整掌握其中已有的全部信息。

逐项清点：
- 现状描述
- 关联资产（链接、仓库、issue）
- 台账里的**每一条**事项：状态、日期、内容、会话引用

**先清点，再动手。** 边读边改会让你丢掉读到一半之后的内容。

## 三、按新规范重组

按新规范的结构重新组织内容。

**必须保留**：所有事实性内容——问题、决定、进展、结论、链接、会话引用。

**可以删除**：新规范明确不再要求的结构性文字、重复表述、与项目无关的旧格式残留。

**判断标准**：如果一条信息能帮助将来的人理解这个项目发生过什么，它就必须留下。

## 四、写回

把重组后的全文写回项目文档。

若某条信息在新规范下**归属不明确**：

- **保留原样**，并在其旁边加一行说明你为什么拿不准
- **不要擅自丢弃**——丢弃是不可逆的，而留给用户看是可逆的

若新规范要求某个字段而现有文档没有对应内容：

- 写 `<待补充>` 或留空，**不要编造**

## 五、完成后

- 不要顺手更新台账状态；重写不改内容语义，只改组织形式
- 如果发现新规范与某条既有信息**根本冲突**（例如状态取值不再存在），保留原值并用括号注明旧取值，在最终回复里向用户说明

## 不要做的事

- ❌ 不要因为"新规范没提"就删除一条事项
- ❌ 不要合并状态不同的事项
- ❌ 不要重新排序台账（除非新规范明确要求）
- ❌ 不要修改会话深链的 base64 部分