完成后的状态
完成本页后，一条发布公告 Issue 会有唯一负责人、可检查的 Agent 运行和产物、结构化评审结论，以及已经接受的done 状态。后来的人只看这条 Issue，就能理解整个过程。
开始前
先准备有边界的结果、验收标准、一名符合条件的负责人，以及需要独立判断时的一名评审人。状态含义和允许的转换以 Issue 状态参考为准，本指南不再另写一套定义。 每条 Issue 只有一名负责人。任务不在backlog 且已经可以执行时，把它分配给 Agent 会唤醒 Agent。Agent 执行时要以运行身份签出任务；已指定评审人时，负责人不能直接完成来绕过评审。
推进发布公告
- 新建“起草发布公告”，写清受众、必须包含的安装命令、宣传边界、产物格式和评审验收标准。
- 这些输入仍需要决定时，留在
backlog。只有另一位负责人不需要追问任务含义就能开始时，才移到todo。 - 分配给文案 Agent，并指定市场评审人。分配会唤醒 Agent，不要再手动启动重复运行。
- 让 Agent 签出 Issue 并生成 Markdown 文件。检查 Agent 运行、产物链接、验证、可用的成本数据和剩余风险。
- 产物真正可以判断时，再移到
in_review。评审路由把下一步交给评审人，但不会把实现工作重新分配给对方。 - 评审人填写说明，并记录一个结构化结论。接受后可以完成 Issue；要求修改时，下一步回到负责人；阻塞时，缺少的信息继续保持可见。
成功信号
处于done 的 Issue 显示原始请求、每个阶段的当前负责人、Agent 运行、Markdown 产物、验证证据、评审说明、结构化结论和后续工作。任何人都不需要再去终端记录或私聊里拼凑结果。
恢复
运行失败时，保持 Issue 打开并附上失败证据。下一步依赖权限、某个人、其他任务或外部条件时，使用blocked，同时写明由谁解除阻塞。如果负责人运行成功却没有留下足够的关闭信号，Rudder 可以安排次数有限的同 Agent 跟进，而不是把缺口隐藏成成功。
已经有评审产物但没有结构化结论时，保持评审状态，并交回评审人。已经关闭的 Issue 只能通过明确的重新打开评论恢复，这个动作会留下持久证据。