architectural-analysis

アーキテクチャ分析

依頼された範囲を監査し、具体的な設計上の問題を報告します。監査のみの場合は読み取り専用です。既存の明示的な調査結果の適用許可に、修正が含まれる場合があります。設計を評価する際は、プロジェクトの境界と公開互換性ポリシーに従ってください。

1. 依頼とコンテキストから対象範囲を特定します。rg --files、対象を絞った rg 検索、利用可能な静的解析の出力を使って、エントリーポイントと関連する依存関係をマッピングします。ソースファイルごとに個別の TODO を作成したり、TypeScript のスタックだと決めつけたりしないでください。
2. シグナルに優先順位を付けます。デッドエクスポート、責務の重複、循環、所有権や型の混同、変更コストの高いパターンを確認します。候補を分類する際は、references/detection-catalog.md の該当セクションを読んでください。しきい値は手掛かりであり、自動的に不具合と判断するものではありません。
3. コードがデッドだと判断する前に、動的読み込み、リフレクション、フレームワークのフック、テスト、公開 API も含めて使用状況を追跡します。このチェックアウト内に利用者がいないという理由だけで、参照されていない公開エクスポートを安全に削除できるとは限りません。
4. 重要な指摘はそれぞれソースで確認します。挙動または保守コストを説明し、パスと行番号を示し、不確実性を明記したうえで、最小限かつ有用な変更を提案します。根拠が増えない場合は、一般的なコードスメルの洗い出しを別途行わないでください。
5. レポートの分量は依頼に合わせます。広範な監査では、assets/report-template.md を柔軟なアウトラインとして使い、.audits/architectural-analysis-<timestamp>.md に保存します。調査した範囲と未調査の範囲を区別してください。狭い範囲への回答なら、簡潔な指摘リストで十分です。未調査の範囲を None found と報告してはいけません。
6. 重要な指摘とその根拠を要約します。既存のソースと要約用テンプレートは任意の提示補助であり、両方のレポートが必須というわけではありません。