██████╗  █████╗ ███████╗██╗  ██╗ ██████╗ ██╗   ██╗     ███████╗██╗  ██╗██╗██╗     ██╗     ███████╗
██╔══██╗██╔══██╗██╔════╝██║  ██║██╔═══██╗██║   ██║     ██╔════╝██║ ██╔╝██║██║     ██║     ██╔════╝
██████╔╝███████║███████╗███████║██║   ██║██║   ██║     ███████╗█████╔╝ ██║██║     ██║     ███████╗
██╔═══╝ ██╔══██║╚════██║██╔══██║██║   ██║╚██╗ ██╔╝     ╚════██║██╔═██╗ ██║██║     ██║     ╚════██║
██║     ██║  ██║███████║██║  ██║╚██████╔╝ ╚████╔╝      ███████║██║  ██╗██║███████╗███████╗███████║
╚═╝     ╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝ ╚═════╝   ╚═══╝       ╚══════╝╚═╝  ╚═╝╚═╝╚══════╝╚══════╝╚══════╝

---

name: x-ray description: "プロトコルの概要、強化された脅威モデル（プロトコルタイプ分類、git加重攻撃面、時間的リスク分析、合成可能性依存関係マッピング）、不変性、統合、ドキュメント品質、テスト分析、開発者/git履歴をカバーするx-ray.md事前監査レポートを生成します。'x-ray'、'audit readiness'、'readiness report'、'pre-audit report'、'prep this protocol'、'protocol prep'、'summarize this protocol'でトリガーされます。"

---

X-Ray

プロジェクトルートに x-ray/ フォルダを生成し、すべての出力ファイルを含めます。パイプライン: 3ステップ、常に順序付け。

$SKILL_DIR = このSKILL.mdファイルを含むディレクトリ。このスキルを読み込んだパスから解決します（例：このファイルが /path/to/x-ray/SKILL.md にある場合、$SKILL_DIR = /path/to/x-ray）。

進行状況追跡（必須）

他に何かする前に、TodoWrite を呼び出して、これら3つのToDo（すべて pending）を設定します：

1. Phase 1: Enumerate & measure codebase
2. Phase 2: Read sources, classify entry points, synthesize invariants
3. Phase 3: Write x-ray report files

遷移（TodoWrite経由で更新 — バッチ処理は禁止）:

• enumerate.sh を実行する直前に Phase 1 を in_progress にマークします。
• ステップ1の並列バッチが戻ったら、1つのTodoWriteコールで Phase 1 を completed にマーク、Phase 2 を in_progress にマークします。
• ステップ2（2b–2gを含む）が完了したら、1つのTodoWriteコールで Phase 2 を completed にマーク、Phase 3 を in_progress にマークします。
• すべてのステップ3出力ファイルが書き込まれた後、Phase 3 を completed にマークします。

ルール: 常に正確に1つのtodoが in_progress です。ステータス更新はフェーズが開始または終了した時点で発生します。

ステップ1: 列挙と測定

ユーザーがパスを指定した場合、それをプロジェクトルートとして使用します。それ以外の場合は cwd を使用します。ルートに .sol ファイルまたは foundry.toml/hardhat.config.* がない場合は、1レベル深くをチェックします。

ソースディレクトリ検出: foundry.toml （src = "..."）または hardhat.config.* から自動検出します。設定ファイルがない場合は、src/ と contracts/ の両方を試します。存在する場合は foundry.toml を最初に読みます。

列挙を実行（単一のBashコール — 出力ディレクトリ作成を含む）:

mkdir -p [project-root]/x-ray && bash $SKILL_DIR/scripts/enumerate.sh [project-root] [src-dir]

直後に、以下のすべてを1つのメッセージで起動します（並列）:

0. バージョンチェック（フォアグラウンド）:

• $SKILL_DIR/VERSION から local VERSION ファイルを読みます
• Bash curl -sf https://raw.githubusercontent.com/pashov/skills/main/x-ray/VERSION
• リモートVERSION取得が成功してローカルと異なる場合、⚠️ You are not using the latest version. Please upgrade for best security coverage. See https://github.com/pashov/skills を表示します。失敗する場合は無視します。

1. カバレッジ（run_in_background: true）:

Foundryの場合:

cd [project-root] && forge coverage 2>&1 || (echo "RETRYING_WITH_IR_MINIMUM" && forge coverage --ir-minimum 2>&1)

Hardhatの場合:

cd [project-root] && npx hardhat coverage 2>&1

ツールチェーンがインストールされていない場合（例：forge: command not found、npx: command not found、missing node_modules/）、カバレッジコマンドは失敗します。これは予想通りです — テスト存在は上記のステップの列挙により既に取得されています。カバレッジ失敗はテストがないことを意味しません。

2. Git セキュリティ分析 + JSON読み込み（フォアグラウンド、単一のBashコール）:

cd [project-root] && python3 $SKILL_DIR/scripts/analyze_git_security.py --repo . --src-dir [src-dir] --json x-ray/git-security-analysis.json 2>&1 && cat x-ray/git-security-analysis.json

JSONは7つのセクションを持ちます: repo_shape, fix_candidates, dangerous_area_changes, late_changes, forked_deps, tech_debt, dev_patterns。

3. 参照ファイルのプリロード（2つの並列Readコール — これらはステップ2d/3aのコンテキストに必要）:

• $SKILL_DIR/references/threats.md — 脅威プロファイル、時間的脅威、合成可能性脅威
• $SKILL_DIR/references/templates.md — 出力テンプレート、エントリポイントテンプレート、アーキテクチャガイド

4. スペック/ホワイトペーパー検出（1つのGlob: **/{whitepaper,spec,design,protocol,architecture,overview,README}*.{pdf,md} ただし node_modules/、lib/、x-ray/、test/ は除外）。ユーザー向けドキュメント（チュートリアル、APIリファレンス、チェンジログ、寄稿ガイド）をスキップします。その後、サイズ対応の処理を適用します:

• パスA（≤5ドキュメント、各≤300行）: ステップ2の並列メッセージにReadコールとして含めます。直接読み込み — サブエージェント不要。
• パスB（>5ドキュメント または任意のドキュメント>300行）: 1つのサブエージェント（model: "sonnet"）を起動して、すべてのドキュメントファイルを読み込み、構造化抽出を返します（最大200行）。サブエージェントプロンプト:

  以下にリストされた各ドキュメントファイルを読みます。セキュリティ関連情報のみをこの形式に抽出します:
  Files: [ドキュメントファイルパスのリスト]
  
  この正確な構造を返します:
  ### Doc-Stated Global Invariants
  [ドキュメントが全体的に保持する必要があると主張するすべての不変式、制約、または保証の箇条書きリスト。ステップ2gのNatSpec述べられた不変式と同様に扱う — 形状により §2 / §3 / §4 of invariants.md に直接ルーティング、§1（Enforced Guards、これはコール単位の事前条件のみ）には含みません。]
  ### Actor Definitions
  [述べられたパーミッションと信頼レベルを持つ各アクター/ロール]
  ### Trust Assumptions
  [プロトコルが外部システム、オラクル、管理者、ユーザーについて想定すること]
  ### Cross-System Flows
  [コントラクト間または外部システム間で価値/データがどのように移動するか]
  ### Economic Properties
  [手数料構造、報酬メカニズム、トークノミクス、境界パラメータ]
  ### Key Design Decisions
  [明示的な「私たちはZのためにYの代わりにXを選びました」ステートメント]
  
  ルール: 各主張のソースドキュメントを引用してください。関連コンテンツのないセクションは省略してください。合計最大200行。
  

  このサブエージェントをステップ1の並列メッセージに含めます。その出力はステップ3レポート執筆に供給されます。

両方のパスについて、以下のみを抽出します: ドキュメント述べられたグローバル不変式、アクター定義、クロスシステムフロー、信頼仮定、経済プロパティ、主要設計決定。レポート内のすべてのスペック派生主張に (per spec) タグを付け、監査者がコード検証済みとスペック述べられたものかを知ることができるようにします。ドキュメント述べられたグローバル不変式はステップ2gのNatSpecルーティングステップに供給されます — それらは形状により invariants.md の §2 / §3 / §4 にルーティング、§1（Enforced Guards）には含みません。

すべてのコール（カバレッジ、git分析、参照読み込み、spec glob）は同じメッセージに表示される必要があります。forge カバレッジを待たずにステップ2に進みます。

ステップ2: ソースファイル読み込み + エントリポイントスキャン（単一メッセージ、すべてのツールコール並列）

重要: すべてのツールコール — Bash、Agent、Read、Grep — は1つのメッセージで発行される必須なので、並行して実行されます。これにはソースファイル読み込み、エントリポイントgrepスキャン、ステップ1で検出されたスペックドキュメント（すべて独立）が含まれます。

スコープフィルタリング

• インターフェイスをスキップ: interfaces/ ディレクトリまたはファイル名 I + 大文字
• ベンダーライブラリをスキップ: Uniswap FullMath/TickMath、OZコピー
• 不確かな場合は含めますが、スコープテーブルから除外

パスA: ≤20個のソースファイル（直接読み込み）

1つのReadコール/ファイル。README、ドキュメント、またはfoundry.toml（ステップ1で既に読まれている）を読まないでください。

ファイルごとに抽出: コントラクトタイプと継承、ロールとアクセス制御、価値保有状態変数、外部呼び出し、資金フロー、不変性コメント、assert/require、後方互換性インジケータ（下記参照）、デルタ書き込み（関数ごと: ストレージ変数と適用される記号デルタ — 例：Δ(totalSupply) = +shares, Δ(balanceOf[msg.sender]) = +shares — 同一の基本ブロック内のみ、クロス関数推論なし; OZ _mint/_burn のような継承ヘルパーは、balanceOf/_totalSupply への効果が意味的に明確でない場合のみ解決可能）、ガード述語（ストレージ変数を参照するすべての require/assert/if-revert、行番号付きで逐語的に引用; 関数パラメータのみを参照するガードはスキップ）、enum/one-shot遷移（require(state == X); ...; state = Y のすべてのペア、X@Lx → Y@Ly として記録 — require(addr == address(0)); addr = concrete のようなone-shotラッチを含める）。

パスB: >20個のソースファイル（並列サブエージェント）

Tier 1 — 小さいファイル（≤120行）: 単一のBash cat コールにバッチ処理。

Tier 2 — 大きいファイル（>120行）: サブシステムごとにグループ化。サブシステムごとに1つのサブエージェントを起動（model: "sonnet"、最大5つ、最大～10ファイル各）。サブエージェントプロンプト:

以下にリストされた各ファイルを読み込み、構造化サマリーを返します。分析しないでください — ただ事実を抽出してください。
Files: [ファイルパスのリスト]
各ファイルについて、この正確な形式を返します:
### [filename]
- **Type**: contract | library | abstract
- **Inherits**: [親コントラクト]
- **Imports**: [インポートされたライブラリ/コントラクト]
- **Roles/Access**: [onlyOwner、ロール定数、修飾子]
- **State vars (value-holding)**: [残高、担保などを保有するマッピング/変数]
- **External calls**: [他のコントラクトへの呼び出し、ERC20転送など]
- **Fund flows**: [deposit/withdraw/mint/burn/transferパス]
- **Invariants**: [require/assertステートメント、NatSpec不変性コメント]
- **Delta writes**: 各非view非pureファンクションについて、変更されるストレージ変数と適用される記号デルタをリストアップします。形式 `Δ(var) = +expr` または `Δ(var) = -expr` を使用します。同じ関数本体内に両方の書き込みが現れており、未知の外部コントラクトへの介入呼び出しがない場合のみペアをレポートします。継承/インポートされた関数を介した書き込みを追跡しないでください。セマンティック効果が明確でない場合のみ追跡します（OZ `_mint` → `balanceOf` + `_totalSupply` は問題ありません; カスタム内部ヘルパーはそうではありません — それらのデルタはその内部ヘルパー自体のエントリでのみリスト）。例:
  - `deposit()`: `Δ(totalSupply) = +shares`, `Δ(balanceOf[msg.sender]) = +shares`
  - `borrow()`: `Δ(totalBorrows) = +amount`, `Δ(underlyingBalance) = -amount`
- **Guard predicates**: ファイル内でストレージ変数を参照するすべての `require`/`assert`/`if-revert`。逐語的に行番号付きで引用してください。関数パラメータのみを参照するガードはスキップしてください。
  - `Vault.sol:206`: `require(_fee <= 10, "fee is capped at 0.1%")`
- **Enum/one-shot transitions**: `require(var == X); ...; var = Y` のすべてのパターン。ここで `var` はストレージenum、uint、またはアドレスです。`X@Lx → Y@Ly` として記録してください。`require(addr == address(0)); addr = concrete` のようなone-shotラッチを含めてください。
- **Key logic**: [コントラクトが何をするかについての1-2文]
- **Function-level access map**（コントラクトは必須、ライブラリはスキップ）:
  すべてのpublic/externalな非view非pureファンクションをそのアクセス制御でリストアップしてください:
  - `functionName()` — [修飾子名、例：`onlyRole(OCT_KEEPER)`] または [NONE — パーミッションレス]
  修飾子なしのファンクションについては、外部呼び出し元もリストアップしてください:
  - `functionName()` — NONE — calls `ContractName.method()`

エントリポイント Grep スキャン（ステップ2のソースファイル読み込みと同じ並列メッセージに含まれる）

以下の2つのBashコールをソースファイル読み込み上と同じメッセージで起動します — これらは独立しており、並行して実行できます。コマンドはPOSIX ERE + POSIX文字クラスのみを使用します（-P / PCRE なし、GNU限定エスケープなし like \s \w \b）。そのため、GNU grep（Linux/WSL）、BSD grep（macOS デフォルト /usr/bin/grep、FreeBSD）、ripgrepで同一に機能します:

# 1. 単一行署名: 関数名と可視性が同じ行
grep -rnE 'function[[:space:]]+[[:alnum:]_]+[[:space:]]*\([^)]*\)[[:space:]]+(external|public)' [src-dir]/ --include='*.sol' \
  | grep -v '/interfaces/' | grep -v '/mock/' \
  | grep -Ev '(^|[^[:alnum:]_])(view|pure)([^[:alnum:]_]|$)'

# 2. 複数行署名: 可視性キーワードが閉じかっこ行（90%以上のマルチライン場合を網羅）
grep -rnE '^[[:space:]]*\)[[:space:]]+(external|public)' [src-dir]/ --include='*.sol' -B5 \
  | grep -v '/interfaces/' | grep -v '/mock/' \
  | grep -Ev '(^|[^[:alnum:]_])(view|pure)([^[:alnum:]_]|$)'

両方の結果を統合します。複数行grepは重要です — Solidityファンクションはパラメータを複数行に分割しており、external/public を ) 行に配置していますが、function name( は上の行です。末尾の grep -Ev '(^|[^[:alnum:]_])(view|pure)([^[:alnum:]_]|$)' はPOSIX互換の \b(view|pure)\b の代替: それは view または pure が非識別子文字または行境界で囲まれたスタンドアロン識別子として現れる行をドロップしますが、単に view_param / pure_x 識別子部分文字列を含む行を保持します。

互換性保証:

• -E, -v, -r, -n, -B → POSIX（2001+）/ macOS、FreeBSD、Linux GNU grep、busybox grep、ripgrepでサポート
• [[:space:]], [[:alnum:]_] → POSIX文字クラス、上記すべてでサポート
• --include='*.sol' → GNU + macOS BSD grep + ripgrep。busybox grep ではサポートされていません（ニッチ; Alpine minimal）; スキルをそこで実行する必要がある場合、--include='*.sol' [src]/ を $(find [src]/ -name '*.sol') に置き換え、引数として渡します。

すべてのツールコール（ソースファイル読み込み/Bash/サブエージェント、両方のgrepスキャン）は1つのメッセージに必須です。

テストファイルまたはドキュメントファイルを読まないでください。

ステップ2b: エントリポイント分類

ステップ2の並列メッセージから既に返されたgrepの結果を使用してすべてのエントリポイントを分類します。サブエージェントサマリーのみに頼らないでください — サブエージェントはコントラクトレベルで事実を抽出し、どの関数がどの外部呼び出しをするか、どの関数がどの修飾子を持つかを誤表示する可能性があります。

エントリポイントから除外: view/pureファンクション、インターフェイスのみ宣言、ライブラリ内部関数（これらは下流呼び出し、エントリポイントではない）、mockコントラクト。

各結果について、3つのカテゴリのいずれかに分類:

1. パーミッションレス — アクセス制御修飾子がなく、かつ関数本体に内部呼び出し制限がない。関数本体をエントリポイントとして分類する前に検証する必須です。**パスA（≤20ファイル）**の場合、本体は既にステップ2読み込みのコンテキストにあります — 追加のReadコール無しで直接分類します。パスBの場合、すべての候補本体読み込みを単一の並列メッセージにバッチ処理します。これらのパターンのいずれかを呼び出し元を制限するものを探します:
   • require(msg.sender == X) または if (msg.sender != X) revert ...
   • if (msg.sender != X || ...) revert ...（複合条件）
   • msg.sender をチェックする内部関数への呼び出し 修飾子なしでも内部 msg.sender チェックがあるファンクションはロール保護です、パーミッションレスではありません。一般的な例: acceptOwnership()、acceptMsig()、confirmX() — これらはしばしば修飾子を持ちませんが、呼び出し元を特定の保留中アドレス制限 if (msg.sender != pendingX) revert。
2. ロール保護 — ロール修飾子（onlyRole(X)、onlyOwner、onlyRouter など）があるか、内部 msg.sender 制限がある（require 経由、if/revert 経由、または委任チェック経由）。必要なロールまたはアドレスを記録します。
3. 管理者のみ — DEFAULT_ADMIN_ROLE、プロトコル管理者を指す onlyOwner、または同様のトップレベル権限によってゲート。

注: nonReentrant のみはアクセス制御ではありません。initializer/reinitializer はワンタイムデプロイメント関数です — 別途追跡します。

各エントリポイントについて、記録:

• コントラクト名とファンクション名
• アクセスレベル（パーミッションレス / ロール名 / 管理者）
• 呼び出し元（User、Keeper、Admin、LP など）
• 信頼レベルを持つパラメータ: (user-controlled)、(user-signed)、(keeper-provided)、(protocol-derived)
• コールチェーン: サブエージェントサマリー + ファンクションレベルアクセスマップを使用した下流呼び出しの追跡。形式: → Contract.fn() → Contract.fn()
• 修正された状態: どのストレージ変数/マッピング変更
• 価値フロー: in（トークンデポジット）、out（トークン引き出し）、none
• Reentrancy ガード: はい/いいえ

このデータは2つの出力に供給されます:

• パーミッションレスエントリポイントリスト in x-ray.md（セクション2）— パーミッションレスサブセットのみを使用
• 完全なentry-points.mdファイル（ステップ3c）— すべてのカテゴリを使用

ステップ2b-flow: プロトコルフロー経路構築

ステップ2bで既に収集されたエントリポイントデータを使用してentry-points.mdのフロー経路を構築します。これは別個の分析パスではありません — 既に持っているデータを再編成します。

主要なユーザー向けエントリポイント各について（パーミッションレスおよび価値を移動するロール保護ファンクション）:

1. その require ステートメント状態変数チェックを特定
2. 各チェックについて、その状態変数を書き込むどのファンクションを見つける（既に他のエントリポイントの「修正された状態」フィールドで既知）
3. これらを後方にチェーン: destination ← その前提条件の作成者 ← その前提条件の作成者 ← ... ← デプロイメント
4. 非ファンクション前提条件（時間経過、市場条件、外部状態）を ◄── アノテーションで注記

出力: シンプルな矢印チェーン、アクターフロー単位でグループ化。前のフローを繰り返すのではなく参照します。合計15-30行。エントリポイント.md テンプレートのプロトコルフロー経路セクションの正確な形式を参照してください。

grepスキャンはハードゲートです: レポート内のパーミッションレスエントリポイントセクションはサブエージェントサマリーではなくこのgrepで検証されたリストと一致する必須です。競合がある場合、grep + コード読み込みの結果が勝ちます。

ステップ2c: 後方互換性コード検出

ソースファイルを読む間、削除されたメカニズムの遺物に見える削除されたメカニズムが、残りのコードベースが壊れないように保持されているかのようにコードを見張る。一般的なシグナル: 空いたまたは些細なファンクション本体、意味的に読み込まれたり書き込まれたりすることのない宣言された状態変数、「deprecated」/「legacy」/「backwards compat」/「no longer used」を含むコメント、インターフェイスを実装するが常にデフォルトを返すファンクション、プロキシストレージレイアウト互換性のためだけに保存される状態変数。

すべてのソースファイルを読み込んだ後、これらの必須検証チェックに対して候補をクロスリファレンスしてから、何かを後方互換性として分類します。すべての候補に対するすべての呼び出し元チェック Grep コール を1つの並列メッセージにバッチ処理 — 1つずつ検証しないでください:

1. 呼び出し元チェック（必須）: Grepを使用してファンクション/変数が現在のコードベースにアクティブな呼び出し元がないことを確認します。呼び出された場合、デフォルトを返すかゼロを返すかに関わらず、これは後方互換性ではなく — これは現在のデザインです。
2. NatSpec/コメントチェック（必須）: コードにNatSpecまたはインラインコメントがある場合、特定の理由を説明している場合（例：「簡略化されてX モード用」、「設計上」、「意図的にゼロ」）、これはドキュメント化された意図的なデザイン、後方互換性コードではありません。明示的な開発者ドキュメントをヒューリスティック パターンマッチングでオーバーライドしないでください。
3. インターフェイス義務チェック: デフォルト値を返すが、インターフェイスが必要であり、アクティブに呼び出されるので存在するファンクションは、現在のアーキテクチャの一部であり、遺物ではありません。

コードを後方互換性として分類するのは、すべての場合のみです: (a) アクティブな呼び出し元が存在しない、(b) NatSpec/コメントが動作を意図的として文書化していない、and (c) gitの履歴がそれが属していたメカニズムが削除されたことを示す。

後方互換性コードを活動機能としてレポートに説明しないでください。代わりに、セクション1で明示的に注記してください（出力テンプレート参照）。監査人はアクティブな機能ではなく互換性のために保持されているコードベースのどの部分かを知ることができます。検証チェックを通じて後方互換性コードが生き残らない場合は、サブセクション全体を省略します。

ステップ2d: 集約化と一時停止カバレッジ分析

ソースファイルを読み込んでエントリポイントを分類した後、2つの分析を実行します。これらはアクターテーブル、信頼境界、主要攻撃面（セクション2）に供給されます。これらはスタンドアロンセクションではありません — 結果は既存レポートセクションに統合されます。

集約化分析 — 各特権ロール（管理者、所有者、オペレータ、キーパー、サービス など）について:

1. ロールが実行できるすべての操作上のアクションをリストアップしてください（ファンクションレベルアクセスマップから）
2. 各アクションについて、タイムロック、マルチシグ、または遅延が存在するかどうかに注記。ロール転送遅延（例：AccessControlDefaultAdminRules 1日遅延）と運用アクション遅延を区別します — それらは同じではありません。ロール転送遅延は、それは妥協した保有者がインスタント運用ファンクションを使用するのを保護しますしません。
3. ユーザー資金を抽出または転用できるアクション（例：emergencyWithdraw、setTreasury、transferFee）を特定

統合する: アクターテーブル（カパビリティ列は即座対タイムロック詳細）、信頼境界（各境界が実際に何を保護するかおよび何をバイパスするかについて記述）、主要攻撃面（「管理操作電力」または「[ロール]妥協」 — 攻撃面は個別ファンクションではなくロール妥協です）。

一時停止カバレッジ分析 — 各重要な状態変更ファンクションについて:

1. whenNotPaused（または同等）が適用されるかどうかをチェック
2. どのファンクションが一時停止可能対不可かを注記 3.論理的に一時停止可能であるべきファンクションが（例：ユーザー資金で動作する境界ロールで呼び出し可能なファンクション）、それを統合する関連する攻撃面に見つけない場合。欠落している一時停止は攻撃面そのものではありません — それはその関連ロールの妥協シナリオを悪化させるの詳細です。

アンチパターン: スタンドアロンの「集約化リスク」サブセクションを作成しないでください。 集約化詳細はアクター、信頼境界、主要攻撃面、およびプロトコルタイプの懸念事項全体に分散されるべきです。専用セクションはこれらのセクションで既に存在する情報を重複します。一時停止カバレッジについても同じです — 関連するロールの攻撃面記述に統合します。

ステップ2e: プロトコル分類

ソースを読んだ後、references/threats.md の手順に従ってプロトコルを分類します（タイプ検出 + ハイブリッド分類、フェーズ検出、および外部呼び出し分類 — 1つのファイルのすべて）。

ステップ2f: nSLOC

ステップ1列挙出力から正確なnSLOC合計を使用します（~ 接頭辞なし）レポートヘッダーおよびスコープテーブルに。

ステップ2g: 不変性合成

ステップ2で抽出されたデルタ書き込み、ガード述語、enum/one-shot遷移、および不変性コメント（パスAの直接読み込みから、またはパスBのサブエージェント出力から）を使用して、以下の分類を体系的にウォーク して不変性候補を生成します。これは推論パス — 新しいツールコール不要（ステップ2パスBのGrepバッチを除く — 下記参照）。

用語: ガードは単一のコールサイトで実施される呼び出しごとの前提条件（例：require(amount >= MIN)）。これは否定可能な不変性ではありません — コード自体がそのコールサイトでそれを保証します。不変性はグローバルに任意の呼び出しシーケンスでたどることが必須のプロパティ（例：「すべてのアクティブなポジション ≥ MIN」）。ガードは invariants.md の§1（実施ガード参照）のみに供給されます。持ち上げられたガード（下記ステップ2参照）またはNatSpecで述べられた不変性は§2 / §3 / §4に供給されます。

NatSpecルーティング（構造ウォーク前に実行）: 各NatSpec @invariant タグまたはグローバルプロパティを主張するインラインコメント（例：「totalSupply は常に Σ balances に等しい」、「手数料は決して MAX_BP を超えない」、「一度に1つのアクティブエポックのみ」）について、セクションとしてDIRECTにルート§2（または§3/§4プロパティが複数のコントラクトにまたがっているか複数の原始から派生する場合）カテゴリ形状（Conservation / Bound / Ratio / StateMachine / Temporal）。ソースタグ: NatSpec: Contract.sol:LN。開発者述べられたグローバル不変性を§1に配置しないでください — §1は呼び出しごとのガード述語のみです。ルーティング後、下記の構造スキャンを実行します — それらが確認（On-chain=Yes）またはNatSpec主張に矛盾（On-chain=No）するかもしれません。

ウォーク順序（各ステップは前のステップの結論ではなく、生の抽出データを使用）:

1. Conservation スキャン: 各ファンクションについて、デルタ書き込みペアを見つけてください。Δ(A) = +expr および Δ(B) = -expr（またはΔ(B) = +expr マッピング対応の場合）同じファンクション本体に。各マッチペアはconservation候補: A + B = const または A == Σ B[key]。

   • マッピング書き込みの場合（mapping[key] += e スカラーと組になって scalar += e）、推論 scalar == Σ mapping[key]。パターンがいずれかの変数を書き込むすべてのファンクション全体で保持されることを確認 — いかなるファンクションも一つなしで他を書き込む場合、「部分conservation」とギャップをNote、Yes/Noをそれぞれ分割。
   • 転送パターン（mapping[from] -= e、mapping[to] += e スカラー変更なし）の場合、マッピング合計は自己保持されることを確認。
   • ネガティブ conservation（重要）: フロー（例：flashloan pull/push、receive/forward）を追跡するべきファンクション、しかしゼロストレージ Δ を持つ場合、これはConservation-negative検出として記録します。Δ の欠落はそれ自体が不変性観察です。

2. ガード抽出と持ち上げ（各 require/assert/if-revert 上2つのパス）:

   パスA — 逐語的に抽出（実施ガード参照）: すべての require/assert/if-revert は invariants.md の§1に G-N 行になります。述語をソース位置で逐語的に引用してください。これはコール単位の前提条件の機械的ダンプです — 否定可能ではなく、ファズされません。ストレージタイバックがなく、グローバル含意がない関数パラメータのみを参照するガードをスキップしてください（パスBを超える監査値がない純粋なローカル入力検証）。

   パスB — グローバルプロパティに持ち上げ、その後すべての書き込みサイトをチェック: 各ガードについて、尋ねてください: 「これはこのコールサイトだけではなく、任意の呼び出しシーケンスで保持する必須のプロパティを意味していますか?」

   • いいえの場合（ガードはアクティブな永続ストレージにタイバックされず、ファンクションで消費される一時的なパラメータのみ制約）→ §1 のみに残してください。持ち上げないでください。
   • はいの場合（ガードが永続プロパティを意味している — 例：require(amount >= MIN) 保証で「すべてのアクティブなポジション ≥ MIN」; require(_fee <= 10) セッターで「fee ∈ [0, 10]」） → ガードをグローバルプロパティに書き直し、スコープファイル全体で変数名上で Grep を使用して制約されたストレージ変数のすべての書き込みサイトを見つけます。すべての書き込みサイト Grep をすべての持ち上げられたガードに対して1つの並列メッセージにバッチ処理 — 1つずつ検証しないでください:
     • すべての書き込みサイトが同等ガードを実施する場合 → §2 に持ち上げ、On-chain=Yes として Bound 不変性。導出: ガード + すべての書き込みサイト確認。
     • いかなる書き込みサイトが同等ガードなしで変数を書き込む場合 → §2 に持ち上げ、On-chain=No として Bound 不変性、ギャップとして保護されていない書き込みサイトを引用。これは高シグナル出力です — ギャップは同時に不変性と潜在的なバグです。

   セッターレベル範囲を含めてください。セッターは所有のパラメータチェックで制約されるストレージ変数を書き込みます。複数のセッターが同じ変数を書き込みますが、いくつかのセッターのみ範囲を実施する場合は、同じすべて書き込みサイトチェックを実行 — プロパティはOn-chain=Noです。

3. Ratio スキャン: 各ストレージ A = B * C / D 書き込みについて B、C、D はストレージ変数またはファンクションスコープストレージスナップショット、比率を記録します。スナップショットが同じファンクション内で他の状態変更の前後に取得されるかどうかについて注記（順序が重要 — 例：totalSupply スナップショット _burn 前対後）。

4. 状態マシン / one-shot スキャン: require(var == X); ... var = Y パターンの各enum/uint/addressについて、遷移を記録します。区別:

   • One-shot ラッチ: require(var == default); var = concrete 戻るパスなし（例：setStrategy、setLeverager）。
   • トグル可能フラグ: require(var == false); var = true しかし別ファンクションがそれを反転（例：freeze/unFreeze、toggleVaultLeverage）。 NOT 状態マシン不変性 — スキップ。
   • Cyclic 状態: false → true → false タイミング/条件によって駆動（例：ongoingVestingPosition）。サイクル不変性として記録。

5. Temporal スキャン: block.timestamp または block.number 比較を含む各ストレージ変数に関するもの（デッドライン、lastUpdate、lockPeriod、interval）、temporal制約を抽出します。制約がチェック後更新（安全）対更新後チェック（潜在的に古い読み込み）かどうか注記。

6. クロスコントラクト スキャン: 戻り値が算術またはストレージ書き込みで使用される各外部呼び出しについて、呼び出し元が想定することを記録します。その後、その状態のcallee書き込みサイトを見つけます。callee が独立してそれを変更できる場合（別のファンクション経由）、想定は検証されていません — クロスコントラクト不変性として記録、On-chain=No。スコープファイル内の両側（呼び出し元想定 + callee書き込みサイト）のみが含まれる行をのみ含めてください。スコープ外コントラクトについて推測しないでください。

   • また含める: セッター対不変性ミスマッチ — 管理者セッターが既存の不変性がまだ保持されることをチェックせずにストレージ値を書き込む場所（例：setReserveCapacity 現在の流動性に対してチェックなし）。これらはセッターが1つのコントラクト/ファンクションで、不変性が他の場所で実施される意味でクロスコントラクトです。

7. Economic 派生: ステップ1-6後、単一コントラクト + クロスコントラクト不変性の任意の組み合わせが高次プロパティを意味するかチェック。各economic不変性は、派生するそれが具体的な I-N / X-N IDを引用する必須です。派生チェーンにギャップがある場合（ソース不変性の1つ On-chain=No）、economic不変性も On-chain=No です。

検証ゲート（任意の推論不変性を含める前に必須）:

• Conservation: Δ ペア cited行に存在することを確認（同じファンクション本体）。
• ガード（パスA、§1行）: require/assert/if-revert がコードから逐語的なことを確認。
• ガード持ち上げ（パスB、§2行）: 持ち上げられたグローバルプロパティが永続ストレージを参照することを確認（一時的なパラメータ表現ではなく）。制約された変数のすべての書き込みサイトが Grep経由で列挙されていることを確認、On-chain=Yes/No 判定が列挙と一致 — ガード不足の書き込みサイトが何かあり、行は On-chain=Yes を言っている場合、行は無効です。
• NatSpec: @invariant タグまたはコメント cited位置に存在することを確認 AND グローバルプロパティを主張（呼び出し単位注記ではなく）。呼び出し単位注記の場合、ドロップ — §2にルーティングしないでください。
• Ratio: 式が正確なことを確認、スナップショット順序（同じファンクション内他の書き込み前/後）注記。
• StateMachine: 両側エッジが存在することを確認 AND 反転パスなしを確認。反転パスがある場合、トグル可能フラグです — ドロップ。
• Temporal: 比較がストレージ変数に関するもの、関数パラメータ対ブロック.timestamp ではないことを確認。
• クロスコントラクト: 呼び出し側想定 AND callee書き込みサイトの両方がスコープファイル内にあることを確認。
• Economic: すべての参照 I-N / X-N ID が自らが検証されることを確認。
• 検証できない場合 → ドロップ行。「検証できませんでした」有効な行ではありません。

出力: 不変性候補は invariants.md（ステップ3a）に直接供給されます。x-ray.md セクション3 は実施ガード（参照）+ トップ3-5推論（Conservation、Cross-Contract、and持ち上げられたガード ギャップから On-chain=Noを優先; 比率またはstate-machine ラッチのような構造カバレッジのために1つの高シグナル Yes行を含める）を取得します。

ステップ3: 出力の書き込み

テスト存在 対 カバレッジ実行（重要）

テスト存在はステップ1列挙で決定（test_files、test_functions、stateless_fuzz、foundry_invariant、echidna、medusa、hardhat_fuzz、fork、certora、halmos、hevm 数）。これらはファイルスキャン結果であり、ツールチェーンが編集またはテスト実行できるかどうかに関わらず常に 信頼できます。マルチシグナルカテゴリ（echidna、medusa、certora、halmos）は functions:configs として出力 — 例：5:1 は5テストファンクション + 1設定ファイル検出を意味します。

カバレッジ メトリクス（行/ブランチ %）は forge coverage または hardhat coverage から、インストール済み依存、成功したコンパイル、合格したテストが必要です。カバレッジはテスト品質と無関係な多くの理由で失敗できます:

• 依存がインストールされていない（npm install / forge install が実行されていない）
• コンパイラエラー（stack-too-deep、バージョンミスマッチ）
• テスト実行失敗（欠落したRPC、forkConfig）

ルール:

1. すべてのテスト存在主張に対してステップ1列挙から test_files/test_functions を使用します。カバレッジツール失敗から「テストなし」を推論しないでください。
2. カバレッジが失敗していますが、列挙がテスト存在を示している場合、レポート: "[N] test files with [M] test functions detected; coverage metrics unavailable — [failure reason]"。
3. 「Gaps」サブセクションで、失敗テストカテゴリ（stateless_fuzz=0、foundry_invariant=0、echidna=0、medusa=0、certora=0、halmos=0、hevm=0、fork=0）のみをフラグしてください。列挙がテストを示している場合、「テストなし」をフラグしないでください。数学的に重い/財務ロジックの欠落したstatefulファズとフォーマル検証で監査影響度でギャップを優先; 欠落したfork tests より高い優先度。
4. Gitの履歴「セキュリティ観察」では、カバレッジ失敗に基づいて「テストなしのコミット」を主張しないでください。git分析からの test_co_change_rate はコミット内でのファイル共修正を測定 — カバレッジではなく — それとしてそれを適格です。
5. カバレッジが失敗する場合、失敗が脅威モデルまたはリスク評価にカスケードしません。テスト存在（列挙から）とカバレッジメトリクス（ツールから）は独立シグナルです。

forge カバレッジステータスをチェック: 完了なら結果を含める、失敗なら失敗理由、実行中なら「pending」。待たないでください。

3a. すべての出力ファイルを書き込み（4つの並列Writeコール、1つのメッセージ）

すべての出力ファイルは x-ray/ ディレクトリに入ります。すべての4ファイルを1つのメッセージで書き込み、並行して作成:

1. x-ray/architecture.json — references/templates.md のアーキテクチャガイドセクション内の形式とルールに従う（ステップ1で既に読み込まれている）。

2. x-ray/x-ray.md — references/templates.md の出力テンプレートセクション内のテンプレートに従う（ステップ1で既に読み込まれている）。500行以下。製造なし。セクション3（不変性）は invariants.md へのポインタのみ — ガードテーブルを含めない、トップ推論不変性をリストアップしない。数（ガード/単一コントラクト/クロスコントラクト/economic）を持つ1つの引用符とinvariants.mdファイルへの強いリンクが§3全体です。不変性カタログは exclusively invariants.md に住む; それを x-ray.md で重複は古いV2動作でした正しくありません。

主要攻撃面クロスリンク要件: セクション2主要攻撃面を書く場合、各面をinvariants.mdブロックで作成済みに対してクロスリファレンス。面のcited file:line が任意の G-N / I-N / X-N / E-N ブロックの Location / Derivation / Caller side / Callee side ウィンドウ内に入る場合、マッチング ID を小文字スラッグ フラグメント使用括弧マークダウンリンクとして面タイトル直後を追加: - **Surface name**  [[X-4](invariants.md#x-4), [I-17](invariants.md#i-17)] — ...。各面の箇条書きを空白行で分離. アクセス制御またはアップグレード可能性懸念のみの面は非リンク — 健全なシグナルであり、ギャップではありません。一般的なヒット率non-trivial プロトコル: ≥70% 面が少なくとも1つの不変性にリンク。

3. x-ray/entry-points.md — ステップ2bで収集された完全なエントリポイントデータおよびステップ2b-flowからのフロー経路を使用して、references/templates.md のエントリポイント テンプレートセクションに従います（ステップ1で既に読み込まれている）。プロトコルフロー経路セクション（各主要エントリポイント向け矢印チェーン前提条件シーケンスを示す）で開始し、次にアクセスレベル詳細セクション。ファクチュアルのみ — 脅威分析なし（それはx-ray.mdに留まる）。プロトコルが>30エントリポイントを持つ場合、ロール保護と管理セクションに対してコンパクトテーブルを使用する代わりにファンクション単位詳細ブロック。パーミッションレスエントリポイントのみは数に関わらず完全詳細ブロック処理を取得。

4. x-ray/invariants.md — references/templates.md の不変性マップテンプレートセクションに従う。4セクション: 実施ガード（参照）、推論（単一コントラクト）、推論（クロスコントラクト）、Economic。テーブル NOT ブロックではなく #### G-N / #### I-N / #### X-N / #### E-N ヘッドを使用します。** ヘッドアンカー（スラッグ #g-1, #i-17, …）はx-ray.md 攻撃面からのクロスファイル マークダウンリンクのターゲット; テーブルセル内インライン <a id> アンカーはVS Code クロスファイルで機能しません。各 G-N ブロック は Purpose 行を含める必須（チェックするだけでなく、ガード保護を説明）。すべての推論ブロック は具体的 Δ