fix

要求された不具合を修正します。変更に影響する質問への回答やアプリケーションの動作確認には、ツインを使用します。通常の開発で得られた証拠を再利用します。必要な動作を網羅してテストに合格したら、作業を完了します。失敗があった場合や、具体的な未回答の要件がある場合に、さらに調査します。

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

作業環境を使用する

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

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

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

ツインが利用できない場合、ツインが必要な検証は実施できません。具体的なエラーを報告します。独立して進められるコード作業やローカルチェックは継続できます。エラーから復旧可能と判断できる場合、または状況に変化があった場合に限り、再試行します。実施していないチェックを合格したと報告しないでください。

診断と実装

読み取りとツールの出力は必要な範囲に絞ります。大きなログや応答はファイルに保存し、会話に繰り返し読み込むのではなく、関連する箇所を確認してください。

課題（GitHub の場合は gh issue view <ref> --json title,body,comments）または提示されたプロンプトを読み、影響を受けるコードを調べます。報告された結果と、修正によって実現すべき動作を特定してください。課題で提案されている原因が誤っていることもあります。twin の注入可能な障害のリストによって、リポジトリの診断が決まるわけではありません。

既存の関連する失敗を再利用するか、可能であればアプリケーションを通じて再現してください。欠陥がベンダーの障害に依存する場合は、fault injection を使用します。ローカルの状態、キャッシュ、キューに関する欠陥は、アプリケーション内で再現してください。観察結果が診断と矛盾する場合は、診断を見直します。修正を退避して過去の失敗実行を捏造したり、経緯を記録するためだけに作業をやり直したりしないでください。元の失敗を再現できなかった場合は、その旨を明記し、実装した動作を検証してください。

未解決のサービスに関する疑問に答えるため、最も手軽な twin インターフェースを使用します。

• 認証情報、サポートされる障害、フィールドのルールについては、Manual/schema を確認します。これらの詳細が必要な場合は、veris sandbox services manual <twin> --raw でマニュアルを取得し、関連するセクションを読んでください。
• アプリケーションが必要とする状態については、Data and seeding を確認します。適切なシード行を再利用してください。ID はこのサンドボックスに属します。フィクスチャの不足はセットアップの問題であり、報告された欠陥の再現ではありません。
• 検出には twin への直接呼び出しを使用します。直接呼び出しで確認できるのは twin の動作であり、アプリケーションの正しさではありません。別個の確認を行わなくても、実用的なアプリケーションテストで同じ疑問に答えられる場合があります。

リポジトリの規約に沿って実装し、必要に応じて影響を受けるテストを強化してください。リトライ、冪等性、または識別子に関する変更では、そのテストで該当する重複、別個の操作、復旧の動作を網羅してください。対象を絞ったレシピは 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 に追加します。古くなった項目は、タスクの報告と重複させずに修正してください。実行方法を修正した場合は更新してください。記録されているライフサイクルの所有者に対応する、保存済みのクリーンアップ手順または変更引き継ぎ手順に従ってください。プラグインが所有するリソースは稼働したままにします。このコマンドから昇格させないでください。リポジトリのコードを新たな場所に送信する前に、許可を求めてください。