# 生命周期

> 五个阶段、门禁与拍板、项目文档

## 五个阶段

*每个项目走同一条路：DESIGN → DEVELOP → VERIFY → DEPLOY → MAINTAIN。阶段记在服务器上，模型不能自己换阶段。*

1. **DESIGN**: 问清楚，写需求、架构、计划
2. **DEVELOP**: 按计划一个任务一个任务做
3. **VERIFY**: 逐条验收，独立审查
4. **DEPLOY**: 发布，并确认真的在线
5. **MAINTAIN**: 上线之后的每一次改动

| 阶段 | 做什么 | 模型 | 出口 |
| --- | --- | --- | --- |
| DESIGN | 先问 5 到 10 个关键问题；在 DESIGN.md 写 `## Requirements`（R1..Rn）和 `## Architecture`（逐个模块的规格、影响分析、依赖顺序），再写与之一一对应的 PLAN.md | Design | A → B → C → develop |
| DEVELOP | 一轮做一个 PLAN.md 任务，验收项通过就勾上 `[x]`，做完自动开始下一个任务 | Dev | verify |
| VERIFY | 需求逐条追溯、集成检查、发现的问题、没能验证的项、发布建议，写进 VERIFY.md；必须经过一次独立审查 | Dev | deploy |
| DEPLOY | 走项目自己的发布方式，并检查发布出去的东西真的在服务；结果记进 STATUS.md 与 VERIFY.md | Dev | maintain |
| MAINTAIN | 先给请求定大小：小事直接做；中等的先改 DESIGN / PLAN，过 Gate C 再开发；大的回到 DESIGN | Dev | — |

每一轮的系统提示里只放当前阶段的做法。新项目从 DESIGN 开始；已有项目按 STATUS.md 里写明的阶段接上。

## 门禁与拍板

*阶段不会自己往前走。每一道门都是一张卡片，你点了「批准」它才过去。*

| 门 | 名称 | 批准之后 |
| --- | --- | --- |
| A | 需求 | 记下需求已确认，仍在 DESIGN |
| B | 架构 | 记下架构已确认，仍在 DESIGN |
| C | 执行计划 | PLAN.md 作为文件卡片发进聊天，大家读的是真文件 |
| develop | 开工 | 进入 DEVELOP |
| verify | 开始验收 | 进入 VERIFY |
| deploy | 上线 | 进入 DEPLOY |
| maintain | 进入维护 | 进入 MAINTAIN |
| design | 回到设计 | 退回 DESIGN，A / B / C 清空 |

A、B、C 只记录批准，不换阶段；DESIGN 里的顺序是死的：A → B → C → develop。其余的门可以从任何阶段向前或向后申请，但不能申请自己当前所在的阶段。批准那一刻，服务器会再检查一次这道门是否仍然成立，并把阶段和检查点写回 STATUS.md。

门禁卡由引擎席的 `phase_gate` 发出，两个按钮：「批准」和「要求修改」；也可以直接写一段反馈，原文回到模型手里。卡片没有超时，等多久都行。

### 往回拨

项目所有者可以在阶段条上点一个更早的阶段，或者批准一道往回的门。退回 DESIGN 会清掉 A / B / C，并暂停 Auto-Run。随后服务器跑一轮文档对齐：从阶段条拨回的只改文档、不碰代码；从门禁拨回的改完文档接着做新的工作；退回 DESIGN 时，PLAN.md 标记为已被取代，任务块保留。

## 项目文档

*项目的状态写在仓库里的几份 Markdown 里。它们只描述现在的状态，历史留在 git 里。*

| 文件 | 装什么 | 谁来写 |
| --- | --- | --- |
| STATUS.md | 当前状态的简短快照：阶段、检查点、最近一步、卡点 | 阶段与检查点由服务器写，其余由模型写 |
| DESIGN.md | `## Requirements`（R1..Rn）与 `## Architecture`，只描述现在的设计 | DESIGN 阶段；之后契约变了就原地改写 |
| PLAN.md | 执行账本：任务块、验收勾选、`Verify:` 脚本 | DESIGN 写计划，DEVELOP 逐项勾，Auto-Run 每个条目一块 |
| VERIFY.md | 验收记录：需求追溯、集成检查、问题、未验证项、发布建议 | VERIFY 阶段 |
| AUDIT.md | 当前队列条目的根因、发现、修复和真实的验证证据 | Auto-Run |
| ARCHITECTURE.md | 大项目的架构契约，与 DESIGN.md 同等对待 | 契约变了才改 |

### 任务块

```
### T1: <短的祈使句标题> [S]
- Goal: 这个任务之后多了什么
- Modules: 动到的文件 / 目录
- Requirements: R1, R3
- Acceptance:
  - [ ] 可观察、可测试的验收项
  - [ ] ...
- Verify: 怎么证明（命令 / 手动检查）
```

大小 `[S|M|L]`：一个任务必须在一段集中的会话里做完，大了就拆；任务按依赖排序，每条需求至少被一个任务覆盖。队列条目的块多一行 `Item:` / `Items:`，宿主按这一行（不看标题）找到它，并运行 `Verify:` 里列出的脚本。

### 规模上限

- **STATUS.md**: 16 KB · 目标
- **PLAN.md · AUDIT.md · VERIFY.md**: 各 48 KB · 目标
- **DESIGN.md**: 160 KB · 只防无限增长
- **ARCHITECTURE.md**: 640 KB · 只防无限增长

账本类文件超了上限，说明里面还留着做完或过时的内容，该删；契约类文件的上限只拦增长，不能为了压体积删掉仍然有效的契约。超了不拦，下一轮提醒。

### 记录规则

- 一件事变了，就在原处改写或删掉旧说法，不在旁边加一段「更新」。
- 收尾前扫一遍：退役的名字、开关、路径，在文档和相关代码注释里还有没有被当成现状。
- 还没做完的事先挪到它的去处（代码注释、队列、STATUS.md），再删那段话。
- 文档里不写带日期的变更日志，提交信息就是变更日志。
- 同一节在一份文档里只出现一次。

> 同一套规则同时写进引擎席、对话席和 Auto-Run 的提示里，所以不管谁来改文档，口径都一样。

### Step 面板

服务器盯着 STATUS / PLAN / VERIFY / DESIGN 这几份文件，改动后 300 ms 内重新解析：STATUS.md 的阶段、最近一步和卡点，PLAN.md 与 VERIFY.md 按标题分组的勾选框，实时出现在右侧的 Step 面板上。