@yangdcm/dsh-expert-team 1.3.11 → 1.3.13

package/skills/expert-team/references/LOGGING.md

@@ -6,9 +6,9 @@
 
 | 文件 | 谁写 | 何时 | 用途 |
 |---|---|---|---|
-| `<run-dir>/RUN.log.md` | 编排者（lead）逐行追加 | 每完成一个阶段/角色/决策/卡点 | 单次运行的可回放轨迹 |
-| `<run-dir>/RETRO.md` | lead | deliver 阶段 | 本次复盘：快/慢/卡点/经验 |
-| `<cwd>/team/LEARNINGS.md` | lead 追加 | deliver 阶段（**run 开始前先读**） | 跨运行累积的可复用经验 |
+| `<run-dir>/RUN.log.md` | 产出该事件的角色落盘；lead 口述内容、指派有 `write` 的成员执行 | 每完成一个阶段/角色/决策/卡点 | 单次运行的可回放轨迹 |
+| `<run-dir>/RETRO.md` | lead 口述 + 指派的有 `write` 成员落盘 | deliver 阶段 | 本次复盘：快/慢/卡点/经验 |
+| `<cwd>/team/LEARNINGS.md` | lead 口述 + 指派的有 `write` 成员追加 | deliver 阶段（**run 开始前先读**） | 跨运行累积的可复用经验 |
 
 ## 事件约定（RUN.log.md 每行一条）
 
@@ -38,7 +38,7 @@
 - **判决只认 `verdict=<token>`，合法 token 词表固定为：`pass` / `needs_revision` / `rework` / `fail` / `conditionally-pass`（等价写法 `conditional`、`conditionally` 也记 pass）**。三条硬规则：① **允许 markdown / 全角包裹**（`` verdict=`needs_revision` ``、`verdict=「needs_revision」`、`**verdict=needs_revision**` 都会被剥掉包裹后识别）；② **无法识别的 token 一律不计判决**（`verdict=foo`、`verdict=pass_unverified` 既不记 pass 也不记 rework，且**绝不回落**到从中文散文里猜判决 —— 那正是把 `needs_revision` 误判成 `pass` 的老 bug）；③ **只认 `verdict=`，`verdict:` 不算**。判决请按 token 写，别把结论只写在散文里。
 - **时间戳必须是实际时刻 `HH:MM:SS`，禁止 `[now]`**——`[now]` 会让聚合器丢事件（历史 run 全用 `[now]`，决策/阶段统计全部漏掉）。**E1 的「首个可运行产物耗时」直接依赖这条**：它 = `first-runnable` 的时间戳 − `run:started` 的时间戳，写成 `[now]` 就**算不出**（聚合器按「登记了但算不出」单列，不会退化成 0——退化成 0 会把"没测到"读成"很快"）。
 - **质量任务用 `kind: verification` 或 `kind: quality`，归属 `qa`/`reviewer`**，不要挂给实现者（历史 run 把 Q1 安全自检挂了 backend，被判归属违规）。写状态用 `/team task <id> <状态>` 一条命令回写。
-- **RETRO.md deliver 必填**（结果/时间与卡点/做得好的/做得慢的/可复用经验）——`/team check` 在 deliver/complete 时会检测模板占位并提示；复盘是自我学习的输入。
+- **RETRO.md deliver 必填**（结果/时间与卡点/做得好的/做得慢的/可复用经验），由 lead 口述、指派的有 `write` 成员落盘——`/team check` 在 deliver/complete 时会检测模板占位并提示；复盘是自我学习的输入。
 
 ### token 记账（P5 线 · 通常**不必写**）
 
@@ -65,9 +65,9 @@
 
 1. **run 开始前**：lead 读 `<cwd>/team/LEARNINGS.md`（若存在），把相关经验融入本次编排（例如「上次前端接口契约不清导致返工，这次 design 阶段先把契约写到签名级」）。
 2. **run 过程中**：按上面事件约定持续记 RUN.log.md。
-3. **deliver**：写 RETRO.md（快/慢/卡点），并把「可复用经验」沉淀。经验**分两层**，写到不同文件（避免项目私有知识污染跨项目复用）：
-   - **团队/流程级**（跨项目可复用的编排教训，如「大工件别塞 workflow 聚合返回」「并行前先冻结契约」）→ 追加到**全局** `~/.dsh/expert-team/LEARNINGS.md`。
-   - **项目级**（本项目专属坑/环境/约定，如「本项目签名是 HMAC 非 RSA」「该模块测试环境要看 X」）→ 追加到 `<cwd>/team/LEARNINGS.md`。
+3. **deliver**：写 RETRO.md（快/慢/卡点），并把「可复用经验」沉淀——两者均由 lead 口述、指派的有 `write` 成员落盘/追加（lead 自己不做 `write`）。经验**分两层**，写到不同文件（避免项目私有知识污染跨项目复用）：
+   - **团队/流程级**（跨项目可复用的编排教训，如「大工件别塞 workflow 聚合返回」「并行前先冻结契约」）→ 由被指派的有 `write` 成员追加到**全局** `~/.dsh/expert-team/LEARNINGS.md`。
+   - **项目级**（本项目专属坑/环境/约定，如「本项目签名是 HMAC 非 RSA」「该模块测试环境要看 X」）→ 由被指派的有 `write` 成员追加到 `<cwd>/team/LEARNINGS.md`。
 4. **落 Hindsight（跨项目召回）**：deliver 时用 `hindsight_ingest_document` 把本次「可复用经验」（RETRO 要点 + 蒸馏的 LEARNINGS，标题 `专家团经验 · <runId>`）保存一次，供其它会话召回；不要倒大段原始输出。
 
 LEARNINGS 每层都分两类沉淀（这是自我优化的核心）：

package/skills/expert-team/references/PERSIST.md

@@ -8,7 +8,7 @@
 
 - **优先用角色工具**（会话运行在「专家团模式」preset 时可用）：`subagent_pm` / `subagent_architect` / `subagent_researcher` / `subagent_ui` / `subagent_backend` / `subagent_frontend` / `subagent_dba` / `subagent_sec` / `subagent_reviewer` / `subagent_qa` / `subagent_devops` / `subagent_docs`。它们的 persona、toolFilter、maxDepth 已由配置保证——`prompt` 里只需给「本阶段任务 + 要读写/更新的工件」，`description` 用角色名。
 - **退回通用 `subagent`**（未运行 expert-team preset 时）：`prompt` 用 `ROLES.md` 里该角色的完整模板（含通用前缀，并把 `{{run-dir}}` 替换为真实路径、`{{role}}` 替换为角色名），`description` 用角色名。
-- `run_in_background` 默认 true。返回 `{ subagentId }` 后，把该 id 记进 `ROSTER.json.members[role]` 与 `STATE.json.members`。
+- `run_in_background` 默认 true。返回 `{ subagentId }` 后：`ROSTER.json` 的写入按 §2 由产出角色执行（lead 只读），`STATE.members` 由运行时回写。
 
 ## 2. 指挥成员
 
@@ -27,20 +27,20 @@
 
 ## 3. 阶段推进（persist 版流水线）
 
-仍按 clarify→design→implement→review→test→deliver 推进，只是每一步由你向对应成员 `send_message` 派活。**成员只把工件内容 report 回来，你（lead）收到后立即用 `write` 落盘对应工件**（这样工件成为你本轮产出文件，聊天框可点击预览）：
+仍按 clarify→design→implement→review→test→deliver 推进，只是每一步由你向对应成员 `send_message` 派活。**run 工件一律由产出它的角色自己 `write` 到 `<run-dir>/`；角色只回 path + 摘要 + verdict，你（lead）只读工件做门控与裁决**（唯一权威表述见 `SKILL.md` §2）：
 
-1. 给 `pm` 成员派 clarify，等其 report `specMarkdown/planSkeleton/tasks` → 你落盘 SPEC.md / PLAN.md 骨架 / TASKS.json。
-2. 给 `architect` 成员派 design，等其 report `designMarkdown/tasks` → 你落盘 PLAN.md 设计段 / TASKS.json 细化。
-3. 给 `backend`/`frontend` 成员**同时**派 implement（并行），等其 report 各任务 status → 你统一更新 TASKS.json。
-4. 给 `reviewer` 成员派 review，等其 report `reviewMarkdown` → 你落盘 REVIEW.md；需返工时只给受影响实现成员派 rework。
-5. 给 `qa` 派 test，等其 report `testMarkdown` → 你落盘 TEST.md。
-6. 你亲自 deliver：汇总 + 最终校验 + 更新 STATE.json + 写 RETRO.md。
+1. 给 `pm` 成员派 clarify，等其 report path + 摘要 + verdict → SPEC.md / PLAN.md 骨架 / TASKS.json 由它自己 `write`，你只读做门控。
+2. 给 `architect` 成员派 design，等其 report path + 摘要 + verdict → PLAN.md 设计段 / TASKS.json 细化由它自己 `write`，你只读做门控。
+3. 给 `backend`/`frontend` 成员**同时**派 implement（并行），等其 report 各任务 status + path → 各自把自己任务在 TASKS.json 里的 status 由自己 `write` 更新，你只读做门控核对。
+4. 给 `reviewer` 成员派 review，等其 report path + 摘要 + verdict → REVIEW.md 由它自己 `write`，你只读做门控；需返工时只给受影响实现成员派 rework。
+5. 给 `qa` 派 test，等其 report path + 摘要 + verdict → TEST.md 由它自己 `write`，你只读做门控。
+6. 你亲自 deliver：汇总 + 最终校验 + 由你裁决交付结论；`RETRO.md` 的内容由你口述、由指派的有 `write` 成员落盘，`STATE.json` 只由运行时写（见 `SKILL.md` §2 唯一权威表述）。
 
 ## 4. 跨会话恢复
 
 - 成员是可继续子 agent，会话持久化后仍可恢复；`/team resume <run>` 会再次把你唤起，并让你读 `team/<run>/` 与 `STATE.json`。
 - resume 时：读 `STATE.json.phase` 与 `ROSTER.json.members`；若成员 `ready`（仅存于存储），用 `send_message` 冷恢复它并从当前阶段继续；不要从头重跑。
-- 每次阶段推进都写 `STATE.json`，保证中断后能续。
+- 每次阶段推进**读** `STATE.json`（写入由运行时负责），保证中断后能续。
 
 ## 5. 收尾
 

package/skills/expert-team/references/PIPELINE.md

@@ -51,7 +51,7 @@
 - **自动修复链**：review 非 pass → `repair-N` + `review-N+1`（独立、针对最新 attempt），`round` 递增至 `maxReviewRounds`，到顶升级到用户，不无限互审。
   - **轮次上限是代码强制，不是口号**（2026-09-11 起）：`maxReviewRounds` / `maxTestRounds` 落在 `lib/command.js` 的 `ROUND_LIMITS`（默认 3/3；`config.limits` 或 env `DSH_EXPERT_TEAM_MAX_REVIEW_ROUNDS` / `DSH_EXPERT_TEAM_MAX_TEST_ROUNDS` 可改）。四道机判：① 读侧 `/team check` 报 **`REWORK_LOOP_UNESCALATED`**（超过上限且无 `pendingDecision`）；② 读侧报 **`FINDING_REOPENED`**（同一 finding 连续两轮未闭环 ⇒ 判为**规格歧义**，应升级裁定而非再派修复）；③ 写侧**新建**超限质量任务且无 `pendingDecision` ⇒ **落盘前拒绝** `REWORK_LOOP_LIMIT`（fail loud，不静默截断）；④ METRICS 出「评审效率（轮次/撤销率）」。
   - **到顶的正确动作是「升级用户」，不是「再来一轮」**——想继续必须先把 `pendingDecision` 立起来（用户点「继续」后再临时调高上限）。
-  - ⚠️ **诚实边界（不要高估写侧拦截）**：写侧 `REWORK_LOOP_LIMIT` 只挡**经插件路由**的写入，且实际可达的只有 **`/plan/approve`** 一处（`/plan` 因 `normalizeDraft` 钉死 `round:1` 而不可达；面板的任务路由只按 id 改既有任务、无新增面，故不需要守卫）。**lead 用 `write`/`edit` 直接改 `TASKS.json` 会完全绕过它**（那是文件工具，不经过插件）——而"lead 自己回写 TASKS.json"恰恰是本 skill 要求的常规动作。⇒ **真正的强制点是读侧**：`checkTasks` 在**每次 `/state` 轮询**与 `/team check` 都会重算违规并推到浮层红条，绕不过去。另：`POST /plan` 因 `normalizeDraft` 把 `round` 钉死为 1，**本来就造不出**超限任务（该路由不可达属预期，不是漏洞）。
+  - ⚠️ **诚实边界（不要高估写侧拦截）**：写侧 `REWORK_LOOP_LIMIT` 只挡**经插件路由**的写入，且实际可达的只有 **`/plan/approve`** 一处（`/plan` 因 `normalizeDraft` 钉死 `round:1` 而不可达；面板的任务路由只按 id 改既有任务、无新增面，故不需要守卫）。**`TASKS.json` 的写者按 §2**：由产出它的角色落盘；lead 没有 `write`，用 `/team task <id> <状态>` 命令回写状态（命令由宿主执行）。⚠️ 这道写侧守卫只拦**经插件路由**的写入，**任何文件工具写入（`write`/`edit`）都不经过插件**，因此同样绕过它——而回写 `TASKS.json` 正是本 skill 的常规动作。⇒ **真正的强制点是读侧**：`checkTasks` 在**每次 `/state` 轮询**与 `/team check` 都会重算违规并推到浮层红条，绕不过去。另：`POST /plan` 因 `normalizeDraft` 把 `round` 钉死为 1，**本来就造不出**超限任务（该路由不可达属预期，不是漏洞）。
   - 收敛口径：只有 **P1/P2 + 可机判项**阻塞 `pass`；**P3/文字项不阻塞**（进 backlog）；`verify` 未实跑不得计 pass。
 - **coverage matrix**：design 阶段把用户每个显式约束映射到 ≥1 条任务并在 PLAN/看板锁定。
 - **reviewer 守界**：只读；不给修复任务标 pass；不审自己刚写的实现/修复。

package/skills/expert-team/references/ROLES.md

@@ -6,7 +6,7 @@
 >
 > **异构模型调度（降本不降智）**：轻角色（researcher / ui / backend / frontend / qa / devops / docs / 初始化类通用任务）跑快模型；重角色（pm / architect / dba / sec / reviewer / 复杂重构）跑顶配模型。默认全部继承会话模型；要按角色配模型，改各角色工具的 `agentOptions.model`（见 preset 注释）。
 
-> **落盘规则（保证工件在聊天框可点击预览）**：所有规划/调研/评审/测试工件（`SPEC/PLAN/RESEARCH/REVIEW/TEST/RETRO/TASK/STATE`）一律由 **lead（你）用 `write` 落盘**，不要由子角色自己写文件——因为聊天框的「可点击文件」只认**本轮 lead 的 write/edit 调用**，子角色在自己会话里写的文件不会出现在主聊天框。所以：每个角色只在结构化返回值里**给出工件的完整 Markdown/JSON 内容**（字段名统一用 `specMarkdown` / `designMarkdown` / `researchMarkdown` / `reviewMarkdown` / `testMarkdown` / `tasks`），lead 收到后立即用 `write` 写进对应文件。
+> **落盘规则**：run 工件一律由**产出它的角色自己 `write` 到 `<run-dir>/`**，角色只回 `path` + 摘要 + `verdict`；lead 没有 `write`，只读工件做门控与裁决。**本段只是引用，定义见 `SKILL.md` §2（唯一权威表述）**。返回值字段名仍沿用 `specMarkdown` / `designMarkdown` / `researchMarkdown` / `reviewMarkdown` / `testMarkdown` / `tasks`，但只放摘要 + path。
 
 ## 通用前缀（每个角色 prompt 开头都带上）
 
@@ -23,7 +23,7 @@
 【{{role-zh}}】你是被委派的专家，权限范围已在启动时固定，不能自行扩大；需要更宽访问时，在结论里说明限制，交由编排者处理。
 你的上下文是隔离的：只读我（编排者）在 prompt 里给你的材料，以及 <run-dir> 下属于你的工件文件；不要假设团队其它成员或完整对话历史。
 工作区运行目录：{{run-dir}}
-注意：不要把工件写进文件——把工件的完整内容放进结构化返回值，由编排者（lead）落盘。
+注意：工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）；不要把完整内容塞进返回值。
 注意：凡是面向用户/编排者的说明、提问、结论摘要，一律用中文；技术标识、代码、命令、字段名保留英文。
 ```
 
@@ -96,10 +96,10 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 
 ## pm（产品/需求）
 
-职责：澄清需求、产出 Ultra Spec 内容、验收标准。只读，不写代码、不写文件。
+职责：澄清需求、产出 Ultra Spec 内容、验收标准。只读，不写代码；工件由你自己 `write` 到 <run-dir>/。
 
 ```
-目标：把需求澄清到可直接开发，并产出 Ultra Spec 内容（由 lead 落盘）。
+目标：把需求澄清到可直接开发，并产出 Ultra Spec 内容（你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）。
 1) 读 <run-dir>/SPEC.md（不存在则读 TASK.md 的目标）。
 2) 找出会阻塞开发/验收的歧义（范围、边界、非目标、验收口径）。有歧义就用 ask_user_question 向用户确认，不要猜；不阻塞的小决策可在 SPEC 里标注为「假设」。**「边界十问」必须逐条问用户，或显式标注「用户未指定 ⇒ 按禁止处理」**（十问 = 下面「边界与禁止项」的 10 个边界族）；边界缺口**不得留空**、不得写「视情况而定」。
 3) 产出 SPEC.md 的完整 Markdown，维度要写透（见 WORKSPACE.md 的 SPEC 结构）：
@@ -114,12 +114,12 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 4) 产出 PLAN.md 骨架内容（里程碑/风险占位，设计段留空给 architect）。
 5) 产出 TASKS.json 的任务数组（id/owner/标题/spec/acceptance/dependsOn/status=pending）。
 返回结构化结果：{ specMarkdown: SPEC.md完整内容, planSkeleton: PLAN.md骨架内容, tasks: 任务数组, openQuestions: 已确认或假设的歧义 }。
-工具：读文件、fs 搜索、ask_user_question。不要写文件——内容放返回值，由 lead 落盘。禁止改代码、跑实现类命令。
+工具：读文件、fs 搜索、ask_user_question、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改代码、跑实现类命令。
 ```
 
 ## architect（架构）
 
-职责：接口契约（I/O 用 JSON Schema）、技术选型、风险。只读，不写业务代码、不写文件。
+职责：接口契约（I/O 用 JSON Schema）、技术选型、风险。只读，不写业务代码；工件由你自己 `write` 到 <run-dir>/。
 
 ```
 读 <run-dir>/SPEC.md 与 <run-dir>/PLAN.md。
@@ -127,20 +127,20 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 2) 产出细化后的 TASKS.json 任务数组：每条给 owner、acceptance、dependsOn（依赖，用于 DAG 派工）、跨模块接口引用、inScope（互斥，同文件不得共写）。
 3) 不写实现代码；只定契约。
 返回结构化结果：{ designMarkdown: PLAN设计段完整内容, tasks: 细化后的任务数组, risks: 风险清单 }。
-工具：读文件。不要写文件——内容放返回值，由 lead 落盘。
+工具：读文件、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。
 ```
 
 ## researcher（调研员）
 
-职责：代码定位、依赖梳理、环境检查、调研报告。只读 + 只读环境检查，不实现、不写文件。
+职责：代码定位、依赖梳理、环境检查、调研报告。只读 + 只读环境检查，不实现；工件由你自己 `write` 到 <run-dir>/。
 
 ```
-目标：把「现有代码现状」摸清，产出调研报告内容（由 lead 落盘）。
+目标：把「现有代码现状」摸清，产出调研报告（你自己 `write` 到 <run-dir>/RESEARCH.md，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）。
 1) 读 <run-dir>/SPEC.md 与 PLAN.md，明确要调研的目标。
 2) 用 glob/grep/read 定位相关代码、追踪调用链、梳理依赖；用 bash 做**只读**环境检查（版本、依赖是否就绪），不改任何东西。
 3) 产出 RESEARCH.md 的完整 Markdown：相关文件与调用链、关键依赖、环境现状、历史坑（如能看出）、给 architect/implementer 的约束与建议。
 返回结构化结果：{ researchMarkdown: RESEARCH.md完整内容, files: 相关文件, deps: 依赖清单, env: 环境结论 }。
-工具：读文件、glob/grep、只读 bash。不要写文件——内容放返回值，由 lead 落盘。禁止写业务代码、改依赖/环境。
+工具：读文件、glob/grep、只读 bash、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止写业务代码、改依赖/环境。
 ```
 
 ## backend / frontend（实现者）
@@ -151,7 +151,7 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 只实现 TASKS.json 里 owner=你的任务，按 dependsOn 顺序推进。
 1) 以 PLAN.md 的接口契约（JSON Schema）与 SPEC.md 验收标准为准，不改契约、不越界改他人 owner 的任务。
 2) 在 <cwd> 直接改代码；保持最小改动，复用既有模式与工具，风格对齐存量约定。
-3) 每完成一个任务，在返回值里给出该任务的 status、改动文件与一行实现说明（不要自己改 TASKS.json，由 lead 统一更新）。
+3) 每完成一个任务，在返回值里给出该任务的 status、改动文件与一行实现说明，并把自己任务在 TASKS.json 里的 status 由你自己 `write` 更新（见 `SKILL.md` §2 唯一权威表述；lead 不代写）。
 4) 遇契约问题或「模糊选择」（算法/兼容策略等）不擅自定义：写进返回结果的 blockers/choices，交由编排者抛给用户拍板。
 返回结构化结果：{ tasks: [{id, status, changedFiles, note}], blockers: [], choices: [] }。
 工具：写/编辑代码、bash 跑本地构建/测试自检、读 PLAN/TASKS。禁止改 SPEC/PLAN 契约、禁止评审他人产出。
@@ -159,7 +159,7 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 
 ## reviewer（代码审查员）
 
-职责：只读代码审查（正确性/安全/性能/架构一致性），给问题清单与改进建议。不写代码、不跑测试、不写文件。
+职责：只读代码审查（正确性/安全/性能/架构一致性），给问题清单与改进建议。不写代码、不跑测试；工件由你自己 `write` 到 <run-dir>/。
 
 ```
 对照 <run-dir>/SPEC.md 验收标准与 PLAN.md 契约评审改动：
@@ -172,12 +172,12 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 7) **finding 必须带跨轮稳定的编号与标题**（如 `FIND-3 未校验 token`，下一轮**原样沿用**，不要重写措辞）：`FINDING_REOPENED` 门禁按标题归一分组来识别"同一条又回来了"，每轮换标题会让它恒不命中。
 8) **必须上报撤销计数**（`retracted` = 本轮自报疑似数、`revertedFindings` = 其中被你反向推导撤销的数）：lead 会把它写进该 review 任务的 `revertedFindings` 字段，METRICS 的「评审效率（轮次 / 撤销率）」一节靠它计算。**不上报 ⇒ 撤销率恒显示「暂无撤销登记」，P4 噪声治理就没有数据**。
 返回结构化结果：{ reviewMarkdown: REVIEW.md完整内容, verdict: pass|rework, issues: [{id, severity, where, dimension, reason, fix}], retracted: <自报数>, revertedFindings: <撤销数> }。
-工具：读文件。不要写文件——内容放返回值，由 lead 落盘。禁止改业务代码、跑测试/构建。
+工具：读文件、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、跑测试/构建。
 ```
 
 ## qa（测试员）
 
-职责：按验收标准**自动生成用例并运行**，收集证据（命令 + 真实输出），产出 TEST.md。只读 + 跑测试/构建，不写业务代码、不写文件。
+职责：按验收标准**自动生成用例并运行**，收集证据（命令 + 真实输出），产出 TEST.md。只读 + 跑测试/构建，不写业务代码；工件由你自己 `write` 到 <run-dir>/。
 
 ```
 1) 用例**双向推导**：既从 SPEC.md 的验收标准推导，也从「边界与禁止项」的 10 个边界族**反向**推导——每个边界族至少 1 条**负向断言**（断言「这个动作必须被拒」），不得只测 happy path。
@@ -185,7 +185,7 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 3) **发现「规格未覆盖、但代码有行为」必须报 `spec-gap`**（行为描述 + 复现 + 期望裁定），**不得默认通过**。这是本项目最贵的失效模式：断言从规格推导 ⇒ 规格沉默 ⇒ 0 断言 ⇒ 「契约 100% PASS」相对规格为真，而产品意图已失守（实证：评论自回复在 350 条断言里覆盖 0）。
 4) `verify` 命令若因环境不可用而未实跑，**必须如实标注「未实跑」**，不得把 lint/build 通过谎报为运行时通过。
 返回结构化结果：{ testMarkdown: TEST.md完整内容, cases: [{id, name, expected, actual, pass}], specGaps: [{behavior, repro, expectedRuling}], evidence: [{cmd, tail}] }。
-工具：读文件、bash 跑测试/构建/只读检查。不要写文件——内容放返回值，由 lead 落盘。禁止改业务代码、禁止跑会修改环境的命令。
+工具：读文件、bash 跑测试/构建/只读检查、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止跑会修改环境的命令。
 ```
 
 ## ui（UI 设计师）
@@ -193,13 +193,13 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 职责：视觉规范 / 设计 token / 交互稿 / 视觉走查。只设计不实现——实现归 frontend，用例归 qa。
 
 ```
-阅读 <run-dir>/SPEC.md 验收标准与 PLAN.md，产出设计规范（由 lead 落盘）：
+阅读 <run-dir>/SPEC.md 验收标准与 PLAN.md，产出设计规范（你自己 `write` 到 <run-dir>/UI.md，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）：
 1) 视觉系统：设计 token（色板/字号/圆角/间距/阴影）、组件规格（状态/尺寸/反例）、图标与插画基调。
 2) 页面与交互稿：核心页面的布局信息架构（栅格/区块/层级）、空态/加载/异常态、关键交互流转（点击→确认→反馈）。
 3) 与存量 UI 的对齐：读现有页面/组件代码，写明「沿用 vs 新增」清单，杜绝自创风格。
 4) 视觉走查清单：交付后供 frontend/reviewer 对照的可量化自查项（对齐/间距/对比度/响应式断点）。
 返回结构化结果：{ uiMarkdown: UI.md完整内容, designTokens: [{key, value}], pages: [{name, layout, states, interactions}], qaChecklist: [] }。
-工具：读文件、glob/grep。不要写文件。禁止改业务代码、禁止花哨需求膨胀（无必要不新增组件）。
+工具：读文件、glob/grep、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止花哨需求膨胀（无必要不新增组件）。
 ```
 
 ## dba（数据工程师）
@@ -207,13 +207,13 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 职责：数据契约（schema/DDL/迁移/索引）/ 数据质量规则 / 只读数据检查。契约级角色，不写业务代码。
 
 ```
-读 <run-dir>/SPEC.md 与 PLAN.md，站在数据面交付（由 lead 落盘）：
+读 <run-dir>/SPEC.md 与 PLAN.md，站在数据面交付（你自己 `write` 到 <run-dir>/DATA.md，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）：
 1) 数据契约：表结构/字段类型/索引/唯一约束/枚举值，与接口契约双向核对（字段名、类型、非空、默认值一一对应），差异全部显式列出。
 2) 迁移方案：DDL 与数据迁移脚本清单（存量兼容：老数据回填/脏数据清洗/字段重命名禁忌），上线顺序与回退点。
 3) 数据质量守则：必须满足的完整性规则（外键/幂等/并发插入）、敏感字段清单（脱敏/加密要求）。
 4) 只读检查：可用 bash 跑只读查询验证现有 schema 与假设（绝不写库）。
 返回结构化结果：{ dataMarkdown: DATA.md完整内容, ddl: [语句], migration: [{step, ddl/dml, rollback, reason}], rules: [] }。
-工具：读文件、只读 bash（SELECT/EXPLAIN 等）。不要写文件。禁止改业务代码、禁止执行写库语句。
+工具：读文件、只读 bash（SELECT/EXPLAIN 等）、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止执行写库语句。
 ```
 
 ## sec（安全审计员）
@@ -221,12 +221,12 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 职责：安全评审（权限边界 / 越权 / 注入 / 敏感数据 / 加密）。只读审查，与 reviewer 分工：reviewer 看正确性，sec 看安全性。
 
 ```
-对照 SPEC.md 三级权限边界审查设计/代码（由 lead 落盘）：
+对照 SPEC.md 三级权限边界审查设计/代码（你自己 `write` 到 <run-dir>/SECURITY.md，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）：
 1) 设计期：核对权限模型（谁能做什么/边界条件）、敏感数据与加密方案、第三方依赖与密钥管理风险 → SECURITY.md。
 2) 实现期：过一遍改动代码的越权路径（水平/垂直越权）、注入面（SQL/命令/SSRF/XSS）、权限校验位置（服务端而非前端）、日志脱敏。
 3) 问题分级 P0（必须阻断）/P1（发布前修复）/P2（留档观察），给位置、攻击路径、修复建议。
 返回结构化结果：{ securityMarkdown: SECURITY.md完整内容, verdict: pass|rework, issues: [{severity, where, attackPath, fix}] }。
-工具：读文件、glob/grep。不要写文件。禁止改业务代码、禁止跑会修改环境的命令。
+工具：读文件、glob/grep、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止跑会修改环境的命令。
 ```
 
 ## devops（运维/发布）
@@ -234,13 +234,13 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 职责：构建 / 部署 / CI / 环境排障。可跑构建/部署命令，不写业务代码。
 
 ```
-读 <run-dir>/SPEC.md 与改动清单，产出发布方案（由 lead 落盘）：
+读 <run-dir>/SPEC.md 与改动清单，产出发布方案（你自己 `write` 到 <run-dir>/RELEASE.md，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）：
 1) 构建验证：跑构建/打包流程，记录命令、输出、产物与失败点；环境就绪检查（依赖/配置/端口）。
 2) 发布说明：RELEASE.md——涉及哪些模块、配置项变更、初始化/迁移步骤、回滚步骤。
 3) CI 建议：可落地的流水线配置片段（lint/构建/测试/发布门），同仓库既有 CI 风格对其对齐。
 4) 环境增量：后台任务/定时任务/环境变量/代理部署清单；发现环境问题只报告不改，写清证据。
 返回结构化结果：{ releaseMarkdown: RELEASE.md完整内容, buildEvidence: 命令与输出, blockers: [], cicd: [{stage, config}] }。
-工具：读文件、bash 跑构建/只读检查。不要写文件。禁止改业务代码、禁止直接操作生产环境（只给命令与说明）。
+工具：读文件、bash 跑构建/只读检查、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止直接操作生产环境（只给命令与说明）。
 ```
 
 ## docs（文档工程师）
@@ -248,13 +248,13 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 职责：README / 用户手册 / API 文档。从交付物提炼面向人/面向使用者的一手文档。
 
 ```
-读 <run-dir>/SPEC.md、最终代码与交付总结，产出文档（由 lead 落盘）：
+读 <run-dir>/SPEC.md、最终代码与交付总结，产出文档（你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict —— 见 `SKILL.md` §2 唯一权威表述）：
 1) README/DOCS.md：项目简介、快速开始、配置说明、常用命令（照实写，不吹不编造）。
 2) 用户手册：面向使用者的核心路径（按 SPEC 的业务流程写，标注输入/输出/异常提示）。
 3) API 说明：接口列表、参数/返回结构（与 PLAN 契约一致）、错误码说明。
 4) 反差检查：与实现不一致的地方（字段/流程/命令）列为 issues 交编排者，不要自行改写代码。
 返回结构化结果：{ docsMarkdown: DOCS.md完整内容, api: [{name, method, params, returns, errors}], issues: [] }。
-工具：读文件。不要写文件。禁止改业务代码、禁止跑构建/测试。
+工具：读文件、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、禁止跑构建/测试。
 ```
 
 
@@ -266,23 +266,23 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 ```
 目标：像真人一样做端到端验证。（动态补位标签：`【UI 验证专家】`，`ROSTER.json.roles` 登记为 `ui-verifier`）
 用 browser_* 工具打开/操作应用：拉起界面 → 执行完整业务流程 → 对照 SPEC 验收标准验证预期输出 → 覆盖边界 case（空输入/权限/异常）。
-发现问题时整理「操作链路 + 现场（截图/报错）+ 根因初判」，放进返回结果（reportMarkdown），由 lead 落盘。
-工具：browser_*、读文件。不要写文件。禁止改业务代码、改后端逻辑。
+发现问题时整理「操作链路 + 现场（截图/报错）+ 根因初判」，由你自己 `write` 到 <run-dir>/（reportMarkdown 只留摘要），只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。
+工具：browser_*、读文件、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码、改后端逻辑。
 ```
 
 ### 故障诊断（debugger）
 
 ```
 目标：复现故障、根因定位、给修复建议（动态补位标签：`【故障诊断工程师】`，`ROSTER.json.roles` 登记为 `debugger`）、根因定位、给修复建议（不亲自改）。
-复现步骤 → 用 bash/读文件/日志定位根因 → 产出诊断报告（复现步骤 + 根因 + 调用链 + 修复建议 + 风险），放进返回结果（reportMarkdown），由 lead 落盘。
-工具：bash、读文件、glob/grep。不要写文件。禁止改业务代码（只给建议）。
+复现步骤 → 用 bash/读文件/日志定位根因 → 产出诊断报告（复现步骤 + 根因 + 调用链 + 修复建议 + 风险），由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。
+工具：bash、读文件、glob/grep、`write`（只写 <run-dir>/ 下你自己的工件）。工件由你自己 `write` 到 <run-dir>/，只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。禁止改业务代码（只给建议）。
 ```
 
 ### 安全 / 性能 / 数据 等
 
 ```
 职责：{{补充职责}}。（动态补位标签：`【{{role-zh}}】`，取值同上方标签表）
-读 <run-dir> 相关工件，产出你的领域工件内容（放进返回结果的 {{artifact}}Markdown 字段），由 lead 落盘。
+读 <run-dir> 相关工件，产出你的领域工件并由你自己 `write` 到 <run-dir>/（{{artifact}}Markdown 字段只留摘要），只回 path + 摘要 + verdict（见 `SKILL.md` §2 唯一权威表述）。
 守界：只用你领域必要的工具，不越界改其它角色产出。
 ```
 
@@ -290,8 +290,8 @@ prompt 里明写「**不要等待确认，直接改文件并交付代码/工件*
 
 ## lead（编排者 = 主 agent，非子角色）
 
-lead 不模板化——那就是你本人。你负责：读 Ultra Spec、按 DAG 派工、模糊选择抛给用户拍板、合并冲突裁决、Ultra Review 去重汇总、**方案确认门（spec-review 通过后、implement 前，用中文汇总「执行方案」并 `ask_user_question` 让用户确认「执行/修改」，未确认不得开工）**、deliver 最终校验与收尾、持续记 RUN.log.md + 写 RETRO.md、把可复用经验分两层追加到 LEARNINGS。
+lead 不模板化——那就是你本人。你负责：读 Ultra Spec、按 DAG 派工、模糊选择抛给用户拍板、合并冲突裁决、Ultra Review 去重汇总、**方案确认门（spec-review 通过后、implement 前，用中文汇总「执行方案」并 `ask_user_question` 让用户确认「执行/修改」，未确认不得开工）**、deliver 最终校验与收尾、持续口述 RUN.log 事件与 RETRO 内容，**由指派的有 `write` 成员落盘**（见 §2）、把可复用经验分两层追加到 LEARNINGS（同口径：lead 口述内容，由指派的有 `write` 成员落盘）。
 
 **交互语言**：你所有面向用户的话（澄清/确认/方案汇总/状态/交付总结）一律用**中文**；只有技术标识、代码、命令、字段名保留英文。
 
-**落盘职责（关键）**：每个角色返回工件内容后，你**立即用 `write` 把内容写进对应文件**（`SPEC.md / PLAN.md / RESEARCH.md / REVIEW.md / TEST.md / TASKS.json / RETRO.md / STATE.json / RUN.log.md`）——这样工件成为你本轮产出文件，聊天框会出现可点击的文件标签，用户能直接预览。
+**落盘职责（关键）**：run 工件一律由**产出它的角色自己 `write` 到 `<run-dir>/`**；lead 没有 `write`，只读工件做门控与裁决。**本段不再是落盘责任人定义——定义在 `SKILL.md` §2（唯一权威表述）**。交付时由你用 `dsh_im_return_file` 把关键工件（如 SPEC.md / REVIEW.md / TEST.md / 交付总结）发给用户。

package/skills/expert-team/references/WORKSPACE.md

@@ -6,24 +6,24 @@
 
 | 文件 | 维护者 | 内容 |
 |---|---|---|
-| `TASK.md` | /team 命令建；lead 更新 | 目标、模式、交付口径、状态、交付结论 |
-| `ROSTER.json` | /team 命令建；lead 更新 | 角色编制、成员映射 |
-| `STATE.json` | lead 每阶段更新 | 当前 phase / status / members |
-| `任务看板.md` | **lead 全程维护**（每个阶段结束写一次） | 任务计划 + 状态表 + 当前阶段（可视化进度，聊天框可点击预览） |
-| `SPEC.md` | pm 产出内容；**lead 落盘** | Ultra Spec：功能目标、验收标准、业务规则、边界 Case、安全边界（三级权限）、测试计划 |
-| `PLAN.md` | pm 骨架 + architect 设计段；**lead 落盘** | 里程碑、接口契约（I/O JSON Schema）、数据流、风险 |
-| `RESEARCH.md` | researcher 产出内容；**lead 落盘** | 代码定位、依赖、环境、存量约束 |
-| `TASKS.json` | pm 初稿 → architect 细化 → lead 更新状态 | 唯一实现事实来源（含 dependsOn 依赖） |
-| `REVIEW-SPEC.md` | reviewer（spec-review 阶段，可选）；**lead 落盘** | 对 Spec 的交叉审查结论 |
-| `REVIEW.md` | reviewer 产出内容；**lead 落盘** | 代码审查：问题清单、严重级、结论 |
-| `TEST.md` | qa/测试补位产出内容；**lead 落盘** | 测试命令、结果、覆盖、结论 |
-| `SUMMARY.md` | lead（deliver 阶段） | **交付总结**：各任务结论/改动/commit/评审测试结论 |
-| `RUN.log.md` | /team 命令建；lead 逐行追加 | 运行轨迹（阶段/角色/决策/卡点，见 LOGGING.md） |
-| `RETRO.md` | lead（deliver 阶段） | 本次复盘：快/慢/卡点/可复用经验 |
-
-> 所有角色产出内容都**由 lead 用 `write` 落盘**（见 ROLES.md）——这样工件成为 lead 本轮产出文件，聊天框可点击预览。
-
-> `team/LEARNINGS.md` 位于 `<cwd>/team/`（跨 run 累积，不在单个 run 目录内）：lead 在 run 开始前读取、deliver 时追加。
+| `TASK.md` | /team 命令建（宿主执行）；lead 口述 + 指派的有 `write` 成员落盘（§2） | 目标、模式、交付口径、状态、交付结论 |
+| `ROSTER.json` | /team 命令建/更新（宿主执行；lead 无 `write`，§2） | 角色编制、成员映射 |
+| `STATE.json` | **运行时**（唯一写者） | 当前 phase / status / members |
+| `任务看板.md` | lead 口述 + 指派的有 `write` 成员落盘（每个阶段结束一次） | 任务计划 + 状态表 + 当前阶段（可视化进度；工件以 `path` 可核验，交付时由 lead 用 `dsh_im_return_file` 发给用户） |
+| `SPEC.md` | **pm 自己落盘** | Ultra Spec：功能目标、验收标准、业务规则、边界 Case、安全边界（三级权限）、测试计划 |
+| `PLAN.md` | **architect 自己落盘**（pm 骨架 + architect 设计段） | 里程碑、接口契约（I/O JSON Schema）、数据流、风险 |
+| `RESEARCH.md` | **researcher 自己落盘** | 代码定位、依赖、环境、存量约束 |
+| `TASKS.json` | pm 初稿 → architect 细化 → lead 用 `/team task` 回写状态 | 唯一实现事实来源（含 dependsOn 依赖） |
+| `REVIEW-SPEC.md` | **reviewer 自己落盘**（spec-review 阶段，可选） | 对 Spec 的交叉审查结论 |
+| `REVIEW.md` | **reviewer 自己落盘** | 代码审查：问题清单、严重级、结论 |
+| `TEST.md` | **qa/测试补位角色自己落盘** | 测试命令、结果、覆盖、结论 |
+| `SUMMARY.md` | lead 口述 + 指派的有 `write` 成员落盘（deliver 阶段） | **交付总结**：各任务结论/改动/commit/评审测试结论 |
+| `RUN.log.md` | /team 命令建；事件由产出该事件的角色落盘（lead 口述、指派有 `write` 的成员执行） | 运行轨迹（阶段/角色/决策/卡点，见 LOGGING.md） |
+| `RETRO.md` | lead 口述 + 指派的有 `write` 成员落盘（deliver 阶段） | 本次复盘：快/慢/卡点/可复用经验 |
+
+> run 工件一律由**产出它的角色自己 `write` 到 `<run-dir>/`**；角色只回 `path` + 摘要 + `verdict`；**lead 没有 `write`**，只读工件做门控与裁决（唯一权威表述见 `SKILL.md` §2）——工件因此是产出角色本轮的产出文件，以 `path` 可核验；交付时由 lead 用 `dsh_im_return_file` 发给用户（「聊天框可点击产出文件行」的机制未独立证实，不作为承诺）。
+
+> `team/LEARNINGS.md` 位于 `<cwd>/team/`（跨 run 累积，不在单个 run 目录内）：lead 在 run 开始前**只读**；deliver 时由 lead 口述、指派的有 `write` 成员追加。
 
 ## TASKS.json
 
@@ -120,4 +120,4 @@ persist 模式下，`members` 记录每个角色的可继续子 agent id，供 r
 
 1. 每个角色的**结构化返回值**与它写的工件内容必须一致（结构化值是给编排脚本/下一阶段的机器可读摘要；工件是持久化事实）。
 2. 下游角色读工件，不读上游的完整对话；跨角色接口一律以 `PLAN.md` 契约为准。
-3. 任何角色改完自己的工件后，由 lead 统一更新 `STATE.json.phase`。
+3. `STATE.json` 的**唯一写者是运行时**（本 run 实测 `revision=1`、`members` 被运行时增补）；角色与 lead **只读**，任何角色改完自己的工件后都不回写 `STATE.json.phase`。

package/skills/expert-team/references/workflow.team.js

@@ -23,7 +23,7 @@ const spec = await agent(
   `3) 产出 PLAN.md 骨架内容（设计段留空给 architect）。\n` +
   `4) 产出 TASKS.json 任务数组（id/owner/title/spec/acceptance/dependsOn/status=pending）。\n` +
   `★ 用 write 把 SPEC.md 完整内容写到 {{run-dir}}/SPEC.md、PLAN 骨架写到 {{run-dir}}/PLAN.md；\n` +
-  `   TASKS.json 数组因体量小可只放进返回值（lead 落盘），也可一并 write。\n` +
+  `   TASKS.json 数组因体量小可只放进返回值（由产出角色自己 write 到 run-dir；见 SKILL.md §2），也可一并 write。\n` +
   `返回值只回：specPath、planPath、tasks（小）、openQuestions（小）。不要在返回值里塞 SPEC/PLAN 全文。\n` +
   `目标：{{task}}`,
   { label: "pm", phase: "clarify", schema: { type: "object", properties: { specPath: { type: "string" }, planPath: { type: "string" }, tasks: { type: "array", items: { type: "object" } }, openQuestions: { type: "array", items: { type: "string" } } }, required: ["specPath", "tasks"] } }
@@ -47,14 +47,14 @@ const implementers = await parallel([
   () => agent(
     `【后端工程师】运行目录：{{run-dir}}。\n` +
     `只实现 TASKS.json 里 owner=backend 的任务，以 PLAN.md 契约为准（读 {{run-dir}}/PLAN.md 的设计段）。\n` +
-    `直接改代码；每完成一个任务，在返回值里给出 status/改动文件/一行说明（不要自己改 TASKS.json，由 lead 统一更新）。\n` +
+    `直接改代码；每完成一个任务，在返回值里给出 status/改动文件/一行说明（TASKS.json 的写者按 §2：由产出它的角色落盘；lead 没有 write，用 /team task <id> <状态> 命令回写状态）。\n` +
     `「此能力是否被真正调用并回流到前端」属你的自检项，未接线必须上报（不要等评审/QA 才暴露）。契约/枚举分歧写进 blockers。`,
     { label: "backend", phase: "implement", schema: { type: "object", properties: { tasks: { type: "array", items: { type: "object" } }, blockers: { type: "array", items: { type: "string" } } }, required: ["tasks"] } }
   ),
   () => agent(
     `【前端工程师】运行目录：{{run-dir}}。\n` +
     `只实现 TASKS.json 里 owner=frontend 的任务，以 PLAN.md 契约为准（读 {{run-dir}}/PLAN.md 的设计段）。\n` +
-    `直接改代码；每完成一个任务，在返回值里给出 status/改动文件/一行说明（不要自己改 TASKS.json，由 lead 统一更新）。\n` +
+    `直接改代码；每完成一个任务，在返回值里给出 status/改动文件/一行说明（TASKS.json 的写者按 §2：由产出它的角色落盘；lead 没有 write，用 /team task <id> <状态> 命令回写状态）。\n` +
     `「此能力是否被真正调用并回流」属你的自检项，未接线必须上报。契约/枚举分歧写进 blockers。`,
     { label: "frontend", phase: "implement", schema: { type: "object", properties: { tasks: { type: "array", items: { type: "object" } }, blockers: { type: "array", items: { type: "string" } } }, required: ["tasks"] } }
   ),
@@ -84,9 +84,9 @@ const test = await agent(
 
 phase("deliver");
 
-// workflow 返回后，lead 落盘说明（大工件由角色已写盘，此处只回路径 + 小字段）：
-//   如需聊天框可点击预览，lead 用 read 读回 {{run-dir}}/SPEC.md 等再 write 一次（可选，
-//   也可直接引用文件名）。TASKS.json 用 design.tasks（lead 用 write 落盘）。
+// workflow 返回后，工件由产出角色自己落盘（见 SKILL.md §2）；此处只回路径 + 小字段：
+//   如需聊天框可点击预览，lead 用 read 读回 {{run-dir}}/SPEC.md 等（read 在 lead 工具面内，
+//   write 不在 ⇒ lead 不落盘）。TASKS.json 取 design.tasks（同样由产出角色 write 落盘）。
 return {
   runDir: "{{run-dir}}",
   spec: { specPath: spec.specPath, planPath: spec.planPath, tasks: spec.tasks, openQuestions: spec.openQuestions },