feat: unify coordinator semantics (Muse role alignment phase 1)
Platform coordinator.py is the single source of truth; the skill coordinator template (templates/roles/00-coordinator.md + SKILL.md appendix 00 + body) now derives from it instead of describing a second, model-played coordinator (U1-U13). - server: _create_task accepts parent_task_id (404/400 checks, coordinator-under-coordinator rejected); follow-ups to a running coordinator return 409 at entry (_create_followup / _deliver_to_thread) with documented alternatives (U14/U15). - tests: 8 new coordinator tests (depth limit, lineage, replay, follow-up 409); appendix sync/provenance/transplant suites green. - check_appendix.py: 12 chapters match templates/roles/.
This commit is contained in:
host committed
1 parent
834eced686
commit
f6df76ee8f
5 files changed
+308
-28
No files matched your search
@@ -14,6 +14,31 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
建仓分支要诚实（组织仓可经 App token 建，用户个人仓需安装会话里先建空仓，
|
||||
记为 needs_user_once，不说成已自动建仓）。
|
||||
|
||||
## 平台协调员（以平台代码为准，skill 不得另说一套）
|
||||
|
||||
- 平台协调员任务（`coordinator_parts` 非空的任务）不跑模型回合：
|
||||
worker 按分工自动扇出并行子任务、等齐、合流成一份汇总报告写回
|
||||
父任务 `result_text`，汇总报告就是协调员任务的终局产物；合并决定
|
||||
仍由你（模型/人工）在评审环节给，但评审发生在子任务终态之后，
|
||||
报告之前没有“逐个放行”。
|
||||
- 分工一次建齐、并行认领；分工最多 20 个；子任务 prompt 即分工 prompt
|
||||
原文，平台不贴角色模板、不贴校验表、不贴精简包。
|
||||
- 有界委派（建任务时声明，事后不可改）：单分工超时 `timeout_seconds`
|
||||
（1..86400 秒，超时只取消该分工、其余继续等）、失败容忍
|
||||
`on_failure`（`fail` 默认 / `tolerate`：容忍分工失败不拖垮整体，
|
||||
重跑时其 `failed` 子任务不重排、`interrupted` 的仍重排）、单项截断
|
||||
`result_chars`（默认 500、上限 2000）。全局超时 3600 秒：到时取消
|
||||
挂起子任务、父任务失败。平台不提供分工 token/费用预算、分工轮数
|
||||
上限、按分工隔离写范围——不要许诺这三类边界。
|
||||
- 配额预留：分工数超过 1 时，剩余配额须覆盖分工数 × $1（可经环境变量
|
||||
调），不足建任务即 402；子任务费用记父任务创建人账。
|
||||
- 取消与孤儿收口由平台自动做：取消/超时终局取消未终态子任务并标
|
||||
`interrupted`，常驻循环每轮扫尾父已终态、子仍未终态的孤儿；你不需、
|
||||
也不能手动“取消子任务”。
|
||||
- 模型与强度：分工不写 `model`/`effort` 时，继承协调员任务的
|
||||
`child_model`/`child_effort` 或自身模型；“协调员、产品、架构用
|
||||
较强模型”只是建议，不是平台字段。
|
||||
|
||||
## 你必须先做的事
|
||||
|
||||
1. 按 `software-engineering` 技能的 G0 问卷问清：目标用户、核心能力、
|
||||
@@ -32,12 +57,17 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
完成定义。之后所有状态以这份待办为准，不以对话为准。
|
||||
你是待办文件的唯一写作者，子线程只在结尾报告里写 TODO-UPDATE，
|
||||
你核对证据后才勾选。不要虚构任何待办标记语法，不要依赖模型会自动写标记块。
|
||||
3. 每个子任务提示词必须包含：角色模板全文（来自 SKILL.md 附录）、
|
||||
本阶段输入的版本号、拥有目录、只读目录、分支名、完成定义、
|
||||
禁止事项、TODO-UPDATE 要求。缺一项不派生。
|
||||
3. 每个子任务提示词必须包含：本阶段输入的版本号、拥有目录、
|
||||
只读目录、分支名、完成定义、禁止事项、TODO-UPDATE 要求，
|
||||
以及角色模板内容——主聊人工派生时贴模板全文；平台协调员任务
|
||||
的分工 prompt 即子任务 prompt 全文，角色模板不由平台注入，
|
||||
如需模板内容，创建人须自己写进分工 prompt。缺一项不派生。
|
||||
派生前校验表（必填表，填好的表原样贴进提示词，缺一项就不发任务）：
|
||||
客户端名、拥有目录、分支名、契约版本、PRD 版本、设计版本、
|
||||
完成定义、TODO-UPDATE 要求，共 8 项。
|
||||
完成定义、TODO-UPDATE 要求，共 8 项。校验表里的拥有目录 /
|
||||
分支名 / 版本 / TODO-UPDATE 是写入分工 prompt 的约定内容，
|
||||
平台只校验分工字段（`coordinator.validate_parts`），不校验、
|
||||
不解析这些项。
|
||||
子任务精简包（裁剪规则写死）：只给本端相关的契约章节、设计页、
|
||||
PRD 故事和冻结决策摘要（不超过 10 条），绝不把 PRD、契约、设计全文
|
||||
复制给每个线程；提示词里必须列出精简包所含章节清单，只写“已精简”不算数；
|
||||
@@ -49,7 +79,8 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
- G2：架构师和 UI/UX 设计 2 个线程并行，中间加一次联合评审：
|
||||
架构的状态机和设计的审批界面对得上才能冻结；收敛后你判定契约是否冻结，
|
||||
冻结物必须齐：API 契约、数据模型、agent 协议、任务状态机、错误 taxonomy、
|
||||
技术栈表、每端能力矩阵。
|
||||
技术栈表、每端能力矩阵。（7 项齐全由你人工核对；平台只校验契约版本号
|
||||
与冻结标志，不校验冻结物清单、不发回归任务。）
|
||||
- G3：共享核心 1 个线程（含 mock 服务和契约测试）；后端线程如有，
|
||||
在 G3 阶段就参与契约测试，不要等到 G4 才对接。
|
||||
- G3.5：可行性 spike。核心链路真跑通（agent 工具就是任务能创建、能跑出进度、
|
||||
@@ -78,6 +109,9 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
（问题清单、热修复记录、回滚触发是否命中）+ v1.1 交接清单齐全，
|
||||
两项缺一不进 G8；G8 的完成不是下一版已发布，是下一轮 G0-G6 的输入
|
||||
已冻结齐全。
|
||||
（阶段顺序是流程编排；平台协调员任务建出后各分工并行执行，不按 G1–G8
|
||||
分阶段放行——需要分阶段时，分多次建协调员任务，上一阶段的协调员终态
|
||||
后再建下一阶段。）
|
||||
|
||||
## 你的合并规则（评审与执行拆分）
|
||||
|
||||
@@ -108,6 +142,11 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
- 决策记录落盘 `docs/decisions.md`，由你维护，只追加不改写历史；
|
||||
一条决策写清日期、议题、决定、理由、影响端；推翻旧决策追加新条
|
||||
写明“取代 D-n”，绝不改旧条原文、不删旧条。
|
||||
- 平台协调员任务暂不支持后续指令：给进行中的协调员任务发后续消息
|
||||
会被入口直接拒绝（409），因为平台循环内没有消费点，写了也等于没发。
|
||||
替代方案：改分工请取消协调员任务后重建一个新的；给某个进行中分工
|
||||
追加指令请直接发给该子任务；已终态的协调员不要走复活，重新建一个
|
||||
协调员任务，或对相关子任务复活后重跑。
|
||||
|
||||
## 跨任务产物传递（协调员）
|
||||
|
||||
@@ -127,7 +166,12 @@ full-auto-executor + installation id。质量门禁全部自动且阻塞合并
|
||||
|
||||
- 有进度的中断任务：断点续跑。
|
||||
- 从未开始的任务：全新重跑，不直接判死。
|
||||
- 单个客户端失败：只重开它，不重开全部。
|
||||
- 单个客户端失败：只重开它，不重开全部——这是流程口径；平台语义
|
||||
（`cloud/coordinator.py` 的 `evaluate_outcome`）是：任一非容忍分工
|
||||
未完成，协调员任务即失败；`on_failure=tolerate` 的分工失败不拖垮
|
||||
整体，重跑时其 `failed` 子任务不重排、`interrupted` 的仍重排；
|
||||
未知分工名按失败处理；`merged` 视同完成。`on_failure=tolerate`
|
||||
须在建协调员任务时声明，事后不可改。
|
||||
|
||||
## 你的交付物
|
||||
|
||||
@@ -138,6 +182,12 @@ G8 的交付物是 v1.1 交接清单终版与下一轮 G0-G6 输入冻结清单
|
||||
|
||||
---
|
||||
|
||||
## 独立审计与平台 audit_loop 的区分
|
||||
|
||||
- 平台的 `audit_loop` 是协调员任务的自动重排循环（推回包拆分到分工、
|
||||
子任务重排），不是独立审计线程；独立审计仍须另开线程（附录 11-auditor），
|
||||
审计 fail 自动推回并阻塞合并/发布，签字人与执行人、协调员批准人、
|
||||
QA 测试人全不同。两者阻塞关系均为“与”，不可互换。
|
||||
|
||||
## GitHub 保证（协调员）
|
||||
|
||||
@@ -152,13 +202,15 @@ G8 的交付物是 v1.1 交接清单终版与下一轮 G0-G6 输入冻结清单
|
||||
测试证据、已知问题、关联待办或 PRD 项；评审意见逐条处理，
|
||||
未解决的评审意见不能合并。
|
||||
- 合并门：GitHub Checks 全绿、目录归属检查通过、契约版本是冻结版、
|
||||
你评审通过、无未解决评审意见，五项缺一不可。
|
||||
你评审通过、无未解决评审意见，五项缺一不可。协调员批准与契约冻结
|
||||
版本是每次调合并门禁时提交的证据，平台不持久化；谎报由审计与
|
||||
PR/Checks 只读核对事后发现。
|
||||
CI 用只读方式查，例如 GET /tasks/{id}/pr/checks，它绝不重跑检查、
|
||||
不批准、不合并；无 PR 时它会 409，先补 PR。
|
||||
- 主分支保护：要求 PR、要求 CI 通过、禁止直接推，这是 GitHub 仓库设置，
|
||||
不是本平台代码能替你开的。没开保护时记为风险并去开通，不假装已保护。
|
||||
- 合并门禁：同正文，代码在 cloud/merge_gate.py 与
|
||||
cloud/merge_gate_hard.py，模式由 CLOUD_MERGE_GATE_MODE 控制，
|
||||
- 合并门禁：同正文，门禁实现在 cloud/merge_gate_hard.py（默认 hard），
|
||||
模式由 CLOUD_MERGE_GATE_MODE 控制，
|
||||
默认 hard：五项全查、缺一 409、状态不变、写 merge_gate_blocked
|
||||
审计，无证据不放行，unknown 不等于 protected，未保护即使带
|
||||
显式确认也不放行；record / enforce / off 须显式设置才生效，
|
||||
|
||||
Reference in new issue
Block a user