Governance
38のプロセスルール、15の品質ゲート、エスカレーションマトリクス、監査ログ。組織の品質と一貫性を保証するガバナンスフレームワーク。
Quality Gates
Compliance Officer(CO)が各フェーズ遷移で実行する品質ゲート。全15ゲートを通過しなければ次のフェーズに進めない。COの BLOCKED 判定はPOでも覆せない。
COは実行層から独立した監査層ロール。Orchestratorに対して拒否権を持つ。
| Gate ID | 遷移 | チェック項目 | 備考 |
|---|---|---|---|
| phase_0_to_1 | 準備 → 要件定義 | ブランチ作成済み、audit-log記録開始、phase-state初期化 | 全パイプラインの起点 |
| phase_1_to_2 | 要件定義 → 技術設計 | 01_requirements.md 作成済み、スコープ明確、受入基準定義 | 要件不備は最大の手戻り原因 |
| phase_1_5_to_2 | リサーチ → 技術設計 | 01.5_research.md 作成済み、調査結果が要件に対応 | skip不可(skip=null) |
| phase_2a_to_checkpoint | RFC → チェックポイント | 02a_rfc.md 作成済み、スコープ・方向性・代替案記載 | ユーザー承認が必要 |
| phase_2b_to_3 | 詳細設計 → UI設計 | 02b_design.md がRFCスコープ内、設計根拠あり | RFC逸脱は即BLOCKED |
| phase_3_to_3_5 | UI設計 → テスト計画 | 03_ui_design.md 作成済み(またはPOスキップ宣言) | UIなしタスクはスキップ可能 |
| phase_3_5_to_4 | テスト計画 → 実装 | 03.5_test_plan.md 作成済み、テスト戦略定義 | Spec-Based Testing の前提 |
| phase_4_to_5 | 実装 → テスト実行 | 実装完了、04_implementation.md 更新、コンパイルエラーなし | テスト実行の前提条件 |
| phase_5_to_6 | テスト → レビュー | 全テスト通過、カバレッジ基準達成 | テスト失敗状態でのレビュー禁止 |
| phase_6_to_6_5 | レビュー → 修正 | 05_review.md 作成済み、NEEDS_REVISION項目あり | レビュー指摘がある場合のみ |
| phase_6_5_to_7 | 修正 → PR作成 | 全NEEDS_REVISION対応済み、再レビューAPPROVED | Reviewer承認必須 |
| small_task_start | 小規模タスク開始 | ブランチ作成済み、tasks.yaml更新、スコープ確認 | 小規模タスク専用ゲート |
| small_task_to_review | 小規模タスク → レビュー | 実装完了、テスト通過、04_implementation.md記録 | 小規模でもレビュー必須 |
COが BLOCKED を返した場合、指摘事項を修正して再チェックを受ける。3回連続BLOCKED が発生した場合、自動的にユーザーへエスカレーションされる。POがCOのBLOCKED判定を覆すことは禁止されている。
Process Rules
組織の全プロセスを規律する28のルール。24のCriticalルールは違反時に即座にプロセスを停止し、4つのWarningルールは警告を出力する。
Critical Rules 24 rules
| ID | 説明 | 強制方法 |
|---|---|---|
| NO_PO_CODE | POはコードの作成・編集・削除を行わない。Projects/配下のファイルに触れない |
Guard Hook |
| NO_PHASE_SKIP | PO宣言なしのフェーズスキップ禁止。スキップ理由をaudit-logに記録 | CO Gate |
| CO_GATE_REQUIRED | 全フェーズ遷移にCOゲートチェック必須。COのBLOCKEDはPOでも覆せない | CO Gate |
| DELEGATION_REQUIRED | POは実装・設計・レビューを行わない。全てOrchestratorに委譲 | Process |
| DOCS_ALWAYS_REQUIRED | 全タスクでドキュメント作成必須。既存プロジェクト参画時も同様 | CO Gate |
| EXISTING_PROJECT_DOCS | 既存プロジェクト参画時に00_existing_analysis.md必須 | CO Gate |
| REVIEWER_APPROVED_BEFORE_MERGE | ReviewerのAPPROVED判定なしにPR作成不可 | CO Gate |
| TEST_ISOLATION | テストは本番データ・外部APIに依存しない。モック・スタブを使用 | Reviewer |
| SPEC_BASED_TEST | Spec作成 → テストコード → 実装の順序。テストファーストを強制 | CO Gate |
| TEST_ENV_DEFINED | テスト実行環境(CI設定、環境変数等)を事前に定義 | Reviewer |
| PLAN_BEFORE_WORK | タスク着手前にPlan Modeに入る。いきなり実装禁止 | Process |
| RFC_CHECKPOINT | RFC作成後にユーザーチェックポイント必須。自動承認禁止 | Process |
| RFC_APPROVED_BEFORE_DESIGN | RFCチェックポイント承認前に詳細設計に入らない | CO Gate |
| DESIGN_WITHIN_RFC_SCOPE | 詳細設計はRFCで承認されたスコープ内に限定 | CO Gate |
| BRANCH_BEFORE_WORK | 作業開始前にブランチ作成必須。mainへの直接コミット禁止 | Guard Hook |
| ONE_BRANCH_PER_TASK | 1タスク=1ブランチ。複数タスクを同一ブランチで混在させない | Process |
| BRANCH_FROM_MAIN | ブランチはmain最新から分岐。古い状態からの分岐禁止 | Process |
| NO_AUTO_MERGE | PRのマージ禁止。gh pr mergeコマンドはGuardがブロック |
Guard Hook |
| PR_USER_APPROVAL | PRマージはユーザーが手動で行う。自動マージ禁止 | Guard Hook |
| DELEGATION_CHECKLIST | Orchestrator委譲時に完了チェックリストをプロンプト末尾に含める | Process |
| PO_POST_COMPLETION | Orchestrator完了後にmemo・token-usage.yamlを更新 | Obligation Hook |
| TOKEN_USAGE_RECORD | 全Agent起動のトークン使用量をtoken-usage.yamlに記録 | Obligation Hook |
| IMPROVEMENT_REPORT_ON_VIOLATION | ルール違反発覚時にリアルタイムで改善レポート作成 | Process |
| SESSION_END_PHASE_STATE_AUDIT | セッション終了時にphase-state棚卸しとAuditor監査を実施 | Process |
Warning Rules 4 rules
| ID | 説明 | 強制方法 |
|---|---|---|
| KNOWLEDGE_READ | サブエージェント起動時に該当ロールのナレッジを読み込む | Process |
| RETROSPECTIVE_REQUIRED | セッション終了時に振り返りを実施(POが自動実行) | Process |
| AUDIT_LOG_COMPLETE | audit-logに全フェーズ遷移イベントを記録 | Auditor |
| KNOWLEDGE_CAPACITY | ナレッジファイルの肥大化を防止。定期的に棚卸し | Secretary |
Layer 1: Hook強制 — guard.sh、obligation hookがシェルスクリプトでコマンドを物理ブロック。LLMの記憶に依存しない。
Layer 2: COゲート — Compliance OfficerがAPPROVED/BLOCKEDで遷移を制御。独立した監査層。
Layer 3: プロセスルール — CLAUDE.mdとrules.yamlに記載。LLMが読み込んで遵守。
Escalation Matrix
エスカレーションは4つのカテゴリに分類される。各カテゴリでトリガー条件、検出者、判断者、選択肢が定義されている。
① 即時判断要求(Immediate Decision)
| トリガー | 検出者 | 判断者 | 選択肢 |
|---|---|---|---|
| 要件の曖昧さが解消できない | PO / Architect | ユーザー | 要件を明確化 / スコープ縮小 / 一旦保留 |
| CO BLOCKED 3回連続 | Orchestrator | ユーザー | 修正続行 / スコープ変更 / タスク中止 |
| 振り子検出(過去の決定と真逆の判断) | Reviewer | ユーザー | 現在の判断を採用 / 過去の判断を維持 / 第三案 |
| 本番環境への影響がある操作 | SRE / Guard | ユーザー | 実行承認 / 代替手段 / 中止 |
② 情報通知(Information Warning)
| トリガー | 検出者 | 判断者 | 選択肢 |
|---|---|---|---|
| トークン使用量が閾値超過 | Orchestrator | PO | 続行 / 最適化して続行 / ユーザーに報告 |
| ナレッジファイル肥大化 | Secretary | PO | 棚卸し実施 / 現状維持 |
| パターン追跡で同一パターン3回以上 | Secretary / Auditor | PO | 改善レポート作成 / 監視継続 |
③ サブエージェント障害(Subagent Failure)
| トリガー | 検出者 | 判断者 | 選択肢 |
|---|---|---|---|
| 一時的エラー(API、タイムアウト) | Orchestrator | PO(自動) | リトライ(retry_count+1、max 3) |
| 構造的エラー(権限不足、ファイル不在) | Orchestrator | PO | 原因修正後に再起動 / ユーザーに相談 |
| 不明なエラー / retry_count >= 3 | Orchestrator | ユーザー | 手動介入 / タスク中止 / 代替アプローチ |
④ 改善提案(Improvement Proposal)
| トリガー | 検出者 | 判断者 | 選択肢 |
|---|---|---|---|
| プロセスルール違反の再発 | Auditor / Secretary | PO → ユーザー | ルール追加 / Hook追加 / 既存ルール強化 |
| 新パターンの発見(成功/失敗) | Secretary | PO | ナレッジ化 / tracker.yaml記録 / 無視 |
| プロンプト改善提案 | Secretary | PO → ユーザー | 承認・適用 / 修正後適用 / 却下 |
エスカレーション時、POは以下の3点をユーザーに提示する:
- 状況 — 何が起きているか
- 選択肢 — 2~3案
- 推奨 — POの推奨案と理由
Audit Log
全フェーズ遷移、ゲート判定、エラー、PR操作を記録する監査ログ。Projects/{project}/docs/audit-log.md に出力される。
フォーマット
## Audit Log
### YYYY-MM-DD HH:MM - EVENT_TYPE
- **Phase**: {phase_name}
- **Actor**: {role_name}
- **Details**: {description}
- **Result**: APPROVED | BLOCKED | COMPLETED | FAILED
- **Token**: {token_count}
### 2026-04-01 10:30 - PHASE_START
- **Phase**: Phase 1 (Requirements)
- **Actor**: Orchestrator
- **Details**: 要件定義フェーズ開始。01_requirements.md作成開始
- **Result**: COMPLETED
- **Token**: 12,450
### 2026-04-01 10:45 - CO_GATE_CHECK
- **Phase**: phase_1_to_2
- **Actor**: Compliance Officer
- **Details**: 要件定義 → 技術設計ゲートチェック
- **Result**: APPROVED
- **Token**: 3,200
イベントタイプ一覧(30種)
📌 セッション管理(5)
- SESSION_START
- SESSION_END
- SESSION_RESUME
- SESSION_HEARTBEAT
- SESSION_TIMEOUT
📌 ブランチ・PR操作(4)
- BRANCH_CREATE
- BRANCH_SWITCH
- PR_CREATED
- PR_UPDATED
📌 フェーズ遷移(5)
- PHASE_START
- PHASE_END
- PHASE_SKIP
- PHASE_RETRY
- PHASE_FAIL
📌 COゲート(3)
- CO_GATE_CHECK
- CO_GATE_APPROVED
- CO_GATE_BLOCKED
📌 サブエージェント(4)
- AGENT_START
- AGENT_END
- AGENT_ERROR
- AGENT_RETRY
📌 レビュー・品質(3)
- REVIEW_APPROVED
- REVIEW_NEEDS_REVISION
- REVIEW_PENDULUM_DETECTED
📌 エスカレーション(2)
- ESCALATION_TRIGGERED
- ESCALATION_RESOLVED
📌 改善・ナレッジ(4)
- IMPROVEMENT_REPORT_CREATED
- KNOWLEDGE_PROMOTED
- RULE_ADDED
- HOOK_UPDATED
Skip Declaration
POは特定のフェーズをスキップする権限を持つ。ただし、スキップには明示的な宣言と理由の記録が必要。
スキップ手順
PO宣言
POがスキップ理由を明示的に宣言する。「UIがないのでPhase 3をスキップ」等。
Audit Log記録
PHASE_SKIPイベントとしてaudit-logに記録。理由と影響を明記。
phase-state更新
phase-state.yamlの該当フェーズをskipped状態に更新。skip_reasonを記載。
スキップ不可フェーズ
以下のフェーズはいかなる理由でもスキップできない。
- Phase 0: 準備(ブランチ作成) — ブランチなしの作業は禁止
- Phase 1: 要件定義 — 要件なしの実装は禁止
- Phase 1.5: 技術リサーチ — skip=null(必須フェーズ)
- Phase 2a: RFC作成 — スコープ合意なしの設計禁止
- Phase 6: レビュー — レビューなしのPR作成禁止
- Phase 7: PR作成 — 成果物のPR化は必須
スキップ可能フェーズ
POが理由を明示した上でスキップできるフェーズ。
- Phase 3: UI/UX設計 — UIを持たないバックエンドタスク等
- Phase 3.5: テスト計画 — POが明示的にテストスキップを宣言(稀)
- Phase 8: デプロイ設計 — インフラ変更を伴わないタスク
- Phase 9: 振り返り — 小規模タスクでは省略可能
Auditorがセッション終了時にスキップの妥当性を検証する。理由が不十分なスキップは改善レポートの対象となる。同一フェーズのスキップが3回連続した場合、パターンとしてtracker.yamlに記録される。