musubix2 0.3.6 → 0.3.7

package/.github/copilot-instructions.md

@@ -30,10 +30,55 @@ TypeScript / Node.js 20+ / ESM のモノレポ構成で、25 パッケージを
 | Article VIII | ADR 記録 | design-generator |
 | Article IX | 品質ゲート | test-engineer |
 
-## SDD ワークフロー（5フェーズ）
+## ⚠️ SDD ワークフロー強制ルール（不可侵）
+
+**機能追加・変更・拡張の依頼を受けた場合、以下のフェーズを順守すること。**
+**いかなる理由があっても Phase をスキップして実装を開始してはならない。**
+
+```
+Phase 1: Requirements（要件定義）
+    → ユーザーレビュー → 承認 ⏸️
+Phase 2: Design（設計）
+    → ユーザーレビュー → 承認 ⏸️
+Phase 3: Task Breakdown（タスク分解）
+    → ユーザーレビュー → 承認 ⏸️
+Phase 4: Implementation（実装）
+    → テスト → 品質ゲート
+Phase 5: Complete
+```
+
+### 禁止事項
+
+1. **要件定義なしの実装開始は禁止**。ユーザーが「実装して」と言っても、まず要件を確認する
+2. **設計なしのコード生成は禁止**。要件が承認されるまで設計に進まない
+3. **タスク分解なしの実装は禁止**。設計が承認されるまでタスク分解に進まない
+4. **レビューなしの Phase 遷移は禁止**。各 Phase の成果物はユーザーに提示し、承認を得る
+
+### タスク分類と適用フロー
+
+| 種別 | 適用フロー |
+|------|-----------|
+| **機能追加・変更** | Phase 1 → 2 → 3 → 4 → 5（フル SDD） |
+| **バグ修正** | 問題分析 → 修正 → テスト（簡易フロー） |
+| **ドキュメント修正** | 直接修正 |
+| **設定・運用変更** | 直接修正 |
+
+### ワークフロー強制の判定基準
 
 ```
-Phase 1: Requirements → Phase 2: Design → Phase 3: Tasks → Phase 4: Implementation → Phase 5: Complete
+ユーザーからの依頼を受信
+    │
+    ├── 新機能・機能変更・機能拡張？
+    │   └── YES → Phase 1（要件定義）から開始。実装に直行しない。
+    │
+    ├── バグ修正？
+    │   └── YES → 問題分析 → 修正 → テスト
+    │
+    ├── ドキュメント・設定変更？
+    │   └── YES → 直接修正
+    │
+    └── 不明？
+        └── ユーザーに確認してから判断
 ```
 
 - **Phase 遷移には前フェーズの承認が必須**（REQ-SDD-002a/b/c）

package/.github/skills/orchestrator/SKILL.md

@@ -38,6 +38,68 @@ SDD（Specification Driven Development）ワークフローのルーティング
 - `steering/` を参照済みであること（Article VI: プロジェクトメモリ）
 - 対象プロジェクトに SDD ワークフローが適用されていること
 
+## ⚠️ ワークフロー強制ルール（不可侵）
+
+**機能追加・変更・拡張の依頼に対して、実装を直接開始することは禁止である。**
+**必ず以下の順序を守り、各 Phase でユーザーの承認を得ること。**
+
+### 強制フロー
+
+```
+1. 要件定義（Phase 1）
+   └── requirements-analyst で EARS 要件を作成
+   └── 情報不足の場合は RequirementsInterviewer で 1問1答ヒアリング
+   └── ユーザーに要件定義書を提示 → レビュー → ⏸️ 承認待ち
+
+2. 設計（Phase 2）
+   └── design-generator で設計書を生成
+   └── SOLID / C4 / ADR を含む
+   └── ユーザーに設計書を提示 → レビュー → ⏸️ 承認待ち
+
+3. タスク分解（Phase 3）
+   └── 設計書からタスクを分解（TASK-XXX-NNN 形式）
+   └── 依存関係 DAG を生成
+   └── ユーザーにタスク一覧を提示 → レビュー → ⏸️ 承認待ち
+
+4. 実装（Phase 4）
+   └── タスク順に Red → Green → Blue サイクルで実装
+   └── 各タスク完了後にテスト実行
+
+5. 完了（Phase 5）
+   └── 全品質ゲート通過を確認
+```
+
+### 実装直行の判定と阻止
+
+```
+ユーザー: 「〇〇を実装して」「〇〇を追加して」「〇〇を作って」
+    │
+    ├── Phase 1 の要件定義書が存在する？
+    │   ├── NO → 「まず要件を定義します」 → Phase 1 開始
+    │   └── YES → 承認済み？
+    │       ├── NO → 「要件のレビューが必要です」 → レビュー依頼
+    │       └── YES → Phase 2 チェックへ
+    │
+    ├── Phase 2 の設計書が存在し承認済み？
+    │   ├── NO → 「設計を行います」 → Phase 2 開始
+    │   └── YES → Phase 3 チェックへ
+    │
+    ├── Phase 3 のタスク分解が存在し承認済み？
+    │   ├── NO → 「タスクを分解します」 → Phase 3 開始
+    │   └── YES → Phase 4（実装開始許可）
+    │
+    └── 全 Phase 承認済み → 実装開始
+```
+
+### 例外（フル SDD を適用しないケース）
+
+| 種別 | フロー |
+|------|--------|
+| バグ修正 | 問題分析 → 修正 → テスト |
+| ドキュメント修正 | 直接修正 |
+| 設定変更・バージョンバンプ | 直接修正 |
+| リファクタリング（動作変更なし） | テスト確認 → 修正 → テスト |
+
 ## ルーティングルール
 
 ### WHEN/DO マッピング