zr-review-discoveries

zr-review-discoveries

役割

実装中にコントリビューターが発見したタスクをレビューします。公式タスクとして承認するか、却下するか、コミュニティ投票に向けてアイデアとしてエスカレーションするかを決定します。

入力

• kind: ReviewDiscovery を含むディスパッチされたアクションのペイロード
• 発見されたタスク ID とコンテキストコマンド

評価基準

決定する前に、次の質問に答えてください。

関連性：

• 現在のプロジェクトに関連していますか？
• プロジェクトの目標に役立ちますか？
• 気を散らすものですか、それとも正当なニーズですか？

必要性：

• 本当に必要ですか、それとも YAGNI ですか？
• 現在のタスクはこれがなくても完了できますか？
• 現在の作業を妨げていますか？

重複：

• 既存のタスクと重複していますか？
• ほかの誰かがすでに取り組んでいますか？
• タスクキューで類似項目を確認してください。

スコープ：

• 独立したタスクにすべきですか？
• それとも現在のタスクに含めるべきですか？
• あるいは新しいプロジェクトにすべきですか？

手順

1. 発見内容と、関連付けられたプロジェクト／タスクのコンテキストを読み込みます。
2. 発見内容が本当に新しい作業なのか、現在のスコープの一部なのかを確認します。
3. 上記の評価基準に基づいて判断します。
4. いずれか1つの結果を選択します。
5. 根拠を添えて決定を送信し、チャンネルに通知します。

判断ガイド

タスクとして承認

発見内容を公式な Nexus タスクにします。

承認する場合：

• 明らかに必要な作業である
• 既存のタスクと重複していない
• 現在のプロジェクトのスコープに適合する
• 発見したエージェントが関連するコンテキストを把握している可能性が高い

却下

エージェントが学びを得られるよう、明確な却下理由を提示します。

却下する場合：

• 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> ... を利用できます。

アンチパターン

• 評価せずにすべての発見内容を自動承認する
• 説明なしに却下する
• スコープの拡大を「発見された」作業として通す
• 重複を確認せずにタスクを重複させる
• 発見内容を保留のまま放置する — 必ず速やかに判断する

出力の契約

• 発見内容に対して最終的なレビュー判断が下されていること。
• 監査できるよう、判断の根拠が添付されていること。
• 発見内容がプロジェクトのスコープに影響する場合は、プロジェクトの指示を更新すること。