create-pass-through-approximation

スキル：PassThrough 近似の作成

削除されたメソッドの汚染伝播を passThrough 近似としてモデル化します。これは、メソッドの入力から出力へデータがどのように移動するかをエンジンに伝える設定であり、解析器が不透明な呼び出しを経由して見失ったフローを復元します。

入力

呼び出し元から指定されます。省略された場合はデフォルト値を使用します。必須入力が不足しており、妥当なデフォルト値がない場合に限り、確認を求めてください。

• project-root（省略可能）— 対象プロジェクトのルートです。Opentaint はすべての解析成果物を固定の <project-root>/.opentaint/ ディレクトリに保存するため、以下の .opentaint/... パスはすべてそこを基準に解決されます。デフォルト：カレントディレクトリ
• language（必須）— このプロジェクトの対象言語と言語固有の指示です
• batch（必須）— バッチ ID です。passthrough エントリーは .opentaint/tracking/approximations/<batch>.yaml にあり、作成したエントリーをそのファイルの build.done に追記します
• methods（省略可能）— 呼び出し元がそのメソッドだけを必要とする場合に、passthrough バケット全体ではなく、再作業する特定の { method, signature } のサブセットです

ワークフロー

1. 伝播を把握する

バッチ内でまだ build.done に記録されていない passthrough メソッド（または指定された methods）を対象に、それぞれの実際のコードを調べます（言語リファレンスに従ってソースを読みます）。各メソッド自身のコードが行うことだけに基づいてモデル化し、プロジェクト内での使われ方には依存しないでください。設定はメソッド固有の伝播を記述します。入力データはどこへ移動するでしょうか。レシーバーまたは引数に到達したデータは、戻り値、メソッドが書き込む引数、レシーバー、または保存先のオブジェクトやフィールドを通じて出力されるでしょうか。また、オブジェクトが呼び出しの間データを保持するかどうかにも注意してください（setter がデータを格納し、getter が後で返す、またはビルダーがデータを蓄積するなど）。その場合は仮想フィールドが必要です。この形状を設定で表現します。

2. 設定を書く

パッケージごとに .opentaint/pass-through の下へ passThrough 設定を 1 つ書きます（形式とパターンは言語リファレンスに記載されています）。build.done にすでに記録されており、methods で明示的に指定されていないメソッドは作成済みで、信頼できるものです。変更せず、その設定もそのままにしてください。明示的に指定されたメソッドを修正する場合は既存の設定内で行い、新しいメソッドはファイルを書き直すのではなく、既存のパッケージ設定に追加します。コピーを作成する際の基本方針は次の 2 つです。

• すべての位置を網羅します。this と各引数について、データの流れ先へコピーするか、データがどこにも流れない場合は自分自身へコピーします。
• オブジェクトが呼び出し間でデータを保持する場合は、書き込み側と読み取り側を共有の仮想フィールド経由でつなぎます。これは、両者が同じ名前で指定する名目上の保存場所です。書き込み側がそこへ格納したデータを読み取り側が取り出すため、両者で名前が異なると汚染が失われます。

3. 設定を再確認する

返答する前に、モデル化対象のすべてのメソッドに passThrough を作成したこと、そして各設定のコピーがソース内でのメソッドのデータ移動と実際に一致していることを確認します。すべての位置が網羅され、書き込み側と読み取り側が同一の仮想フィールドを共有していることを確認してください。新たに記録されていない、今回書き込んだメソッドはそれぞれ build.done に追記します（Tracking に従います）。修正したメソッドは、すでに記録されている状態を維持します。

出力

実施内容を簡潔に報告します。

成果物：

• .opentaint/pass-through/<package-kebab>.yaml — passThrough 設定（パッケージごとに 1 つ。依存関係は複数のパッケージにまたがる場合があります）。ファイル名とファイル全体の形式は言語リファレンスに記載されています
• バッチファイルの build.done に記録された、正常に作成されたメソッド（新しいメソッドは追記し、修正したメソッドは Tracking に従ってすでに記録されている状態を維持します）

要約：

• 書き込んだ設定ファイルのパスと、モデル化したメソッド

トラッキング

.opentaint/tracking/approximations/<batch>.yaml — 1 バッチ分の呼び出し可能要素の分類です。<batch> は計画ファイルの名前部分です。各呼び出し可能要素は、計画に記載された言語固有の method と signature をそのままキーとして使い、必ずいずれか1つの判定グループに分類します。これにより、異なるバリアントを別々に扱えます。

• passthrough、dataflow — モデル化された伝播要素です。各エントリーは { method, signature } です。
• skipped — 終端となる非伝播要素です。各エントリーは { method, signature, reason } です。
• engine_issues — エンジンが伝播できないことが明らかな伝播要素のための独立したグループです（構築されているにもかかわらず、伝播の途中で破棄されます）。終端として扱われ、skipped と同じ扱いです。異なるのは理由のみです。merge-skipped は、このグループを skipped.yaml に通常のスキップ対象である methods と並ぶ独立した engine_issues グループとして引き継ぎます。

dependencies には、データフローテストプロジェクトに必要な依存関係の識別子を列挙します。build ブロックはビルドを追跡します。test_project には、各データフローメソッドのテストプロジェクトでの状況を記録します（バッチのテストプロジェクトにサンプルを書き込めた場合は done、書き込めず、そのメソッドをプロジェクトから除外した場合は failed）。done には、完了した { method, signature } を記録します。コメントで明確にしてください

passthrough:
  - { method: "<qualified-member-a>", signature: "<language-signature-a>" }
dataflow:
  - { method: "<qualified-member-b>", signature: "<language-signature-b>" }
skipped:
  - { method: "<qualified-member-c>", signature: "<language-signature-c>", reason: "retains none of its input data" }
engine_issues: []
dependencies: []
build:
  test_project:
    - { method: "<qualified-member-b>", signature: "<language-signature-b>", status: done }
  done: []

このスキルは、正常にビルドされた各メソッドを、まだ存在しない場合に限り { method, signature } として build.done に追加します。新たに割り当てられたメソッドのサンプルを書けなかった場合、そのメソッドは対象外のままとなり、次のループで再び処理されます。明示的に修正したメソッドについては、既存のエントリーを変更しません。分類グループには一切触れず、build.done 内のエントリーも編集しないでください。

制約

OpenTaint は、プログラム全体を対象とする、手続き間およびフィールド単位のエイリアス解析エンジンです。表示可能なアプリケーションコード、呼び出し、エイリアス、個々のフィールドを通じて、すでに伝播を行います。カスタムルールと近似モデルで表すのは、割り当てられたソース、シンク、または不透明なメソッドの境界のみです。コンパイル時定数とリテラルは汚染を引き継がないため、出力が定数のみのソースや伝播要素は、何も導入しません。

• ルールごとに関数を1つだけモデル化してください。一度に多数をカバーするための正規表現やワイルドカードによるマッチャー、全引数を対象とする位置指定は使用しないでください。過剰なモデル化は、検証していないメソッドを通じて汚染を伝播させ、誤検出を生みます。
• 生成する設定にはコメントを含めないでください。