build

要求された機能を実装します。変更に影響する質問への回答や、アプリケーションの動作確認には twin を使用します。通常の開発で得られるエビデンスを再利用し、必要な動作を確認してテストに合格したら完了します。失敗が発生した場合や、具体的な未回答の要件がある場合は、さらに調査します。

ベンダーとの有意なやり取りが発生しない変更では、Veris のセットアップと twin での作業を省略し、リポジトリの検証を実施して、その範囲を結果に明記します。ローカルのキューやキャッシュの不具合がベンダー向けの動作を変える場合は、影響を受けるアプリケーションのフローを twin に対してテストする必要があります。

作業環境を使用する

.veris/NOTES.md の関連する調査結果を読み、条件が引き続き当てはまるものを再利用します。準備、アプリケーションのコマンド、エビデンスの収集、クリーンアップには、How to run に従います。接続の選択と設定はセットアップが管理します。必要な引き継ぎ手順が不足している場合、接続が切れている場合、またはベンダーサービスやホスト名の追加など、変更によって接続設定が無効になる場合にのみ、setup を実行します。アプリケーションのアサーション失敗だけを理由に、セットアップをやり直してはいけません。

プラグイン管理のセッションでは、リポジトリと twin のライブバインディング、およびプロバイダーのツールについて、session.md に従います。このセッションですでに検証済みのバインディングを再利用し、再接続後、または関連する ID に変更があった場合は再検証します。保存されたメタデータだけではライブバインディングとは見なせません。プラグインが所有するリソースは稼働したままにします。

必要な場合にのみ、保存された開始／再接続手順を使用し、このタスクで有効なサンドボックスを再利用します。長時間の作業に入る前に、有効期限を確認します。有効期限が迫っている URL や認証情報は、保存された準備手順を通じて更新します。

twin を利用できない場合、twin が必要な検証は実施できません。具体的なエラーを報告してください。独立して実施できるコード作業やローカルチェックは続行できます。エラーが回復可能な状況を示している場合、または状況が変わった場合にのみ再試行します。実行していないチェックを合格として報告してはいけません。

理解して実装する

読み取りとツールの出力は要点に絞ります。大きなログやレスポンスはファイルに保存し、会話に何度も読み込むのではなく、関連する抜粋を確認してください。

issue（GitHub の場合は gh issue view <ref> --json title,body,comments）または提示されたプロンプトを読みます。求められている動作、その呼び出し元、関連するサービス依存関係を特定します。新しいフローを設計する前に、既存のアプリケーションコードとテストを確認してください。

設計に影響する未解決の疑問に答えられる、最も低コストな twin インターフェースを使います。twin.md では、疑問とマニュアル、スキーマ、操作一覧、データとの対応を示しています。認証情報、API バージョン、障害の詳細が必要な場合は、veris sandbox services manual <twin> --raw でマニュアルを取得し、該当するセクションを読んでください。twin への直接プローブは、調査に役立ちます。アプリケーション経由のテストで同じ疑問に答えられる場合は、実装も同時に確認できます。これらの条件について、すでに確立されている回答を再利用してください。

状態.md を使って、機能に必要な状態を準備します。デフォルトのシード状態が適していると思い込まず、関連する所有者と時間枠を確認してください。このサンドボックスの ID を使います。たとえば、予約が埋まったフィクスチャがあっても、別の日付を予約する機能が否定されるわけではありません。シード状態に合わせて、求められている動作を変更しないでください。

リポジトリの規約に従って実装し、関連するテストを拡張します。機能によって失敗時の処理が変わる場合は、該当する条件に対して障害注入を使います。リトライ、冪等性、ID に関する変更では、該当する重複、異なる操作、復旧のケースを変更対象のテストに含めます。proof.md に焦点を絞ったレシピがあります。未回答の主張が判断を左右する場合は調査しますが、ベンダーに関するあらゆる疑問をすべて列挙し終えるまで、ソースコードの編集を先送りにしないでください。

タスクで約束された呼び出し元を使って動作を確認します。オプション機能の場合は、新しい引数やフラグをテストし、既存の必須動作も維持してください。結果に影響しうる関連の別ディスパッチ分岐も確認します。通常の呼び出し元が到達できないテスト専用経路では、その呼び出し元に対して機能が動作することの証明にはなりません。変更したシンボルの呼び出し元を検索するだけでは見落とす場合があるため、同じ動作をインラインで実装している関連する兄弟分岐も確認してください。

変更したアプリケーションをテストする

実行方法に保存されている実行手順と証跡手順を使って、影響を受けるアプリケーションのテストまたはフローを実行します。リポジトリに既存の統合テストがある場合は、そちらを優先してください。設定済みの環境と接続設定を維持しながら、記載に従って影響を受けるテストまたはフローを選択します。

編集したソース、または保存済みのソース／ビルド手順に従って生成したビルドを使用します。マウント先を誤ると、イメージに焼き込まれた古いコードが実行される可能性があります。設定済みのルーティングと TLS の信頼設定を維持し、テストを通すために本番ベンダーへの呼び出し先を変更しないでください。

テストでは、期待されるレスポンスまたは永続化された結果をアサートする必要があります。また、そのレシートまたは対象が特定できるトレースで、関連するアプリケーションのトラフィックがツインに到達したことを確認できる必要があります。結果を読み取る既存のアサーションで十分です。手動でデータを読み取って同じ確認を繰り返さないでください。結果が不明瞭な場合は、保存済みの証跡手順に従い、返された ID を使って関連する行を調べるか、この実行のトレースを確認します。レシート／終了結果は、設定された経路に対応するリファレンスに照らして解釈してください。コールバックがタスクに含まれる場合は、webhooks.md を参照してください。

最終的に関連するコード／ビルドと条件をテスト済みであれば、既存の実行をその証拠として使用できます。1 つのスイートで複数の要件を網羅できます。また、リトライケースで 1 つのテスト中に複数回呼び出すこともできます。2 回目の成功実行や独立した証明フェーズは必要ありません。リポジトリで必須のチェックに従い、その証跡を再利用して、変更後または失敗後は影響を受けるチェックを再実行してください。

アサーションが失敗した場合は、実装を変更するか、診断されたセットアップ上の問題を修正します。必須の動作が未テストのままであれば、その不足を報告してください。プロセスが正常終了したことや、無関係なツインのトラフィックだけでは、変更を検証したことにはなりません。

完了

変更内容、テスト／コマンド、その結果を既存の証跡参照とともに要約し、重要な制限事項を記載します。evidence.md に短い記載例があります。調査によってタスクの前提が誤りだと判明し、それが解決策に影響した場合は、その点も記載してください。把握された矛盾は解消すべき不具合であり、前提として扱ってはいけません。

リポジトリの PR の慣例に従い、引き継ぎ方法として求められている場合はドラフトを作成します。PR を作成できるリモートがない場合は、説明をローカルに保存し、PR を作成していないことを伝えてください。コード作業に Git の履歴、タスク ID、任意の 監査ヘルパーは必須ではありません。Git を暗黙に初期化したり、リモートを追加したりしないでください。デバッグに役立つ場合は、利用可能なパッケージ／バージョンのメタデータを使ってもかまいません。これは独立した完了要件ではありません。

クリーンアップの前に、引用する編集済み証跡を保存し、.veris/setup.json に既存の artifact_policy を遵守してください。再利用できる新たなサービスや SDK の知見は、関連する条件と既存の編集済み証跡参照を添えて .veris/NOTES.md に追加します。古くなった項目は、タスクの報告と重複させずに修正してください。実行方法を修正した場合は更新してください。記録されているライフサイクルの所有者に対応する、保存済みのクリーンアップ手順または変更引き継ぎ手順に従ってください。プラグインが所有するリソースは稼働したままにします。このコマンドから昇格させないでください。リポジトリのコードを新たな場所に送信する前に、許可を求めてください。