spawn-ori-eval

Ori Eval の実行

Ori は固定されたハーネスとモデルで評価を作成し、採点するため、どのコーディングエージェントでもベンチマークは同一です。Ori を実行し、ユーザーに状況を伝え、結果を報告してください。自分で評価を作成すると再現できず、スコアの変化は環境ではなくユーザーのエージェントによるものでなければなりません。

固定設定

このセクションでは、2 つのモデルを指定します。他のセクションでは、<RUN_MODEL> と <JUDGE_MODEL> という名前を使用します。それぞれ、このセクションで指定するモデル名に置き換えてください。モデルを変更する場合は、続く 2 行だけを変更してください。

• RUN_MODEL は openai/gpt-5.6-terra です。実行にはこのモデルを使用します。
• JUDGE_MODEL は openai/gpt-5.6-terra です。評価の判定にはこのモデルを使用します。

手順

以下を順番に実行します。1 行につき 1 つの操作を行います。付録の文字は詳細を示しており、トラブルシューティング表を除き、手順の順番どおりに参照します。トラブルシューティング表は参照用で、最後に確認します。

1. 実行ディレクトリを作成し、リポジトリのルートからそのパスを導き出します（付録 A）。
2. 実行ディレクトリの場所をユーザーに伝えます。
3. ディレクトリ内にすでにあるものを変更せずに読み取り、何があり、どのくらい前のものかをユーザーに伝えます（付録 A）。
4. そのディレクトリをどうするかユーザーに尋ねます。そのうえで、既存の steps.txt を再利用して、4 の次にある未完了の最初の手順に進むか、ファイルをアーカイブして 5 以降を記載した新しい steps.txt を作成するか、何も変更せずに停止します。ディレクトリに独自の実行ファイルがない場合に限り、確認せずに新しいトラッカーを書き込みます（付録 A）。
5. ori バイナリを自分で検索またはインストールします（付録 B）。
6. まだ見つからない場合は、自分で ~/.local/bin/ori のフォールバックを実行し、それも失敗したら停止します。
7. ori auth を自分で実行して出力を読み取り、終了ステータスとメッセージに応じて分岐します。アクセスが解決したら続行し、認証情報が見つからなければログイン手順を案内して停止します。コマンドが不明な場合は、インストールされた Ori が、このスキルで必要なヘッドレス実行サポートを含むバージョンより古いため、0.3.0 以降を使う手順を案内して停止します（付録 B）。
8. bun があるか自分で確認し、なければ停止します。
9. 評価の対象を自分で読み取ります。コマンドでエラーが発生しても続行します（付録 B）。
10. バイナリをインストールした場合は、その配置先をユーザーに伝えます。
11. 手順 9 で読み取った内容に基づき、実行で行われることをユーザーに伝えます。
12. 所要時間は 10～30 分で、ユーザーのキーのクレジットをそれ以上消費する可能性があることを伝えます。
13. スコア付きの表が得られることと、質問によって実行を再開できることをユーザーに伝えます。
14. タスクのプロンプトファイルを書き込みます（付録 C）。
15. リポジトリのルートから実行を 1 回開始し、回答ファイルとエラーファイルを保存します（付録 D）。
16. 実行の終了を待ってから、回答ファイルを読み取ります（付録 E）。
17. 回答ファイルにある Ori のナレーション行を、わかりやすくユーザーに伝えます。
18. 完了した回答のどこかにタグ付きの質問が含まれているか、要約行より前のアシスタントのテキストがタグなしの質問で終わっている場合は、手順 19 に進みます。最初の質問だけを伝え、別の質問が現れた場合は 1 問だけという契約への違反を報告します。タグなしの質問も違反として報告しつつ、ユーザーには伝えます（付録 E）。
19. 最初の質問について、表があればそれも含めた Ori のコンテキスト全体を通常のメッセージで出力します。この手順ではほかに何もしません（付録 E）。
20. コンテキストのメッセージと質問の間に、ここで steps.txt を更新し、実際に出力した内容を記録します。回答に表が含まれていた場合は、出力した表のヘッダー行を引用します。表がなかった場合は、その旨を記録します（付録 E）。
21. 独自の質問 UI を使ってユーザーに尋ねます。3 つの短い選択肢と自由記入の Other を維持します。質問は短い 1 文にし、コンテキストの表を言い直したり要約したりしません（付録 E）。
22. 質問とユーザー自身の回答をタスクのプロンプトファイルに追記します。回答が質問に答えていない場合は何も追記せず、質問 UI でもう一度同じ質問をして、次の返信でこの手順を再実行します（付録 E）。
23. 手順 22 で回答を追記した場合に限り、プロンプトファイル全体を使って次の試行番号で再起動し、手順 16 に戻ります（付録 E）。
24. 結果の表、リリース可否の判断、引用した失敗内容を伝えます。
25. Ori のコストと所要時間の表を省略せずに伝えます（付録 F）。
26. 各試行の回答ファイルの末尾にある要約行から、その試行固有の所要時間とコストを追加します（付録 F）。
27. 再実行のほうが安価であることを 1 行で伝えます。
28. Ori が一時ワークスペースを残した場所と、それが使い捨てであることを伝えます。
29. 数値を見て評価を残したいと思った場合は、リポジトリに移動できることを伝えます。

ルール

以下は実行全体に適用されます。

• 評価を自分で作成したり、自分のサブエージェントに委任したりしないでください。Ori の create-eval スキルは実行中に自動で動作します。
• 常に --model <RUN_MODEL> を渡し、--harness は決して渡さないでください。この固定指定により、すべてのコーディングエージェントの実行で同じベンチマークが使われます。別のスラッグに置き換えたり、このフラグを省略したりしないでください。どちらの場合も、ユーザーのインストール環境にある既定値が実行に使われてしまいます。
• 常に --prompt-file を渡してください。-p フラグも機能しますが、ここでは決して使わないでください。一度限りの文字列では再起動後に状態を引き継げず、位置引数だけのプロンプトは完全に拒否されます。
• 手順 5〜9 のコマンドはすべて自分で実行してください。バイナリが見つからない場合にインストールするのは想定内です。セットアップを引き継ぐのは認証情報の確認だけです。
• 自分の判断で再開したり、以前の実行を消去したりしないでください。このスキルは一つのセッション内で読み込まれて実行されるため、ディレクトリにすでに存在するものはすべて別のセッションで作成されたものです。また、これはユーザーが対価を払った作業の唯一の記録です。手順 4 以降のどの経路でも、ユーザーの回答を先に得てください。ただし、実行ファイルが一つもないディレクトリで新規に開始する場合は除きます。
• 作業を進めながら steps.txt を更新してください。手順を実行する前に現在の手順として記録し、次の手順を始める前に完了として記録します。記憶に頼らず、次に何をするか決める際はファイルを読み直してください。再起動するとプロンプトファイルの先頭から再実行されるため、前回の試行がどこまで進んだかを示す唯一の記録です。
• ユーザーへのメッセージが作業内容となる手順は、そのメッセージが会話に表示された後でのみ完了と記録してください。ツールの実行結果で内容を読んだだけでは、ユーザーに見せたことにはなりません。
• Ori のプロセスは一度に一つだけ実行し、候補モデルごとに一つずつ実行しないでください。モデルを比較するのは ori eval です。
• eval run pass 3 のような内部的な試行ラベルをユーザーに伝えないでください。代わりに、わかりやすい進捗表現を使ってください。
• 実行ディレクトリにある task.txt だけを、タスクのプロンプト状態として扱ってください。それ以降のメッセージはすべて追記し、再起動のたびにファイル全体を再送してください。--session は使わず、試行ごとに回答ファイルとエラーログを一つずつ用意してください。
• 実行を始める前に、何を評価するかユーザーに尋ねないでください。Ori のヒアリングでは、対象範囲、成功基準、実データ、コスト上限、ベースラインモデルを確認します。曖昧な依頼や空の依頼は、そのまま渡してください。
• Ori の質問にユーザーの代わりに回答しないでください。ユーザーに連絡できない場合は、停止して返答を待ってください。推測した目標に基づく評価は、正しそうに見えても無効です。
• 現在提示されている質問へのユーザーの返答だけを追記してください。確認を求める内容や苦情は返答ではないため、何も追記せず、ユーザーが実際に述べた内容に応じて返答し、質問 UI を使って同じ質問をもう一度行ってください。その後の返答は、その時点で提示されている質問への回答であり、前の確認段階にさかのぼって補うものではありません。
• 実行開始前に承認が必要という段階を勝手に設けないでください。手順 12 と 13 で所要時間とコストを伝えます。ユーザーの返答を待つのは、手順 4 での実行ディレクトリの選択と、手順 21 で扱う質問だけです。
• 各ターンは最初から最後まで無言で進めてください。開始前にそのことを明確に伝えてください。ターンが終わるまで表示されないため、フェーズのバナーを節目として報告しないでください。
• 数値を作り上げないでください。各試行の所要時間とコストは、その回答ファイルの末尾にあるサマリー行に記録されます。評価で行われたモデル呼び出しの数は、Ori の最後の表から確認してください。試行にサマリー行がまったく記録されていない場合に限り、数値は未計測としてください。
• 本番モデルが表に含まれていない限り、勝者を挙げないでください。「変更なし」も妥当な結果です。
• モデル ID や価格を記憶に頼って提示しないでください。OpenRouter で最新の価格を確認してください。このスキルで固定されているため、ピン指定だけは例外です。
• セットアップ確認では、OpenRouter へのアクセスが ori auth 経由で解決されることを確認してください。解決されない場合は ori login の実行をユーザーに案内し、生のキーを環境変数に設定するよう指示してはいけません。すでに継承されているキーで確認できる場合もあります。ori auth コマンドが認識されない場合、インストール済みの Ori はこのスキルが必要とするヘッドレス実行に対応していません。0.3.0 以降が必要だと伝え、停止してください。
• 手順 9 の出力をユーザーに貼り付けないでください。内容を読むのはあなたであり、ユーザーはそれを求めていません。
• credentials.json、.env ファイル、設定ファイルに含まれる秘密の値を表示しないでください。キー名と場所だけを示してください。例：OPENAI_API_KEY at .env:4
• 評価をユーザーのリポジトリに作成しないでください。これは使い捨ての測定ツールであり、ユーザーが保持を依頼したものではありません。評価結果を見た後で保持するかどうかを決めるのはユーザーです。
• 評価をリポジトリ独自のテストフレームワークに入れないでください。ori eval が検出するのは *.eval.ts ファイルだけです。そのため、pytest、vitest、Go のテストファイルは実行されないままになります。
• 生の API 呼び出しを Ori の評価として提示しないでください。別の方法で測定する場合は、そのことを明確に示してください。
• このスキルの用語をユーザーに見せないでください。「pre-run」「spawn」「verbatim」「harness」も含まれます。
• ユーザーに「bakeoff」と書かないでください。Ori の評価ドキュメントや説明では引き続きこの語が使われますが、内容を伝えたり、引用したり、要約したりする際は、毎回「モデル比較」に置き換えてください。自分の進捗表示やコマンドラベルでも同様です。
• 進捗状況は毎回、平易な言葉で伝えてください。試行番号、ファイルパス、プロセス ID、コマンドフラグ、終了コードをユーザーに見せないでください。実行に失敗した場合も同様です。例については Appendix E を参照してください。
• Ori のヒアリングには、次の順で七つのタグがあります。[surface]、[workspace-files]、[workspace-data]、[criteria-priority]、[evaluation-constraint]、[candidates]、[next-step] です。[surface] はスキャンで呼び出し箇所が複数見つかった場合に限ります。[workspace-files] は、スキャンでモデル呼び出し箇所も利用可能な素材も見つからなかった場合に限ります。この二つの条件付き質問が同時に行われることはありません。ほかの五つは常に尋ねるため、質問数は最低五つ、最大六つです。
• 1 ターンにつき質問は一つだけ伝えてください。三つの具体的な選択肢をそれぞれそのまま保ち、Other は自由記述として表示してください。Ori が一度のターンで二つの質問を出した場合は、最初の質問だけを伝え、一問ずつ尋ねるという契約への違反を報告してください。
• 中断後や、別の経路でやり取りがあった後も、すべての質問を質問 UI で行ってください。通常の文章で質問しても、手順 21 の要件を満たしません。
• 質問の前に、表を含むすべてのコンテキストを通常のメッセージで表示してください。これにより、回答後も会話内に読みやすい表が残ります。コンテキストのメッセージと質問の間で、手順トラッカーを更新してください。これは [next-step] を含むすべての質問に適用されます。結果表とコスト表は、質問に圧縮して含めるのではなく、その前にすべて表示してください。質問本文には Markdown の表を入れないでください。本文は折り返されたプレーンテキストとして表示され、表が生のパイプ文字列になってしまいます。配置方法の例は Appendix E を参照してください。
• CLI の詳細をこのスキルやユーザー向けの文章に転記しないでください。実行オプション、レポート、ベースライン、タイムアウト、評価ファイル API については、手順 9 の出力を読み直してください。CLI は変更されるため、転記した情報は古くなります。

付録 A：実行ディレクトリとステップトラッカー

必要なのは、評価対象のリポジトリによって名前が固定される、ユーザーのリポジトリ外のスクラッチディレクトリです。重要な点は 2 つあります。同じリポジトリは、サブディレクトリから実行を開始した場合も含め、常に同じディレクトリに解決される必要があるため、リポジトリのルートの絶対パスから名前を導き出し、リポジトリがない場合は作業ディレクトリを使います。異なるリポジトリが同じディレクトリに解決されてはならないため、名前はそのパスに応じて変わります。また、その名前を生成するものは Linux と macOS のどちらでも動作する必要があります。片方で何も出力されないステップがあると、すべてのリポジトリが 1 つのディレクトリにまとまってしまうためです。コマンド間でシェルの状態は通常引き継がれないため、変数が維持されると期待せず、必要なシェルごとに名前を計算し直してください。

後続の実行では検索ではなく同じパスにたどり着くことで以前の実行を見つけるため、名前はバイト単位で再現可能でなければなりません。つまり、/tmp/spawn-ori-eval-<hash> であり、ハッシュはツリーを特定するパス、すなわちリポジトリのルート、またはリポジトリがない場合は作業ディレクトリのパスだけを対象に、そのパスの末尾に改行を付けず、ほかのものを一切入力せずに計算した SHA-256 の 16 進数表記の先頭 12 文字です。固定されているのはその値だけで、計算方法ではありません。ただし、使う方法がそのバイト列だけをハッシュ化していることを確認してください。末尾に改行があると別のディレクトリになり、以前の実行が見つからなくなります。環境によって変わる一時ディレクトリではなく、/tmp を使ってください。そうすれば、同じマシンで次のセッションから実行を見つけられなくなることはありません。

外側の実行が生成するすべてのファイルは、そこにだけ置きます。steps.txt、task.txt、各試行の answer-<n>.txt と error-<n>.log です。ori/ サブディレクトリは、Ori のトラッカーと実行が自身で書き込むすべてのファイル用に確保します。スクラッチワークスペースは、create-eval 自体のインターフェースが作成する場所にあるため、Ori が報告するパスを ori/ に記録してください。ディレクトリはリポジトリごとに分かれているため、同じマシンで評価する 2 つのリポジトリが互いのプロンプトや回答を読み込むことはありません。

steps.txt の 1 行目にはユーザーの依頼を記載し、その後にステップ 5 以降の各ステップを 1 行ずつ記載します。それぞれに todo、current、done のいずれかを付けます。ステップ 1〜4 はファイルを生成するためのものなので、追跡しません。

request: which model should we use for the support triage agent
5 done look up the ori binary
6 done fallback lookup not needed
...
15 current start one run
16 todo wait for it to exit and read the answer file

実行ファイルが何もないディレクトリについては、判断する必要がないため、質問する必要もありません。つまり、previous/ 以外は空であり、steps.txt、task.txt、試行ファイル、ori/ サブディレクトリがありません。これは、ディレクトリが空の場合と、以前のアーカイブだけがある場合の両方に当てはまります。アーカイブ後も previous/ は残り続けるためです。それ以外は、何が入っていてもユーザーに確認してください。別の依頼に対して開始されたトラッカーや、すべてのステップが完了したトラッカーがある場合は、何を見ているのかをユーザーに伝える必要があります。ファイルを消してよいという意味ではありません。回答ファイルはユーザーが対価を払った実行結果であり、移動する前に確認したい場合があるためです。

ディレクトリを読み取り、その内容を報告してください。ユーザーが自分で開かなくても判断できるよう、古いトラッカーが開始されたときの依頼、どのステップで止まったかを平易な言葉で、試行回数、最後に何かを書き込んでからどれくらい経ったかを伝えてください。その後、オペレーター独自の質問 UI で質問し、回答を待ってください。

以前のトラッカーの 1 行目が現在の依頼と一致し、未完了のステップがある場合に限り、再開の選択肢を提示してください。それ以外の実行を再開すると、別の依頼のプロンプトファイルを Ori に再送してしまいます。新しい実行を開始する選択肢と停止する選択肢は常に提示できるため、回答は最低 2 つ、最大 3 つにしてください。 再開では、現状のものをそのまま再利用します。同じ steps.txt に印を付け、同じ task.txt に追記し、コスト表にはこれまでのすべての試行を残し、記録済みのスクラッチワークスペースのパスとともに ori/ ディレクトリも残します。ユーザーはすでにその作業に費用をかけているためです。新しい実行を開始すると、トラッカー、プロンプトファイル、すべての回答とエラーログ、ori/ ディレクトリがアーカイブされます。その結果、ユーザーが Ori にすでに提供した回答が失われ、リポジトリの調査を再び行うことになります。停止しても何も変わらず、そこでタスクは終了します。これは、何かが動く前に古いファイルを読みたいとユーザーが望む場合の選択肢です。どれを推奨するのか、その理由とともに伝え、判断はユーザーに委ねてください。

再開する前に確認すべきことが1つあります。ステップ15または16に current の印が残っている場合、その試行は開始済みですが、結果が不明です。別の試行を始める前に、そのプロセスがまだ実行中かどうかを確認し、実行中であれば終了するまで待ってください。同じプロンプトファイルに対する2つの実行は、1プロセスのルールに違反します。current のままになっているほかのステップは、開始されたものではなく中断されたものです。質問への回答を待っている間、ステップ22も current のままにしてください。

アーカイブすると、ori/ を含む古い実行のファイルは、実行ディレクトリ内の previous/ の下に、移動した時刻を名前にした専用のサブディレクトリとして格納され、何も削除されません。タイムスタンプがないと、後のアーカイブが前のアーカイブを上書きし、アーカイブディレクトリが自分自身の中に移動するという2つの問題が起こります。そのため、実行自身のファイルを移動し、previous/ はそのまま残してください。

付録 B：セットアップコマンド

curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash でバイナリをインストールします。バイナリは ~/.local/bin に配置されます。このディレクトリは、非ログインシェルでは PATH に含まれていないことがよくあります。そのため、失敗を報告する前に ~/.local/bin/ori --version を試してください。Ori は *.eval.ts を実行するために Bun を必要とします。

ori eval -h と ori eval skill で評価の仕組みを確認し、2つ目のコマンドがエラーになった場合は ori skills get create-eval を試してください。これは、実行中に Ori 自体が従う手順です。実行内容と、どのような質問をするかがわかります。タスクを妨げることはありません。両方のコマンドがエラーになった場合は、そのまま続行してください。

開始前に ori auth を実行してください。継承された環境キーを含め、CLI が使用する認証情報を解決します。アクセス可能な場合は終了コード0で終了します。その出力を読み、未知のコマンドと認証情報の不足を区別してください。ただし、その出力をユーザーに見せたり、認証情報の値を繰り返したりしてはいけません。認証情報が解決されず、終了コードが0以外の場合は、ユーザーに ori login を実行するよう伝え、停止してください。バイナリが auth を未知のコマンドとして報告した場合は、インストール済みの Ori がこのスキルで必要なヘッドレス実行に対応する前のバージョンであり、0.3.0 以降が必要であるとユーザーに伝え、停止してください。

付録 C：タスクプロンプトのテンプレート

山かっこで囲まれたすべてのフィールドに値を入力し、<JUDGE_MODEL> には pins の値を使って、これを実行ディレクトリ内の task.txt に書き込みます。

外側の実行が自身の所有するすべてのファイルをアーカイブし、次のセッションを問題なく開始できるよう、実行ディレクトリをプロンプトに渡してください。

Use the create-eval skill. Follow its five phases in this order: workspace
context, criteria and narrowing, model comparison, routing, close. There are
seven possible question tags in this order: `[surface]`, `[workspace-files]`,
`[workspace-data]`, `[criteria-priority]`, `[evaluation-constraint]`,
`[candidates]`, and `[next-step]`. The first two are mutually exclusive
conditional questions, so each run asks five or six questions.
Ask exactly one question per turn and end the turn after asking it. Give each
question three concrete options plus a free-text `Other` option. Never combine
questions in one turn.

Judge with <JUDGE_MODEL> rather than the SDK's default judge model: pass it
to setupJudge as its own agent.

User request: <verbatim request>
Repo context pointers: <paths>. Read these first.

The Ori directory is <absolute run directory>/ori. Create it if it is absent.
Keep the step tracker and every file you write outside the scratch workspace
under that directory. Record the scratch workspace path you report in the
tracker directory. Do not derive another tracker path, and do not adopt or
resume tracker state outside it. The scratch workspace path you report is the
only other location this run may use for its eval and supporting files. Any
other tracker or state files outside these locations belong to a different
session. Keep the eval and supporting files in that scratch workspace outside
the user's repository. Run the eval with ori eval. Do not create or modify
anything in the user's repository.

付録 D：実行の開始

このステップの最後に目指す状態は、リポジトリのルートから、固定されたモデルを使って起動した ori code プロセスが 1 つだけ実行され、プロンプトファイル全体が渡されていることです。また、アシスタントのテキストと診断情報が、同じ試行番号の実行ディレクトリ内にある 2 つの別々のファイルに出力されている状態です。

試行番号には、まだ使用されていない最初の番号を使います。固定の番号は使いません。費用表は各試行のファイルから読み取られ、回答を上書きすると、その試行の費用も一緒に失われるためです。同じ理由で、2 つの出力を分けておくことも重要です。アシスタントのテキストと費用表に必要な要約行が含まれるのは回答の出力だけであり、診断情報が混ざると両方が壊れてしまいます。この実行で使う試行番号を控えておいてください。以降の各ステップでは、その試行のファイルを参照します。

フォアグラウンドで実行してください。オペレーターのシェル呼び出しが実行終了前に打ち切られる場合は、バックグラウンドで実行し、オペレーター自身のプロセス管理ツールで状態を確認してください。

付録 E：回答の形式

現在の実行の回答ファイルは、実行ディレクトリ内の answer-<n>.txt です。プロセスはターンが確定したときにアシスタントの回答全体を書き込むため、終了後に回答ファイルを読み取ってください。診断情報はエラーログに出力されます。ターン中のリアルタイムな進捗情報や質問の検出元はありません。

回答ファイルの最後の行は回答の一部ではなく、Ori 自身の要約行です。次のような形式です。

summary  model=served/model  duration=200ms  input=100 tok  output=25 tok  context=90 tok  $0.012346

質問で停止した場合も含め、各試行で必ずこの行が書き込まれます。この行から、その試行の所要時間と費用がわかります。完了前にターンが終了した場合は、何も書き込まれません。要約行が実際にファイルを終わらせているため、質問はその上にあるアシスタントのテキストから読み取ってください。

要約行より上のアシスタントのテキストには、Ori による説明が含まれます。たとえば「このリポジトリでモデルを呼び出している箇所をスキャンしています。数分かかります」のような、行動を伝える短い簡潔な文です。ターンが終わったら、質問や結果を伝える前に、これらの行をユーザーに見せてください。無言の間に何が起きていたかが伝わります。行が多い場合は、短く要約してください。Ori 自身の言葉がすでに簡潔な場合は、そのまま使ってください。

再開は再試行ではありません。Ori は会話をそのまま続けることができないため、回答のたびに新しいセッションを開始し、プロンプトファイル全体を再読み込みして続けます。ユーザーには「restart」や「attempt」という言葉を絶対に見せないでください。実際には起きていない失敗を連想させるためです。

ユーザーに表示するステータス更新は、簡潔な表現にしてください。例：

言わない表現	言う表現
Attempt 2 exited with a tagged question; see answer-2.txt.	Ori がリポジトリを読み、続行する前に確認したいことがあります。
eval run pass 3 completed.	Ori の読み取りが終わりました。戻ってきた内容を確認しています。
Restarting ori code --prompt-file with n=3.	回答を Ori に送りました。プロジェクトとこれまでの経緯をすべて読み直してから、中断したところから続けます。15 分ほどかかります。
Background command "Restart Ori run as attempt 4 with priority answer" completed (exit code 0)	Ori の読み取りが終わりました。戻ってきた内容を確認しています。
Process 48210 is running; error-1.log is empty.	実行は続いています。ここで無言になるのは正常です。
The run wrote no summary line.	実行は、所要時間と費用を報告する前に停止しました。
The bakeoff is launched.	モデルの比較を実行中です。
完了したターンでは、アシスタントのテキストは質問または最終報告で終わります。完了した回答テキストのどこにあるかを問わず質問タグを探し、最初の質問より後の説明は、ターンがその質問を越えて続いた証拠ではなくノイズとして扱ってください。ターンに複数の質問が含まれている場合は最初の質問だけを伝え、質問が1つという契約への違反を報告してから、以下のルールに従って追記し、最初からやり直してください。アシスタントのテキスト末尾にタグのない質問がある場合も同様に伝え、契約違反もあわせて報告してください。最初の質問と3つの選択肢をユーザーに提示し、オペレーター独自の質問 UI を使って尋ねてください。Other は自由記述のままにし、回答が質問への返答である場合に限り、質問とユーザー自身の回答を task.txt に追記してください。確認を求める返答など、質問に答えていない返答は回答ではありません。その場合は何も追記せず、ユーザーの発言に応答し、同じ質問をもう一度尋ねて待ってください。プロンプトファイルに変更がないまま再開すると、リポジトリを読み直すコストが発生し、同じ質問に戻ってくるためです。自分で質問に答えてはいけません。Ori がスコープ確認の質問に自分で答えてしまった場合、その試みは結果として伝えず破棄し、ユーザーに尋ねて回答を追記し、再開してください。中断や別経路でのやり取りの後も、すべての質問で質問 UI が必要です。通常の文章で質問するだけでは、この手順を満たしません。

質問はラベルだけで構成されるものではありません。ラベルには含まれない、対象範囲と現在のモデルを示す Markdown 表などの背景情報も含まれます。ユーザーが回答時にその背景情報を確認できるようにしてください。ナレーションと背景情報全体を、表があればそれも含めて通常のメッセージとして表示してから、同じターン内で質問する前にステップトラッカーを更新してください。背景情報のステップを完了とするのは、そのメッセージが会話に表示された後だけです。実際に表示した表のヘッダー行を記録するか、表がなかったことを明記してください。表示した表は回答後も会話履歴で読みやすく残ります。これは [next-step] を含むすべての質問に適用されます。結果表とコスト表は、質問にまとめて入れるのではなく、質問の前にすべて表示してください。

質問には、短い一文、短い選択肢ラベル3つ、自由記述の Other だけを含む最小限の質問 UI を使ってください。質問本文に Markdown 表を入れてはいけません。折り返されたプレーンテキストとして表示されるため、表を入れると生のパイプ文字列になり、読みにくくなります。3つの選択肢はそれぞれ元と対応させ、Other は自由記述のままにし、簡潔な言葉に訳してください。

その後に追記するのは、質問の全文を平易な言葉で記したものと、ユーザーが Other を選んだ場合は入力テキストも含めた回答文字列1つです。

付録 F：コストと所要時間の表

再開するとリポジトリの調査が繰り返されるため、質問で終了した試みも含め、すべての試みについて1行ずつ記載してください。各試みの所要時間とコストは、その回答ファイル末尾のサマリー行から取得します。評価自体のモデル呼び出しと判定の値は、最終回答にある Ori の締めくくりの表から取得します。サマリー行に記載されるのは所要時間だけなので、開始時刻はオペレーターが観測した時刻です。回答ファイルにサマリー行がない試みは、何も報告されていないため、「未計測」と記載してください。これはゼロではありません。未計測の行が1つでもある場合は、合計を下限として報告してください。ユーザーに提示する表なので、行の名称は平易な言葉にしてください。この場合も、平易な言葉を使うルールが適用されます。

手順	開始時刻	所要時間	コスト
プロジェクトを読み、質問するために中断	観測時刻 20:29	39s	$0.42
回答後にプロジェクトを再度読み込み	観測時刻 20:30	15m 10s	$3.20
評価のモデル呼び出し	20:46	2m	$0.46
判定	20:48	1m	$0.05
…
合計			$4.13

その後に、たとえば「今回の実行コストは合計 $4.13 です。再実行のコストは Ori の締めくくりの表に示された金額だけです。」という一文を続けてください。

付録 G：トラブルシューティング

症状	対応
実行ディレクトリにすでに実行ファイルがある	その中身を報告して、ユーザーに確認してください。自分の判断で続行したり、削除したりしないでください。
正常にインストールした後に ori: command not found と表示される	~/.local/bin/ori を実行してください。インストーラーによる PATH の変更は、現在のシェルには適用されません。
認証情報がない	停止してください。ユーザーに ori login を実行するよう伝えてください。
初回実行時に長い間応答がない	初回実行では ~/.ori/global が作成され、テンプレートがダウンロードされます。約 30 秒かかりますが、実行が停止したわけではありません。
Ori が何もせず、プロンプトが空に見える	起動コマンド内のパスが、作成したファイルと一致していません。
Ori がモデル ID を利用できないと報告する	Ori に ID を再度探すよう伝えてください。記憶を頼りに ID を提示しないでください。
eval ファイルがユーザーのリポジトリ内にある	そのファイルと関連ファイルを一時ワークスペースに移動し、新しいパスに対して ori eval を実行してください。
Ori が以前のセッションから自身のトラッカーを再開した	その試行は引き継がず、破棄してください。Ori が以前のセッションの状態を再開したことをユーザーにはっきり伝え、何かを移動する前に確認してください。ユーザーの同意を得たら、残っている ori/ の状態だけを previous/<timestamp>/ に移動し、現在のトラッカー、プロンプトファイル、コスト表はそのまま残して、次の試行番号を使い、完全なプロンプトファイルから再開してください。
Ori が対象を自分で選んだ	推測された対象を受け入れず、その試行を破棄してください。ユーザーに確認し、回答を追加して、完全なプロンプトファイルから再開してください。
回答にタグ付きの質問がないが、実行が停止したように見える	最終回答を読んでください。タグなしの質問をそのまま伝え、契約違反を報告して、手順 19 から続行してください。
ユーザーが表を読めないと言う	通常のメッセージでコンテキストを再度表示してください。質問本文に Markdown の表を入れないでください。生のパイプとして表示されます。
ori code がターミナルを必要とするため、リダイレクトされた実行を拒否する	停止してください。この試行では何も消費されておらず、このバイナリでは実行を続行できません。Ori 0.3.0 以降を使うようユーザーに伝えてください。
403 Key limit exceeded または 402 の支払いエラー	キーの利用上限に達しています。以下を参照してください。

キーの利用上限または支払いエラーによって数秒以内に終了した実行は、Ori や eval の不具合ではありません。キーにクレジットがなく、eval は書き込まれておらず、この試行では何も消費されていないことを、ユーザーにはっきり伝えてください。エラーに記載された Manage it using <url> のリンクをそのまま提示し、上限を引き上げるか、クレジットを追加するかを確認してください。認証情報は有効なままなので、ダッシュボードを変更するだけで十分で、新たに ori login を実行する必要はありません。ユーザーが確認したら、同じ実行を再開し、一時的に回復可能な中断であり、最終的な失敗ではないため、同じ時点からタスクを続けてください。