ln-633-test-value-auditor

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

Portfolio Value Auditor（L3 ワーカー）

タイプ： L3 ワーカー

各テストのポートフォリオ価値と保守コストを算出する、専門ワーカーです。

目的と範囲

• ポートフォリオ価値（カテゴリー 3：最優先）を監査します
• 価値スコア = 影響度 × 発生確率を算出し、一意性、回帰履歴、保守コストに基づいて調整します
• 正式な KEEP、DELETE、MERGE、REWRITE の判断を行います
• 準拠スコア（X/10）を算出します

入力

必ず読み込むこと： references/audit_worker_core_contract.md を読み込みます。

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

ワークフロー

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

1. コンテキストの解析： contextStore から技術スタック、影響度／発生確率のマトリックス、テストファイル一覧、output_dir を抽出します
2. スコアの算出（レイヤー 1）： 各テストについて、価値スコア = 影響度 × 発生確率を算出し、重複カバレッジ、既知の回帰防止、保守コストを注記します 2b) コンテキスト分析（レイヤー 2 -- 必須）： DELETE または MERGE の判断を確定する前に、次の点を確認します。
   • 過去の既知のバグに対する回帰防止テストですか？ -> スコアに関係なく KEEP
   • スコアが <10 でも、重要なビジネスルール（決済、認証）を対象にしたテストですか？ -> アサーションが弱い場合は、DELETE ではなく REWRITE
   • 重要なフローのエッジケースを対象にする唯一のテストですか？ -> KEEP
   • より明確なアサーションまたは低いコストで同じ動作を検証する別のテストがありますか？ -> MERGE
3. 判断の分類： KEEP、DELETE、MERGE、または REWRITE
4. 指摘事項の収集： 各 REVIEW/REMOVE 判断について、重大度、場所（file:line）、作業量の見積もり（S/M/L）、推奨事項を記録します
5. スコアの算出： 重大度別に違反件数を数え、準拠スコア（X/10）を算出します
6. レポートの作成： references/templates/audit_worker_report_template.md に従って完全な Markdown レポートをメモリ上に構築し、単一の Write 呼び出しで {output_dir}/ln-633--global.md に書き込みます
7. 概要の返却： コーディネーターに最小限の概要を返します（出力形式を参照）

有用性スコアの計算

計算式

Usefulness Score = Business Impact (1-5) x Failure Probability (1-5)

影響度のスコアリング（1-5）

スコア	影響度	例
5	致命的	金銭的損失、セキュリティ侵害、データ破損
4	高	主要なフローが機能しない（チェックアウト、ログイン、登録）
3	中	機能の一部が動作しない、UX の低下
2	低	軽微な UX の問題、見た目上のバグ
1	ごくわずか	見た目上の問題、ユーザーへの影響なし

発生確率のスコアリング（1-5）

スコア	発生確率	指標
5	非常に高い	複雑なアルゴリズム、新しい技術、多数の依存関係
4	高い	複数の依存関係、並行処理、エッジケース
3	中	標準的な CRUD、フレームワークのデフォルト設定、確立されたパターン
2	低い	単純なロジック、広く使われているライブラリ、単純な操作
1	非常に低い	単純な代入、フレームワークによる生成、壊れる可能性がない

判断のしきい値

スコア範囲	判断	対応
>=15	KEEP	テストには価値があるため、維持します
10-14	REWRITE	アサーションによって固有の製品リスクを証明できる場合に限り、維持します
<10	DELETE	保守コストに見合わないため、テストを削除します。例外： 既知のバグに対する回帰防止テストは -> KEEP

スコアリング例

例 1：決済処理のテスト

Test: "processPayment calculates discount correctly"
Impact: 5 (Critical -- money calculation)
Probability: 4 (High -- complex algorithm, multiple payment gateways)
Usefulness Score = 5 x 4 = 20
Decision: KEEP

例 2：メールアドレス検証のテスト

Test: "validateEmail returns true for valid email"
Impact: 2 (Low -- minor UX issue if broken)
Probability: 2 (Low -- simple regex, well-tested library)
Usefulness Score = 2 x 2 = 4
Decision: DELETE (likely already covered by E2E registration test)

例 3：ログインフローのテスト

Test: "login with valid credentials returns JWT"
Impact: 4 (High -- core flow)
Probability: 3 (Medium -- standard auth flow)
Usefulness Score = 4 x 3 = 12
Decision: REWRITE (if E2E covers the flow, merge/delete duplicate assertions; otherwise focus assertions on auth behavior)

監査ルール

1. 各テストのスコアを算出する

手順：

• テストファイルを読み込み、テスト名／説明を抽出します
• テスト対象コード（CUT）を分析します
• 影響度（1-5）を判定します
• 発生確率（1-5）を判定します
• 有用性スコアを算出します

2. 判定の分類

KEEP:

• 価値の高いテスト (金銭、セキュリティ、データ整合性)
• コアフロー (チェックアウト、ログイン)
• 複雑なアルゴリズム

MERGE:

• 同じ振る舞いを証明する重複したテスト
• 1 つのシナリオに統合すべき断片化されたアサーション
• 見た目のアサーションの違いだけの繰り返しセットアップ

REWRITE:

• アサーションが弱い中価値のテスト
• より明確なプロダクトリスクのオラクルが必要なテスト

DELETE:

• 低価値のテスト (見た目のみ、些細なもの)
• E2E テストの重複

3. パターンの特定

よくある低価値テスト:

• 些細な getter/setter のテスト
• 定数値のテスト
• 型アノテーションのテスト
• 重複したセットアップ/アサーションのバリエーション
• 保守コストが信頼性の価値を上回るテスト

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

必読: references/audit_scoring.md をロードしてください。

Value Score による重大度マッピング:

• スコア <5 -> CRITICAL (テストが多大な保守工数を浪費している)
• スコア 5-9 -> HIGH (テストが無駄である可能性が高い)
• スコア 10-14 -> MEDIUM (レビューが必要)
• スコア >=15 -> 問題なし (KEEP)

出力形式

必読: references/templates/audit_worker_report_template.md をロードしてください。

references/audit_summary_contract.md に従って JSON サマリーを書いてください。マネージドモードでは呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、ワーカーは共有契約に従って自身の run スコープのアーティファクトパスを生成します。

レポートを {output_dir}/ln-633--global.md に category: "Portfolio Value" とチェック項目: value_score、delete_candidates、merge_candidates、rewrite_candidates を付けて書いてください。Findings には正規の action を KEEP、DELETE、MERGE、REWRITE のいずれかとして含める必要があります。

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-633--global.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

Note: KEEP 判定のテストは findings ではなく、保持されたエビデンスとして要約されます。Findings には DELETE、MERGE、REWRITE の判定のみが含まれます。

重要なルール

すでにロード済みの references/audit_worker_core_contract.md を適用してください。

• 自動修正しない: レポートのみ
• 独自の観点: 最終的なポートフォリオ価値の判定を担います。プラットフォーム挙動の検出、クリティカルカバレッジの発見、分離、オラクル強度、構造チェックを重複させないでください。
• 工数の現実性: S = <1h、M = 1-4h、L = >4h
• スコアの客観性: Impact と Probability は仮定ではなくコード分析に基づいてください
• KEEP テストは報告しない: findings には DELETE、MERGE、REWRITE の判定のみが現れます
• E2E とのクロスリファレンス: REVIEW の判定は E2E がすでにそのシナリオをカバーしているかどうかに依存します

完了の定義

すでにロード済みの references/audit_worker_core_contract.md を適用してください。

• contextStore が正常にパースされた (output_dir を含む)
• 各テストの Value Score が算出された (Impact x Probability に加え、一意性、リグレッション、保守コンテキスト)
• 判定が分類された: KEEP、DELETE、MERGE、REWRITE
• Findings が重大度、場所、工数、推奨、アクションを伴って収集された
• ペナルティアルゴリズムを使用してスコアが算出された
• レポートが {output_dir}/ln-633--global.md に書かれた (アトミックな単一 Write 呼び出し)
• サマリーが契約に従って書かれた

参照ファイル

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

---

Version: 3.0.0 Last Updated: 2025-12-23