work-tournament

/work-tournament — 並列実装トーナメント

複数の異なる方法でタスクを並列に実装し、各候補を決定論的なオラクルで判定して、合格した候補を実際の差分に基づいて評価し、最良のものを適用します。最後に、main で再検証します。

これは品質システムの実装部門です。../work/references/workflow-mode.md §2（「実装作業では、worktree 上で work-tournament を使用する」）で触れられているビルド段階のトーナメントです。../work/references/anti-error-lessons.md の教訓 L1～L8 を実践するもので、以下の教訓タグ（L1～L8）は同ファイルを参照しています。内容を重複して記載せず、そちらをお読みください。

ワークフローの構成

並列バリア → その後に短いパイプラインの後続処理。

• 並列展開部分はバリアです。候補は同じタスクをそれぞれの worktree で並列に実装し、比較は本質的に項目間で行われます。すべての候補が完了し、オラクルの判定を通過するまでは候補 A の順位を決められません。これは workflow-mode §1 にある、正当なバリアの理由 3 つのうちの 1 つです（「項目間の比較：すべての候補を順位付けする審査」）。
• 勝者を選んだ後の後続処理（取り込み → 完全性の確認 → main での再検証）は、単一の項目に対する短いパイプラインです。

これは LOOP ではありません。N は事前に固定され、完了するまで繰り返す契約もありません。（最良の候補でも不十分な場合は、ループをひそかに続けるのではなく、異なる観点を増やして再実行するか、オーケストレーターにタスクを引き継いでください。）

使い方

/work-tournament [N] <task>

• 最初のトークンが 2～10 の数字の場合、その数字が候補数になり、残りがタスクです。
• 省略した場合、N は既定で 3 です。

例：

• /work-tournament implement the login page（候補 3 件）
• /work-tournament 5 refactor the auth module（候補 5 件）

予算、並行処理、上限の無告知禁止

起動する前に、N とその理由を記録してください（ハーネスの todo／計画ツールに 1 行で記録します）。これにより、読者は意図的に選んだ件数なのか、途中で打ち切られたのかを判断できます（L7／workflow-mode §3「上限の無告知禁止」）。

• 並行処理の上限：min(N, 16, cores−2) 件ずつ、管理されたウェーブで起動します。N が上限を超える場合は、超過分をキューに入れてください。候補をひそかに削除してはいけません。
• 予算への配慮：予算が厳しい場合は、N を明示的に減らし、そのことを記録してください（「予算により N を 5→3 に削減」）。ひそかに件数を減らしてはいけません。
• 実行記録：重要度の高い実行では、エージェントのデータディレクトリ配下に quality-journals/<task-id>.json を作成し、次の情報を記録してください。 { N, anglesUsed[], worktrees[], oracleResults[], survivors[], disqualified[], winner } これにより、実行の監査と再開が可能になります。worktree のパスと、候補ごとのステータス（built／DQ'd／予算による削除）を記録してください。

手順

1. リクエストを解析する

N（候補数。既定値は 3）とタスクの説明を抽出します。

2. 各候補に異なる観点を割り当てる（L3）

同じプロンプトを N 個使うと、ほぼ同じ差分が N 個できてしまいます。それはトーナメントではなく冗長であり、異なる観点だからこそ見つかるものを見落とします。次のリストから各候補に 1 つずつ観点を割り当ててください（N がリストの数を超える場合は繰り返します）。

1. 差分を最小化 — タスクを完全に満たす最小の変更にします。変更するファイル数を最小限にします。
2. 慣用的な実装を優先 — 周囲のコードベースのパターンや規約に最も忠実に合わせます。
3. 防御性とエッジケースの網羅性を優先 — すべてのエッジケース、null／空／エラーの経路、境界を処理します。
4. パフォーマンスを優先 — 最も効率的な方法を選びます（アロケーション、クエリ、計算量）。
5. 読みやすさを優先 — 最も明快で、正しさが明白なコードを目指します。

観点と候補の対応関係を記録してください（多様性の理由を説明でき、実行記録にも利用できます）。

3. 並列ワークツリーで N 個の候補を起動する（バリア）

N 個のサブエージェントを単一のメッセージ（並列ツール呼び出し）で起動します。各候補について、次の条件でサブエージェントを起動します。

• 適切なサブエージェントの役割（汎用実装担当）
• 分離されたワークツリー ← 必須。候補はファイルを同時に変更するためです（workflow-mode §3「ワークツリーの分離」）。
• バックグラウンドで実行する
• 説明：「Candidate <number> (<angle>)」
• プロンプト：タスクの説明、割り当てられた観点、および次の文： 「あなたは、 の観点から作業する、 個の独立した実装のうちの候補 です。タスクを最後まで実装してください。見栄えをよくするために手を抜かないでください。評価対象は実際の差分とビルド／テストの合否であり、要約ではありません。返信の最後のブロックには、以下の Candidate Output Contract JSON のみを返してください。」

返却形式を確実にするため、以下の Candidate Output Contract を各プロンプトに含めてください。起動後は、すべての候補が完了するまで待機し、その後、各結果を収集します。ハーネス固有のツール名（サブエージェントの起動／全員の完了待ち／結果の収集／バックグラウンドでの実行／分離されたワークツリー）については、../work/references/workflow-mode.md のハーネス別の表を参照してください。

3.5 候補ごとのオラクルゲート — 評価の前に実施（L1、フェイルクローズ）

候補の自己申告は証拠ではありません。まず各ワークツリーで決定論的なオラクルを実行してください。ランキングの対象とするのは、実際にビルドできた候補のみです。

• リポジトリからオラクルコマンドを自動検出します。package.json のスクリプト（build、typecheck／tsc、test、lint）、Makefile のターゲット、または AGENTS.md／CLAUDE.md の規約を確認します。検出できるものがない場合は、oracle: "none-available" と記録し、その旨を明記します（合格したように装わないでください）。
• 各ワークツリーで、build → typecheck → test → lint の順に実行します。それぞれの実際の合否を記録します（候補の申告ではありません）。
• ビルドに失敗した候補、またはテストに失敗した候補は自動的に失格となります。 失敗したコマンドと最初のエラー行を添えて、ジャーナルに disqualified として残します。必ず記録してください。黙って除外してはいけません（L7）。lint のみの失敗は Medium の不具合であり、自動失格ではありません（記録し、採点に反映してください）。
• Null の処理（workflow-mode §3）： .filter(Boolean) で停止／空／エラーの候補を除外し、残った候補をもとに「survivors」を再計算して、除外を記録します（例：「5 件起動 → 1 件クラッシュ、1 件はビルド失敗で失格 → 3 件を採点」）。停止した候補は、参加者として数えてはいけません。

4. 実際の差分に基づいて残った候補を評価する（L2）— 自己要約に頼らない

残った候補ごとに、以下の作業を自分で行ってください。説明文だけを根拠に採点してはいけません。

1. git -C <worktree> diff を実行します（新規／名前変更されたファイルについては git -C <worktree> status も実行します）。
2. ワークツリー内の変更されたファイルをすべて読みます。実際のソースを開き直し、diff_summary／self_report を信頼してはいけません。これは L2 の修正です。調査担当者が引用した証拠ではなく、現在のソースに基づいて採点します。
3. 差分とオラクルの結果から、次の 3 つの軸を採点します。
   • 正確性 — 差分は実際にタスクを解決し、要件を満たしていますか？ロジック／型のエラーはありませんか？考慮漏れはありませんか？（オラクルの結果を主な証拠とします）
   • コード品質 — 明確で読みやすく、コードベースの規約に沿っており、不要な変更や範囲外の編集がありませんか？
   • 安全性 — 新たなバグ、セキュリティ上の問題、データ損失につながる経路、既存動作の破壊がありませんか？

5. 所見の表における重要度の調整（L6）

各所見の重要度は、検証済みの影響に基づいて判断してください（誤検知による過大評価と、見逃しによる過小評価の両方を防ぎます）。

• Critical = データ損失／セキュリティホール／ビルドを壊す（実際に到達可能で、損害をもたらすことが具体的に確認できる。変更をこのままリリースしてはいけません）。
• High = 出力が誤っている／動作が壊れている／テストが失敗する（実際に到達可能で、損害をもたらすことが具体的に確認できるが、データ損失／セキュリティ／ビルドの破損には至らない）。
• Medium = エッジケースの見落とし、カバレッジ不足、lint の失敗、もっともらしいが未検証の問題。
• Low = スタイル／見た目／命名。

推測に基づく見落としを Critical／High にしてはいけません。また、悪用可能な問題やビルドを壊す問題を Low にしてはいけません。

6. 採用候補の網羅性チェック（L5）

適用する前に、採用候補の差分とタスクの全スコープを対象に、少なくとも1つの全体的な検証手段を実行してください。最も価値の高い確認は、変更済みの箇所を再確認することではなく、まったく変更されていない箇所を見つけることです。

• リポジトリ全体で、タスク対象の中核となるエンティティ／シンボルを grep する → 変更されるべきなのに変更されていないファイル（未変更の呼び出し箇所、設定、型、テスト）がないか確認します。
• 元の依頼に対する未対応の要件（タスクを読み直し、項目ごとに確認します）。
• 変更した API／シグネチャ／スキーマの下流の利用側が更新されているか確認します。

見つかった不足は、名前付きリストとして記録します（L7）。スコープを損なうほど重大な不足があれば、採用候補を降格させるか、別候補から変更を取り込みます（work-judge 方式）。どちらを選んだか明記してください。

7. 採用候補を main に適用する

採用した作業ツリーの変更を main ワークスペースに取り込みます。現在の main に対する競合は明示的に解決し、ローカルの変更を上書きしないでください。

8. 適用後の再検証（L1、フェイルクローズ）

取り込み後、同じ検証手段を main で再実行します（build → typecheck → test → lint）。作業ツリー内で問題なく動作した候補でも、マージ後に問題が発生する可能性があります（競合、差異、作業ツリー外のファイル）。WINNER を出す前に、競合や失敗を修正してください。 main で問題を解消できない場合は、採用候補を宣言せず、失敗と残作業を報告してください。

9. クリーンアップ

採用候補を含むすべての候補について、生成した作業ツリーを git worktree remove で削除します（その内容はすでに main に存在します）。ジャーナルはそのまま残します。作業ツリーが残った場合は、その理由を記録してください。

10. 採用候補を宣言する

手順 8 が成功した場合に限り、回答の最後を WINNER: <number>（1-N）で締めくくります。

候補の出力契約（各サブエージェントは最終ブロックとして以下を返す）

自己報告はトリアージとジャーナルのためだけのものであり、呼び出し元による検証手段の実行（3.5）や差分の確認（4）の代わりにはなりません。呼び出し元は出力形式を検証し、不正な場合は1回だけ再要求します。なお不正な候補は採用せず、記録します（workflow-mode §3「構造化出力」）。

{
  "candidate": 2,
  "angle": "most-defensive",
  "approach": "one-paragraph summary of how this candidate solved the task",
  "files_changed": ["auth/login.ts", "auth/login.test.ts"],
  "diff_summary": "added null-guards on session lookup; new test for expired token",
  "build_passed": true,
  "tests_passed": false,
  "self_report": "free-form notes, known gaps, anything the grader should re-check"
}

各フィールドの規則：

• candidate（int、必須）、angle（string、必須 — 割り当てられた観点）。
• files_changed（string[]、必須） — 呼び出し元は git diff と照合します。不一致は警告サインです。評価は差分に基づいて行います。
• build_passed／tests_passed：boolean | null。null = 候補が実行していない（不明）ことを意味します。呼び出し元はこれを未検証として扱い、成功とはみなしません。呼び出し元は実際の検証手段を必ず実行し（3.5）、測定値でこれらの値を上書きします。空または未入力のオブジェクトは .filter(Boolean) で除外されます。
• diff_summary、self_report（string）— 参考情報のみです。

評価結果の提示

まずスポーン台帳を示します（N、角度マップ、理由付きの生存者と失格者）。 次に、生存した候補の比較と所見を示します。

評価項目	候補 1（最小差分）	候補 2（防御重視）	...
オラクル（ビルド／型チェック／テスト／Lint）	✅✅✅✅	✅✅❌ DQ	...
正確性	簡潔な判定	—（DQ）	...
コード品質	簡潔な判定	—	...
安全性	簡潔な判定	—	...

所見	重大度	候補 1	候補 2	...
具体的な問題	Critical／High／Medium／Low	対応方法	対応方法	...

選んだ候補とその理由、完全性スイープの結果（ステップ 6）、適用後の再検証結果（ステップ 8）を記載します。

作業例（抜粋）

/work-tournament 4 add rate-limiting to the login route

1. 方針：c1 最小差分、c2 最も慣用的、c3 最も防御的、c4 パフォーマンス優先。(記録済み)
2. ワークツリーで 4 件をバックグラウンドで起動します（上限 = min(4,16,cores−2)）。 3.5 ワークツリーごとにオラクルを実行：c1 ✅build ✅type ✅test ✅lint、c2 ✅✅✅✅、c3 ✅✅❌test（ウィンドウのリセットでオフバイワン）→ DQ、記録済み、c4 クラッシュ／空 → .filter(Boolean) → 除外、記録済み。生存者：c1、c2（4 件起動 → 1 件クラッシュ、1 件失格 → 2 件を評価）。
3. git -C wt-c1 diff とファイルを確認：c1 はインメモリのカウンターを追加します（再起動で失われます）。git -C wt-c2 diff：c2 は既存の共有キャッシュヘルパーを使います。
4. 所見：c1「デプロイ時にレートリミッターがリセットされる」→ High（レート制限を事実上回避可能）。c2 は問題なし。
5. 完全性スイープ：リポジトリ内でログインハンドラーのシンボルを検索 → 管理者ログインの別名にも保護がないことが判明 → 不足を記録し、両方のルートにガードを適用します。 7–8. c2 と管理者ルートの修正をメインに取り込み、メインでオラクルを再実行 → 成功。
6. WINNER: 2。

構成

• ../work/SKILL.md から呼び出し可能 （workflow-mode §2 のビルドフェーズのトーナメント）。
• 委任可能：../work-check/SKILL.md で生存者を評価、 ../work-refute/SKILL.md で有力候補の差分を徹底的に検証、 または ../work-gaps/SKILL.md でステップ 6 のスイープを実行します。
• ../work-judge/SKILL.md との違い：work-judge は 広い解決策の範囲を扱う生成的な設計です（提案のみで、コードは適用しません）。 work-tournament はコードを実装し、実際のオラクルによるゲートを通過した勝者を適用します。

依頼の規模に合わせる

明らかに正解が 1 つしかない 1 行の変更に、5 候補のトーナメントは不要です。直接対応し、その理由を記録してください（workflow-mode §5）。work-tournament は、設計の自由度が実際にあるタスク（妥当な実装が複数ある、差分が小さくない、正確性／品質／パフォーマンスの間に意味のあるトレードオフがある）で使用します。