refactor(agent-collaboration-kit): split stable core from project overrides
- Reorganize flat files into core/ templates/ examples/ scripts/ with VERSION - Deduplicate: single-source state machine, three-round policy, acceptance signals - Abstract orchestration in closed-loop.md with manual mode; move Orca commands to orca-adapter.md - Add tasks.schema.json + validate_tasks.py (jsonschema or builtin rules, no hard deps) - Add filled examples, concurrency write rule, kitVersion tracking; unify to Chinese Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -0,0 +1,132 @@
|
||||
# 闭环流程（稳定核心，编排无关）
|
||||
|
||||
本文件定义**与具体编排工具无关**的协作闭环。运行时调度可以用 Orca（见 `orca-adapter.md`），也可以手动跑（见下方「手动模式」）。
|
||||
|
||||
原则：调度消息只是运行时载体，**所有结论都必须回写到 `tasks.yaml`**（事实源），不要把消息当最终记录。
|
||||
|
||||
---
|
||||
|
||||
## 编排抽象
|
||||
|
||||
无论用什么工具，闭环都由这几个能力组成：
|
||||
|
||||
| 抽象动作 | 含义 | Orca 实现 | 手动实现 |
|
||||
|----------|------|-----------|----------|
|
||||
| `prepare(task)` | 把任务和验收标准写进 `tasks.yaml` | 同左 | 同左 |
|
||||
| `dispatch(task, worker)` | 把任务连同上下文交给 Developer | `orca orchestration dispatch` | 复制 prompt 到 Developer 终端/会话 |
|
||||
| `wait()` | 等待 `worker_done` / `escalation` / `decision_gate` | `orca orchestration check --wait` | 人工等待 Developer 回报 |
|
||||
| `retest(task)` | Coordinator 独立黑盒复测 | 同左 | 同左 |
|
||||
| `writeback(task, result)` | 把复测结果写回 `tasks.yaml` | 同左 | 同左 |
|
||||
|
||||
派发用的 prompt 见 `prompt-templates.md`。状态流转见 `roles-and-permissions.md` §「任务状态机」。
|
||||
|
||||
---
|
||||
|
||||
## 标准闭环
|
||||
|
||||
```text
|
||||
Product/Test 发现或读取 open 任务
|
||||
-> prepare：写/补全 tasks.yaml 验收标准
|
||||
-> dispatch 给 Developer Worker
|
||||
-> wait：worker_done / escalation / decision_gate
|
||||
-> retest：Coordinator 构建并独立复测
|
||||
-> 通过：writeback verified
|
||||
-> 失败：writeback failed_retest，追加证据，最多再派发两轮
|
||||
-> 累计三轮失败：writeback leftover，继续下一个任务
|
||||
```
|
||||
|
||||
一次派发只修一个明确问题（细则见 `optimization-method.md` §「每轮派发只修一个明确问题」）。
|
||||
|
||||
---
|
||||
|
||||
## 手动模式（无 Orca）
|
||||
|
||||
没有编排工具时，闭环不变，只是 `dispatch` / `wait` 由人工承担：
|
||||
|
||||
1. Coordinator 在 `tasks.yaml` 写好任务和验收标准。
|
||||
2. 用 `prompt-templates.md` 的初始派发模板生成 prompt，手动发给 Developer（另一个会话/终端/人）。
|
||||
3. Developer 完成后按 worker_done 模板回报（可直接贴回 Coordinator 会话）。
|
||||
4. Coordinator 独立复测，回写 `tasks.yaml`。
|
||||
5. 失败则用「复测失败再派发模板」继续，最多三轮。
|
||||
|
||||
手动模式下同样遵守：worker_done 不等于完成、只有 Coordinator 写 `tasks.yaml`、三轮失败留档。
|
||||
|
||||
---
|
||||
|
||||
## worker_done 后复测（编排无关）
|
||||
|
||||
即使 worker_done 写了"全部通过"，Coordinator 仍必须独立复测：
|
||||
|
||||
```bash
|
||||
git status --short
|
||||
<test_commands>
|
||||
curl -s <base_url>/health-or-summary
|
||||
```
|
||||
|
||||
浏览器复测建议记录：
|
||||
|
||||
```text
|
||||
BASE_URL:
|
||||
page:
|
||||
steps:
|
||||
expected:
|
||||
actual:
|
||||
snapshot evidence:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 服务与 worktree 对齐（防假通过/假失败）
|
||||
|
||||
复测前记录运行环境：
|
||||
|
||||
```bash
|
||||
pwd
|
||||
git rev-parse --abbrev-ref HEAD
|
||||
git rev-parse --short HEAD
|
||||
```
|
||||
|
||||
```text
|
||||
serverPid:
|
||||
serverCommand:
|
||||
BASE_URL:
|
||||
frontendDir:
|
||||
worktreePath:
|
||||
```
|
||||
|
||||
如果开发在 `<dev_worktree>` 修复，但服务跑的是另一个 worktree，必须**停止并重启正确服务**后再测。长跑服务或静态前端尤其要确认加载的是最新构建产物。
|
||||
|
||||
---
|
||||
|
||||
## 结果回写
|
||||
|
||||
回写 `tasks.yaml` 时按状态填写（字段结构见 `templates/tasks.schema.json`）：
|
||||
|
||||
```yaml
|
||||
# 通过
|
||||
status: verified
|
||||
resolution:
|
||||
verifiedAt: "<timestamp>"
|
||||
evidence:
|
||||
verification: "<commands passed>"
|
||||
browser: "<snapshot or API evidence>"
|
||||
```
|
||||
|
||||
```yaml
|
||||
# 失败但未满三轮
|
||||
status: failed_retest
|
||||
dispatch:
|
||||
rounds:
|
||||
- round: 1
|
||||
result: failed
|
||||
evidence: "<latest evidence>"
|
||||
```
|
||||
|
||||
```yaml
|
||||
# 累计三轮失败
|
||||
status: leftover
|
||||
resolution:
|
||||
leftoverReason: "failed after 3 supervised developer rounds"
|
||||
evidence:
|
||||
final: "<latest failing evidence>"
|
||||
```
|
||||
@@ -0,0 +1,148 @@
|
||||
# 优化方法（稳定核心）
|
||||
|
||||
减少"开发声称完成但复测不过"的循环成本。本文件是**验收信号写法**和**三轮失败策略**的 SSOT，其它文件引用这里。
|
||||
|
||||
复测步骤与环境对齐见 `closed-loop.md`；状态机与完成定义见 `roles-and-permissions.md`。
|
||||
|
||||
---
|
||||
|
||||
## 1. 先把验收写成可观测信号（SSOT）
|
||||
|
||||
不要只写"页面可用""体验更好"。每个任务至少写三类信号：
|
||||
|
||||
| 类型 | 示例 |
|
||||
|------|------|
|
||||
| 可见文本 | 页面出现 `确认应用标签`、`取消`、`将修改` |
|
||||
| API 结果 | `POST /api/...` 返回 `code=0` 且字段存在 |
|
||||
| 交互结果 | 点击按钮后出现确认区；取消后不触发写入 |
|
||||
|
||||
好的验收：
|
||||
|
||||
```text
|
||||
点击"预览变更"后，页面必须出现 API 返回的 diff 行：
|
||||
- title
|
||||
- 修改前值
|
||||
- 修改后值
|
||||
- coverChanged 提示
|
||||
```
|
||||
|
||||
不好的验收：
|
||||
|
||||
```text
|
||||
预览功能正常。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. worker_done 必须带证据，不带结论
|
||||
|
||||
Developer Worker 的 `worker_done` 应报告：改了哪些文件、跑了哪些命令、自己如何复现验收路径、仍可能有的风险。
|
||||
|
||||
不要写：
|
||||
|
||||
```text
|
||||
已完成，应该可以了。
|
||||
```
|
||||
|
||||
要写：
|
||||
|
||||
```text
|
||||
修改 web/app/fix/page.tsx。已运行 npm run build、go test ./...。
|
||||
手测 /fix?fileId=1：搜索、选择候选、预览、确认区都可见。
|
||||
风险：未执行真实写文件 apply。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Product/Test 只信自己的复测
|
||||
|
||||
即使 worker_done 写了"全部通过"，Coordinator 仍必须独立复测。完整复测步骤与 worktree/服务对齐见 `closed-loop.md`。这可避免三类假通过：测错服务实例、测到旧构建产物、开发只验证静态文本没验证真实交互。
|
||||
|
||||
---
|
||||
|
||||
## 4. 三轮失败策略（SSOT）
|
||||
|
||||
每个任务最多自动派发三轮：
|
||||
|
||||
```text
|
||||
round 1: 常规修复
|
||||
round 2: 带复测失败证据的定向修复
|
||||
round 3: 明确指出重复失败点，要求 worker 自己复现完整路径
|
||||
failed after round 3: 标记 leftover，继续下一个任务
|
||||
```
|
||||
|
||||
三轮失败后不要继续消耗同一个 worker。常见原因：验收标准需要重新设计、Worker 对问题模型理解错了、UI 自动化与实际浏览器状态有差异、需要人工观察或调试工具介入。
|
||||
|
||||
留档字段（结构见 `templates/tasks.schema.json`）：
|
||||
|
||||
```yaml
|
||||
status: leftover
|
||||
resolution:
|
||||
leftoverReason: "failed after 3 supervised developer rounds"
|
||||
dispatch:
|
||||
rounds:
|
||||
- round: 1
|
||||
result: failed
|
||||
evidence: "<why failed>"
|
||||
- round: 2
|
||||
result: failed
|
||||
evidence: "<why failed>"
|
||||
- round: 3
|
||||
result: failed
|
||||
evidence: "<why failed>"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 任务排序
|
||||
|
||||
1. P0 阻塞主流程。
|
||||
2. P1 高频用户路径。
|
||||
3. P1/P2 体验改进。
|
||||
4. 重构和内部质量。
|
||||
|
||||
三轮失败的 P0 可以留档，但发布前需人工决策：降级范围、改验收标准、换新 Agent / 新 worktree 重做、人工修复。
|
||||
|
||||
---
|
||||
|
||||
## 6. 每轮派发只修一个明确问题
|
||||
|
||||
不要一次让 Developer Worker 修太多失败项，除非它们共享同一根因：
|
||||
|
||||
```text
|
||||
one dispatch = one bug = one acceptance path
|
||||
```
|
||||
|
||||
优点：复测更快、失败原因更清楚、三轮失败留档更准确。
|
||||
|
||||
---
|
||||
|
||||
## 7. 把失败证据写给下一轮 worker
|
||||
|
||||
第二轮以后，派发 prompt 应突出"上一轮为什么没过"，而非重复原始描述。模板见 `prompt-templates.md` §「复测失败再派发模板」。
|
||||
|
||||
---
|
||||
|
||||
## 8. 优先让测试可执行化
|
||||
|
||||
如果某个问题需要多轮修复，说明它值得沉淀成自动化检查。优先级：
|
||||
|
||||
1. API smoke。
|
||||
2. 浏览器脚本或 case 文档。
|
||||
3. 单元测试。
|
||||
4. 人工检查清单。
|
||||
|
||||
目标不是全部自动化，而是把最容易反复误判的路径自动化。
|
||||
|
||||
---
|
||||
|
||||
## 9. 结束条件
|
||||
|
||||
一轮闭环结束时，必须能回答：
|
||||
|
||||
- 哪些任务 verified？哪些 leftover？
|
||||
- 每个 leftover 失败了几轮？最后一轮失败证据是什么？
|
||||
- 当前工作树有哪些未提交改动？
|
||||
- 是否还有 open / failed_retest 未处理？
|
||||
|
||||
答不清楚，闭环就还没结束。
|
||||
@@ -0,0 +1,126 @@
|
||||
# Orca 适配器（稳定核心，一种编排实现）
|
||||
|
||||
Orca orchestration 是运行时调度层的一种实现。闭环流程本身与工具无关（见 `closed-loop.md`）；本文件只提供 Orca 的具体命令。没有 Orca 时用 `closed-loop.md` §「手动模式」。
|
||||
|
||||
所有结论仍以 `tasks.yaml` 为准，Orca 消息不是最终记录。
|
||||
|
||||
---
|
||||
|
||||
## 何时用 Orca 编排
|
||||
|
||||
用：需要监督、等待结果、闭环修复、三轮重试；有多个可独立派发的任务；需要 `worker_done` 后再复测。
|
||||
|
||||
不用：单次问答；用户只要求完整 handoff 不需监督；不需要复测的小改动。
|
||||
|
||||
---
|
||||
|
||||
## 运行前检查
|
||||
|
||||
```bash
|
||||
orca status --json
|
||||
orca terminal list --json
|
||||
orca orchestration task-list --json
|
||||
orca orchestration inbox --limit 20 --json
|
||||
```
|
||||
|
||||
确认：Orca runtime 可达；Coordinator 与 Developer Worker 终端都存在；Developer 在正确 worktree；当前没有冲突的活跃编排任务。
|
||||
|
||||
---
|
||||
|
||||
## 创建父任务
|
||||
|
||||
```bash
|
||||
orca orchestration task-create --spec "$(cat <<'EOF'
|
||||
Goal: Complete <release_or_feature> with supervised Product/Test -> Developer loop.
|
||||
|
||||
Coordinator: owns task board, black-box tests, retest, final verification.
|
||||
Developer: owns implementation and white-box verification.
|
||||
|
||||
Policy:
|
||||
- Each issue can be dispatched at most 3 rounds.
|
||||
- If still failing after 3 rounds, record as leftover and continue next issue.
|
||||
- worker_done is not final completion.
|
||||
EOF
|
||||
)" --json
|
||||
```
|
||||
|
||||
## 创建子任务
|
||||
|
||||
```bash
|
||||
orca orchestration task-create --parent <parent_task_id> --spec "$(cat <<'EOF'
|
||||
Fix <task_id>: <title>
|
||||
|
||||
Repository:
|
||||
- Path: <repo_path>
|
||||
- Worktree: <dev_worktree>
|
||||
|
||||
Read: AGENTS.md, tasks.yaml, <relevant_spec_or_test_doc>
|
||||
Failure evidence: <copy latest Product/Test evidence>
|
||||
Acceptance: <copy expected behavior + verification commands>
|
||||
|
||||
Constraints:
|
||||
- Follow AGENTS.md path scope.
|
||||
- Do not write tasks.yaml, do not mark verified.
|
||||
- Do not commit or push unless user asks.
|
||||
EOF
|
||||
)" --json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 派发给 Developer Worker
|
||||
|
||||
终端是 Orca 可识别的 Agent CLI 时：
|
||||
|
||||
```bash
|
||||
orca orchestration dispatch --task <task_id> --to <developer_handle> --inject --json
|
||||
```
|
||||
|
||||
不能 `--inject` 时，先登记 dispatch，再手动投递 `prompt-templates.md` §1 的初始派发 prompt：
|
||||
|
||||
```bash
|
||||
orca orchestration dispatch --task <task_id> --to <developer_handle> --json
|
||||
orca terminal send --terminal <developer_handle> --text "$(cat <<'EOF'
|
||||
<粘贴 prompt-templates.md §1 初始派发模板，已填占位符>
|
||||
EOF
|
||||
)" --enter --json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 等待结果
|
||||
|
||||
```bash
|
||||
orca orchestration check \
|
||||
--terminal <coordinator_handle> \
|
||||
--wait \
|
||||
--types worker_done,escalation,decision_gate \
|
||||
--timeout-ms 900000 \
|
||||
--json
|
||||
```
|
||||
|
||||
等待超时不等于失败。长任务可继续等待，或检查 worker 终端活性。
|
||||
|
||||
---
|
||||
|
||||
## Developer 回报 worker_done
|
||||
|
||||
字段含义见 `prompt-templates.md` §3：
|
||||
|
||||
```bash
|
||||
orca orchestration send \
|
||||
--to <coordinator_handle> \
|
||||
--type worker_done \
|
||||
--subject "<task_id> fix ready round <n>" \
|
||||
--body "<修了什么。跑了哪些验证。如何复现。还有什么风险。>" \
|
||||
--payload '{
|
||||
"taskId": "<orca_task_id>",
|
||||
"dispatchId": "<orca_dispatch_id>",
|
||||
"filesModified": ["<file_a>", "<file_b>"],
|
||||
"verification": ["<command_a>: passed", "<command_b>: passed"],
|
||||
"risk": "<remaining risk or none>"
|
||||
}' \
|
||||
--json
|
||||
```
|
||||
|
||||
收到 worker_done 后，Coordinator 按 `closed-loop.md` 独立复测并回写 `tasks.yaml`。
|
||||
@@ -0,0 +1,106 @@
|
||||
# 派发 Prompt 模板（稳定核心）
|
||||
|
||||
用于 Coordinator 给 Developer Worker 派发任务。复制时替换尖括号占位符。这些模板与编排工具无关：Orca 模式用 `orca-adapter.md` 的命令投递，手动模式直接把文本发给 Developer。
|
||||
|
||||
---
|
||||
|
||||
## 1. 初始派发模板
|
||||
|
||||
```text
|
||||
你现在接到一个受监督的协作任务。请在 <dev_worktree> 开发工作树内完成。
|
||||
|
||||
任务：
|
||||
- 修复 <task_id>: <task_title>
|
||||
|
||||
请先读取：
|
||||
- AGENTS.md
|
||||
- tasks.yaml
|
||||
- <relevant_spec_or_test_doc>
|
||||
|
||||
当前失败证据：
|
||||
<copy latest Product/Test evidence>
|
||||
|
||||
验收标准（可观测信号，见 optimization-method.md §1）：
|
||||
1. <expected behavior 1>
|
||||
2. <expected behavior 2>
|
||||
3. <expected behavior 3>
|
||||
|
||||
约束：
|
||||
- 只修改 Developer 可写路径（见 AGENTS.md 权限表）。
|
||||
- 不要修改 Product/Test 负责的规格和集成测试文件，除非任务明确要求。
|
||||
- 不要写 tasks.yaml，不要标记 verified。
|
||||
- 不要提交或推送，除非用户明确要求。
|
||||
- 最小 diff，避免无关重构。
|
||||
|
||||
完成前必须运行：
|
||||
- <test command 1>
|
||||
- <test command 2>
|
||||
|
||||
完成后回报一次 worker_done（格式见 §4）。如果阻塞，请发送 escalation 或 ask。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 复测失败再派发模板
|
||||
|
||||
```text
|
||||
第 <n> 轮复测未通过，请继续修 <task_id>。
|
||||
|
||||
上一轮开发声称：
|
||||
<worker_done summary>
|
||||
|
||||
Product/Test 独立复测结果：
|
||||
- 运行命令：<commands>
|
||||
- 失败页面/API：<page or endpoint>
|
||||
- 仍缺失：<missing expected checks>
|
||||
- 实际观察：<actual evidence>
|
||||
|
||||
关键提示：
|
||||
- 不要只满足静态文案，必须满足交互后的真实状态。
|
||||
- 如果后端/API 正常而 UI 不更新，请优先排查事件链、状态重置、异步请求、构建产物和服务 worktree。
|
||||
- 修复后请自己用浏览器或脚本复现 Product/Test 的完整步骤。
|
||||
|
||||
验收不变：
|
||||
<copy acceptance criteria>
|
||||
|
||||
完成后回报 worker_done，subject 使用："<task_id> fix ready round <n>"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Developer Worker worker_done 回报格式（通用）
|
||||
|
||||
无论 Orca 还是手动，回报都应包含以下字段：
|
||||
|
||||
```text
|
||||
subject: <task_id> fix ready round <n>
|
||||
filesModified: [<file_a>, <file_b>]
|
||||
verification:
|
||||
- <command_a>: passed
|
||||
- <command_b>: passed
|
||||
reproduce: 我如何复现验收路径 <steps>
|
||||
risk: <remaining risk or none>
|
||||
```
|
||||
|
||||
Orca 模式下用 `orca-adapter.md` §「Developer 回报 worker_done」的命令发送同样的字段。
|
||||
|
||||
---
|
||||
|
||||
## 4. Coordinator 最终报告模板
|
||||
|
||||
```text
|
||||
本轮闭环完成。
|
||||
|
||||
已验证：
|
||||
- <task_id>: <what passed>
|
||||
|
||||
遗留：
|
||||
- <task_id>: 三轮仍未通过，已记录为 leftover。最后失败证据：<evidence>
|
||||
|
||||
验证命令：
|
||||
- <command>: passed
|
||||
|
||||
工作树状态：
|
||||
- <repo_path>: <git status summary>
|
||||
- <dev_worktree>: <git status summary>
|
||||
```
|
||||
@@ -0,0 +1,90 @@
|
||||
# 角色与权限（稳定核心）
|
||||
|
||||
本文件是**角色模型、路径权限、任务状态机、完成定义**的单一事实源（SSOT）。其它文件只引用本文件，不重复定义。
|
||||
|
||||
目标：让每个 Agent 只处理自己能验证的事情，减少上下文污染和越权修改。
|
||||
|
||||
---
|
||||
|
||||
## 角色模型
|
||||
|
||||
| 角色 | 主要职责 | 验证方式 | 不应做的事 |
|
||||
|------|----------|----------|------------|
|
||||
| Product/Test Coordinator | 需求拆解、任务记录、黑盒测试、复测验收、调度开发 | 浏览器、API、集成脚本、用户可见行为 | 修改应用源码、凭 worker_done 直接标记完成 |
|
||||
| Developer Worker | 实现修复、写单元测试、运行构建和白盒验证 | 单元测试、类型检查、构建、本地运行 | 修改产品规格、标记 verified、绕过测试声称完成 |
|
||||
| User / Decision Owner | 决定范围、优先级、阻塞项是否继续 | 审阅报告和遗留清单 | 直接替代复测证据 |
|
||||
|
||||
---
|
||||
|
||||
## 路径权限模板
|
||||
|
||||
目标项目在自己的 `AGENTS.md` 中填入实际路径（见 `templates/AGENTS.template.md`）。
|
||||
|
||||
| 路径 | Product/Test | Developer | 说明 |
|
||||
|------|:------------:|:---------:|------|
|
||||
| `<spec_paths>` | R/W | Read-only | PRD、API spec、设计文档 |
|
||||
| `<integration_test_paths>` | R/W | Read-only | 浏览器用例、API smoke、回归清单 |
|
||||
| `<test_records_path>` | R/W | Read-only | 复测记录，通常可 gitignore |
|
||||
| `<source_paths>` | Read-only | R/W | 应用源码 |
|
||||
| `<unit_test_paths>` | Read-only | R/W | 单元测试 |
|
||||
| `<shared_config_templates>` | Read-only | R/W | 可提交配置模板 |
|
||||
| `<local_config>` | Read-only | Read-only | 本地私有配置，不提交 |
|
||||
| `tasks.yaml` | R/W | Read-only | 见下方「任务板写入约定」 |
|
||||
|
||||
---
|
||||
|
||||
## 任务状态机（SSOT）
|
||||
|
||||
```text
|
||||
open
|
||||
-> dispatched
|
||||
-> fixed_by_dev
|
||||
-> retesting
|
||||
-> verified
|
||||
```
|
||||
|
||||
失败分支：
|
||||
|
||||
```text
|
||||
dispatched -> blocked
|
||||
fixed_by_dev -> failed_retest -> dispatched
|
||||
failed_retest（累计 3 轮） -> leftover
|
||||
```
|
||||
|
||||
状态定义：
|
||||
|
||||
| 状态 | 写入者 | 含义 |
|
||||
|------|--------|------|
|
||||
| `open` | Product/Test | 已发现，等待处理 |
|
||||
| `dispatched` | Product/Test | 已派发给开发 Agent |
|
||||
| `fixed_by_dev` | Product/Test（据 worker_done 回写） | 开发声称已修复并提供验证 |
|
||||
| `retesting` | Product/Test | 正在复测 |
|
||||
| `failed_retest` | Product/Test | 复测失败，可继续派发 |
|
||||
| `verified` | Product/Test | 复测通过 |
|
||||
| `blocked` | Product/Test | 需要用户决策或外部条件 |
|
||||
| `leftover` | Product/Test | 累计 3 轮仍未通过，留给人工或专项处理 |
|
||||
|
||||
三轮失败的处理细则见 `optimization-method.md` §「三轮失败策略」。
|
||||
|
||||
---
|
||||
|
||||
## 任务板写入约定（并发安全）
|
||||
|
||||
`tasks.yaml` 是持久事实源，为避免多 Worker 并发写冲突：
|
||||
|
||||
- **只有 Coordinator 写 `tasks.yaml`**。Developer Worker 对它是只读的。
|
||||
- Developer 的实现状态、证据通过 `worker_done` 消息回传，由 Coordinator 落盘。
|
||||
- 每次写入前先读最新内容，写入后更新顶层 `updatedAt`。
|
||||
- 单次写入应是一个任务的一次状态跃迁，避免整表批量重写。
|
||||
|
||||
---
|
||||
|
||||
## 完成定义（Definition of Done）
|
||||
|
||||
一个任务只有同时满足以下条件，才能标记 `verified`：
|
||||
|
||||
- Developer 已提供修改文件和验证证据。
|
||||
- Product/Test 在正确 worktree 和正确服务实例上复测（对齐检查见 `closed-loop.md`）。
|
||||
- 相关单元测试、构建、集成或浏览器检查通过。
|
||||
- `tasks.yaml` 中记录了复测证据。
|
||||
- 用户可见行为符合验收标准。
|
||||
Reference in New Issue
Block a user