docs: 改为全程自动推进，开发中不再向负责人提问

2026-09-30 05:31:46 +08:00
parent 7c7fb3b155
commit 4bdeb07a09
3 changed files with 31 additions and 25 deletions
@@ -1,8 +1,8 @@
 # 实现与文档的偏差

-开发中凡是实现和 [PRD.md](./PRD.md)、[DEVELOPMENT.md](./DEVELOPMENT.md) 不一致的地方，都记在这里，交给负责人审核。
+开发中凡是实现和 [PRD.md](./PRD.md)、[DEVELOPMENT.md](./DEVELOPMENT.md) 不一致的地方，以及文档没写清、开发中自己拿主意的地方，都记在这里，交给负责人事后审阅。开发全程自动推进，记下来就继续，不等审阅。

-每条写清：日期、原条款（文档和小节）、实际做法、原因、影响。各线只写自己那一节，避免多条线同时改同一段。
+每条写清：日期、原条款（文档和小节）、实际做法、原因、备选方案、影响。各线只写自己那一节，避免多条线同时改同一段。

 ## 总控 L

@@ -15,11 +15,11 @@
 下面全部满足才算交付：

 1. `main` 上 `task check`（构建、代码检查、单元测试）和全部集成测试通过。
-2. PRD 第 10 节 F01–F23 每条都有验收结果：通过；或未测，写明原因并经负责人认可。
+2. PRD 第 10 节 F01–F23 每条都有验收结果：通过；或未测，写明原因，列进交付说明供负责人事后审阅。
 3. 四种 SDK 都通过 DEVELOPMENT 第 9 节的接入清单。
 4. DEVELOPMENT 第 13 节的弱网、崩溃、压测、端到端测试做完并有报告。
 5. 二进制（`linux/amd64`、`linux/arm64`、`windows/amd64`）和 Docker 镜像（amd64、arm64）能按文档启动；镜像已推到 `git.asio.asia/nixevol/nixmsg`。
-6. 和文档不一致的实现都写进 `docs/DEVIATIONS.md`，并经负责人确认。
+6. 和文档不一致的实现、开发中自己拿的主意，都写进 `docs/DEVIATIONS.md`（写明原因和备选方案），并汇总进交付说明，供负责人事后审阅。
 7. 最终代码按第 7 节审核过，打上 `v0.1.0` 和 `sdk/go/v0.1.0` 标签并推送；npm、PyPI、Maven 三个 SDK 包已发布到 Gitea 包仓库。

 ## 2. 资料
@@ -28,7 +28,7 @@
 - `docs/DEVELOPMENT.md`：实现规范。第 5 节的库用法和第 15 节「不要这样做」必须看。
 - `docs/TASKS.md`：本文件。
 - MemRelay 项目记忆（项目 NixMsg，ID `25464650-ed5d-440e-b362-190f2852d451`）：已确认的决定、技术栈选型、依赖库行为核对结论，以及各线的进度检查点。随时可以查。
- 文档没写清或互相矛盾时，停下来问总控；总控拿不准的问负责人。不要自己改 PRD 的产品行为。
+- 负责人已授权全程自动（第 9 节）。文档没写清或互相矛盾时不要停下来问，按和 PRD、DEVELOPMENT、PRD 第 9 节已确认决定最一致、最稳妥的做法自己定，写进 `docs/DEVIATIONS.md`（原因和备选方案）；不改 PRD 的产品行为。子 Agent 定不了的写进报告，由总控定。

 ## 3. 环境

@@ -57,7 +57,7 @@
 - 一功能一验证一提交：做完一个能验证的小功能，就补测试、跑 `task check`、提交，并推送到自己的远端分支。
 - 提交信息：`type: 中文一句话描述`，type 取 feat、fix、refactor、style、docs、test、chore、revert。
 - 不提交：构建产物、`web/dist`、数据库文件、证书和私钥、任何密码或令牌、`aidocs/`。
- 只改自己线负责的目录（第 5 节）。必须动别人的目录时，先告诉总控，改动尽量小。
+- 只改自己线负责的目录（第 5 节）。必须动别人的目录时，改动尽量小，并在提交说明和报告里写明。

 ### 4.2 共享文件

@@ -69,7 +69,7 @@
 | `cmd/nixmsg/wire.go`（组装各模块） | 各线只加自己的注册代码；冲突时两边都保留 |
 | `Taskfile.yml` | 总控维护；各线自己的任务写在 `taskfiles/<线名>.yml`，由主文件引入 |
 | `docs/DEVIATIONS.md` | 按线分节，各线只写自己那节 |
-| `docs/PRD.md`、`docs/DEVELOPMENT.md`、`docs/TASKS.md` | 只有总控改，而且要先得到负责人同意 |
+| `docs/PRD.md`、`docs/DEVELOPMENT.md`、`docs/TASKS.md` | 开发期间不改 PRD 的产品行为；DEVELOPMENT、TASKS 只有总控能改（例如修正写错的地方），改了什么写进 `docs/DEVIATIONS.md` |

 ### 4.3 合并进 main

@@ -89,7 +89,7 @@

 | 线 | 负责目录 | 主要内容 |
 |---|---|---|
-| 总控 L | 根目录配置、`cmd/nixmsg/wire.go`、`internal/protocol`、迁移 `0001`、`test/harness`、`docs/` | 阶段 0、审阅合并、集成验证、最终验收 |
+| 总控 L | 根目录配置、`cmd/nixmsg/wire.go`、`internal/protocol`、迁移 `0001`、`test/harness`、`docs/` | 阶段 0（派子 Agent 做）、审阅合并、集成验证、最终验收和发布 |
 | 平台 P | `cmd/nixmsg`（`wire.go` 除外）、`internal/config`、`internal/store`（`0001` 除外）、`internal/auth` | 配置和命令、写入合并、密码哈希池、令牌和锁定计数、指标注册 |
 | 连接 N | `internal/listener`、`internal/broker` | 端口识别、TLS、WebSocket、mochi、登录与会话令牌、连接表、握手 |
 | 消息 M | `internal/app/message` | 提交、分发、推送、确认、撤回、回执、清理、启动恢复 |
@@ -119,7 +119,7 @@ flowchart LR
    V --> Z[阶段3 总控 审核与交付]
 ```

- **阶段 0**（只有总控，串行）：T0.1–T0.5。全部合进 main 并推送后才开阶段 1。
+- **阶段 0**（总控负责，按第 8.2 节分三步派子 Agent 做）：T0.1–T0.5。全部合进 main 并推送后才开阶段 1。
 - **阶段 1、2**（并行开发、联调和验收）：按第 8.2 节分四波，由总控派子 Agent 执行。前两波以各线开发为主，后两波以 SDK 接入清单、端到端测试、验收、弱网和压测为主。每波结束由总控审核、合并、验证；发现的问题开 `fix/` 分支，交回原负责线修。
 - **阶段 3**（只有总控）：全量回归、审核、偏差确认、打标签交付。

@@ -326,7 +326,7 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语

 **Z2 审核**：按本文第 7 节清单逐项审核；做安全检查（日志和管理接口里没有正文、密码、令牌）；检查依赖的许可证。

-**Z3 交付**：汇总 `docs/DEVIATIONS.md` 并请负责人确认；打 `v0.1.0` 和 `sdk/go/v0.1.0` 标签并推送；按本文第 3 节创建发布令牌，把 npm、PyPI、Maven 三个 SDK 包发布到 Gitea 包仓库，把两个架构的镜像推到 `git.asio.asia/nixevol/nixmsg`（版本号标签和 `latest`）；构建三个平台的二进制；写交付说明（功能清单、验收结果、已知问题）。
+**Z3 交付**：汇总 `docs/DEVIATIONS.md` 写进交付说明，供负责人回来审阅，不等确认；打 `v0.1.0` 和 `sdk/go/v0.1.0` 标签并推送；按本文第 3 节创建发布令牌，把 npm、PyPI、Maven 三个 SDK 包发布到 Gitea 包仓库，把两个架构的镜像推到 `git.asio.asia/nixevol/nixmsg`（版本号标签和 `latest`）；构建三个平台的二进制；写交付说明（功能清单、验收结果、已知问题）。

 ## 7. 审核清单

@@ -342,41 +342,45 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语

 ## 8. 负责人操作说明（Cursor Multitask 模式）

-负责人只给总控发一段提示词。总控先自己完成阶段 0，再分四波派出子 Agent 并行开发；每个子 Agent 在独立的工作树和分支里工作，每波结束由总控审核、合并、验证，最后执行阶段 3。用本地 Agent：仓库在自建的 Gitea 上，Cursor 的云端 Agent 只支持 GitHub、GitLab 等托管平台，而且用不了本机的 Docker。
+负责人只给总控发一段提示词，之后全程自动，不再向负责人提问。总控分波派出子 Agent 并行开发（阶段 0 也由子 Agent 完成），每个子 Agent 在独立的工作树和分支里工作；每波结束由总控审核、合并、验证，最后执行阶段 3 并发布。用本地 Agent：仓库在自建的 Gitea 上，Cursor 的云端 Agent 只支持 GitHub、GitLab 等托管平台，而且用不了本机的 Docker。

 ### 8.1 负责人要做的

-1. 在 Cursor 里新建一个 Agent，模型选 Grok，切到 Multitask 模式，把下面的提示词原样发出。
-2. 总控每完成一波会汇报一次。它问产品问题、请你确认偏差（`docs/DEVIATIONS.md`）时再答复，其余时间不用盯着。
-3. 中途断了（会话太长、机器重启等），新开一个 Multitask 会话再发一次同样的提示词。总控会看 MemRelay 检查点和 git 记录，从断点继续。
+1. 在 Cursor 里新建一个 Agent，模型选 Grok，切到 Multitask 模式，把下面的提示词原样发出，之后就可以离开。
+2. 总控不会停下来问你。每完成一波，它会在对话里留一段汇报；它自己拿的主意和与文档不一致的地方都记在 `docs/DEVIATIONS.md`，最后汇总进交付说明，回来后审阅即可。
+3. 回来时如果发现它停在半路（例如会话太长被截断、机器重启），新开一个 Multitask 会话再发一次同样的提示词。总控会看 MemRelay 检查点和 git 记录，从断点继续。
 4. 并行 N 个子 Agent，用量大约是 N 倍。Cursor 默认整台机器最多保留 25 个工作树，超出会删掉最旧的，所以总控合并后要及时删掉用完的工作树；需要时在设置里调大 `cursor.worktreeMaxCount`。

 提示词：

 ```text
-你是 NixMsg 项目的总控 Agent，工作目录 e:\code\NixMsg（仓库 https://git.asio.asia/nixevol/NixMsg.git，主分支 main）。目标：用多个子 Agent 并行，把整个系统开发、测试到交付状态。
+你是 NixMsg 项目的总控 Agent，工作目录 e:\code\NixMsg（仓库 https://git.asio.asia/nixevol/NixMsg.git，主分支 main）。目标：用多个子 Agent 并行，把整个系统开发、测试、发布到交付状态。负责人不在，全程自动完成：中途不要向负责人提问，也不要等回复。

-开工前：按协作规则读 MemRelay 项目记忆（项目 NixMsg）和最新检查点，看 git log，再完整阅读 docs/PRD.md、docs/DEVELOPMENT.md、docs/TASKS.md。如果前面的阶段或波次已经完成，从断点继续，不要重做。TASKS.md 第 8.2 节是你的编排计划，第 8.3 节是子 Agent 提示词模板，第 7 节是审核清单，严格照做。
+开工前：按协作规则读 MemRelay 项目记忆（项目 NixMsg）和最新检查点，看 git log，再完整阅读 docs/PRD.md、docs/DEVELOPMENT.md、docs/TASKS.md。如果前面的阶段或波次已经完成，从断点继续，不要重做。TASKS.md 第 8.2 节是编排计划，第 8.3 节是子 Agent 提示词模板，第 7 节是审核清单，严格照做。

 执行顺序：
-1. 阶段 0 由你自己完成（T0.1–T0.5），全部验证通过后快进合并进 main 并推送。
-2. 按第 8.2 节的四波依次推进。每一波在同一条消息里同时启动这一波的全部子 Agent；每个子 Agent 必须在各自独立的环境里运行（独立工作树和独立分支，each in its own environment），用和你相同的模型；用第 8.3 节模板把它的线、任务、负责目录、要读的文档小节和要返回的内容写清楚，因为子 Agent 看不到你的上下文。子 Agent 报告的工作路径如果是主工作区而不是独立工作树，立即停下这一波，改为逐个串行执行。
-3. 每一波的子 Agent 全部返回后：逐个按第 7 节审核；按第 8.2 节的合并顺序 rebase 后快进合并进 main，每合并一个跑一次 task check，全部合并后跑集成测试，再推送 main。审核或合并不通过的，让原来的子 Agent 接着修（resume），或者新开一个修复子 Agent（fix/ 分支），修好再合并。合并后删掉对应工作树，在 MemRelay 存检查点，然后用几句话向我汇报：合并了什么、测试结果、遗留问题。
-4. 四波都完成后执行阶段 3（Z1–Z3）：全量回归、审核、汇总 DEVIATIONS 请我确认，然后打标签、发布 SDK 和镜像、写交付说明。
+1. 按第 8.2 节从阶段 0 开始，一波一波推进。每一波在同一条消息里同时启动这一波的全部子 Agent；每个子 Agent 必须在各自独立的环境里运行（独立工作树和独立分支，each in its own environment），用和你相同的模型；用第 8.3 节模板把它的线、任务、负责目录、要读的文档小节和要返回的内容写清楚，因为子 Agent 看不到你的上下文。子 Agent 报告的工作路径如果是主工作区而不是独立工作树，这一波改为逐个串行执行。
+2. 每一波的子 Agent 全部返回后：逐个按第 7 节审核；按第 8.2 节的合并顺序 rebase 后快进合并进 main，每合并一个跑一次 task check，全部合并后跑集成测试，再推送 main。审核或合并不通过的，让原来的子 Agent 接着修（resume），或者新开一个修复子 Agent（fix/ 分支），修好再合并。合并后删掉对应工作树，在 MemRelay 存检查点，在对话里写几句本波汇报（合并了什么、测试结果、遗留问题），然后不要结束，直接进入下一波。
+3. 四波都完成后执行阶段 3（Z1–Z3）：全量回归、审核，把 DEVIATIONS 汇总进交付说明，打标签、发布 SDK 和镜像、写交付说明。这些全部完成后才结束。

-规则：main 只由你合并，任何时候都要构建和测试全绿；子 Agent 不能再派生子 Agent，只做自己那条线；产品行为有疑问、要改 PRD，或要做删除数据之类的破坏性操作时先问我，其余自己判断推进，不用每一步等我确认。
+规则：
+- 需要拿主意时，按和 PRD、DEVELOPMENT、PRD 第 9 节已确认决定最一致、最稳妥的做法自己决定，写进 docs/DEVIATIONS.md（写明原因和备选方案），不改 PRD 的产品行为。
+- 卡住的问题先换思路解决；实在解决不了就记进遗留问题，继续推进其余工作，最后在交付说明里写清楚。
+- main 只由你合并，任何时候都要构建和测试全绿；子 Agent 不能再派生子 Agent，只做自己那条线。
+- 不做破坏性操作：不删除业务数据和别人的文件，不强推、不改写 main 的历史，要撤销就用 git revert；清理自己建的分支、工作树、容器和测试数据可以直接做。
+- 具体的开发、调试、修复都交给子 Agent，你只做编排、审核、合并和验证；少读大段输出，保持自己的上下文精简，避免中途被截断。
 ```

 ### 8.2 编排计划（总控照此执行）

 | 波次 | 同时启动的子 Agent（线：任务） | 合并顺序 |
 |---|---|---|
-| 阶段 0 | 不派子 Agent，总控自己做 T0.1–T0.5 | — |
+| 阶段 0 | 分三步，每步合并后再开下一步：先 L：T0.1；再同时 L：T0.2、L：T0.3、L：T0.5；最后 L：T0.4 | 按步骤顺序；第二步里 T0.2 → T0.3 → T0.5 |
 | 第 1 波 | P：P1–P4；N：N1–N2；M：M1；I：I1；A：A1；W：W1–W3（用假数据）；Q：Q1 和 Q4 的镜像骨架；S1：Go、JS 的任务 1–3；S2：Python、Java 的任务 1–3 | P → N → M → I → A → W → Q → S1 → S2 |
 | 第 2 波 | N：N3；M：M2–M4；I：I2–I4；A：A2；Q：已合并功能的验收用例（Q2 的第一部分） | N → M → I → A → Q |
 | 第 3 波 | I：I5；A：A3；S1：Go、JS 的任务 4–5；S2：Python、Java 的任务 4–5；Q：补齐 Q2，做 Q3 | I → A → S1 → S2 → Q |
 | 第 4 波 | W：W4；Q：Q4 定稿、Q5 | W → Q |
-| 阶段 3 | 不派新的开发线，总控自己做 Z1–Z3；发现问题派修复子 Agent（`fix/` 分支） | — |
+| 阶段 3 | 总控负责 Z1–Z3：回归中发现的问题派修复子 Agent（`fix/` 分支），打标签、发布等收尾由总控执行 | — |

 - 每一波只依赖之前已经合进 main 的成果。同一波里依赖别的线还没合并的功能时（例如第 1 波的 A1、I1 用到 P3、N1，第 2 波的 I2、I3 用到 N3，A2 用到 I5），先用 T0.4 的接口和假实现写代码和单元测试，合并时由总控接上真实实现；需要真实实现的集成测试放到下一波补上。
 - 同一波的子 Agent 互相看不到对方的改动，只能看到这一波开始时的 main。
@@ -392,7 +396,7 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语

 要做：按顺序完成 {任务号}，只改 {负责目录}。这一波里别的线还没合并的功能，用 T0.4 的接口和假实现。

-规则：一功能一验证一提交（补测试 → task check 通过 → 提交 → 推送自己的分支）；提交信息用「type: 中文一句话」；测试用随机端口和临时目录；缺工具用 scoop 安装；实现和文档不一致的，写进 docs/DEVIATIONS.md 你那一节；不能再派生子 Agent；产品行为有疑问就停下来写进报告，不要自己改 PRD。
+规则：一功能一验证一提交（补测试 → task check 通过 → 提交 → 推送自己的分支）；提交信息用「type: 中文一句话」；测试用随机端口和临时目录；缺工具用 scoop 安装；实现和文档不一致的，写进 docs/DEVIATIONS.md 你那一节；不能再派生子 Agent；文档没写清或有疑问时，按和 PRD、DEVELOPMENT、PRD 第 9 节已确认决定最一致的做法实现，写进 DEVIATIONS 你那一节和报告，不要停下来等回复，也不要改 PRD；不做破坏性操作（不删别人的文件和数据，不碰 main）。

 完成后返回：1）分支名和工作树路径；2）提交列表；3）每个任务的完成情况、验证命令和结果；4）写进 DEVIATIONS 的内容；5）没做完或拿不准的地方。返回前确认分支已推送、工作区干净。
 ```
@@ -402,3 +406,4 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语
 - 2026-09-30：允许各开发 Agent 在 rebase 后用 `git push --force-with-lease` 更新自己的 `feat/*`、`fix/*` 远端分支；`main` 任何时候都不许强推。
 - 2026-09-30：SDK 发布到 Gitea 包仓库，镜像推到 `git.asio.asia/nixevol/nixmsg`；本期不做 CI；许可证为专有，源码仓库和发布物公开可读（DEVELOPMENT 第 2.1 节、第 9 节、第 11.4 节）。
 - PRD 第 9 节的默认规则 D1–D33 已全部确认，开发中不再等待确认；和文档不一致的实现按第 4.2 节写进 `docs/DEVIATIONS.md`。
+- 2026-09-30：负责人授权全程自动开发。开发、测试、发布过程中不向负责人提问、不等回复；需要拿主意时，按和 PRD、DEVELOPMENT、已确认决定最一致、最稳妥的做法自己定，写进 `docs/DEVIATIONS.md`（原因和备选方案），不改 PRD 的产品行为；不做破坏性操作；解决不了的问题记进遗留问题，继续推进其余工作。