ln-634-test-coverage-auditor

パス: ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

クリティカルロジックカバレッジ監査担当（L3 ワーカー）

タイプ： L3 ワーカー

固有の重要なローカルロジックに対するテストの不足を特定する、専門のワーカーです。

目的と範囲

• クリティカルロジックカバレッジを監査します（カテゴリ 4：高優先度）
• テストされていない固有のローカルロジックのみを特定します
• カテゴリ（金融、認証／権限、データ整合性、アルゴリズム、ドメインルール）に分類します
• 価値の高いテストが不足している場合、ADD_MISSING の指摘を出力します
• カバレッジ率を上げることだけを目的としたテストは推奨しません
• コンプライアンススコア（X/10）を算出します

入力

必ず読み込むこと： references/audit_worker_core_contract.md と references/mcp_tool_preferences.md を読み込みます。 ツールポリシー：ホストの AGENTS.md が対象範囲外となる独立したサブエージェントとして実行される場合があるため、ファイルの読み取り、検索、編集にはまず hex-line MCP を使用します。MCP の動作が不明な場合に限り、references/mcp_integration_patterns.md を読み込みます。

以下を含む contextStore を受け取ります：tech_stack、testFilesMetadata、codebase_root、output_dir。

ドメイン対応： domain_mode と current_domain をサポートします（audit_output_schema.md#domain-aware-worker-output を参照）。

ホットスポットによってカバレッジ不足の発見が大きく改善される場合は、まず hex-graph を使用します。利用可能な場合は、ローカルコードとテストの読み取りにはまず hex-line を使用します。MCP が利用できない、対応していない、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash を使用して続行し、レポートにフォールバックしたことを記載します。

ワークフロー

検出ポリシー：2 層の検出（候補のスキャン、その後のコンテキスト検証）を使用します。検証方法が曖昧な場合に限り、references/two_layer_detection.md を読み込みます。

1. コンテキストを解析 -- フィールドを抽出し、scan_path を決定します（指定があればドメイン対応） ELSE: scan_path = codebase_root domain_name = null

2. scan_path 内の重要なローカルロジックを特定します（コードベース全体ではありません）

   • scan_path 内の本番コードをスキャンし、金融／認証／権限／データ／アルゴリズム／ドメインルールに関するキーワードを探します
   • すべての Grep/Glob パターンでは、codebase_root ではなく scan_path を使用します
   • 例：Grep(pattern="payment|refund|discount", path=scan_path)

3. 重要な各処理経路のテストカバレッジを確認（レイヤー 1）

   • すべてのテストファイルを検索してカバレッジを確認します（テストは本番コードとは別の場所にある場合があります）
   • 関数名、モジュール名、またはテストの説明を照合します 3b) コンテキスト分析（レイヤー 2 -- 必須）： 不足候補ごとに、以下を確認します。
   • この関数はすでに E2E／統合テストでカバーされていますか？ -> LOW に引き下げ
   • この関数は、テスト済みのコードから呼び出される 10 行未満のヘルパー関数ですか？ -> スキップ
   • キーワードの一致は誤検出ですか（例：paymentIcon() は UI であり、決済ロジックではない）？ -> スキップ

4. 不足しているテストを収集

   • ドメイン対応の場合、各指摘に domain: domain_name のタグを付けます
   • 確認済みの各指摘について、action: "ADD_MISSING" を設定します

5. スコアを算出： 重大度別に違反数を数え、コンプライアンススコア（X/10）を算出します

6. レポートを作成： references/templates/audit_worker_report_template.md に従って完全な Markdown レポートをメモリ上に構築し、単一の Write 呼び出しで {output_dir}/ln-634--{identifier}.md（またはドメイン対応の場合は {output_dir}/ln-634--{identifier}.md）に書き込みます

7. 概要を返す： 最小限の概要をコーディネーターに返します（出力形式を参照）

重要なローカルロジックの分類

1. 金銭の流れ（優先度 20 以上）

対象： 金融取引を処理するコード

例：

• 決済処理（/payment、processPayment()）
• 割引／プロモーション（calculateDiscount()、applyPromoCode()）
• 税額計算（calculateTax()、getTaxRate()）
• 返金（processRefund()、/refund）
• 請求書／請求処理（generateInvoice()、createBill()）
• 通貨換算（convertCurrency()）

最小優先度： 20

重要な理由： 金銭的損失、不正、法令遵守

2. 認証と権限（優先度 20 以上）

内容： ローカルの認証、認可、権限、セキュリティに関する判断

例：

• ログイン／ログアウト（/login、authenticate()）
• トークンの更新（/refresh-token、refreshAccessToken()）
• パスワードのリセット（/forgot-password、resetPassword()）
• 権限／RBAC（checkPermission()、hasRole()）
• 暗号化／ハッシュ化（カスタムの暗号処理のオーケストレーションまたはポリシー。bcrypt/argon2 などのライブラリの動作は対象外）
• API キーの検証（validateApiKey()）

最小優先度： 20

重要な理由： セキュリティ侵害、データ漏えい、不正アクセス

3. データ整合性（優先度 15 以上）

内容： CRUD 操作、トランザクション、検証

例：

• 重要な CRUD（createUser()、deleteOrder()、updateProduct()）
• データベーストランザクション（withTransaction()）
• データ検証（カスタムバリデーター。フレームワークのデフォルトは対象外）
• データ移行（runMigration()）
• 一意制約（checkDuplicateEmail()）

最小優先度： 15

重要な理由： データの破損、データの損失、一貫性のない状態

4. アルゴリズムとドメインルール（優先度 15 以上）

内容： ローカルでの計算、分岐ルール、状態遷移、およびプロジェクト固有の動作を定めるアルゴリズム

例：

• ランキング／スコアリングアルゴリズム
• 適格性ルール
• ドメインの状態遷移
• フレームワークのデフォルトを超えるカスタム検証ルール
• インポート／エクスポートの変換

最小優先度： 15

重要な理由： 製品の誤った動作、不適切な判断、ビジネス状態の破損

監査ルール

1. 重要なローカルロジックを特定する

手順：

• 金銭関連のキーワードをコードベース内で検索します：payment、refund、discount、tax、price、currency
• 認証／権限関連のキーワードを検索します：auth、login、password、token、permission、role、policy
• データ関連のキーワードを検索します：transaction、validation、migration、constraint
• アルゴリズム／ドメインルール関連のキーワードを検索します：score、rank、eligibility、state、workflow、rule
• フレームワークのデフォルト、生成された動作、ライブラリのプリミティブは除外します。既存テストにおける製品とプラットフォームのテスト対象の判断は ln-631 が担います

2. テストカバレッジを確認する

各クリティカルパスについて：

• 対応するテスト名／説明をテストファイル内で検索します
• テストが見つからない場合 -> 不足テストのリストに追加します
• テストが見つかっても不十分な場合（成功ケースのみで、エッジケースがない） -> ギャップのリストに追加します

3. ギャップを分類する

優先度に応じた重大度：

• CRITICAL： 優先度 20 以上（金銭、セキュリティ）
• HIGH： 優先度 15～19（データ、コアフロー）
• MEDIUM： 優先度 10～14（重要だがクリティカルではない）
• 引き下げ条件： 関数が E2E テストで既にカバーされている場合は LOW。テスト済みコードから呼び出される 10 行未満のヘルパーはスキップします

4. 根拠を示す

不足しているテストごとに：

• 重要な理由（金銭的損失、セキュリティ侵害など）を説明します
• テストの種類（E2E、統合、単体）を提案します
• アクションを ADD_MISSING に設定します
• 工数を見積もります（S/M/L）

スコアリングアルゴリズム

必読： references/audit_scoring.md を読み込みます。

優先度に応じた重大度の割り当て：

• 優先度 20 以上（金銭、セキュリティ）でテストが不足 -> CRITICAL
• 優先度 15～19（データ整合性、コアフロー）でテストが不足 -> HIGH
• 優先度 10～14（重要）でテストが不足 -> MEDIUM
• 優先度 10 未満（あると望ましい） -> LOW

出力形式

必ずお読みください： references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON サマリーを記述してください。管理モードでは、呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、ワーカーが共有コントラクトに従って、実行スコープの成果物パスを生成します。

{output_dir}/ln-634--{identifier}.md（グローバル）または {output_dir}/ln-634--{identifier}.md（ドメイン対応）に、category: "Critical Logic Coverage" および以下のチェック項目を含むレポートを記述してください：money_logic_coverage、auth_permission_coverage、data_integrity_coverage、algorithm_domain_rule_coverage。

references/audit_summary_contract.md に従ってサマリーを返してください。

summaryArtifactPath がない場合は、スタンドアロンの実行時サマリーを .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json に記述し、必要に応じて構造化出力にも同じサマリーを出力してください。

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/ln-634--{identifier}.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

重要なルール

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• ドメイン対応スキャン： domain_mode="domain-aware" の場合、scan_path の本番コードのみをスキャンしてください（コードベース全体は対象外です）。
• 検出結果へのタグ付け： ドメイン対応の場合、各検出結果に domain フィールドを含めてください。
• テスト検索の範囲： カバレッジを確認するため、すべてのテストファイルを検索してください（テストは本番コードとは別の場所にある場合があります）。
• 名前で照合： 関数名、モジュール名、またはテストの説明を使って、テストと本番コードを照合してください。
• 自動修正しない： 報告のみを行ってください。
• 独自の観点： 独自のローカルな重要ロジックに対するテストの不足のみを検出してください。既存の価値の低いテスト、E2E ジャーニーの優先度、信頼性、オラクルの強度、手動の証拠、構造は評価しないでください。
• カバレッジ率に関する作業は禁止： 行カバレッジや分岐カバレッジの指標を改善することだけを目的に、テストを推奨しないでください。
• 必須アクション： すべての検出結果で action: "ADD_MISSING" を使用してください。

完了の定義

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• contextStore が正常に解析されている（output_dir、domain_mode、current_domain を含む）
• scan_path が特定されている（ドメインのパスまたはコードベースのルート）
• scan_path 内の重要なローカルロジックが特定されている（金銭、認証／権限、データ整合性、アルゴリズム、ドメインルール）
• 重要なローカルロジックの各パスについて、テストカバレッジが確認されている
• 重要度、優先度、正当性、ドメイン、および ADD_MISSING アクションを含む不足テストが収集されている
• ペナルティアルゴリズムを使ってスコアが計算されている
• {output_dir}/ln-634--{identifier}.md または ln-634--{identifier}.md にレポートが記述されている（単一の Write 呼び出しでアトミックに実行）
• コントラクトに従ってサマリーが記述されている

参照ファイル

• 監査出力スキーマ： references/audit_output_schema.md

---

バージョン： 3.0.0 最終更新日： 2025-12-23