ln-54-codebase-auditor

コードベース監査

目標： 本番コードを対象に、広範な読み取り専用の健全性監査を実施します。検出器の一致結果や個人的なスタイルの好みを指摘事項にせず、複数領域にまたがる具体的な障害、セキュリティ、デリバリー、保守性のリスクを特定します。ドキュメントの信頼性、テストポートフォリオ、アーキテクチャ全体、永続化に特化したレビューの代わりにはなりません。

実行契約： チェックリストの各項目を、観測した結果の証拠を伴う PROVEN、条件が存在しないことを示す証拠を伴う CLEARED、または不足がある UNPROVEN として追跡します。読み取り、委任、ツールの失敗、終了ステータス 0、自己申告の成功は証明になりません。各セクションの後に整合性を確認し、回答を返す前にすべての PENDING を解消し、PROVEN と CLEARED のみを集計して、すべての不足に判定と承認のルールを適用します。 意図、スコープ、モード、既存の承認を維持します。必要な外部承認の前に、承認済みの作業を完了します。重大な未解決の選択肢のみを確認します。回答できる人がいない場合、正確な質問を報告し、待機や推測はせず、このスキルの不足時の判定を適用します。作業を妨げる指示と未解決の境界を引用し、承認の関門を捏造しません。重大なリスクに応じて調査の深さを調整しつつ、必須チェック、依存関係、安全な順序を維持し、検証方法を選択します。 ユーザーまたはリポジトリから得られた同等の証拠を受け入れ、別のスキル、指定された成果物、またはライフサイクル全体を必須にしません。元の要件と判断 ID を維持します。証拠を再利用する場合は、関連するバージョン、未コミットの変更、構成、環境、観測期間に紐付け、影響を受ける主張のみを無効にします。 成果と明示的な選択に基づいて、主要なワークフローを選択します。隣接する契約や有効な証拠を取り込み、所有範囲の重複や監査のやり直しを避けます。複数の成果物がある場合は、スキルの呼び出しを必須にせず、スコープごとに分けます。広範で独立した評価には監査ワークフローを使用し、対象を絞ったドメインレビューは読み取り専用のままにします。 継続時には、タスク、承認、状態、不足を再確認します。長時間の作業では簡潔な継続記録を返すか、すでに承認済みの成果物を更新します。読み取り専用のスキルでは、その記録を永続化しません。成果物の準備状況、検証済みの動作、外部アクションの権限を区別します。 適用される要件を、その正式な所有者、計画中または実装済みの変更、受け入れ証拠、ステータスに紐付け、既存の成果物または回答に記載します。新しい台帳は不要です。明示された制約は、承認済みの逸脱がない限り拘束力を保ちます。リスクは優先順位を決めますが、制約を無視する許可にはなりません。 最初に指定されたファイルだけでなく、因果関係の流れを調査します。実装権限の範囲内で、目的の達成に必要な構造上の修正を含めます。変更行数ではなく、全体の複雑さとリスクを最小化します。これにより、レビュー中の無関係なクリーンアップや変更が許可されるわけではありません。 情報を取得する前に、証拠で答えるべき問いを定義します。適用される指示を省略せず、必要な情報を選択的に読み取ります。機械的な処理にはツールを使い、範囲を限定した結果、エラー、カバレッジ、ソースのパスを要約します。完全な出力はコンテキストの外に保ちます。 技術的な判断の前に、適用可能性と実際のバージョンを確認します。バージョン依存の前提は、公式ドキュメントまたは仕様で検証します。最新の外部推奨事項については、一次情報のページを検索して読みます。スニペットは証拠になりません。バージョンが一致した同梱ドキュメント、または有効な過去の証拠があれば十分です。判断、バージョン、情報源、制約を記録します。入手できない証拠は UNVERIFIED とし、それに依存する必須作業のみを停止します。標準機能を優先し、追加のツールや抽象化は証拠に基づいて正当化し、既存のルールの所有者を再利用します。

ツールの振り分け

必要な作業	優先するツール	使用する場面	代替手段
リポジトリの構成把握と技術スタックの検出	ネイティブのファイル一覧表示、マニフェスト、ビルドファイル、リポジトリの指示書	対象範囲、生成物の領域、エントリーポイント、サポート対象のランタイム、コマンドを把握するとき	対象を絞ったツリーの確認と既知のエントリーポイント
シンボル、呼び出し元、所有関係、データフロー	言語サーバーまたはホストネイティブのコードインテリジェンス	シンボルの同一性、参照、オーバーライド、ルートの接続、ファイルをまたぐ動作が調査結果に関わるとき	対象を絞ったテキスト検索と、該当するすべての一致箇所の直接確認
現在の変更と過去の経緯	Git のステータス、差分、ログ、blame	現在の作業、リグレッション、意図された制約、不要になった互換性維持用のコードを切り分けるとき	現在の実装と明示的な意思決定記録
提供準備状況	リポジトリで定義されたビルド、lint、型チェック、テスト、スモークテストのコマンド	プロジェクトを文書化された環境でリリースできるか確認するとき	CI とスクリプトを確認し、実行できない場合はその旨を記録
依存関係とセキュリティの状態	ネイティブのパッケージマネージャーによる監査、マニフェスト、ロックファイル、公式アドバイザリ	既知の脆弱性、サポート対象外のバージョン、依存関係の健全性を確認するとき	公式レジストリとベンダーの情報源を使用し、深刻度を推測しない
ランタイムのエビデンス	既存のログ、メトリクス、トレース、プロファイル、診断情報	静的解析では頻度、到達可能性、運用上の影響を判断できないとき	静的解析のみであるという制約を明記した呼び出し経路の分析
外部の現在の動作	公式仕様、ベンダーのドキュメント、リリースノート	現在の API、ランタイム、標準の動作が調査結果に関わるとき	一次情報を用いたウェブ調査。それ以外の場合は UNVERIFIED と記録

まず概要レベルで調査し、範囲を絞ってから詳しく確認してください。リポジトリで定義されたコマンド、または明らかに安全な診断コマンドのみを実行してください。監査中に、公開、デプロイ、本番データの移行、シークレットのローテーション、ファイルの書き換えを行ってはいけません。

ワークフローの境界

このワークフローが担当するのは、読み取り専用の横断的な調査結果です。技術的な契約の修正は、基盤エンジニアリングが許可を得たうえで担当します。監査の依頼は、調査結果を修正するために実装ワークフローを実行する許可にはなりません。

エビデンスのルール

• パターンに一致した箇所は候補であり、調査結果ではありません。到達可能性、コンテキスト、結果を確認してください。
• ランタイムエラーや再現性のあるコマンド出力は、静的解析上の疑いより優先されます。実行できず、その制約を明記する場合は、静的エビデンスも有効です。
• 生成コード、ベンダー提供コード、フィクスチャ、マイグレーション履歴、意図的に互換性を維持しているコードは、それぞれのコンテキストに応じて扱ってください。
• 外部のベストプラクティスは、リポジトリにある具体的な欠陥またはリスクに対処する場合に限り、実行可能なものとします。
• 原因が異なる調査結果のみを採点または集計してください。同じ修正で対処できる症状は重複として除外してください。

チェックリスト

1. 対象範囲とベースラインを確立する

• 言語、フレームワーク、パッケージマネージャー、エントリーポイント、デプロイモデル、生成物の領域、リポジトリでサポートされている検証コマンドを特定します。
• プローブ、テレメトリー、シグナル処理、終了処理を求める前に、各ランタイムの対象を、長時間稼働するサービス、CLI、ライブラリ、ジョブ、サーバーレス関数、プラットフォーム管理コンポーネントのいずれかに分類します。
• 該当する指示を読み、セキュリティ境界、重要なビジネスパス、公開インターフェイス、取り消し不能な操作を特定します。
• Git の状態を確認し、監査によって無関係なユーザー変更を上書きしたり、誤って関連付けたり、見落としたりしないようにします。
• 実行可能なビルド、lint、型チェック、テスト、スモークテストのベースラインを確立し、実行範囲、環境、終了ステータス、エビデンスを記録します。選択されたテストがない、またはゲートがスキップされたまま成功していないことを確認し、必要な作業が実行されたことを確かめます。
• すべてのファイルを同じ労力でスキャンするのではなく、リスクに応じて除外対象と調査の深さを定めます。
• 監査は読み取り専用で行います。許可されているキャッシュとビルド成果物のみを作成し、作成した場合はその旨を明記します。

2. セキュリティとデリバリー境界を監査する

• コミット済みのシークレット、安全でない認証情報のパターン、機密性の高いデフォルト設定、デバッグ用のバイパス、ログやエラーを通じた意図しない情報漏えいを検索します。

• 認証情報に関する検出結果では、値そのものを決して公開しないでください。実際に使用可能な情報と、プレースホルダー、テスト用データ、サンプル、許可リストに登録されたフィンガープリントを区別し、種類、場所、マスキングした証拠のみを報告します。監査中に実行せず、実際の漏えいが確認された場合に限り、失効、ローテーション、履歴の修正を推奨します。

• 信頼できない入力が、SQL、シェル、テンプレート、HTML、ファイルパス、URL、デシリアライズ、リダイレクト、その他のインジェクションの影響を受けやすい出力先に到達する経路を追跡します。

• 認証、認可、テナントまたは所有者ごとの分離、権限の移行、安全でない直接オブジェクト参照、デフォルト拒否の動作を確認します。

• 信頼境界での検証、正規化、サイズとレートの制限、安全でないファイル操作、破壊的操作の確認またはガードを確認します。

• 重要度を割り当てる前に、実際の呼び出し経路、フレームワークの動作、設定、最新の公式ガイダンスに照らしてセキュリティ上の検出結果を検証します。

• コンパイラー、リンター、型チェッカー、テスト、パッケージング、CI の設定を調査し、ゲートのスキップ、失敗の無視、環境の差異、再現不能なデリバリーを確認します。

• パッケージングの成功によって、意図したエントリーポイント、アセット、メタデータ、対象プラットフォーム、デプロイ可能なアーティファクトが生成されることを検証します。終了コードがゼロであることだけでは、出荷可能なビルドであるとは証明できません。

• 必須のシグナルを成功しているように見せる、古いスキップ、隔離、失敗許容、エラー時の続行、警告抑制の経路を特定します。

• 設定の網羅性、必須の環境検証、安全でないフォールバック、欠落しているサンプル、ローカル、CI、デプロイ環境の設定の違いを確認します。

• エンジニアリングの強制適用： 該当する技術ルールを、実行可能なチェック、対象となる技術やファイル、厳格さ、文書化された例外に対応付けます。不足しているチェックや効果のないチェックと、その実装担当者を特定し、必須のプリセットと警告ポリシーを維持します。証拠は設定が存在することではなく、実際のコマンドとサポート対象の環境に結び付けます。読み取り専用のワークフローでは、ギャップを報告し、修正は行いません。ガイダンスのみのワークフローでは、制御策を説明し、実行や実装は行いません。

3. 保守性と依存関係の監査

• 関数、ハンドラー、モジュール、設定、統合コード全体で、根拠のある重複を見つけます。共有されるドメイン概念と、偶然の類似を区別します。
• 過剰な抽象化、未使用の拡張ポイント、過剰なファクトリーやラッパー、並行する仕組み、宣言済みのプラットフォーム機能を重複して実装するカスタムユーティリティを特定します。
• 重複を統合したり、抽象化を削除したりする前に、ライフサイクルと所有権の境界、意図的な疎結合、依存性注入やテスト用の接点、フレームワーク要件、公開された拡張契約、独立して進化することが想定されているかを確認します。
• 複雑さが集中している箇所、長いメソッド、巨大なモジュール、深いネスト、過剰なパラメーター、真偽値でモードを切り替える API、誤解を招く名前、責務の混在を調べます。
• アルゴリズムについて、早期終了の誤り、重複キーによるデータ損失、境界の誤り、処理量の上限がないこと、スキャンの繰り返し、反復中の変更、隠れた共有状態を確認します。
• 明示的な設定や名前付きポリシーにすべき、ハードコードされた運用値、URL、タイムアウト、上限、識別子、環境固有の動作を確認します。
• 外部契約、DTO、サービス、永続化、ストレージにわたって、ある概念の扱いを追跡します。明示的なシリアライザー、コード生成、ORM の境界マッピングで説明できない場合に限り、同義語の使用や大文字・小文字の不一致を指摘します。
• 依存関係の脆弱性、サポート状況、ライセンスやランタイムの制約、重複パッケージ、未使用パッケージ、妥当な置き換えまたは削除の機会を監査します。
• アドバイザリを解決済みのバージョンとデプロイ環境に照らし合わせ、到達可能性と悪用条件に基づいて、影響を「確認済み」「不明」「該当なし」に分類します。呼び出し経路が利用できないことだけを理由に、影響を受けるコンポーネントを対象外としてはなりません。
• ネイティブ機能、既存の依存関係、外部の代替手段を推奨するのは、必要な機能の同等性、移行の範囲、保守状況、ライセンス、セキュリティ履歴、ドメイン固有の動作を確認した後に限ります。
• 到達不能なコード、未使用のインポートやエクスポート、コメントアウトされた実装、古くなったフラグ、不要になった互換性シム、後継コードの横に残された置き換え前のコードを見つけます。
• 削除が安全だと報告する前に、リフレクション、登録、フレームワークによる検出、設定、シリアライズ、テンプレート、外部エントリーポイントを確認し、不要なコードという指摘を裏付けます。

4. 監査の診断可能性、並行処理、ライフサイクル

• ログが構造化され、適切なレベルで記録され、対応可能な内容を含み、リクエストやジョブをまたいで関連付けられ、機密情報や過剰なペイロードデータを含まないことを確認します。
• 相関コンテキストが、最初のリクエストログだけに存在するのではなく、外部への呼び出し、キュー、再試行、スケジュールされた処理、分離された非同期処理の境界を越えて引き継がれることを確認します。
• 重要な経路について、メトリクス、トレース、ヘルスシグナル、エラーコンテキストを確認します。オペレーターが障害を検出または診断する必要がある箇所に限って、可観測性を求めます。
• 到達可能な並行処理経路における共有可変状態、ロックの取得順序、原子性、非同期タスクの所有権、キャンセル、再試行、競合が発生する時間帯を追跡します。
• await または yield の発生箇所をまたぐ読み取り・変更・書き込みを調査し、共有ファイル、サブプロセス、ターミナルや OS のリソース、繰り返されるユーザートリガーについて、リソースとアクセス元のタイムラインを作成します。現在のプロセス外のアクセス元も含めます。
• 非同期経路でのブロッキング I/O や同期的な待機、上限のない並行処理、孤立したタスク、デッドロック、TOCTOU の危険、スレッドセーフでないリソースを確認します。
• 起動順序、依存関係の準備完了、設定の検証、即時終了の動作、シグナル処理、正常なシャットダウン、処理中の作業の完了を確認します。
• 起動時と実行時に取得されるリソースを一覧にし、成功、失敗、タイムアウト、キャンセル、シャットダウンシグナルの繰り返しにおいて、それぞれが依存関係の安全な逆順で冪等にクリーンアップされることを確認します。
• ホスト固有のプローブの意味を確認します。ライブネスの失敗は再起動の妥当性を示すものであり、レディネスはトラフィックを受け入れる条件を決め、スタートアップチェックは初期化を保護します。依存関係をきっかけとする再起動の連鎖や、大きな負荷または副作用を引き起こすプローブは避けます。

5. 指摘事項の検証と報告

• 指摘事項の判断を変え得る場合に限り、外部 API、標準、脆弱性、実行時の動作を調査し、該当バージョンに一致する公式情報源を使用します。
• 指摘候補を確定する前に、フレームワークの慣例、生成コード、範囲が限定された管理用経路、テスト、例、文書化されたトレードオフを除外します。
• 可能な限り、安全なコマンド、テスト、最小限の呼び出しトレース、または完全な静的障害経路を使って、重大度の高い問題を再現します。
• 重要度の基準を適用します。適用可能な、受け入れ済みのルールへの違反、または具体的な障害、セキュリティ、デリバリー、運用性への影響、もしくは証拠で裏付けられた規模で繰り返し発生する保守上の影響を立証できることを求めます。好み、理論上の純粋さ、一般論としての慣行、仮定上の規模、妥当な代替案は指摘対象から除外します。望ましい実装ではなく、結果または制約を必須条件とします。
• 外部情報による修正の根拠： 外部情報に基づく修正は、バージョンが一致する公式仕様を根拠とし、未解決のトレードオフについては、一次のエンジニアリング情報源を使用します。根拠となる仕組みを引用します。ローカルな不具合については、ローカルの証拠で十分です。
• 採用する指摘事項ごとに、範囲が限定された担当機能と、観測可能な修正の証拠を特定し、監査をやり直したり、無関係なクリーンアップを承認したりせずに修正を進められるようにします。
• 悪用可能性、データや可用性への影響、デリバリーの阻害、再発性、修正の緊急性に基づき、指摘事項を P0～P3 に分類します。
• ファイル順や検出器の分類ではなく、リスク低減と依存関係に基づいて修正の順序を決めます。
• 信頼できる代替手段を使っても、必要な安全環境、高リスクの動作、権威ある仕様を検証できない場合は BLOCKED を使用します。証拠によって裏付けられた未解決の P0/P1、必須のデリバリーゲートの失敗、または実証された危険な動作がある場合は FAIL を使用します。検証済みだがブロック要因にならないリスクには CONCERNS のみを使用し、必要なチェックが完了し、重要な指摘事項がない場合に限って PASS を使用します。

セルフチェック

• 返答前に照合してください。 項目単位の証拠、要件の網羅性、矛盾、スコープ、判定、該当するクリーンアップを確認してください。報告内容または許可された成果物を修正してください。有効な証拠は再利用し、リポジトリを自動的に再スキャンしたり、成功済みのコマンドを再実行したりしないでください。関連する変更、失敗、または未解決の証拠がある場合に限り、確認を繰り返してください。残っている不足事項を明示してください。

出力仕様

ユーザーの言語で、以下の順序で報告してください。5つのフィールドすべてにラベルを付け、各事実は一度だけ記載してください。統制された平易な表現を使い、1文につき1つの事実を述べ、通常は20語未満にしてください。能動態を使い、判定、ID、状態にはそれぞれ一つの用語を使い、同義語は使わないでください。簡潔な結果はフィールドごとに1行で記載できます。空の表は省略し、リンク先の成果物を転載しないでください。

1. 結果： スキル固有の正確な判定トークンを最初に記し、次に裏付けのある結果を記載してください。
2. スコープ： 確認・変更した範囲、除外項目、ベースライン、重要な前提を記載してください。
3. 証拠： 以下のスキル固有のフィールドを記載してください。事実、推論、未検証の主張を区別してください。成果物にはリンクを付け、必要に応じて表を使ってください。
4. 検証： 確認内容と結果、入手できない証拠、該当するクリーンアップ／外部状態を記載してください。
5. 完了： Checklist: X/Y complete と記載してください。Incomplete: None、または各 UNPROVEN 項目について、理由、結果への影響、具体的な次のアクションを記載してください。残存リスクと必要な判断も記載してください。

スキル固有の証拠： セキュリティ、デリバリー、保守性／依存関係、診断可能性、並行処理、ライフサイクルに関する証拠。指摘事項には、優先度、場所、発生条件または障害経路、確度、重大な影響、許容できないトレードオフ、最小限の修正と見込み工数を含めてください。同等に有効な解決策も認めてください。修正は検出数ではなく、前提条件とリスク低減の順に並べてください。