runtime-probes

ランタイムプローブ

コードの反対側にある、spec-probes スキルの対となるものです。あちらは何かが実行される前に要件を調査します。こちらは、稼働中のシステムを調査するか、対象にまだ到達できない場合に、範囲を限定したランタイムの引き継ぎを準備します。

設計を左右する失敗モードは 2 つあります。範囲を限定しないプローブ実行は予算を浪費し、ノイズを返します。昇格させた調査結果に呼び出し元が到達できなければ、メンテナーの 1 日を無駄にします。パス 1 では調査範囲を限定します。パス 2 では、その範囲から外に出るものを限定します。

どちらかのパスを始める前に

この順番で、対象範囲、サーフェス、停止条件を明示します。

対象範囲。 PR の差分、1 つの機能、または製品全体です。差分の場合は、変更マップに blast-radius スキルを使用し、変更マップを再導出せず、そこに記載された内容を調査します。

サーフェス。 プローブは、プロジェクトに verify-<app> ドライバーがない場合に create-verification-skill スキルが作成する、そのドライバーを通じて実物を対象に実行します。そのドライバーが存在しない場合は、別の経路をでっち上げず、必要な検証サーフェスをブロッカーとして報告します。稼働中のサーフェスに到達しなかったプローブは、合格ではなく、必ず not run とします。

停止条件。 実行を始める前に、範囲を限定します。終わりのないライブ探索には、タスクまたはプロジェクトが指定する予算と影響の下限が必要です。その 2 つの制限は分けて報告し、指定された値をそのまま保ち、どちらかが欠けている場合は明示します。呼び出し回数と終了条件またはタイムアウトが明示された、呼び出し元が指定する有限のアクションリストは、すでに範囲が限定されています。自分で選んだプローブやその件数を、タスクが指定した予算、呼び出し上限、または有限の実行許可として扱ってはいけません。計画が自らの実行制限を定めることはできません。実行可能な実行の範囲が限定されていない場合は、制限をでっち上げたり別の作業に置き換えたりせず、停止して不足している制限を尋ねます。利用できないランタイムの計画は進めてもかまいませんが、未指定の実行制限がどれかを明記する必要があります。予算は探索を制限し、影響の下限は、どのような影響を継続調査し、昇格させる価値があるかを定めます。ループガバナンススイートが導入されている場合は、外側のループをそのスイートに任せ、このスキルはそのループが実行する手法として扱います。

ツリー外に、ランタイムプローブが所有する記録を 1 つ維持し、プローブごとに 1 行記載します。各行には、エントリーポイント、カテゴリ、プローブ、ステータス、および観察結果と証拠 ID、または実行しなかった理由を記載します。完了した呼び出しには、それぞれ固有の証拠 ID が必要です。件数は証拠ではありません。書き込みが禁止されている場合は、ファイルを作成せず、同じ情報を返信に記載します。判断ログには、show-me-your-work スキルを別途使用します。

パス 1：プローブ

実行中は、エントリーポイントを一覧化し、その形状を使って該当するカテゴリを選び、範囲を限定した敵対的仮説を立てます。明示されたスコープと停止条件の範囲内で、観測された結果に応じて適応します。中断されたシーケンスについて、読み取り専用のクエリは決して実行しません。分類体系は意図的に閉じています。誰も完了できない40カテゴリより、完了した8カテゴリのほうが有益です。

計画のみの場合、または作業を実行できない場合は、タスクまたはソースに具体的な条件と、結果を観測できる場所が示されているプローブだけを含めます。順序、タイミング、証拠、追加カテゴリを作り出さず、明示された分岐、境界、結果をそのまま保ちます。ソースに実際に記載された条件に基づいて分類します。型またはエンコーディングの誤りは不正な入力、完了前の放棄は中断、完了後の再試行はリプレイです。似た言葉や結果があっても、別のカテゴリに分類する根拠にはなりません。ソースの動作の区分を見分けられる最小限のセットを使います。これらのプローブには not run と記し、実行しなかった理由を述べます。要求されたプローブに条件または観測可能な対象が欠けている場合は、補完せず、不足している事実を記録します。

タスクで指定された有限の作業単位が終わったら、指定された作業だけを処理します。スコープは許可リストとして扱います。背景情報があっても、隣接するシナリオの分析、分類、提案、追加確認の要求は許可されません。まとめて提供された結果や事前計算済みの隣接結果は背景情報であり、許可されたアクションによって発見された効果ではありません。許可されたアクション自体が重大な予期しない効果を引き起こした場合は、その効果を一度だけ記録し、範囲を広げる前に確認を求めます。実行中の調査では、境界は開始点であって上限ではありません。スコープと予算の範囲内で、観測された動作に応じて値や型を調整します。

カテゴリ	形状	敵対的な問い
不正な入力	input	型、エンコーディング、または呼び出し元が送る想定のないフィールドが誤っていた場合、どうなりますか？
極端なサイズ	input、resource	ゼロ、1、文書化された境界、そして現実的な最大値を大幅に超える値では、どうなりますか？
中断されたシーケンス	sequence、state	閉じたタブ、強制終了されたプロセス、または切断された接続によって操作が途中で放棄されたとき、何が残りますか？
反復とリプレイ	sequence、state	二重送信、戻る操作、またはリクエストの再試行では、どうなりますか？
古い状態	state	サーバーが変更した後の状態に対して、クライアントが操作した場合、どうなりますか？
依存関係の障害	boundary	依存関係がエラーを返す、何も返さない、または利用できなくなった場合、呼び出し元には何が見えますか？
依存関係の遅延	boundary、resource	呼び出しに10ミリ秒ではなく10秒かかる場合、どうなりますか？
同時操作するアクター	concurrency、state	2つのアクターが同じレコード、ファイル、またはキーを同時に操作した場合、どうなりますか？

範囲を定めない実行では、swarm スキルを使ってプローブをエントリーポイントごとに分割し、並行して実行します。このスキルが独自にワーカーモデルと作業量を決定するため、ここで選択を言い直さないでください。ワーカーは、swarm 独自の規約に従って、証拠とともに PASS、ISSUES、または BLOCKED を報告します。別の規約を作らないでください。

呼び出し元が指定する有限の作業では、指定された効果を伴うアクションだけを実行し、その順序と意味を保ちます。指定されたファイルの読み取り専用の調査は許可されますが、プローブの証拠にはならず、スコープの拡張、リプレイの追加、隣接する処理の判断の根拠にはできません。同時実行が明示されていない限り、1つのアクションを実行して結果を観測し、次のアクションが引き続き許可されているか判断します。リテラルなコマンドは先頭部分ではなく、呼び出し全体です。記述どおりに一度だけ実行します。必要な実行コンテキストを利用できない場合は、ラッパー、代替手段、または再試行を試さず、実行を妨げる要因を報告します。各呼び出しは個別に記録します。

実行時の調査では、該当する形状を持たないエントリーポイントに対して、無記載にするのではなく、「未分類。手動でプローブ」とする控えめな行を1つ追加します。この行は、計画のみの場合や実行できない旨の回答には追加しません。

パス 2：昇格

すべての指摘は仮説です。設定済みの「判断と文章作成」モデルと、その設定済みの推論レベルで、それぞれを評価します。解決には pstack-harness スキルを使用します。次の 3 つすべてを満たした場合にのみ、指摘を昇格させます。

1. 再現する。 ライブ作業では、ハーネスがクリーンな状態から再実行し、再び失敗する必要があります。判定のみのタスクでは、タスクで提供された完了済みの観察結果が、タスク作成者の許可した実行証拠です。タスクで禁止されている再実行を求めてはいけません。クリーンな再実行も提供済みの完了済み証拠もない指摘は、昇格しません。
2. 実際の呼び出し元が到達できる。 呼び出し元と、実際のエントリポイントから失敗に至る経路を示します。実行されたドライバーまたは操作をその呼び出し元の経路に対応付ける、提供済みのソースコード上の記述は到達可能性の証拠です。プローブで実際のエントリポイントを再び呼び出すよう要求したり、ソースにすでに記載されている対応付けについてメンテナーに再確認を求めたりしてはいけません。厳密な到達可能性の条件では、どの呼び出し元も通過しないガードの背後にある不具合は昇格しません。ソースで呼び出し元の対応付けや適用されるガードが明らかになっていない場合にエスカレーションし、対応付けが直接記載されている場合にはエスカレーションしません。
3. メンテナーが修正を受け入れる。 影響がユーザーに見える、データに影響する、またはセキュリティやプライバシーの境界を越える必要があります。内部的な雑然さは不具合ではありません。

../poteto-mode/references/bugbot-triage.md の fix／dismiss／ask 判定基準に照らして、すべての指摘をトリアージします。3 つの判定結果には、以下の状態に示すタグが付いています。学習済みの却下パターンは、次回に再導出するのではなく、同ファイルに定められた形式で記録してください。

各指摘は、実行終了時に必ず次のいずれか 1 つの状態になります。

• promoted（fix）：3 つの条件をすべて満たします。回帰テストを作成し、課題リストに 1 行追加します。
• dismissed（dismiss）：理由を添えて却下します。「到達不能。このフィールドにアクセスする唯一の呼び出し元は、範囲が限定された列挙値に対して検証する」は有効な理由です。理由の記載なしは認められません。
• gap：再現するものの、条件 2 を満たさず、到達不能にしているガードを行に明記します。到達可能性を厳密に確認することで、後から再検討する必要のない指摘リストが得られます。この行を追加する手間はかかります。後でそのガードを削除すると、このギャップが有効になるため、行を残す価値はガードの名前にあります。この状態は条件 2 によって生じるものであり、判定基準によるものではないため、判定タグは付きません。
• escalated（ask）：条件 2 または 3 を自分では判断できず、指摘がセキュリティ、プライバシー、認証、請求、データ保持、または権限の境界に関わります。ユーザーに確認してください。これらのカテゴリでは、判断がつかないまま却下してはいけません。これは判定基準そのものに定められたルールです。この指摘について実行はここで終了しますが、指摘自体が終わるわけではありません。回答が届いた後、promoted、dismissed、または gap になります。

残務

実行した実行後は、プローブハーネスが成果物となります。タスクでリポジトリの変更が許可されている場合は、レビュー担当者が再実行できるようにコミットしてください。計画のみの場合、実行できない場合、または読み取り専用の作業では、ハーネスを作成もコミットもせず、ファイル変更が禁止されていない限り、範囲を限定した引き継ぎ内容を findings.tsv に残してください。

回帰テストの追加について明示的な許可がある場合は、poteto-tdd スキルを使用してください。採用した各調査結果について、修正に着手する前に失敗するテストを1つ作成し、ステージングします。修正の実装について明示的な許可がある場合は、調査結果を1つずつ扱い、Bug fix playbook（../poteto-mode/playbooks/bug-fix.md）を実行してください。その許可なしにテストをステージングしたり、修正に着手したりしないでください。また、複数の修正を1つのコミットにまとめないでください。

採用するテストでは、記録の再現ではなく、不変条件を検証してください。「ゼロ未満の数量を拒否する」というテストは、リファクタリング後も有効です。「このバイト列に対して、この正確なエラー文字列を返す」というテストは有効ではありません。生成されたテストが何も測定しないまま成功するのは、テストがないよりも悪いため、採用するテストが反映される前に、すべて verify-commands スキルを使って検証してください。

対象範囲、対象箇所、停止条件、実施した作業または not run のまま残した作業、エビデンス ID、最終的な処置を報告してください。実行済みのエビデンスも、タスクから提供された完了済みのエビデンスもない場合は、合格、調査結果、再現、または Pass 2 の結果を主張せず、阻害要因と不足している事実を報告してください。プローブ記録を書き込んだか、インラインのままにしたかも明記してください。