L2 技術基盤生成コマンド
<tri_ssd_context>
Tri-SSD（Tri-Layer Slice Spec Driven）はAI/LLMコードエージェントを前提とした仕様駆動開発。
レイヤー構造:
- L1: ビジョン・要求（docs/l1_vision.md）
- L2: 技術基盤（docs/l2_system/）- foundation.md, phases.md, rules.md
- L3: 機能仕様（docs/l3_features/F-xxx.md）
ID形式: PREFIX-YYYYMMDD-nnn（REQ, PH, F, NF）
ステータス: draft → reviewed → implemented（L3のみ）
</tri_ssd_context>
概要
L1（ビジョン・要求）から L2 技術基盤（foundation.md）を生成する。
技術選定はユーザーとの対話を通じて行う。
注: フェーズ定義・機能一覧は /gen-phases で生成する（技術基盤確定後）。
生成時の原則
<avoid_over_engineering>
- 直接要求されたか、明確に必要な技術選定のみ行う
- シンプルな技術スタックを優先する（複雑な構成は避ける）
- 要件の規模に見合った技術を選定する（個人プロジェクトにエンタープライズ構成は不要）
- 「将来必要になるかも」で技術を追加しない
</avoid_over_engineering>
引数
REQ-xxxx ...: 対象のREQ ID（省略時は全REQ）
前提処理
templates/l2_foundation.md を読み込み、技術基盤テンプレートを確認docs/l1_vision.md を読み込み、要件を把握するdocs/l2_system/foundation.md が存在するか確認（再生成モード判定）
再生成モード（既存ファイルがある場合）
既存の foundation.md がある場合は再生成モードで動作する。
保持するもの（上書きしない）
| セクション | 理由 |
|---|
| 採用しなかった選択肢 | 過去の検討結果は資産 |
| 更新・変更管理の履歴 | 変更の経緯を保持 |
| ユーザーが追記したメモ・注釈 | 手動編集を尊重 |
更新するもの
| セクション | 条件 |
|---|
| 技術スタック | L1変更または明示的な変更要求時 |
| アーキテクチャ | 技術スタック変更に伴う場合 |
| NFRカタログ | L1のNFR変更時 |
| セキュリティ/エラー/ログ方針 | 技術スタック変更に伴う場合 |
再生成時の手順
- 既存ファイルを読み込み、各セクションの内容を把握
- L1との差分を分析
- ユーザーに「何を更新するか」を確認
- 保持セクションはそのまま、更新セクションのみ再生成
- 変更履歴セクションに今回の変更を追記
生成手順
Step 1: L1分析
- 要件を把握
- 用語集の抽出
- セキュリティ・非機能要件の抽出
Step 2: 技術選定（対話型）
WebSearchで以下のカテゴリの候補を最低3個ずつ並列で検索:
- フレームワーク（フロント/バック）
- データベース
- 認証方式
- インフラ/デプロイ先
<thinking_process>
技術選定の判断時は、以下の形式で思考を整理してから結論を出す：
- 要件の確認: L1で求められている規模・性能・セキュリティレベル
- 候補の評価: 各候補の長所・短所をL1要件に照らして評価
- チーム適合性: ユーザーの技術スタック経験を考慮
- 判断: 最もシンプルかつ要件を満たす選択肢を推奨
</thinking_process>
ユーザーに選択肢を提示し、対話を通じて選択してもらう。
重要: 技術選定はこのコマンドで確定させる。フェーズ計画は技術が決まってから行う。
Step 3: アーキテクチャ設計
以下を定義:
- コンポーネント構成図（ASCII図）
- レイヤ構造（UI/Application/Domain/Infrastructure）
- モジュール間依存関係
- ディレクトリ構成（プロジェクト構造）
Step 4: セキュリティ方針策定
以下を定義:
- 認証・認可: 認証方式、セッション管理、認可モデル（RBAC等）
- データ保護: 通信暗号化、保存データ暗号化、認証情報ハッシュ
- 脆弱性対策: XSS、CSRF、SQLi等への対策方針
Step 5: エラーハンドリング方針策定
以下を定義:
- エラー分類: バリデーション/認証/ビジネスルール/システムエラー
- レスポンス形式: 統一エラーレスポンス構造
- エラーコード体系: プレフィックスと採番ルール
Step 6: ログ・監視方針策定
以下を定義:
- ログレベル: ERROR/WARN/INFO/DEBUG の使い分け
- ログ出力方針: いつ何を出力するか
- 監視項目: エラー率、レスポンス時間、リソース使用率
Step 7: 開発環境要件定義
以下を定義:
- 必須ツール: 言語ランタイム、コンテナ、バージョン管理等
- 環境構築手順: クローンから起動までのステップ
- 外部サービス依存: 開発環境での代替方法
Step 8: NFRカタログ作成
- 性能、セキュリティ、可用性等を具体化
- NFR IDはNF-YYYYMMDD-nnn形式で採番
- 優先度（Must/Should/Could/Won't）を設定
ID採番ロジック
L2 ID
- 現在日時を取得: YYYYMMDD
- 既存L2 IDを検索（Grepで docs/**/*.md から）
- 同日の最大連番 + 1 で新ID生成
非機能要求ID（NF）
- 現在日時を取得: YYYYMMDD
- 既存NF IDを検索（Grepで docs/**/*.md から）
- 同日の最大連番 + 1 で新ID生成
出力ファイル
| モード | ファイル |
|---|
| 通常 | docs/l2_system/foundation.md |
生成時の注意
- セキュリティ方針はL1の要件レベルに応じて調整（個人プロジェクトとエンタープライズで異なる）
- エラーコード体系は一度決めたら変更コストが高いため慎重に
- 開発環境要件は「新メンバーが1時間以内に環境構築できる」を目標に
完了後の案内
- 生成ファイルのパスを報告
/gen-phases でフェーズ定義・機能一覧を生成することを案内/draft-rules で実装ルールを生成することを案内/check で整合性チェックを案内