docs: 改为 Multitask 模式的单段提示词和分波编排

docs/TASKS.md

@@ -2,7 +2,7 @@
 
 | 项 | 内容 |
 |---|---|
-| 版本 | 0.2 |
+| 版本 | 0.3 |
 | 日期 | 2026-09-30 |
 | 对应 | [PRD.md](./PRD.md) 0.5、[DEVELOPMENT.md](./DEVELOPMENT.md)（对应 PRD 0.5） |
 | 仓库 | https://git.asio.asia/nixevol/NixMsg.git，主分支 `main` |
@@ -46,7 +46,7 @@
 ### 4.1 分支、工作树和提交
 
 - `main` 只由总控合并，任何时候都要能构建、测试全绿。
-- 每条线在自己的 git 工作树（worktree）里、自己的分支上工作，不共用目录。用 Cursor 代理窗口的工作树功能创建，或者自己建：
+- 每条线在自己的 git 工作树（worktree）里、自己的分支上工作，不共用目录。Multitask 模式下由总控给每个子 Agent 开独立环境（第 8 节）；需要手动建时：
 
   ```bash
   git fetch origin
@@ -73,7 +73,7 @@
 
 ### 4.3 合并进 main
 
-1. 开发线：`git fetch` → `git rebase origin/main` → `task check` 和本任务的验证全过 → 推送分支 → 在 MemRelay 存一个检查点，标签 `ready-to-merge`，写清分支名、任务号、验证结果。
+1. 开发线：`git fetch` → `git rebase origin/main` → `task check` 和本任务的验证全过 → 推送分支 → 在 MemRelay 存一个检查点，标签 `ready-to-merge`，写清分支名、任务号、验证结果；Multitask 模式下，同样的内容也写进返回给总控的报告。
 2. 总控：按第 7 节清单审阅差异 → 在主工作区 `git merge --ff-only <分支>` → 跑 `task check` 和集成测试 → 推送 main → 通知各线 rebase。
 3. 不能快进（main 已经前进）时打回给开发线重新 rebase。冲突由开发线理解双方改动后解决。
 4. 功能分支 rebase 后，用 `git push --force-with-lease` 更新自己的远端分支（负责人已同意，见第 9 节）。只能用在自己的 `feat/*`、`fix/*` 分支上，不许用于别人的分支；任何人都不许强推 `main`。
@@ -120,11 +120,10 @@ flowchart LR
 ```
 
 - **阶段 0**（只有总控，串行）：T0.1–T0.5。全部合进 main 并推送后才开阶段 1。
-- **阶段 1**（并行）：P、N、M、I、A、W、Q 同时开工，共 7 个 Agent。S1、S2 可以一起开工，先做不依赖服务端的部分（连接状态机、发送队列、去重、本地检查和单元测试），也可以等 N、M 合进 main 再开，看机器负载。
-- **阶段 2**（联调和验收）：N、M、I、A 的核心任务合进 main 后，S1、S2 跑接入清单，W 接真实接口做端到端测试，Q 跑验收、弱网、崩溃和压测。发现的问题开 `fix/` 分支，交回原负责线修。
+- **阶段 1、2**（并行开发、联调和验收）：按第 8.2 节分四波，由总控派子 Agent 执行。前两波以各线开发为主，后两波以 SDK 接入清单、端到端测试、验收、弱网和压测为主。每波结束由总控审核、合并、验证；发现的问题开 `fix/` 分支，交回原负责线修。
 - **阶段 3**（只有总控）：全量回归、审核、偏差确认、打标签交付。
 
-下面每个任务都要做到：代码、测试、文档依据里的规则都满足；验证项全部通过；`task check` 通过。
+下面每个任务都要做到：代码、测试、文档依据里的规则都满足；验证项全部通过；`task check` 通过。任务说明里的「第 X 节」都指 DEVELOPMENT.md 的小节；指 PRD 或本文的会写明「PRD 第 X 节」「本文第 X 节」。
 
 ### 6.1 阶段 0：总控 L
 
@@ -325,9 +324,9 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语
 
 **Z1 全量回归**：在 main 上跑 `task check`、全部集成测试、端到端测试、四个 SDK 的接入清单、弱网和压测。
 
-**Z2 审核**：按第 7 节清单逐项审核；做安全检查（日志和管理接口里没有正文、密码、令牌）；检查依赖的许可证。
+**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. 审核清单
 
@@ -341,27 +340,61 @@ S1 先做 Go，再做 JS/TS；S2 先做 Python，再做 Java/Android。每种语
 - 新代码有测试；测试用随机端口和临时目录。
 - 没有引入技术栈以外的框架和中间件。
 
-## 8. 负责人操作说明
+## 8. 负责人操作说明（Cursor Multitask 模式）
 
-用本地 Agent。仓库在自建的 Gitea 上，Cursor 的云端 Agent 只支持 GitHub、GitLab 等托管平台，而且用不了本机的 Docker。
+负责人只给总控发一段提示词。总控先自己完成阶段 0，再分四波派出子 Agent 并行开发；每个子 Agent 在独立的工作树和分支里工作，每波结束由总控审核、合并、验证，最后执行阶段 3。用本地 Agent：仓库在自建的 Gitea 上，Cursor 的云端 Agent 只支持 GitHub、GitLab 等托管平台，而且用不了本机的 Docker。
 
-1. 按 `Ctrl+Shift+P`，执行 `Open Agents Window` 打开代理窗口。每新建一个 Agent，先在输入框的模型选择器里选好 Grok 模型再发第一条消息。
-2. 阶段 0：新建一个 Agent 当总控，就在主工作区 `e:\code\NixMsg` 里运行，发「总控提示词」。等它报告阶段 0 已经合进 main 并推送。
-3. 阶段 1：每条线新建一个 Agent，让它在自己的工作树里运行（在代理窗口新建时选工作树；找不到这个入口就让 Agent 按第 4.1 节自己建）。发「开发线提示词」，把 `<线名>` 换成 P、N、M、I、A、W、Q。建议同时跑的不超过 7 个；S1、S2 在机器有余力时再开，或者等 N、M 合进 main 后再开。
-4. 日常：在代理窗口侧栏看各 Agent 的进度和改动。某条线说可以合并时，告诉总控「合并 <分支名>」，或者让总控定期查 MemRelay 里标了 `ready-to-merge` 的检查点。Agent 提问时在它的对话里回答，拿不准的转给总控判断。
-5. 阶段 2、3：N、M、I、A 的核心任务合进 main 后，让 S1、S2、W、Q 按任务表联调和验收；最后告诉总控「开始阶段 3」。
-6. 注意：Cursor 默认整台机器最多保留 25 个工作树，超出会自动删掉最旧的，所以要各 Agent 勤提交、勤推送；需要时在设置里调大 `cursor.worktreeMaxCount`。
+### 8.1 负责人要做的
 
-总控提示词：
+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 工作。先按协作规则读 MemRelay 项目记忆，再完整阅读 docs/PRD.md、docs/DEVELOPMENT.md、docs/TASKS.md。现在完成 TASKS.md 阶段 0 的 T0.1 到 T0.5：每个任务一个分支，一功能一验证一提交，全部验证通过后快进合并进 main 并推送。完成后向我汇报，并告诉我可以开启阶段 1。之后你负责按 TASKS.md 第 4.3 节和第 7 节审阅、合并各线分支并跑集成验证，最后执行阶段 3。
+你是 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 节是审核清单，严格照做。
+
+执行顺序：
+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 和镜像、写交付说明。
+
+规则：main 只由你合并，任何时候都要构建和测试全绿；子 Agent 不能再派生子 Agent，只做自己那条线；产品行为有疑问、要改 PRD，或要做删除数据之类的破坏性操作时先问我，其余自己判断推进，不用每一步等我确认。
 ```
 
-开发线提示词：
+### 8.2 编排计划（总控照此执行）
+
+| 波次 | 同时启动的子 Agent（线：任务） | 合并顺序 |
+|---|---|---|
+| 阶段 0 | 不派子 Agent，总控自己做 T0.1–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/` 分支） | — |
+
+- 每一波只依赖之前已经合进 main 的成果。同一波里依赖别的线还没合并的功能时（例如第 1 波的 A1、I1 用到 P3、N1，第 2 波的 I2、I3 用到 N3，A2 用到 I5），先用 T0.4 的接口和假实现写代码和单元测试，合并时由总控接上真实实现；需要真实实现的集成测试放到下一波补上。
+- 同一波的子 Agent 互相看不到对方的改动，只能看到这一波开始时的 main。
+- 每个子 Agent 做完先推送自己的分支、确认工作区干净，再返回报告。
+- 同一波子 Agent 太多、机器吃不消时，分两批启动，合并顺序不变。
+
+### 8.3 子 Agent 提示词模板（总控把花括号换成具体内容再发）
 
 ```text
-你是 NixMsg 的开发线 <线名> Agent。先按协作规则读 MemRelay 项目记忆，再阅读 docs/TASKS.md（重点第 3、4、5 节和第 6 节里 <线名> 的任务）以及 PRD、DEVELOPMENT 的相关小节。在你自己的工作树和 feat/<任务号>-<简述> 分支上工作，只改本线负责的目录，按依赖顺序完成本线任务：一功能一验证一提交，并推送自己的分支。每个任务完成后 rebase 到 origin/main、跑全部验证，通过后在 MemRelay 存标签为 ready-to-merge 的检查点，然后告诉我。缺工具用 scoop 安装；文档有疑问先问我，不要自己改产品行为。
+你是 NixMsg 的开发线 {线名} 子 Agent，在自己独立的工作树和分支上工作，起点是 origin/main 的最新提交，分支按 feat/{任务号}-{简述} 命名。你看不到之前的对话，需要的信息都在仓库文档和 MemRelay 项目记忆（项目 NixMsg）里。
+
+先读：docs/TASKS.md 第 3、4、5 节和第 6 节里 {任务号} 的说明；docs/DEVELOPMENT.md 的 {相关小节}；docs/PRD.md 的 {相关功能编号}；.cursor/rules/nixmsg-dev.mdc。
+
+要做：按顺序完成 {任务号}，只改 {负责目录}。这一波里别的线还没合并的功能，用 T0.4 的接口和假实现。
+
+规则：一功能一验证一提交（补测试 → task check 通过 → 提交 → 推送自己的分支）；提交信息用「type: 中文一句话」；测试用随机端口和临时目录；缺工具用 scoop 安装；实现和文档不一致的，写进 docs/DEVIATIONS.md 你那一节；不能再派生子 Agent；产品行为有疑问就停下来写进报告，不要自己改 PRD。
+
+完成后返回：1）分支名和工作树路径；2）提交列表；3）每个任务的完成情况、验证命令和结果；4）写进 DEVIATIONS 的内容；5）没做完或拿不准的地方。返回前确认分支已推送、工作区干净。
 ```
 
 ## 9. 负责人已确认的协作事项