15
Quality Gates
24
Critical Rules
4
Warning Rules
30
Audit Events
4
Escalation Types

Quality Gates

Compliance Officer(CO)が各フェーズ遷移で実行する品質ゲート。全15ゲートを通過しなければ次のフェーズに進めない。COの BLOCKED 判定はPOでも覆せない。

🔒
CO Gate Flow
① フェーズ完了
② Orchestrator がCO起動
③ CO がチェック実行
APPROVED or BLOCKED
⑤ 次フェーズ or 修正

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記録 小規模でもレビュー必須
BLOCKED リカバリー

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
🔐
ルール強制の3層構造

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出力フォーマット

エスカレーション時、POは以下の3点をユーザーに提示する:

  1. 状況 — 何が起きているか
  2. 選択肢 — 2~3案
  3. 推奨 — POの推奨案と理由

Audit Log

全フェーズ遷移、ゲート判定、エラー、PR操作を記録する監査ログ。Projects/{project}/docs/audit-log.md に出力される。

フォーマット

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は特定のフェーズをスキップする権限を持つ。ただし、スキップには明示的な宣言と理由の記録が必要。

スキップ手順

1

PO宣言

POがスキップ理由を明示的に宣言する。「UIがないのでPhase 3をスキップ」等。

2

Audit Log記録

PHASE_SKIPイベントとしてaudit-logに記録。理由と影響を明記。

3

phase-state更新

phase-state.yamlの該当フェーズをskipped状態に更新。skip_reasonを記載。

スキップ不可フェーズ

以下のフェーズはいかなる理由でもスキップできない。

スキップ可能フェーズ

POが理由を明示した上でスキップできるフェーズ。

スキップの乱用防止

Auditorがセッション終了時にスキップの妥当性を検証する。理由が不十分なスキップは改善レポートの対象となる。同一フェーズのスキップが3回連続した場合、パターンとしてtracker.yamlに記録される。