stack-detect

stack-detect（フェーズ 1 — 検出）

プロジェクトを 1 つ以上の { paradigm, engine, orm, platform, source_of_truth, confidence, files } スタックに分類します。これはすべての監査の確定的な入口です。スコアラーが再正規化する パラダイムプロファイル（scripts/score.mjs → PROFILES）と、各監査ツールが実行するモジュールセットを選択します。

実行すること

1. 対象ディレクトリを解決します（$ARGUMENTS のパス、それ以外の場合はプロジェクトのルート／cwd）。

2. 検出ツールを実行し、JSON の標準出力を読み取ります。

   node scripts/detect-stack.mjs --dir "<dir>"
   

   { stacks: [...], files_scanned } が返されます。編集や再実装は絶対にしないでください。これはテスト済みの基盤です。

3. stacks が空の場合 → オフラインで監査できるものはありません。エンジンを推測してはいけません。ユーザーを /claude-db:start（ガイド付きウィザード）に案内するか、想定しているデータベースを平易な言葉で説明してもらいます。検出ツールの hint をそのまま提示します。

正準ソースの優先順位（references/detection-signals.md を参照）

複数のソースが同じデータベースについて記述している場合、優先順位は次のとおりです。

1. Tier 1 のライブイントロスペクション（introspect スキル経由）— どのファイルよりも優先します。
2. 宣言的／生成されたアーティファクト — schema.prisma、Drizzle *_snapshot.json、structure.sql、schema.rb、生成されたマイグレーション SQL → confidence: established。
3. マイグレーション SQL → ORM のプログラムソースより優先します。
4. ORM のプログラムソース（schema.ts、models.py、Mongoose/CDK）→ confidence: directional。

プログラムソースから解析された directional スタックは、重大度 5 の上限を引き上げることはありません。生成されたアーティファクトまたは Tier 1 の利用を促すものです。宣言的アーティファクトと ORM ソースの内容が一致しない場合、これはスキーマドリフトであり、db-migration-safety（M22）が担当します。

スタックごとに出力するルーティング

検出された各スタックについて、オーケストレーターに必要なルーティングを出力します。

• paradigm → score.mjs のプロファイルと --paradigm フラグ（relational | document | key-value | wide-column | vector | time-series | graph）を選択します。
• module set → M0 のエンジン選択（推奨、スコア対象外）と、そのパラダイムのプロファイルモジュールに絞り込んだ M1..M22。スコア対象の所見を出力しないカテゴリは非アクティブになります。たとえば、ドキュメントストアが外部キーの欠如によって減点されることはありません。
• source_of_truth + confidence → 各所見に引き継がれる解析信頼度の上限（Tier 0(a) は信頼性あり、Tier 0(b) はベストエフォート）を示します。

マルチストア

すべてのスタックを返します（例：プライマリの Postgres ＋ Redis キャッシュ）。オーケストレーターは各スタックを監査し、それぞれ固有の --paradigm でスコアを算出します。各軸について、ストア間で最も低いスコアを集計し、そのスコアを決定したストアの名前を示します（references/scoring-model.md → マルチストア集計を参照）。

出力

生の stacks 配列、スタックごとのルーティング（パラダイムプロファイル ＋ モジュールセット）、および正準ソースの優先順位に関する注記を出力します。説明は簡潔にしてください。ユーザーの言語（EN/ES）で回答します。