工作流状态
workflow-state.json 是运行执行的单一事实来源。模式：
templates/workflow-state.template.json。它由每次工件写入后的 post-write-state 钩子以及 scripts/approve_event.py / scripts/reject_event.py 更新。
代理不得手动编辑它。
键
| 键 | 含义 |
|---|---|
run_id | 必须等于运行文件夹名称（runs/<run-id>） |
requirements_hash | 工件的 artifacts/01-requirements.md 的 SHA-256 哈希（写入时设置） |
execution_plan | 有序步骤：step、name、agents、depends_on、status（pending/running/done/failed）、attempts |
artifacts | 相对于运行的路径映射 → {owner, status, sha256, updated_at} |
gate_results | 映射 G1..G8 → {status: PASS/FAIL/PASS-N/A, attempts, findings, responsible_agent} |
retry_counters | 映射 G1..G8 → 已消耗的重试轮数 |
approval | {status: pending/approved/rejected, approved_at, plan_sha256, rejected_count, feedback[]} |
notes | 仅追加的自由格式日志（决策、跳过的代理及原因） |
更新规则
- 哈希是文件字节的 SHA-256（十六进制，小写）。当步骤由于工件状态为
done且磁盘上的哈希匹配而被跳过时，不记录任何新内容。 - 状态转换：
pending → running → done|failed。针对性重试仅重新运行负责代理的步骤及其下游依赖项；增加该步骤的attempts和retry_counters[gate]。 - 跳过的代理记录在
notes中（例如，"entertainment-planner skipped: no entertainment required"），其工件仍会写入，内容为Not applicable — <reason>。 - 门控结果按门控记录，包含发现和
responsible_agent；状态为FAIL且attempts为 3 的门控停止相关执行——将下游步骤标记为failed，并以清晰的报告结束运行。 - 审批：仅
scripts/approve_event.py可以设置approval.status = "approved"和approval.plan_sha256。scripts/reject_event.py向approval.feedback追加内容并递增rejected_count。对06-event-plan.md的修订会使plan_sha256失效，即使该字段已过时。 - 写入是原子的（临时文件 + 重命名）。保持
updated_at为 UTC ISO-8601 格式（...Z）。
恢复合同（/plan-event --resume <run-id>）
- 加载状态；如果
workflow-state.json缺失或无效 → 停止并报错。 - 重新哈希磁盘上
artifacts中的每个路径；不匹配则将工件标记为stale。 - 仅执行状态为
pending/running/failed的步骤，以及工件为stale的步骤（及其下游依赖项）。 - 绝不重复执行工件为
done且哈希匹配的步骤。 - 每个工件完成后，钩子自动更新状态——协调器仅更新
execution_plan、gate_results、retry_counters和notes。