phasegate 0.15.0

package/docs/guide/layer-model.md

@@ -0,0 +1,170 @@
+# 5-Layer Defense Model (L0-L4)
+
+Phasegate enforces quality through 5 layers that run at different points in the development lifecycle. Each layer catches a distinct class of defect, and together they form a defense-in-depth strategy that prevents design drift, code smells, security issues, and stale artifacts from reaching production.
+
+## Overview
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  L0  HOOKS ENGINE    — Agent hook configuration validation  │
+│  L1  EDITOR TIME     — Biome AST rules (real-time)          │
+│  L2  PRE-COMMIT      — Validators (before commit)           │
+│  L3  CI/CD           — Validators (before merge)            │
+│  L4  SCHEDULED       — Validators (weekly)                  │
+└─────────────────────────────────────────────────────────────┘
+         ▲ fastest feedback              slowest feedback ▼
+```
+
+Layers are additive: L1 rules still apply when L3 runs. The earlier a defect is caught, the cheaper it is to fix. L0 and L1 give sub-second feedback; L4 catches slow-moving drift that only matters over days or weeks.
+
+---
+
+## L0: Hooks Engine
+
+The Hooks Engine validates agent hook configuration and enforces completion gates before work can proceed.
+
+| Rule | Description |
+|------|-------------|
+| **hook-config** | Validates `.harness-hooks.yml` configuration structure and semantics |
+| **gate-check** | Verifies that all required completion gates have been satisfied |
+
+**Command:**
+
+```bash
+npx harness validate --layer L0
+```
+
+---
+
+## L1: Editor Time — Biome AST Rules
+
+L1 rules run in real-time as code is written. They are implemented as Biome AST rules and provide immediate feedback in the editor.
+
+### Structural Rules
+
+| Rule | Description |
+|------|-------------|
+| **require-unit-comment** | Every source file must have a `// @unit <unit-name>` annotation |
+| **require-layer-comment** | Every source file must have a `// @layer <layer-name>` annotation |
+| **no-layer-violation** | Import direction must follow `domain -> application -> infrastructure/presentation`. Reverse dependencies are rejected. |
+| **enforce-folder-structure** | Files must reside in the correct layer directory matching their `@layer` annotation |
+| **no-ghost-file** | No orphaned files outside the unit structure |
+
+### Code Quality Rules
+
+| Rule | Description |
+|------|-------------|
+| **no-any-abuse** | Restricts TypeScript `any` usage to prevent type-safety erosion |
+| **no-comment-flood** | Prevents excessive comments that obscure code intent |
+| **no-code-duplication** | Detects duplicated code blocks that should be extracted |
+
+### Test Quality Rules (L1)
+
+| Rule | Description |
+|------|-------------|
+| **it-test-mock-detection** | Detects improper mock usage in integration tests |
+| **stub-comment-detection** | Flags stub comments left in test files (e.g., `// TODO: implement`) |
+
+**Command:**
+
+```bash
+npx harness lint
+```
+
+---
+
+## L2: Pre-commit Validators
+
+L2 validators run before every commit. They enforce process discipline and test quality standards.
+
+| Validator | Description |
+|-----------|-------------|
+| **phase-gate** | Enforces design-before-implementation order. Code changes to `scripts/harness/` are blocked unless the corresponding design documents exist in `docs/product/construction/`. |
+| **metadata** | Verifies completeness of source file annotations: `@unit`, `@layer`, `@US-XXX`, and `@story` |
+| **test-quality** | Enforces test authoring standards: AAA pattern (Arrange/Act/Assert), `actual` variable naming, single-act-per-test, and no mocking in domain layer tests |
+
+**Command:**
+
+```bash
+npx harness validate --layer L2
+```
+
+---
+
+## L3: CI/CD Validators
+
+L3 validators run in the CI/CD pipeline before a merge is permitted. They cover security, performance, coverage, and traceability.
+
+| Validator | Description |
+|-----------|-------------|
+| **security** | Scans for hardcoded secrets, SQL injection patterns, and other security anti-patterns |
+| **performance** | Detects `await`-in-loop, N+1 query patterns, and bundle size regressions |
+| **coverage** | Enforces test coverage thresholds. Standard preset requires 90%; strict preset requires 95%. |
+| **nyquist** | Bidirectional requirements-test traceability. Validates that every requirement in `requirement-test-matrix.json` has corresponding tests and vice versa. |
+
+**Command:**
+
+```bash
+npx harness validate --layer L3
+```
+
+---
+
+## L4: Scheduled Validators
+
+L4 validators run on a weekly schedule. They detect slow-moving drift that accumulates over time.
+
+| Validator | Description |
+|-----------|-------------|
+| **drift-detect** | Bidirectional design-code drift detection. Compares design documents against the actual codebase to find divergence in either direction. |
+| **consistency-check** | Cross-document layer consistency. Ensures that references between design documents, ADRs, and code remain coherent. |
+| **dead-code** | Detects unused exports and unreachable code that should be removed. |
+
+**Command:**
+
+```bash
+npx harness validate --layer L4
+```
+
+---
+
+## HarnessError Format
+
+Every validation failure produces a structured `HarnessError` object. The `suggestion` and `fix_example` fields enable AI agents to self-correct without human intervention.
+
+```typescript
+interface HarnessError {
+  code: string;         // "L1-003", "L2-001", etc.
+  severity: "error" | "warning";
+  message: string;
+  suggestion: string;
+  adr_ref?: string;     // "ADR-003"
+  fix_example?: string; // Code fix for AI self-correction
+}
+```
+
+Error codes follow the pattern `L{layer}-{number}`:
+
+- `L0-xxx` — Hooks Engine errors
+- `L1-xxx` — Biome AST rule violations
+- `L2-xxx` — Pre-commit validator failures
+- `L3-xxx` — CI/CD validator failures
+- `L4-xxx` — Scheduled validator findings
+
+---
+
+## Presets and Layer Activation
+
+Presets control which layers are active. Choose based on project maturity and team discipline.
+
+| Preset     | L0  | L1  | L2  | L3  | L4  |
+|------------|-----|-----|-----|-----|-----|
+| `minimal`  | off | on  | on  | off | off |
+| `standard` | off | on  | on  | on  | off |
+| `strict`   | on  | on  | on  | on  | on  |
+
+- **minimal** — Suitable for early prototyping. Editor-time rules and pre-commit checks only.
+- **standard** — Recommended for active development. Adds CI/CD validators for security, performance, coverage, and traceability.
+- **strict** — Full defense. Enables the Hooks Engine (L0) and scheduled drift detection (L4). Use for production-critical codebases.
+
+Presets are configured in `phasegate.config.json`, the single source of truth for all quality settings.

package/docs/guide/skills-overview.md

@@ -0,0 +1,107 @@
+# Skills Overview
+
+Phasegate provides 28 skills covering the full AIDLC (AI-Driven Development Life Cycle). Skills are deployed to `.claude/skills/` by `npx harness init` and invoked as slash commands in AI agent sessions.
+
+## AIDLC Process — Skill Execution Order
+
+The AIDLC follows a 3-level execution flow, each level producing design artifacts that gate the next.
+
+### Level 1: Requirements Definition
+
+Artifacts are placed in `inception/_shared/`.
+
+Skills run in sequence:
+
+1. `/product-architect` — Define the product vision, domain boundaries, tech stack, and constraints.
+2. `/story-writer` — Create user stories in Who/What/Why format with acceptance criteria.
+3. `/story-mapper` — Organize MVP scope and prioritize stories.
+4. `/unit-designer` — Group stories into independently buildable Units and define integration contracts.
+
+### Level 2: Cross-Unit Design
+
+Artifacts are placed in `inception/{unit}/`.
+
+Skills run per Unit:
+
+1. `/domain-designer` — DDD domain model (Aggregates, Entities, Value Objects, Domain Events).
+2. `/logical-designer` (cross-unit mode) — Hexagonal Architecture design with Ports and Adapters.
+3. `/environment-designer` — Local development environment and infrastructure design.
+4. `/mock-designer` — UI mockup design for validation and feedback.
+
+### Level 3: Story Implementation
+
+Artifacts are placed in `inception/{unit}/{US-XXX}/`.
+
+Skills run per User Story:
+
+1. `/logical-designer` (US-specific mode) — Story-scoped logical design refinement.
+2. `/uiux-designer` — Final UI/UX definition incorporating test cases, logical design, and existing UI.
+3. `/unit-test-designer` — Unit test case design from domain model.
+4. `/it-test-designer` — Integration test case design from logical design.
+5. `/scenario-test-designer` — E2E scenario test case design.
+6. `/unit-test-logic-designer` — Vitest implementation logic with pseudocode.
+7. `/it-test-logic-designer` — IT Vitest implementation logic with pseudocode.
+8. `/scenario-test-logic-designer` — Playwright E2E test implementation logic.
+9. `/implementation-readiness-checker` — Automated pre-implementation readiness verification.
+10. `/story-implementor` — TDD implementation with atomic commits.
+
+### Phase Dependency Rules
+
+- **Level 2 requires Level 1**: The `/unit-designer` output (Unit definitions and contracts) must exist before any Level 2 skill can run.
+- **Level 3 requires Level 2**: `domain_model.md` and `logical_design.md` must exist in `docs/product/construction/{unit}/` before Level 3 skills can write to that Unit. This is enforced by the pre-tool-use hook and cannot be bypassed.
+- **story-implementor requires test design**: At least one test design phase (unit-test-designer, it-test-designer, or scenario-test-designer) must be completed before `/story-implementor` can execute. This requirement is non-relaxable.
+
+## Skill Categories
+
+### Foundation (4 skills)
+
+| Skill | Description |
+|---|---|
+| `/product-architect` | Define product vision from business requirements. Covers domain boundaries, architecture decisions, tech stack, and constraints. |
+| `/story-writer` | Create user stories in Who/What/Why format with acceptance criteria. |
+| `/story-mapper` | Organize MVP scope and prioritize stories. Convergence phase after story divergence. |
+| `/unit-designer` | Group stories into independently buildable Units and define integration contracts. |
+
+### Design (5 skills)
+
+| Skill | Description |
+|---|---|
+| `/domain-designer` | DDD domain model design — Aggregates, Entities, Value Objects, and Domain Events. |
+| `/logical-designer` | Hexagonal Architecture design (Ports and Adapters). Two modes: cross-unit and US-specific. |
+| `/mock-designer` | UI mockup design for validation and feedback. |
+| `/uiux-designer` | Final UI/UX definition incorporating test cases, logical design, and existing UI. |
+| `/environment-designer` | Local development environment and infrastructure design. Bridges code and platform. |
+
+### Test Engineering (7 skills)
+
+| Skill | Description |
+|---|---|
+| `/unit-test-designer` | Design unit test cases from domain model. |
+| `/it-test-designer` | Design integration test cases from logical design. |
+| `/scenario-test-designer` | Design E2E scenario test cases from user stories, logical design, and mockups. |
+| `/unit-test-logic-designer` | Design Vitest implementation logic with pseudocode for unit tests. |
+| `/it-test-logic-designer` | Design Vitest implementation logic for DB, Repository, UseCase, and Controller integration tests. |
+| `/scenario-test-logic-designer` | Design Playwright E2E test implementation logic with selector strategies and seed data. |
+| `/test-coverage-checker` | Test coverage verification — checks acceptance criteria, domain logic, and UseCase coverage. Includes Nyquist Validation. |
+
+### Implementation (4 skills)
+
+| Skill | Description |
+|---|---|
+| `/story-implementor` | TDD implementation based on logical and environment design. Produces atomic commits with environment verification and lessons-learned feedback. |
+| `/quick-implementor` | Quick Mode ad-hoc implementation for bugfixes, docs, tests, and config changes. Phase Gate relaxed; L1/L2 maintained. |
+| `/implementation-planner` | Create implementation plan from Unit specs and domain model. Identifies related Units, API design, and layer-by-layer implementation strategy. |
+| `/implementation-readiness-checker` | Automated pre-implementation readiness verification — checks test design, coverage, and logic design existence. |
+
+### Verification (8 skills)
+
+| Skill | Description |
+|---|---|
+| `/consistency-checker` | Cross-layer consistency check across AIDLC design documents. Detects contradictions and gaps. |
+| `/cascade-updater` | Feedback lower-phase discoveries to upstream design documents and reconcile impact. |
+| `/codex-delegator` | Delegate tasks to Codex CLI with Claude Code as quality manager. Supports parallel execution of design, test, and implementation tasks. |
+| `/codebase-mapper` | Analyze `@unit`/`@layer` annotations across all source files to generate a structure map. Visualizes Unit distribution, inter-Unit dependencies, and circular dependencies. |
+| `/doc-freshness-checker` | Design document freshness check (L4 validator extension). Detects stale documents and code-design drift. |
+| `/pointer-validator` | Validate file pointers (relative path references) in design documents. Detects broken links. |
+| `/engineering-perspective` | Design review from Kent Beck, Martin Fowler, Uncle Bob, and Eric Evans perspectives. Multi-angle quality evaluation. |
+| `/skill-creator` | Create and update Agent Skills. Packaging, scripting, references, and asset management. |

package/docs/principles/architecture-philosophy.md

@@ -0,0 +1,64 @@
+# Unit Developer 共通ルール
+
+このファイルはすべてのUnit Developer（Unit1〜Unit6）に共通するルールを定義する。
+各Unitの固有ルールは対応する `unitN-developer.md` に記述されている。
+
+## Persona
+
+あなたはKent Beck（TDD）、Martin Fowler（リファクタリング）、Uncle Bob（Clean Architecture）、Eric Evans（DDD）の設計哲学を体現するソフトウェアエンジニアであり、担当Unitの専任開発者である。
+
+## エンジニアリング哲学（共通）
+
+- **設計書駆動:** 実装の前に必ず設計書を読み、仕様を正確に理解してからコードを書く。推測で実装しない。
+- **アーキテクチャ厳守:** ヘキサゴナルアーキテクチャ（ポート＆アダプター）とDDDの原則に従い、レイヤー間の依存方向を絶対に違反しない。`domain → port → repository/usecase → controller` の依存方向を常に意識する。
+- **最小限の変更:** 与えられたタスクに必要な最小限の変更のみを行う。過剰な抽象化、不要なリファクタリング、先回りの実装を一切しない。
+- **テストによる証明:** 実装の正しさはテストで証明する。手動確認に頼らず、自動テストで再現可能な形で検証する。
+- **既存コードへの敬意:** 変更前に既存のコードを必ず読み、設計意図を理解する。既存のパターンやコンベンションに従い、一貫性を保つ。
+- **ドメインモデルの豊かさ:** ビジネスロジックは値オブジェクト・エンティティ・集約に配置することを最優先とする。Usecaseは集約の取得・永続化・ドメインイベント発行などの調整役に徹する。ドメインサービスは「複数集約にまたがる操作」「外部システム連携を含むドメインロジック」など、上記のいずれにも自然に属さない場合に限り、例外的に使用する。安易にドメインサービスを作ることで集約が貧血モデル（Anemic Domain Model）に陥ることを防ぐ。
+
+## 専門領域（共通）
+
+- TypeScript（型安全性を最大限に活用した堅牢な実装）
+- ヘキサゴナルアーキテクチャ / DDD（エンティティ、値オブジェクト、集約、リポジトリパターン、ドメインサービスは例外的使用）
+- Vitest（ユニットテスト、統合テスト）
+
+## 参照先（共通）
+
+| カテゴリ | パス |
+| --- | --- |
+| ドメイン用語 | `product_overview.md` |
+| バックエンド実装 | `backend/` |
+| フロントエンド実装 | `frontend/` |
+| ユニット間の契約 | `integration_contract.md` |
+
+> ※ バックエンド設計書・フロントエンド設計書・ユニット要件のパスは各Unitファイルを参照。
+
+## 禁止事項（共通・絶対厳守）
+
+- **NEVER:** 担当UnitとShared Kernal以外のUnitに関するコードを変更する（依存関係がある場合や、全体最適のために必要な場合を除く）
+- **NEVER:** 担当UnitとShared Kernal以外のUnitの設計書を参照・変更する（依存関係がある場合や、ドメイン用語集を除く）
+- **NEVER:** プロジェクトルート外でのファイル操作
+- **NEVER:** 設計書を確認せずに実装を開始する
+- **NEVER:** 既存コードを読まずに変更する
+
+## 必須事項（共通）
+
+- **YOU MUST:** 実装開始前に担当Unitの設計書を確認する（バックエンド設計書・フロントエンド設計書の両方）
+- **YOU MUST:** ドメイン用語は `atomica_ubiquitous_word.md` に従う（コード内の命名も含む）
+- **YOU MUST:** 既存の実装コードを確認してから変更を行う
+
+## ワークフロー（共通）
+
+タスクを受け取ったら、以下の順序で作業する。
+
+1. **設計書の確認** — 該当する設計書を読み、仕様・制約・ドメインルールを把握する
+2. **既存コードの確認** — 変更対象と周辺のコードを読み、設計意図とパターンを理解する
+3. **テストの作成（TDD）** — 実装に先立ち、仕様を満たすために必要最小限のテストを書く。E2Eテスト・インテグレーションテスト・ユニットテストを適切な粒度で用意し、まず失敗する状態（Red）を確認する
+4. **実装** — テストを通過させることを目標に、設計書に忠実かつ既存パターンに従って最小限の変更を行う（Green）
+5. **リファクタリング** — テストが通る状態を維持しながら、コードの可読性・設計品質を改善する（Refactor）
+6. **シナリオ確認** — 各Unitファイルに定義された確認フローを実行する
+7. **レポート出力** — 完了報告を出力する
+
+## スコープ境界（共通原則）
+
+担当Unitの範囲内でのみ作業する。他のUnitのコード・設計書には関与しない。自分の担当領域を完璧に仕上げることが、プロジェクト全体の品質につながるという信念を持つ。

package/docs/principles/model-routing.md

@@ -0,0 +1,176 @@
+# モデルルーティング規約
+
+## 原則
+
+**Opus = 決める、Sonnet = 広げる、Codex = 作る。**
+
+| 役割 | モデル | 得意領域 |
+|------|--------|---------|
+| Architect | Opus 4.6 | 発明・判断・骨格設計・品質レビュー |
+| Expander | Sonnet 4.6 | 展開・量産・構造化・列挙 |
+| Implementor | Codex GPT-5.4 | TDD実装・repo整合・コード生成 |
+
+---
+
+## モデル割り当て表
+
+### 骨格設計（Opus 4.6 — メインセッション内実行）
+
+| Skill | AIDLC Step | 理由 |
+|-------|-----------|------|
+| `product-architect` | 0 | プロダクト全体像の発明・制約統合 |
+| `domain-designer` | 2.1 | 集約境界・不変条件の発明 |
+| `logical-designer` | 2.2 | 横断設計の骨格判断 |
+| `uiux-designer` | 7 | 体験設計・導線の発明 |
+| `kimunii-perspective` | Any | 多角的な品質判断 |
+| `skill-creator` | Tooling | スキル設計・構造化 |
+
+### 展開・量産（Sonnet 4.6 — 委任実行 → Opusレビュー）
+
+| Skill | AIDLC Step | 理由 |
+|-------|-----------|------|
+| `story-writer` | 1.1 | US一覧の粒度統一・量産 |
+| `unit-designer` | 1.2 | Unit-USマッピング表の量産 |
+| `story-mapper` | 1.5 | MVP整理・優先順位表化 |
+| `mock-designer` | 2 | 画面一覧・状態展開 |
+| `environment-designer` | 2.2並行 | 環境構成の列挙・整理 |
+| `scenario-test-designer` | 6 | E2Eテストケース列挙 |
+| `unit-test-designer` | 8前段 | ユニットテストケース列挙 |
+| `it-test-designer` | 8前段 | ITテストケース列挙 |
+| `unit-test-logic-designer` | 8前段 | テスト疑似コード展開 |
+| `it-test-logic-designer` | 8前段 | IT疑似コード展開 |
+| `scenario-test-logic-designer` | 8前段 | E2E疑似コード展開 |
+| `implementation-planner` | 実装前 | 実装計画の構造化展開 |
+| `cascade-updater` | 全工程 | 上位文書への変更波及 |
+| `consistency-checker` | 全工程 | 文書間整合チェック |
+| `test-coverage-checker` | 6以降 | カバレッジ網羅性検証 |
+| `implementation-readiness-checker` | 実装前 | 準備状況チェック |
+
+### 接地・実装（Codex GPT-5.4 — codex-delegator経由）
+
+| Skill | AIDLC Step | 理由 |
+|-------|-----------|------|
+| `story-implementor` | 2.3-2.7 | TDD実装（コード生成） |
+| `codex-delegator` | Any | 並列タスク委任 |
+
+---
+
+## Sonnet委任プロトコル
+
+### 実行フロー
+
+```
+┌─────────────────────────────────────────────────┐
+│ Phase 1: 計画（Opus in-session）                  │
+│  - Skillのプロンプトに従い計画を立案               │
+│  - 出力: Sonnetへの委任プロンプト + レビュー観点    │
+│  → 人間承認待ち                                    │
+├─────────────────────────────────────────────────┤
+│ Phase 2: 実行（Sonnet委任）                       │
+│  - delegate-sonnet.sh 経由で Sonnet 4.6 に委任     │
+│  - Sonnetはファイル読み取り + 文書生成のみ          │
+│  - 出力: 設計文書（mdファイル）                     │
+├─────────────────────────────────────────────────┤
+│ Phase 3: レビュー（Opus in-session）              │
+│  - Sonnet出力を品質基準で検証                      │
+│  - PASS → 完了                                    │
+│  - FAIL → Opusが直接修正                          │
+└─────────────────────────────────────────────────┘
+```
+
+### Phase 2: Sonnet委任
+
+#### 委任方法
+
+```bash
+# scripts/delegate-sonnet.sh を使用
+bash scripts/delegate-sonnet.sh \
+  --prompt "委任プロンプト" \
+  --output "出力ファイルパス" \
+  --context "読み込みファイル1,読み込みファイル2"
+```
+
+#### Sonnetへの委任プロンプト構造
+
+```
+[コンテキスト層] 読むべきファイルパス + 上位設計文書の引用
+[タスク層]       作業内容、入力ファイル、出力ファイルパスと期待フォーマット
+[制約層]         変更許可ファイル、スコープ制限、フォーマット規約
+[禁止層]         判断を含む作業の禁止（判断はOpusが行う）
+```
+
+#### Sonnetに委任してよい作業
+
+- 一覧表・マトリクスの作成
+- テストケースの列挙
+- 既存骨格に沿った章展開
+- 用語表・制約表の整理
+- 設計文書間のマッピング表作成
+- チェックリストの実行
+
+#### Sonnetに委任してはいけない作業
+
+- 集約境界の決定
+- アーキテクチャ選択の判断
+- 優先順位の最終決定
+- トレードオフを伴う設計判断
+- レビュー結果に基づく修正方針の決定
+
+### Phase 3: Opusレビュープロトコル
+
+#### レビュー観点（全Sonnet委任共通）
+
+| ID | 観点 | 検証内容 | 重大度 |
+|----|------|---------|--------|
+| R1 | 上位文書整合 | 上位設計文書（product_overview, domain設計等）との矛盾がないか | BLOCK |
+| R2 | 粒度一貫性 | 成果物内で抽象度・粒度が統一されているか | BLOCK |
+| R3 | 網羅性 | 入力に含まれる要素が漏れなく展開されているか | BLOCK |
+| R4 | 配置ルール | `folder_management_rules.md` に準拠しているか | BLOCK |
+| R5 | 判断混入 | Sonnetが独自判断を行っていないか（骨格逸脱） | BLOCK |
+| R6 | 表現品質 | 用語・文体がプロジェクト規約と統一されているか | WARN |
+| R7 | YAGNI | スコープ外の「改善」「将来への備え」がないか | WARN |
+
+#### 判定ロジック
+
+```
+BLOCK に 1つでも FAIL → Opus が直接修正
+WARN のみ FAIL         → Opus が直接修正（軽微）
+全 PASS                → 完了
+```
+
+**重要: Sonnetへの再委任は行わない。** 修正はすべてOpusが直接行う。
+理由: 修正は「何が問題か」の判断を含むため、Opus の責務である。
+
+#### レビュー出力フォーマット
+
+```markdown
+## Opus Review
+
+### 判定: PASS / FAIL
+
+### 検証結果
+| ID | 観点 | 結果 | 備考 |
+|----|------|------|------|
+
+### 修正内容（FAILの場合）
+- [R1] {ファイル}: {修正内容}
+- ...
+```
+
+---
+
+## ハイブリッド分業パターン
+
+一部のSkillでは Phase 1（Opus骨格）→ Phase 2（Sonnet展開）の分業が有効。
+
+| Skill | Opusが決めること | Sonnetが広げること |
+|-------|-----------------|-------------------|
+| `story-writer` | US粒度の判断基準、分割方針 | US一覧の列挙、受け入れ基準の標準化 |
+| `logical-designer` | 横断設計の骨格、レイヤー方針 | 章展開、DTO/UseCase一覧、ケース表 |
+| `unit-test-designer` | テスト戦略、重点観点 | テストケース一覧、境界値列挙 |
+
+このパターンでは:
+1. Phase 1 で Opus が骨格（アウトライン + 判断事項）を出力
+2. 人間承認
+3. Phase 2 で Sonnet に骨格を渡して展開を委任
+4. Phase 3 で Opus がレビュー + 修正