db-orchestrator

db-orchestrator（レイヤー 2）

監査全体を調整します。3 つのフェーズで構成されます：detect → dispatch → synthesize。スコアは 2 つあり、決して混合しません。

1. Detect

1. 対象を解決します（プロジェクトディレクトリ、または平易な言葉による説明）。
2. stack-detect（scripts/detect-stack.mjs をラップします）を実行します。stacks 配列を取得します。各要素には paradigm、engine、orm、platform、source_of_truth、confidence が含まれます。
3. 結果が空の場合は、/claude-db:start（ウィザード）または説明モードにルーティングします。エンジンを決して推測しません。
4. ユーザーが Tier-1 を選択している場合は、ランタイムに依存するチェックが established に到達できるよう、introspect（読み取り専用）を実行します。そうでない場合、これらのチェックは needs_api を返します。

2. Dispatch（並列、読み取り専用）

各スタックについて、読み取り専用の監査サブエージェントを並列で起動します。つまり、複数の Task 呼び出しを含むメッセージを 1 つ送信し、冗長な中間出力を分離したままにします。（context: fork は Task のパラメーターではありません。複数の Task 呼び出しを 1 つのメッセージで発行することで並列処理を実現します。）各エージェントには source_of_truth の場所／内容、パラダイム、エンジン／プラットフォーム、割り当てられたモジュールを渡します。非アクティブなパラダイムの監査エージェントは起動しません（そのモジュールは検出結果を出さず、分母にも含まれません）。

• schema-integrity-auditor → M1–M10（モデリング、キー、参照整合性、型、制約、デフォルト、命名、時間関連、マルチテナンシー、セキュリティ／RLS）。常時実行（リレーショナル）。NoSQL の場合は、パラダイムに応じたサブセットを実行します。
• performance-scale-auditor → M11–M18（インデックス、衛生状態、クエリパターン、並行性、プーリング、パーティショニング、レプリカ／ビュー、ストレージ／肥大化）。常時実行します。
• nosql-paradigm-auditor → M19（NoSQL のアンチパターン）＋アクセスパターンとの適合性。document / key-value / wide-column の場合のみ。
• specialized-platform-auditor → M20（ベクトル／時系列／グラフ／検索）、M21（プラットフォーム適合性）、M0（設計モードでのエンジン選択の推奨）。ベクトル／TS／グラフ／検索、およびすべてのプラットフォームチェックで実行します。
• migration-safety-auditor → M22（マイグレーションの lint）。マイグレーションファイルが対象範囲にある場合（/claude-db:migrate、またはマイグレーションディレクトリが存在する場合の監査）。

各サブエージェントは、schema/finding.schema.json に準拠する検出結果の JSON 配列を返します。監査エージェントは読み取り専用で、使用できるツールは Read, Grep, Glob, Bash, WebFetch のみです。監査によってファイルが変更されることはありません。M19／M20 の検出結果は出所を示すために module ID を保持しますが、スコアリング時には該当する自然なモジュールのカテゴリを継承します。

3. Synthesize

1. すべての検出結果を統合し、id で重複を排除します（最も重大度の高いステータスを保持：fail > warn > needs_api > pass > not_applicable）。
2. パラダイムに合わせてスタックごとにスコアを算出します。

   node scripts/score.mjs --findings <merged.json> --paradigm <paradigm>
   

   複数ストアの場合は、各スタックのスコアを算出してから、軸ごとに全ストアのうち最も低いスコアを集計します（design = min over stores、performance も同様）。スコアの下限を決めたストアを示します（例：「Design 58 — redis-cache により下限が設定されています」）。
3. レポートを出力します（バンド／解釈は references/scoring-model.md を参照）。
   • ヘッダー： Design & Integrity のバンド／スコアと Performance & Scale のバンド／スコア。それぞれに score.mjs の 1 行の解釈を付けます。スコアが capped:true の場合は、value と上限適用前の computed の両方を示し、上限の原因となった重大度 5 の fail を明記します。
   • 軸ごとのカテゴリーテーブル（各スコアにつき 1 つ）：カテゴリ、重み、値、active?。非アクティブなカテゴリはその旨を示し、分母から再正規化して除外します。
   • 信頼度の行： 到達したティア（0/1/2）＋両軸の needs_api の合計数。needs_api のチェックを pass として提示してはいけません。
   • 優先順位付けされたアクション： 検出結果を severity × magnitude ÷ effort で並べ替えます（magnitude は high|medium|low の区分で示し、架空の % は使いません）。各項目に status、severity、evidence.observed（実際の DDL／クエリ。シークレットはマスキング）、verification.reproduce、recommendation、fixability（auto/proposed/advisory）、expected_impact（軸＋信頼度＋magnitude）を含めます。
   • フッター： 「安全で元に戻せるマイグレーションを適用するには /claude-db:fix を実行してください。変更はそれぞれ確認できます。」

平易な表現の説明（初心者向け）

技術レポートに加えて、平易な言葉で短く要約してください。2つのスコアが何を意味するのか、それぞれ1文で説明してください（「設計はしっかりしていますが、まだ負荷には耐えられません」）。専門用語を使わず、最初に修正すべき上位3項目を示してください。また、needs_api の意味も説明してください（「これらを確認するには、読み取り専用の接続が必要です」）。専門的な詳細は残し、人に伝わる説明を加えてください。どちらか一方で、もう一方を置き換えないでください。

注意事項

• このスキルの出力は簡潔にしてください。価値があるのは統合されたレポートであり、説明文ではありません。
• 誠実さを守ってください。統計値、レイテンシ、スループット、行数、価格を捏造しないでください。ライブ DB が必要な場合は needs_api を使用してください。デフォルトでは読み取り専用とし、推測に基づく指摘で上限を設定しないでください。
• ユーザーの言語（EN/ES）で回答してください。