arena

Arena

子ブリーフ、並列実行、パネル、モデル、フォールバックについては、ポータブルランタイム契約に従ってください。

同じタスクに対する N 個の並列試行を展開します。すべての候補を最初から最後まで読みます。最も強力なものをベースとして選びます。他の候補から最良のアイデアをそこに接ぎ木します。統合された結果を検証します。

開始

何かを起動する前に、フェーズごとに 1 つのチェックリスト項目を追跡します。ホストの計画機能が利用可能な場合はそれを使用し、そうでない場合は会話またはプロジェクトローカルの決定記録にコンパクトなチェックリストを保持します。Arena は自律的に実行されるため、このリストによってフェーズが黙って消えるのを防ぎます。

1. 枠組み
2. 展開
3. 相互審査
4. 選定
5. 接ぎ木
6. 検証

フェーズ A: 枠組み

N 個の候補は同じプロンプトを受け取るため、プロンプトが契約となります。何かを生成する前にそれを正しく仕上げます。

1. 各候補が生成する成果物を明示します。
2. 評価基準を導出します。このタスクにとって成功とはどのようなものかを述べ、それを 3〜6 個の具体的で採点可能な基準に変換します。具体的: 書き込みをスキップする --dry-run フラグを追加する。曖昧: コードが正しい。評価基準はフェーズ D における選定者のツールです。候補はタスクのみを見ます。
3. 実行者を選びます。ポータブル pstack 構成に arena runners パネルが存在する場合はそれを使用します。そうでない場合は、designer、planner、reviewer、inherit-parent から引き出した、ホストがサポートする多様なパネルを使用します。Arena が複数の設計方向をカバーする場合は、さらに多くを起動します。作業が判断に敏感ではなく生成に制約されている場合、ホストがサポートする 1 つの選択肢を N 回繰り返すことは有効です。
4. 出力パスを割り当てます。各候補はそれぞれ独自の場所（可能であれば git worktree、そうでなければ /tmp/arena-<slug>/candidate-<n>/）に書き込みます。N 個の候補が同じパスに書き込むことは共有可変状態であり、separate-before-serializing-shared-state 原則スキルテストに失敗します。

フェーズ B: 展開

ホストのタスク機能を通じて、N 個の子をすべて同時に起動します。それぞれに、タスク、共有グラウンディングへのパス、独自の出力パス、受け入れ基準、検証、禁止スコープ、および成果物と短い根拠の両方を生成するための指示を含む、スタンドアロンのブリーフを与えます。

根拠は必須です。それがなければ、親は候補の構造が原則に基づくものか偶発的なものかを判断できず、フェーズ E の接ぎ木が信頼できなくなります。各根拠は、候補が検討した代替案と、何を却下したかを明示します。

候補が出力の生成に失敗した場合は、N-1 で続行し、統合記録に脱落を記録します。

フェーズ C: 相互審査

フェーズ B の候補がすべて完了した後、ポータブル pstack 構成に arena cross-judge pool が存在する場合はそこから 1 つの選択肢を選びます。そうでない場合は、ホストの reviewer ロールまたは inherit-parent を使用します。ホストがモデル識別情報を公開する場合は、親とは異なるモデルファミリーを優先します。その選択肢に対して 1 つの読み取り専用の審査子を起動します。それは評価基準とパスラベルによる候補を参照し、各基準を採点し、根拠とともにベースを推薦します。それはフェーズ D における親の読み込みと並行して実行され、候補自体とは並行しません。候補がまだ書き込んでいる間に起動すると、審査子は部分的または空の出力を見て、それらを脱落として報告します。

フェーズ D: ベースの選定

選定する前に、すべての候補を最初から最後まで読みます。N 個の候補をざっと流し読みすると、表面的に最も見慣れた候補だけが浮かび上がります。

各候補を、全体的な印象ではなく、評価基準に対して基準ごとに採点します。相互審査と比較します。ベースについての一致は選定を裏付けます。不一致は、どちらかがバイアスを持っているか、評価基準が曖昧であったことを意味します。決定する前に両方の根拠を読みます。

将来のメンテナーが不変条件を壊さずに最も容易に拡張できる候補をベースとして選びます。Laziness Protocol に従い、2 つが同等に感じられる場合は、よりクリーンな境界またはより小さな表面積を優先します。

選定とその理由を、ベース成果物と並んで短い統合メモに記録し、相互審査の判定を含めます。

Phase E: 統合

敗れた候補をそれぞれもう一度確認し、ベースに取り込む価値のある要素を特定します。通常、各候補から見つかるのは1つか2つで、大部分ではありません。

redesign-from-first-principles 原則スキルに従い、要素を1つずつ手作業で統合します。機械的に貼り付けてはいけません。結果は、1つのメンタルモデルのもとで一貫している必要があります。

何を、どの候補から取り込んだのか、また何を、なぜ却下したのかを記録します。却下理由の記録が、最も価値の高い情報です。後から読む人が学べるのは、採用したものだけでなく、検討して見送ったものからです。

N個の候補が同じ形に収束した場合、それは強い合意を示すシグナルです。記録に収束したことを記し、合意された形を採用します。統合は不要です。N個の候補が大きく食い違う場合、Phase Aの仕様が不十分でした。食い違いを平均化するのではなく、問題を捉え直して再実行します。

Phase F: 検証

合成された成果物は、prove-it-works 原則スキルに従い、ほかの出力と同じ厳しい検証に耐える必要があります。アリーナを通過したからといって、検証を免除されるわけではありません。

検証でアリーナが見つけられなかった問題が明らかになった場合、Phase Aが誤っていた（問題を捉え直して再実行する）か、ある候補が問題を捉えていたのに、その要素を取り込めなかった（Phase Eに戻る）かのどちらかです。問題を取り繕ってはいけません。

成果物

合成された成果物を1つ。その横に、ベース、取り込んだ要素（出典となる候補を含む）、却下した要素、あれば脱落した候補、検証結果を記した短い合成メモを1つ。