phasegate 0.15.0

package/skills/environment-designer/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: environment-designer
+description: ローカル開発環境のプラットフォーム構成設計。コードと環境のブリッジ（AIDLC Step 2.2並行）
+model: sonnet
+review: opus
+---
+
+# Environment Designer
+
+論理設計のコンポーネントをローカル開発環境で動作させるために必要なプラットフォーム構成を設計するスキル。
+
+**「コードの正しさ」と「環境の正しさ」のブリッジ**として機能する。
+
+## 前提条件チェック
+
+### 必須インプット（存在しなければ`[Question]`で提供を要求）
+- **ドメインモデル** — DBスキーマの根拠
+- **横断論理設計** — 各層のコンポーネント構成
+
+### 任意インプット（あれば参照）
+- **技術スタック概要** — 各層の技術選定
+- **既存の設定ファイル** — 現在の構成を理解
+
+---
+
+## ⚠️ 上位レイヤー存在チェック
+
+**このスキルは AIDLC Step 2.2並行「環境設計」に対応します。実行前に上位設計の存在を確認してください。**
+
+### 依存する上位設計文書
+
+| ファイル | 必須 | チェック方法 |
+|---------|------|------------|
+| `docs/product/construction/{unit}/domain_model.md` | ✅ 必須 | 少なくとも1つのUnitのドメインモデル存在を確認 |
+| `docs/product/construction/{unit}/logical_design.md` | ✅ 必須 | 少なくとも1つのUnitの論理設計存在を確認 |
+
+### 上位設計が存在しない場合のアクション
+
+上位設計文書が存在しない場合、**設計を開始せず**、以下を行う：
+
+1. **状況報告** — ユーザーに不足している設計文書を明示
+2. **選択肢提示** — 以下の選択肢を提示
+   - 上位設計（domain-designer, logical-designer）を先に実行する
+   - 上位設計をスキップして進める（非推奨）
+3. **ユーザー指示待ち** — 独自判断で設計を開始しない
+
+**報告テンプレート:**
+```markdown
+## ⚠️ 上位レイヤー設計が見つかりません
+
+以下の設計文書が存在しないため、環境設計を開始できません：
+- `docs/product/construction/*/domain_model.md` ❌ 未作成
+- `docs/product/construction/*/logical_design.md` ❌ 未作成
+
+### 推奨アクション
+まず `domain-designer` でドメインモデルを、次に `logical-designer` で論理設計を作成してください。
+
+### 選択肢
+1. **上位設計を先に実行する**（推奨）
+2. **このまま進める**（上位設計なしで進める場合、整合性リスクあり）
+
+どちらを選択しますか？
+```
+
+---
+
+## ⚠️ 3フェーズ実行ルール
+
+**このスキルは3フェーズで実行する。**
+- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
+- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`scripts/delegate-sonnet.sh` 経由）
+- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
+
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+
+---
+
+## Phase 1: 計画（plan）
+
+### 目的
+環境設計のスコープ・技術スタック確認・不明点を整理し、人間の承認を得る。
+
+### 出力ファイル
+`docs/inception/_shared/environment_design_plan.md`
+
+### 計画ファイルの構成
+
+```markdown
+# 環境設計計画
+
+## 1. スコープ
+- 対象コンポーネント一覧（論理設計から抽出）
+
+## 2. 技術スタック確認
+| レイヤー | 技術 | 確認状況 |
+|---------|------|---------|
+
+## 3. 設計セクション方針
+- 各セクション（マイグレーション台帳、サービス構成、認証、シード、制約集、検証チェックリスト）の方針
+
+## 4. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+
+## 5. 前提条件・リスク
+- ...
+```
+
+### Phase 1 完了条件
+- 計画ファイルを出力した
+- 技術スタックが不明な場合は`[Question]`で確認した
+- **人間にボールを渡した**
+- **成果物（environment_contract.md）はまだ作成していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1の計画を承認した
+- QAセクションの全[Question]に[Answer]が記入されている（QAがある場合）
+
+### ワークフロー
+
+1. **マイグレーション台帳** — スキーマ変更の累積リスト
+2. **サービス構成マニフェスト** — 各サービス/関数の設定ファイル登録要件
+3. **認証・認可アーキテクチャ** — 認証方式、トークン検証、ローカル環境の制約
+4. **シードデータ定義** — 3層戦略（マスター/認証テスト/業務サンプル）
+5. **フレームワーク・ランタイム制約集** — 既知の制約ルール
+6. **環境検証チェックリスト** — セットアップ後の機械的検証手順
+
+### Phase 2 最低出力基準（Sonnet委任時の品質制約）
+
+以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
+
+| 基準 | 最低要件 |
+|------|---------|
+| マイグレーション台帳 | 論理設計のDB層で定義された全テーブルに対応するエントリがあること |
+| サービス構成 | 論理設計の全サービス/関数が設定ファイル要件として列挙されていること |
+| 認証アーキテクチャ | 認証方式・トークン検証・ローカル環境制約が記載されていること |
+| シードデータ | 3層戦略（マスター/認証テスト/業務サンプル）が定義されていること |
+| 制約集 | 既知のフレームワーク・ランタイム制約が列挙されていること |
+| 検証チェックリスト | セットアップ後の機械的検証手順が記載されていること |
+
+### 出力ファイル
+
+| 種別 | 配置先 |
+|------|--------|
+| 成果物 | `docs/product/environment_contract.md` |
+
+---
+
+---
+
+## Phase 3: レビュー（Opus review）
+
+### 実行主体
+メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+
+### レビュー手順
+1. Sonnetが出力したファイルを読み込む
+2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+3. **スキル固有レビュー観点**を検証する
+4. 判定結果を出力する
+
+### スキル固有レビュー観点（BLOCK基準）
+- [ ] 論理設計のDB層定義と環境設計のマイグレーション台帳が整合しているか
+- [ ] サービス構成が論理設計のコンポーネント構成と一致しているか
+- [ ] 検証チェックリストが実行可能な具体的手順か（曖昧な指示がないか）
+- [ ] シードデータが3層戦略で分離されているか
+- [ ] フレームワーク制約が具体的な回避方法を含んでいるか
+
+### 判定と修正
+- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
+- **WARNのみFAIL** → Opusが直接修正してから完了とする
+- **全PASS** → 完了
+
+## 更新タイミング
+
+- **新ストーリー実装時:** マイグレーション台帳・サービス構成に追記
+- **新フレームワーク制約発見時:** 制約集に追記（`cascade-updater`経由）
+- **環境セットアップ手順変更時:** 検証チェックリストを更新

package/skills/implementation-planner/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: implementation-planner
+description: "Unit仕様とドメインモデル設計を元に実装計画を立てる。ストーリーIDや機能名から関連Unitを特定し、API設計・レイヤー別実装方針を整理してmdファイルで出力する。使用タイミング: 実装計画を立てて、US-XXXの実装方針を決めて、この機能の設計を整理して、など実装前の計画策定時。"
+model: sonnet
+review: opus
+---
+
+# Implementation Planner
+
+UnitドキュメントとConstructionのドメインモデル設計を元に、**設計フェーズの実装計画**を体系的に立案する。
+
+## ⚠️ `story-implementor` との役割分担
+
+| 観点 | `implementation-planner`（本スキル） | `story-implementor` |
+|------|-------------------------------------|---------------------|
+| **目的** | 設計段階で実装方針を整理・合意する | TDD実装を実行する |
+| **タイミング** | 論理設計の前後（設計の方向性確認） | テスト設計・カバレッジ検証の後 |
+| **出力** | 実装計画書（API設計・レイヤー別方針） | TDD実装計画 → 実装コード |
+| **テスト設計** | 参照しない（設計フェーズのため） | 必須（テスト設計完了が前提） |
+
+**使い分けの指針:**
+- 「この機能どう実装する？」→ `implementation-planner`
+- 「テスト設計も終わった、TDD実装を始めたい」→ `story-implementor`
+
+## ⚠️ 3フェーズ実行ルール
+
+**このスキルは3フェーズで実行する。**
+- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
+- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`scripts/delegate-sonnet.sh` 経由）
+- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
+
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+
+---
+
+## ワークフロー
+
+```
+入力解析 → Unit特定 → ドメインモデル確認 → 既存実装確認 → 計画作成 → 出力
+```
+
+### Step 1: 入力解析
+
+ユーザー入力から抽出:
+- ストーリーID（US-XXX形式）
+- 機能名・タスク説明
+- 優先度・制約条件
+
+### Step 2: Unit特定
+
+1. `docs/product/units/integration_contract.md`を読み込み
+2. 関連する公開APIエンドポイントを特定
+3. 該当Unitの`{unit}.md`を確認
+4. Unit間依存関係を整理
+
+**検索方法:**
+- Grep/Globツールを使用して `docs/product/units/` 配下からストーリーIDやキーワードを検索する
+- `integration_contract.md` から関連する公開APIエンドポイントを特定する
+
+### Step 3: ドメインモデル確認
+
+1. `docs/product/construction/{context}/domain_model.md`を読み込み
+2. 以下を把握:
+   - 集約と不変条件
+   - エンティティ・値オブジェクト
+   - ドメインイベント
+   - 状態遷移
+3. 必要に応じて`shared_kernel/domain_model.md`を参照
+
+### Step 4: 既存実装確認
+
+- Glob/Readツールを使用してプロジェクトの実装ディレクトリ構造を確認する
+- 既存の実装パターンを検索し、コードスタイル・ファイル配置を把握する
+
+### Step 5: 計画作成
+
+[references/plan-template.md](references/plan-template.md)のフォーマットに従って:
+1. API設計（新規/既存拡張）
+2. レイヤー別実装内容
+3. 実装ステップ分解
+4. 影響範囲特定
+
+### Step 6: 出力
+
+計画をmdファイルとして出力。パスの推奨:
+```
+docs/inception/{task_id}_plan.md
+```
+
+**[Question][Answer]セクション必須**: 不明点や確認事項をまとめ、ユーザーからのフィードバックを受け取れるようにする。
+
+---
+
+## 参照ドキュメント
+
+| ファイル | 用途 |
+|----------|------|
+| `docs/product/units/integration_contract.md` | Unit間API定義・依存関係 |
+| `docs/product/units/{unit}.md` | ユーザーストーリー・機能要件 |
+| `docs/product/construction/{context}/domain_model.md` | ドメインモデル設計 |
+
+**詳細は以下を参照:**
+- [document-structure.md](references/document-structure.md): ドキュメント構造リファレンス
+- [workflow.md](references/workflow.md): 詳細ワークフロー
+- [plan-template.md](references/plan-template.md): 出力テンプレート
+
+---
+
+## Unit一覧（クイックリファレンス）
+
+実行時に `docs/product/units/` 配下のUnit定義ファイルを動的に読み取ること。ハードコードしない。
+
+---
+
+### Phase 2 最低出力基準（Sonnet委任時の品質制約）
+
+以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
+
+| 基準 | 最低要件 |
+|------|---------|
+| Unit特定 | 対象ストーリー/機能に関連するUnitが正しく特定されていること |
+| ドメインモデル参照 | 関連する集約・エンティティ・値オブジェクトが列挙されていること |
+| API設計 | 新規/既存拡張のエンドポイントが具体的に定義されていること |
+| レイヤー別実装内容 | 各層（Domain/UseCase/Controller/Infrastructure）の実装内容が記載されていること |
+| 実装ステップ | 実装順序が具体的なステップに分解されていること |
+| 影響範囲 | 変更が他Unit・他コンポーネントに与える影響が分析されていること |
+| QAセクション | 不明点・確認事項が[Question][Answer]形式で記載されていること |
+
+---
+
+## Phase 3: レビュー（Opus review）
+
+### 実行主体
+メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+
+### レビュー手順
+1. Sonnetが出力したファイルを読み込む
+2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+3. **スキル固有レビュー観点**を検証する
+4. 判定結果を出力する
+
+### スキル固有レビュー観点（BLOCK基準）
+- [ ] 対象Unit/ドメインモデルの特定が正確か
+- [ ] API設計が統合契約と整合しているか
+- [ ] レイヤー間の依存方向が正しいか（Domain → Port → UseCase → Controller）
+- [ ] 実装ステップの順序が論理的か（依存関係に沿っているか）
+- [ ] 影響範囲の分析が漏れなく行われているか
+
+### 判定と修正
+- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
+- **WARNのみFAIL** → Opusが直接修正してから完了とする
+- **全PASS** → 完了
+
+## コードベース構成（クイックリファレンス）
+
+実行時にプロジェクトのディレクトリ構造を動的に確認すること。ハードコードしない。

package/skills/implementation-planner/references/document-structure.md

@@ -0,0 +1,116 @@
+# ドキュメント構造リファレンス
+
+## Units ドキュメント (`docs/product/units/`)
+
+各Unitは境界づけられたコンテキストを表す。
+
+| ファイル | 内容 |
+|----------|------|
+| `integration_contract.md` | Unit間連携API定義・技術スタック・依存関係図 |
+| `{unit}_unit.md` | ユーザーストーリー・機能要件・外部依存 |
+
+### integration_contract.md の構造
+
+```
+- 技術スタック概要（Auth/Gateway/API Server/DB/Worker/UI/Realtime）
+- ユニット間依存関係図（Mermaid）
+- 公開APIエンドポイント定義（各Unit）
+- 共通データフォーマット
+- 認証・認可
+```
+
+### Unit一覧
+
+| Unit | 責務 |
+|------|------|
+| IAM Unit | 認証・JWT発行・ユーザー情報 |
+| Admin Unit | ユーザー・チーム管理・権限付与 |
+| Client Unit | クライアント（BPO委託元企業）管理 |
+| Knowledge Unit | クライアントごとの業務ナレッジ管理 |
+| Partner Master Unit | 取引先マスタ管理 |
+| Workflow Dashboard Unit | プロセス一覧・状態管理 |
+| Estimate Unit | 見積書作成プロセス管理（コアドメイン） |
+| Audit Unit | 監査ログ記録・閲覧 |
+
+---
+
+## ドメインモデル (`docs/product/construction/`)
+
+各境界づけられたコンテキストのドメイン設計。
+
+### ディレクトリ構成
+
+```
+docs/product/construction/
+├── {context}/domain_model.md    # 各コンテキストのドメインモデル
+├── shared_kernel/domain_model.md # 共有カーネル
+├── architecture_image.md         # アーキテクチャ図
+└── flow_image.md                 # フロー図
+```
+
+### domain_model.md の構造
+
+```
+1. コンテキスト概要
+   - 境界づけられたコンテキスト
+   - ユビキタス言語
+   - コンテキストマップ
+
+2. 集約 (Aggregates)
+   - 集約ルート定義
+   - 不変条件
+   - 状態遷移図
+
+3. エンティティ (Entities)
+
+4. 値オブジェクト (Value Objects)
+
+5. ドメインイベント (Domain Events)
+
+6. ポリシー (Policies)
+
+7. リポジトリ (Repositories)
+
+8. ドメインサービス (Domain Services)
+
+9. クラス図（Mermaid）
+
+10. イベントソーシング実装（該当する場合）
+```
+
+---
+
+## コードベース構成
+
+### functions/ (API Server - Cloud Run)
+
+```
+functions/
+├── src/
+│   ├── model/           # ドメインモデル層
+│   ├── usecase/         # ユースケース層
+│   ├── port/            # ポートインターフェース
+│   ├── controller/      # コントローラー層
+│   ├── gateway/         # 外部通信ゲートウェイ
+│   └── infrastructure/  # インフラ層
+└── tests/               # テスト
+```
+
+### hosting/ (Frontend - React)
+
+```
+hosting/
+├── src/
+│   ├── pages/           # ページコンポーネント
+│   ├── components/      # 共通コンポーネント
+│   ├── hooks/           # カスタムフック
+│   └── api/             # API通信
+└── tests/               # テスト
+```
+
+### supabase/ (Edge Functions)
+
+```
+supabase/
+└── functions/           # Edge Functions
+```

package/skills/implementation-planner/references/plan-template.md

@@ -0,0 +1,177 @@
+# 実装計画テンプレート
+
+以下のフォーマットで計画ファイルを出力する。
+
+---
+
+```markdown
+# 実装計画: {タスク名}
+
+生成日時: {YYYY-MM-DD HH:mm}
+ステータス: DRAFT / REVIEWING / APPROVED
+
+---
+
+## 1. 概要
+
+### 1.1 実装目的
+{何を実現するか、ビジネス価値}
+
+### 1.2 対象ユーザーストーリー
+| ID | ストーリー | 優先度 |
+|----|-----------|--------|
+| US-XXX | ... | MVP/後続 |
+
+---
+
+## 2. 関連Unit分析
+
+### 2.1 プライマリUnit
+{メインで影響を受けるUnit}
+
+### 2.2 依存Unit
+| Unit名 | 依存タイプ | 理由 |
+|--------|-----------|------|
+| ... | 参照/イベント発行/API呼び出し | ... |
+
+### 2.3 公開APIエンドポイント
+| Method | Endpoint | 用途 | 新規/既存 |
+|--------|----------|------|----------|
+| ... | ... | ... | ... |
+
+---
+
+## 3. ドメインモデル設計
+
+### 3.1 集約
+{対象となる集約とその変更内容}
+
+### 3.2 エンティティ・値オブジェクト
+{新規追加または変更が必要なもの}
+
+### 3.3 ドメインイベント
+| イベント名 | トリガー | ペイロード |
+|-----------|---------|-----------|
+| ... | ... | ... |
+
+### 3.4 ドメインサービス
+{必要な場合のみ}
+
+---
+
+## 4. レイヤー別実装方針
+
+### 4.1 Model層
+```
+対象ファイル:
+- functions/src/model/{context}/...
+
+実装内容:
+- ...
+```
+
+### 4.2 UseCase層
+```
+対象ファイル:
+- functions/src/usecase/{context}/...
+
+実装内容:
+- ...
+```
+
+### 4.3 Port層
+```
+対象ファイル:
+- functions/src/port/{context}/...
+
+実装内容:
+- ...
+```
+
+### 4.4 Controller層
+```
+対象ファイル:
+- functions/src/controller/{context}/...
+
+実装内容:
+- ...
+```
+
+### 4.5 Repository層
+```
+対象ファイル:
+- functions/src/infrastructure/repository/...
+
+実装内容:
+- ...
+```
+
+### 4.6 Frontend (必要な場合)
+```
+対象ファイル:
+- hosting/src/pages/...
+- hosting/src/components/...
+
+実装内容:
+- ...
+```
+
+---
+
+## 5. 実装ステップ
+
+### Phase 1: ドメインモデル実装
+- [ ] Step 1.1: {具体的なタスク}
+- [ ] Step 1.2: {具体的なタスク}
+
+### Phase 2: UseCase実装
+- [ ] Step 2.1: {具体的なタスク}
+- [ ] Step 2.2: {具体的なタスク}
+
+### Phase 3: API実装
+- [ ] Step 3.1: {具体的なタスク}
+- [ ] Step 3.2: {具体的なタスク}
+
+### Phase 4: テスト
+- [ ] Step 4.1: ユニットテスト作成
+- [ ] Step 4.2: 統合テスト作成
+
+---
+
+## 6. 影響範囲と考慮事項
+
+### 6.1 既存コードへの影響
+{変更が必要な既存コード}
+
+### 6.2 マイグレーション
+{DBスキーマ変更がある場合}
+
+### 6.3 リスクと対策
+| リスク | 影響度 | 対策 |
+|--------|-------|------|
+| ... | 高/中/低 | ... |
+
+---
+
+## 7. [Question][Answer]
+
+### 未解決の質問
+
+**Q1: {質問内容}**
+> A1: {回答待ち / 回答内容}
+
+**Q2: {質問内容}**
+> A2: {回答待ち / 回答内容}
+
+### 追加情報リクエスト
+- {必要な追加情報1}
+- {必要な追加情報2}
+
+---
+
+## 変更履歴
+
+| 日付 | 変更者 | 内容 |
+|-----|-------|------|
+| YYYY-MM-DD | AI | 初版作成 |
+```