veris-reference

コマンドではありません。setup、build、fix から、各ステップで必要なファイルに移動できます。

file	read it when
twin.md	設計がベンダーに関する主張に基づいている場合、またはベンダーが行ったこと（マニュアル、スキーマ、操作、データ、トレース）を確認する必要がある場合
state.md	行やファイルのシード、サンドボックス内の分離、リセット、スナップショット、ベースラインについて確認する場合
run.md	veris run で変更をテストする場合：2 つのティア、イメージ、実行時にワークロードへ渡されるもの、判定を変えるフラグ、終了コード、成功によって証明されること
direct.md	アプリが環境変数からすべてのベンダーのベース URL を読み取り、プロキシを必要としない場合
session.md	現在のツール／コンテキストから、プラグイン管理の既存のサンドボックスがあると判断できる場合：ID の確認、インターセプトの再利用、レシートの帰属、変更の同期
opencode.md	既存のセッションが OpenCode の場合：プロバイダーツール、認証情報、信頼、アクセス制御、ライフサイクルの違い
hosted.md	エンジニアがリモートテストを依頼した場合、またはコードのリダイレクトが必要で Docker が利用できない場合：プロバイダーレシピ、リモートワークロードの準備、トレースの証拠、プロジェクトメモ、クリーンアップ
daytona.md	ホスト型ティアで Daytona を選択する場合：公開 SDK、既存の twin への接続、イメージ、アップロード、信頼、エグレス、コールバック、削除
e2b.md	ホスト型ティアで E2B を選択する場合：公開 SDK、既存の twin への接続、テンプレート、アップロード、信頼、ネットワークポリシー、コールバック、削除
faults.md	タスクが障害に関するもの、またはベンダーが任意のタイミングで発生させない条件をケースで必要とする場合：障害行、認証情報、クロック
webhooks.md	アプリケーションがコールバックを受け取る場合
troubleshooting.md	レシート、終了コード、トレースのティア、証明書エラー、ベンダー固有のエラー、/veris/* からの 401／404、またはサンドボックス化されたエージェントの doctor の出力行が何を意味するかを確認する場合
evidence.md	既存の証拠と重要な制約を用いて簡潔な結果をまとめる場合
proof.md	テストの証拠を解釈する場合、リトライ／ID の挙動を調査する場合、またはオプションの監査ヘルパーを使用する場合

検証済みのプラグインセッションでは、session.md が CLI の操作とライフサイクルを、検出されたセッションインターフェースに置き換えます。それ以外の場合、twin の操作には veris を使用します。veris <command> --help でフラグを確認できます。ホスト型ランナーのコマンドは、各プロバイダーレシピに記載されています。twin のすべての操作には動詞があります。ファイルのアップロード（sandbox files import）、twin ごとのリセット（sandbox reset <twin>）、操作一覧（sandbox services operations）も同様です。twin の制御 URL に curl を実行してはいけません。CLI が Veris API キーを直接送信するため、キーをエクスポートしたり表示したりすることはありません。制御 URL はアプリが呼び出すアドレスではなく、ベンダーのホスト名の /veris/* はベンダー独自の 404 です。詳しくは state.md の 制御 URL とそのキーを参照してください。 scripts/ には、オプションの監査ヘルパー record.sh と ledger.sh があります。調査でこれらが必要な場合の準備方法は、setup のステップ 9 で説明しています。通常の開発では、タスク台帳や独立した証明フェーズは必要ありません。