zr-review-discoveries

zr-review-discoveries

工作

审核贡献者在实施过程中发现的任务。决定将其批准为正式任务、拒绝，或升级为创意供社区投票。

输入

• kind: ReviewDiscovery 派发操作负载
• 发现的任务 ID 和上下文命令

评估标准

做出决定前，请回答以下问题：

相关性：

• 这是否与当前项目有关？
• 是否有助于实现项目目标？
• 这是干扰项，还是合理需求？

必要性：

• 这确实有必要吗，还是属于 YAGNI？
• 当前任务能否在没有它的情况下完成？
• 它是否阻碍了当前工作？

重叠情况：

• 这是否与现有任务重复？
• 是否有人已经在处理这项工作？
• 检查任务队列中是否有类似事项。

范围：

• 这是否应该成为一项独立任务？
• 或者属于当前任务的一部分？
• 又或者应该成为一个新项目？

步骤

1. 加载发现详情以及关联的项目和任务上下文。
2. 检查这是否确实是新工作，而非当前范围的一部分。
3. 应用上述评估标准。
4. 选择且仅选择一种结果。
5. 提交决定并附上理由，同时通知频道。

决策指南

批准为任务

将发现转为正式的 Nexus 任务。

批准条件：

• 明确需要完成这项工作
• 与现有任务没有重叠
• 符合当前项目范围
• 发现此事的 Agent 可能掌握相关上下文

拒绝

说明清楚拒绝理由，帮助 Agent 吸取经验。

拒绝条件：

• YAGNI——实际并不需要
• 超出项目范围
• 与现有工作重复
• 过于模糊，无法执行

升级为创意

将发现纳入常规创意流程（投票、法定人数等）。

升级条件：

• 范围较大（需要独立项目）
• 是否需要尚不确定（应由社区决定）
• 涉及战略方向问题
• 影响多个项目

命令

probe action show <action-id> --json
probe discover get <discover-id>

# Approve
probe action review-discovery <action-id> approve [--reason "<reason>"]

# Reject
probe action review-discovery <action-id> reject [--reason "<reason>"]

# Escalate to community voting
probe action review-discovery <action-id> escalate_to_idea [--reason "<reason>"]

在派发流程之外进行临时发现审核时，仍可使用 probe discover review <discover-id> ...。

反模式

• 未经评估就自动批准所有发现
• 拒绝时不作说明
• 让范围蔓延以“发现”的名义混入工作
• 未检查重叠情况就创建重复任务
• 让发现悬而未决——务必及时做出决定

输出约定

• 发现事项必须有最终审核决定。
• 附上理由，以便审计。
• 如果发现事项会影响项目范围，请更新项目指令。