rlm-workflow

RLM ワークフロー

概要

.agent/PLANS.md に記載された標準 RLM プロセスを使用してリポジトリ作業を実施し、呼び出し規約には .codex/AGENTS.md の内容を適用します。リポジトリの成果物を信頼できる唯一の情報源として扱い、プロンプトはパスベースのコマンドとして維持してください。

トリガーの例

• Implement requirement '2026-02-24-add-oauth'
• Run RLM Phase 2 for .codex/rlm/2026-02-24-add-oauth/
• Resume requirement '2026-02-24-add-oauth' after manual QA
• Verify locks for .codex/rlm/2026-02-24-add-oauth/
• Lock Phase 3 for run '2026-02-24-add-oauth'

ブートストラップの事前確認（必ず最初に実行）

ほかの作業を始める前に、リポジトリの足場が存在し、最新の状態であることを確認してください。

• .codex/AGENTS.md に RLM Workflow ブロックが含まれている（管理対象のアップサートブロック）
• .agent/PLANS.md に references/plans-canonical.md の標準ワークフローブロックが含まれている（管理対象のアップサートブロック）
• .codex/rlm/ が存在する
• インストーラースクリプト（scripts/install-rlm-workflow.ps1 または scripts/install-rlm-workflow.py）が作成するほかのファイルが存在する

不足または古くなっているものがあれば、次を実行してください。

# Windows PowerShell:
powershell -ExecutionPolicy Bypass -File ./scripts/install-rlm-workflow.ps1 -RepoRoot .

# PowerShell 7+ (pwsh):
pwsh -NoProfile -File ./scripts/install-rlm-workflow.ps1 -RepoRoot .

# Python (Windows/macOS/Linux):
python ./scripts/install-rlm-workflow.py --repo-root .
# or:
python3 ./scripts/install-rlm-workflow.py --repo-root .

# Bash wrapper (macOS/Linux):
bash ./scripts/install-rlm-workflow.sh --repo-root .

スクリプトを実行できない場合は、同等の手動ブートストラップを実施してください。

• 上記に記載された不足しているディレクトリ／ファイルを作成する
• 管理対象マーカーを使用して、references/plans-canonical.md の標準プランを .agent/PLANS.md にアップサートする
• 管理対象マーカーを使用して、「RLM Workflow Skill」ブロックを .codex/AGENTS.md にアップサートする

その後、ワークフローの各フェーズに進んでください。

読む順序

1. ローカルの呼び出し規約を把握するため、.codex/AGENTS.md の冒頭部分を読みます。
2. 標準フェーズのルールと要件を確認するため、.agent/PLANS.md を読みます。
3. AGENTS の記述と PLANS の記述が異なる場合は、PLANS に従ってください（AGENTS では PLANS を標準として定めています）。該当する場合は、現在のフェーズの成果物に不一致を記録してください。

トリガーの例

• Implement requirement '<run-id>'
• Run RLM Phase 2 for .codex/rlm/<run-id>/
• Create .codex/rlm/<run-id>/02-to-be-plan.md with Coverage and Approval gates
• Update tests and lock Phase 4 artifact for this run

呼び出しモード

• 単一コマンドモード：
  • Implement requirement '<run-id>' を受け取ったら、実行フォルダーを特定し、各フェーズを順番に実行します。
  • フェーズ 5 で手動 QA の承認を得る場合に限り、一時停止します。
• 単一フェーズモード：
  • Run RLM Phase N を受け取ったら、必要な前のフェーズがすべてロック有効な場合に限り、そのフェーズのみを実行し、そのフェーズの出力のみを書き込みます。

単一コマンド契約（必須）

• 実行フォルダーを .codex/rlm/<run-id>/ に解決します。
• 実行フォルダーまたは 00-requirements.md がない場合は、停止して提示を求めます。要件を捏造してはいけません。
• 現在の状態から自動再開します。
  • フェーズ 0（要件）： 00-requirements.md が存在することを確認します（ユーザーが作成した開始点です）。ない場合は停止します。
  • フェーズ 0（ワークツリー）： 隔離されたワークツリーを作成して移動し、そのワークツリーから実行します。
  • フェーズの成果物が DRAFT またはゲートに不合格の状態で存在する場合、そのフェーズを再開します。
  • フェーズの成果物がない場合は、次の順序に該当するフェーズ用に作成します。
  • ロック済みの前フェーズの成果物を編集してはいけません。
• フェーズ 0 からフェーズ 7 まで、順番に実行します。
• フェーズ 0（ワークツリーの分離、必須）：
  • 00-requirements.md を実行の開始入力として扱います（あらかじめ存在している必要があります）。
  • .worktrees/<run-id> または設定された場所にワークツリーが存在するか確認します。
  • main/master ブランチにいる場合は、明示的な同意を得るか、ワークツリーを自動作成します。
  • ワークツリーのディレクトリーが Git の追跡対象外になっていることを確認します（プロジェクト内の場合）。
  • プロジェクトのセットアップを実行します（npm install、cargo build など）。
  • テストのクリーンなベースラインを確認します。
  • 続行する前に 00-worktree.md を作成してロックします。
  • スキル： skills/rlm-worktree/SKILL.md
• フェーズ 1.5（デバッグモード、省略可）：
  • 要件にデバッグ（バグ修正、テスト失敗、予期しない動作）が必要か判断します。
  • 必要な場合は、フェーズ 2 の前に 01.5-root-cause.md を作成してロックします。
  • フェーズ 1.5 では、体系的なデバッグを行います（skills/rlm-debugging/SKILL.md を参照）。
• フェーズ 5 では：
  • シナリオを DRAFT として 05-manual-qa.md に記述します。
  • 一時停止して、ユーザーに結果と承認を求めます。
  • 次回の呼び出し時に結果を記録し、フェーズ 5 をロックしてから、フェーズ 6 と 7 に進みます。

フェーズ遷移ガードレール（必須、ハードストップ）

• フェーズ N を開始する前に、.agent/PLANS.md を使用して、すべての前フェーズ（0..N-1）のロックチェーンを検証します。
• フェーズ 0 が存在する場合： フェーズ 1/2 を開始する前に、ロックが有効である必要があります（ワークツリーの分離が検証済みであること）。
• フェーズ 1.5 が存在する場合： フェーズ 2 を開始する前に、ロックが有効である必要があります。
• 前フェーズがロック有効とみなされるのは、基本成果物とフェーズ内の追記が LOCKED であり、LockedAt と LockHash が含まれ、末尾が Coverage: PASS および Approval: PASS である場合に限ります。
• ロック検証： LockHash が、正規化された成果物の内容（LF 改行、LockHash: 行を除く）の SHA-256 と一致することを検証します。自動検証には scripts/verify-locks.py（クロスプラットフォーム）または scripts/verify-locks.ps1（PowerShell）を使用します。
• いずれかの前フェーズでロックが有効でない場合、後続フェーズの成果物を作成または更新してはいけません。
• 最も早い不合格フェーズを再開し、ロックが有効になるまで修正してから続行します。
• 05-manual-qa.md のロックが有効でない限り、フェーズ 6 または 7 を開始してはいけません。
• 意図的な一時停止はフェーズ 5 の手動 QA のみです。それ以外の一時停止はすべてブロッカーです。

メインブランチの保護（必須）

鉄則：明示的な同意なしに、main/master ブランチで作業してはいけません。

自動保護

main/master ブランチから呼び出された場合：

1. 停止して警告を表示します
2. 既定の対応： 隔離されたワークツリーを作成します
3. main で作業を進めるには、明示的な同意が必要です

同意の要件

ユーザーが main ブランチでの作業を希望する場合：

• リスクを了承したことを記録します
• 明示的な同意をタイムスタンプ付きで記録します
• 例外を認める理由を記載します
• 推奨： 今後の要件ではワークツリーを使用します

ワークツリーの作成（既定）

# Create feature branch worktree
git worktree add .worktrees/<run-id> -b rlm/<run-id>
cd .worktrees/<run-id>

以降のすべてのフェーズはワークツリーのコンテキストで実行します。

TDD の規律（フェーズ 3 で必須）

鉄則：失敗するテストを先に作成せずに、本番コードを書いてはいけません。

Phase 3 における RED-GREEN-REFACTOR

1. RED フェーズ：

   • 期待する動作を示す最小限のテストを書く
   • テストを実行し、正しく失敗することを確認する
   • 失敗の内容を Phase 3 の成果物である TDD Compliance Log に記録する

2. GREEN フェーズ：

   • テストに合格する最もシンプルなコードを書く
   • テストを実行し、合格することを確認する
   • 最小限の実装を記録する

3. REFACTOR フェーズ：

   • テストに合格した状態を保ちながらコードを整理する
   • 整理した内容を記録する

TDD Compliance Log

すべての Phase 3 の成果物に、次の項目を含める必要があります：

## TDD Compliance Log

### R1: [description]
**Test:** `path/to/test.ts` - "[name]"
**RED:** [timestamp] - Failed as expected: [output]
**GREEN:** [timestamp] - Minimal implementation: [description]
**REFACTOR:** [timestamp] - Cleanups: [description]

危険信号 - 削除してやり直す

• テストを書く前にコードを書く -> 削除する
• テストにすぐ合格する -> テストを修正する
• 「後でテストを追加する」 -> 追加しません

参照： skills/rlm-tdd/SKILL.md

TODO の規律（すべてのフェーズで必須）

鉄則：未チェックの TODO がある状態でロックしたり、フェーズを進めたりしてはいけません。

TODO の要件

各フェーズの成果物には、次の項目を含む ## TODO セクションが必須です。

1. すべてのタスク、サブフェーズ、成果物に対するチェック可能な項目
2. 作業の完了に応じた段階的なチェック
3. ロック前に未チェック項目をゼロにすること

TODO の構成

## TODO

- [ ] Task 1: [description]
- [ ] Task 2: [description]
  - [ ] Sub-task 2a: [description]
  - [ ] Sub-task 2b: [description]
- [ ] Task 3: [description]

TODO のルール

#### TODO の厳格なゲート

次の条件を満たすまで、フェーズをロックしたり、次のフェーズに進んだりしてはいけません。

• すべての TODO 項目にチェックが入っていること（[x]）
• 未チェックの項目が残っていないこと（[ ] または空のチェックボックス）
• 「作業中」または「延期」の項目がないこと

例外： ありません。ロックする前に、すべての TODO を完了してください。

フェーズごとの TODO パターン

Phase 0 Worktree：

• Worktree を作成
• ブランチ保護を確認
• クリーンなベースラインを確認
• Phase 0 の Worktree 成果物を作成

Phase 0 Requirements：

• 要件を引き出す
• 受け入れ基準を定義
• 対象外の範囲を記録
• Phase 0 の成果物を作成

Phase 1 AS-IS：

• 現在の動作を記録
• コードへの参照を記録
• 判明していない点を列挙
• Phase 1 の成果物を作成

Phase 1.5（使用する場合）：

• エラー分析を完了
• 再現を確認
• 根本原因を特定
• Phase 1.5 の成果物を作成

Phase 2：

• サブフェーズを定義（必要な場合）
• ファイルの変更内容を指定
• テストコマンドを記録
• Phase 2 の成果物を作成

Phase 3：

• SP1 を実装してテスト
• SP2 を実装してテスト
• ...（サブフェーズごと）
• TDD Compliance Log を完成
• Phase 3 の成果物を作成

Phase 3.5（使用する場合）：

• 計画との整合性を確認
• コード品質を評価
• 問題を分類
• 判定を記録
• Phase 3.5 の成果物を作成

Phase 4：

• テスト前の実装監査を完了（Phase 3 の概要を要件および Phase 2 の計画と照合）
• 単体テストを実行
• 統合テストを実行
• E2E テストを実行（Tier A）
• Phase 4 の成果物を作成

Phase 5：

• QA シナリオを実行
• 結果を確認
• ユーザーの承認を記録
• Phase 5 の成果物を作成

適用

Status: LOCKED を設定する前に：

1. 成果物を確認し、未チェックの [ ] がないか調べる
2. 見つかった場合：作業を完了するか、追加資料にする
3. すべてのチェックボックスに [x] が入っていることを確認する
4. その後にのみ、ロックに進む

よくあるアンチパターン

アンチパターン	適切な対応
「後で完了する」	今すぐ完了するか、追加資料を作成する
一部だけチェックする	完全に完了した場合にのみチェックする
「作業する」のような曖昧な項目	具体的にする：「認証ハンドラーを実装する」
TODO セクションがない	すべてのフェーズの成果物で必須

順次的なフェーズの分離（必須、フェーズ作業の並行実施は禁止）

• ワークフローは厳密に順次進行し、1 回の実行につき、同時にアクティブにできるフェーズは必ず 1 つだけです。
• アクティブなフェーズとは、ベース成果物が存在しないか、ロックが有効でない最も早いフェーズです。
• アクティブなフェーズが解決されるまで、それ以降のフェーズの成果物を作成、更新、ロックしてはいけません。
• 複数のフェーズのベース成果物を同時に DRAFT のままにしてはいけません。
• 複数のフェーズ成果物が DRAFT の場合、最も早い DRAFT フェーズのみをアクティブとして扱います。それ以降の DRAFT 成果物は無効な並行事前作業であり、アクティブなフェーズのロックが有効になるまで続行してはいけません。
• アクティブなフェーズのロックが有効になったら、順次進めます。無効な後続フェーズの DRAFT 成果物は、そのフェーズがアクティブになったときにのみ再作成または上書きしてください。

実行フォルダーと成果物

• 主な実行パス：.codex/rlm/<run-id>/
• 実行ごとの成果物：
  • 00-worktree.md（必須 - フェーズ 0 のワークツリー設定）
  • 00-requirements.md
  • 01-as-is.md
  • 01.5-root-cause.md（任意、デバッグモード用）
  • 02-to-be-plan.md
  • 03-implementation-summary.md
  • 04-test-summary.md
  • 05-manual-qa.md
  • addenda/
  • evidence/（スクリーンショット／ログ／パフォーマンスデータ／トレース。フェーズ 4／5 から参照）
• グローバル成果物：
  • .codex/DECISIONS.md
  • .codex/STATE.md
• ワークツリーの場所（分離環境）：
  • .worktrees/<run-id>/（デフォルト、プロジェクト内、非表示）
  • または ~/.config/rlm-workflow/worktrees/<project>/<run-id>/（グローバル）
• スキル（参照用）：
  • skills/rlm-worktree/SKILL.md - フェーズ 0 のワークツリー分離
  • skills/rlm-tdd/SKILL.md - フェーズ 3 の TDD 規律
  • skills/rlm-debugging/SKILL.md - フェーズ 1.5 の体系的なデバッグ
• スクリプト（ユーティリティ）：
  • scripts/install-rlm-workflow.py - クロスプラットフォームのブートストラップ／更新
  • scripts/rlm-init.py - 新しい実行フォルダーとテンプレートの初期化（クロスプラットフォーム）
  • scripts/rlm-init.ps1 - 新しい実行フォルダーとテンプレートの初期化（PowerShell 版）
  • scripts/rlm-status.py - 実行ステータスとロックチェーンの概要（クロスプラットフォーム）
  • scripts/rlm-status.ps1 - 実行ステータスとロックチェーンの概要（PowerShell 版）
  • scripts/lint-rlm-run.py - 成果物の構造と TODO 規律のリンター（クロスプラットフォーム）
  • scripts/lint-rlm-run.ps1 - 成果物の構造と TODO 規律のリンター（PowerShell 版）
  • scripts/verify-locks.py - ロックハッシュの自動検証（クロスプラットフォーム）
  • scripts/verify-locks.ps1 - ロックハッシュの自動検証（PowerShell 版）

フェーズ実行プロトコル

1. .agent/PLANS.md からフェーズの入力ベースファイルを特定します。
2. 各入力を有効な入力に展開します。有効な入力は、ベースファイルと、ステージローカルの追加文書を辞書順に並べたものです。
3. 出力のドラフト作成前に、有効な入力をすべて読みます。
4. 必須のヘッダーフィールドを含めて、フェーズ成果物を作成／更新します。
   • Run、Phase、Status、Inputs、Outputs、Scope note
5. 各 R# の対応箇所と根拠を示す Traceability セクションを含めます。
6. Coverage Gate と Approval Gate で締めくくり、それぞれの結論を明示的に PASS または FAIL とします。
7. 両方のゲートに合格するまで、Status: DRAFT のままにします。
8. 合格したら、成果物をロックします。
   • Status: LOCKED に設定します。
   • LockedAt（ISO8601）を追加します。
   • LockHash（正規化した成果物コンテンツの SHA-256。詳細は /.agent/PLANS.md ／ references/plans-canonical.md を参照）を追加します。

ヘッダーとゲートの正確なひな形については、references/artifact-template.md を使用してください。

適用される PLANS の必須セクション

該当する場合は、.agent/PLANS.md の次のセクションを常に適用してください。

• 大規模な要件：実装のサブフェーズ（スコープが大きい、またはリスクが高い場合に必須）
• RLM 実行および実装サブフェーズの Playwright タグ付け（必須）
• フェーズ 2、4、5 の テスト規律（TDD + Playwright） セクション
• RLM TDD 規律（フェーズ 3） - RED-GREEN-REFACTOR サイクル、鉄則
• RLM の体系的なデバッグ（フェーズ 1.5） - デバッグモードを使用するタイミングと方法
• RLM の単一コマンドオーケストレーション（「Implement requirement '<run-id>'」）
• 実行フォルダーの解決
• フェーズの自動再開とフェーズ選択
• フェーズ遷移時のハードストップ・ロックチェーン（必須）
• 厳密な順序でのフェーズ実行（フェーズ作業の並行実行は禁止）
• 手動 QA による停止（唯一意図された一時停止）
• 単一コマンド実行のロック規則

不変性と追補

• ロック済みの前フェーズの成果物は編集しないでください。
• ロック済みの上流成果物に不足が見つかった場合は、現在のフェーズに上流ギャップの追補を作成してください。
• 追補の命名規則：
  • ステージ内：<base>.addendum-01.md
  • 上流ギャップ：<current>.upstream-gap.<prior>.addendum-01.md
• 現在のフェーズで作成したすべての追補を、そのフェーズのロック時にロックしてください。

フェーズの要件

0. フェーズ 0（00-worktree.md）- 分離必須

   • トリガー： すべての RLM 実行の開始時、他の作業を始める前に実施します。
   • 鉄則： 明示的な同意なしに、main/master ブランチで作業してはいけません。
   • .worktrees/<run-id>/（または設定された場所）に分離された git worktree を作成します。
   • worktree ディレクトリが git の無視対象になっていることを確認します（プロジェクト内に作成する場合）。
   • プロジェクトのセットアップを実行します（自動検出：npm install、cargo build、pip install など）。
   • テストのクリーンなベースライン（すべてのテストが合格すること）を確認します。
   • worktree の場所、ブランチ名、ベースラインの状態を記録します。
   • スキル： skills/rlm-worktree/SKILL.md

1. フェーズ 0 の要件（00-requirements.md）

   • 安定した ID R1..Rn と OOS1..OOSn を定義します。
   • 各 R# の観測可能な受け入れ基準を定義します。
   • 実行を初期化するため、ユーザーが最初に作成します。

2. フェーズ 1：現状（AS-IS）（01-as-is.md）

   • 初心者でも実行できる再現手順、現在の動作、コードの参照先、既知の不明点を記載します。
   • worktree のコンテキスト内で実行します。

3. フェーズ 1.5（01.5-root-cause.md）- デバッグモード（任意）

   • トリガー： 要件にバグ修正または予期しない動作の調査が含まれる場合に使用します。
   • 鉄則： 根本原因の調査を先に行わずに修正してはいけません。
   • 体系的なデバッグに従います：エラー分析 -> 再現 -> データフローの追跡 -> 仮説の検証 -> 根本原因の要約。
   • このフェーズを実施する場合は、フェーズ 2 の前に LOCKED にする必要があります。
   • スキル： skills/rlm-debugging/SKILL.md

4. フェーズ 2（02-to-be-plan.md）

   • 具体的なファイル編集、コマンド、テスト、手動 QA シナリオを含む、ExecPlan レベルの計画を作成します。
   • 範囲やリスクが大きい場合は、実装サブフェーズ（SP1、SP2 など）を追加します。
   • フェーズ 1.5 がある場合は、根本原因の調査結果を修正計画に反映します。

5. フェーズ 3（03-implementation-summary.md）- TDD の規律 + 並列化

   • 鉄則： 失敗するテストを先に書かずに、本番コードを書いてはいけません。
   • RED-GREEN-REFACTOR サイクルを記録した TDD 準拠ログを必ず含めます。
   • 並列モード（サブエージェント）： 独立したサブフェーズが 3 つ以上あり、サブエージェントを起動できる場合：
     • サブフェーズごとに新しいサブエージェントを割り当てます
     • 2 段階でレビューします：仕様への準拠 -> コード品質
     • 承認されるまでレビューを繰り返します
     • すべてのサブフェーズ完了後に統合テストを実施します
   • 逐次モード（フォールバック）： サブエージェントを利用できない場合：
     • メインエージェントでサブフェーズを順番に実行します
     • 拡張版のセルフレビュー用チェックリストを使用します
     • 各サブフェーズの間に統合テストを実施します
   • スキル： TDD には skills/rlm-tdd/SKILL.md、並列化には skills/rlm-subagent/SKILL.md

6. フェーズ 3.5（03.5-code-review.md）- コードレビュー（任意）

   • トリガー： 大規模な変更、重要なパス、またはさらなる確信が必要な場合
   • 使用する場面： リスクの高い変更、複雑なサブフェーズ、または外部検証が必要な場合
   • 並列モード： code-reviewer サブエージェントを割り当てます
   • 逐次モード： メインエージェントが拡張版のチェックリストを使ってセルフレビューします
   • 使用する場合は、フェーズ 4 の前に LOCKED にする必要があります
   • スキル： skills/rlm-subagent/SKILL.md

7. フェーズ 4（04-test-summary.md）- 並列テスト

   • テストの実行前に、03-implementation-summary.md の実装内容を 00-requirements.md および 02-to-be-plan.md と照合して監査し、不一致、追記事項、または確認事項を記録します。
   • 具体的な検証コマンド、結果、要件のカバレッジを記録します。
   • TDD 準拠を確認します：フェーズ 3 で作成したすべてのテストが合格していること。
   • 並列モード： 独立したテストスイートにサブエージェントを割り当てます：
     • サブエージェント 1：ユニットテスト
     • サブエージェント 2：統合テスト
     • サブエージェント 3：E2E Tier A
     • すべてを並行して実行し、結果を集約します
   • 逐次モード： メインエージェントでテストスイートを順番に実行します

8. フェーズ 5（05-manual-qa.md）

   • ユーザーの承認を得るために一時停止し、確認した結果と明示的な承認を記録します。

9. フェーズ 6 および 7

   • .codex/DECISIONS.md、次に .codex/STATE.md を更新します。
   • 変更は worktree のコンテキスト内で行います。準備ができたら、ユーザーがフィーチャーブランチをマージします。

RLM スキルの優先順位

要件が複数の懸念事項に関わる場合は、どのスキル／フェーズを先に適用するか、以下の優先順位に従って判断してください。

優先順位

1. デバッグ（バグ修正）→ まずフェーズ 1.5 の根本原因分析を実施します

   • トリガー： 要件にバグ、テスト失敗、または予期しない動作が含まれる場合
   • アクション： フェーズ 1 とフェーズ 2 の間にフェーズ 1.5 を挿入します
   • スキル： skills/rlm-debugging/SKILL.md
   • 理由： 修正を計画する前に、根本原因を理解する必要があります

2. 設計／分析（新機能または変更）→ フェーズ 1 の AS-IS 分析をすべて実施します

   • トリガー： 新機能、機能強化、または動作の変更
   • アクション： フェーズ 2 の前に、フェーズ 1 を徹底的に実施します
   • 理由： 将来の状態を定義する前に、現状を理解する必要があります

3. 実装 → 分析完了後、フェーズ 2 以降に進みます

   • トリガー： フェーズ 1（または 1.5）がロックされ、準備が整っている場合
   • アクション： フェーズ 2（TO-BE 計画）を開始します
   • 理由： 計画には、現在の状態／デバッグ対象の状態を完全に理解している必要があります

4. テスト → フェーズ 3 で TDD の規律に従います

   • トリガー： 実装作業全般
   • アクション： フェーズ 3 で TDD を適用します
   • スキル： skills/rlm-tdd/SKILL.md
   • 理由： テストによって、実装が要件を満たしているか検証します

5. レビュー → 実装と最終検証の間にコードレビューを行います

   • トリガー： 実装が完了した場合（フェーズ 3 がロック済み）
   • アクション： フェーズ 4 の前に、任意でフェーズ 3.5 のコードレビューを実施します
   • 理由： 最終検証の前に問題を見つけます

判断フロー

Requirement received
  |
  v
Is it a bug fix? --YES--> Phase 1.5 (Root Cause Analysis)
  |                          |
  NO                         v
  |                    Phase 2 (incorporate findings)
  v                          v
Phase 1 (AS-IS) -------> Phase 3 (TDD implementation)
  |                          |
  v                          v
Phase 2 (TO-BE) -------> Phase 4 (validation)
  |                          |
  v                          v
Phase 3 (TDD) ---------> Phase 5 (Manual QA)
                             |
                             v
                       Phase 6/7 (global updates)

例

要件	適用する優先事項	実行順序	実行モード
「ログイン時のクラッシュを修正」	まずデバッグ	フェーズ 0 -> 1 -> 1.5 -> 2 -> 3 -> 4 -> 5...	順次または並列
「ダークモードを追加」	まず設計	フェーズ 0 -> 1 -> 2 -> 3 -> 4 -> 5...	順次（単一の SP）
「空の入力でクラッシュする」	まずデバッグ	フェーズ 0 -> 1 -> 1.5 -> 2 -> 3 -> 4...	順次または並列
「OAuth を実装」	設計 + レビュー	フェーズ 0 -> 1 -> 2 -> 3 -> 3.5 -> 4 -> 5...	並列（複数の SP）
「複数ドメインのリファクタリング」	設計 + 並列	フェーズ 0 -> 1 -> 2 -> 3 -> 3.5 -> 4 -> 5...	並列（サブエージェント）

実行モードの凡例：

• 順次： 単一のサブフェーズで、並列処理は不要です
• 並列： 複数のサブフェーズがあり、サブエージェントを利用できる場合は並行して実行します
• 順次または並列： サブエージェントの利用可否の確認に基づいてモードを決定します

必須ゲート

必須ゲートとは、次に進む前に必ず満たさなければならないチェックポイントです。

### フェーズ 0 -> 1/2 の必須ゲート

次の条件を満たすまで、フェーズ 1 または 2 に進んではいけません。

• フェーズ 0 のワークツリーが作成され、検証済みである
• ワークツリーのディレクトリが Git の追跡対象外になっている（プロジェクト内に作成した場合）
• クリーンなテストベースラインが検証済みである
• メインブランチの保護が確認済みである
• フェーズ 0 の成果物が LockedAt と LockHash とともにロックされている

例外： ありません。すべての実行でフェーズ 0 が必須です。

### フェーズ 1 -> 2 の必須ゲート

01-as-is.md が次の条件を満たしてロックされるまで、02-to-be-plan.md を作成してはいけません。

• 網羅性：合格
• 承認：合格
• LockedAt と LockHash が入力済み

例外： フェーズ 1.5 が存在する場合は、フェーズ 2 の前にそちらもロックされている必要があります。

### フェーズ 1.5 -> 2 の必須ゲート（デバッグモード）

根本原因分析が完了するまで、TO-BE 計画を作成してはいけません。

• フェーズ 1.5 の成果物がロックされている
• 根本原因が特定されている（症状だけでは不十分）
• 修正方針が定義されている
• 網羅性：合格
• 承認：合格

例外： ありません。デバッグモードでは計画前に完了する必要があります。

### フェーズ 3 の TDD 必須ゲート

次の条件を満たすまで、実装コードを書いてはいけません。

• 失敗するテストが存在し、実行済みである
• テストの失敗がフェーズ 3 の成果物の TDD Compliance Log に記録されている
• 実際のテスト出力によって RED フェーズが検証されている

例外： ありません。鉄則に例外はありません。

フェーズ 4 → 5 のハードゲート

次の条件を満たすまで、手動 QA に進まないでください。

• 00-requirements.md と 02-to-be-plan.md に照らした実装監査が、フェーズ 4 の成果物に記録されている
• フェーズ 3 のすべてのテストに合格している
• TDD 準拠が確認されている
• テストの証拠がフェーズ 4 の成果物に記録されている
• フェーズ 4 がロックされている

### フェーズ 5 手動 QA ハードゲート

次の条件を満たすまで、DECISIONS.md または STATE.md を更新しないでください。

• ユーザーが QA シナリオを明示的に承認している
• 05-manual-qa.md にすべてのシナリオの観測結果が記載されている
• 承認：PASS。ユーザー名と日付が記録されている
• フェーズ 5 がロックされ、LockHash が内容と一致している

例外： ありません。グローバル更新には QA の完了が必須です。

### ロックチェーン・ハードゲート（すべての遷移に適用）

それ以前のすべてのフェーズ（0 から N-1）がロック要件を満たすまで、フェーズ N を開始しないでください。

• Status：LOCKED
• LockedAt：入力済み
• LockHash：コンテンツの SHA-256 と一致
• Coverage：PASS
• Approval：PASS

例外： ありません。ロックチェーンは絶対です。

実行モード：並列と逐次

RLM は、フェーズ 3（実装）とフェーズ 4（テスト）で 2 つの実行モードをサポートします。

並列モード（サブエージェント駆動）

要件：

• サブエージェントの起動機能が利用可能である
• 独立したサブフェーズが 3 つ以上定義されている
• サブフェーズ間でファイルを共有しない、または依存関係が最小限である

利点：

• 複数のサブフェーズを 3～5 倍速く実行
• サブフェーズごとに新しいコンテキストを使用（混乱を防止）
• 個別のサブエージェントによる独立したレビュー
• 自然な TDD の徹底

プロセス：

1. コントローラーがフェーズ 2 の計画からすべてのサブフェーズを抽出する
2. サブフェーズごとに実装サブエージェントを並列で割り当てる
3. 各実装担当が実装、テスト、コミットを行う
4. サブフェーズごとに仕様レビュアーを並列で割り当てる
5. 仕様レビュー合格後、サブフェーズごとにコードレビュアーを並列で割り当てる
6. 問題が見つかった場合はレビューを繰り返す
7. すべての承認後に統合テストを行う

ドキュメント： モードとサブエージェントの使用状況をフェーズ 3 の成果物に記録します

逐次モード（フォールバック）

起動条件：

• 現在の環境でサブエージェントを起動できない
• ユーザーが逐次実行を明示的に要求している
• サブエージェント機能の確認に失敗した

特徴：

• メインエージェントでサブフェーズを逐次実行
• 拡張版セルフレビュー・チェックリスト
• サブフェーズごとに統合テストを実施
• 時間はかかりますが、厳密さは同等です

フォールバックの起動フロー：

**Subagent Check:** NOT AVAILABLE
**Reason:** [Tool not found / Platform limitation / User request]
**Action:** Using SEQUENTIAL fallback mode

モード検出

フェーズ 3 の開始時に自動検出します。

1. サブエージェント機能の有無を確認する
2. 利用可能な場合 -> 並列モードを使用する
3. 利用できない場合 -> 明示的に記録したうえで逐次モードを使用する

プラットフォームごとの検出：

• Claude Code： Task ツールを確認する
• Codex： ネイティブのサブエージェント対応を確認する
• OpenCode： skill ツールの機能を確認する
• Cursor： サブエージェント対応が限定的なため、通常は逐次モード

ユーザーによるモード指定

ユーザーはモードを明示的に指定できます。

"Implement requirement 'X' using parallel subagents"
-> Attempt parallel, fallback if unavailable

"Implement requirement 'X' with sequential execution"
-> Force sequential even if subagents available

モードの比較

項目	並列モード	逐次モード
実行	サブエージェントによる並行処理	メインエージェントで逐次実行
速度	3～5 倍高速	線形
レビュー	独立したサブエージェントによるレビュー	セルフレビュー
コンテキスト	サブフェーズごとに新規	蓄積
厳密さ	外部による 2 段階レビュー	拡張セルフレビュー
フォールバック	利用できない場合は自動で切り替え	デフォルトモード

両モードでの品質維持

並列モードの品質：

• 2 段階レビュー（仕様＋コード品質）
• 独立した検証
• 修正のためのレビュー反復

逐次モードの品質：

• 拡張版セルフレビュー・チェックリスト
• 明示的な検証手順
• サブフェーズ間の回帰テスト

両モードで徹底する事項：

• TDD の規律
• 成果物のロック
• ゲートへの準拠
• 統合テスト

手動 QA の一時停止ルール

明示的なユーザー検証／承認のために一時停止するのは、フェーズ 5 のみです。ゲートを機械的に評価できる場合、他のフェーズでは承認のために一時停止しないでください。

運用ルール

• プロンプトは短く、パスベースにします。実質的な要件や計画はリポジトリ内のドキュメントに記載します。
• 実装と検証には、決定的で再現可能なコマンドを使用します。
• 必要な入力が不足している場合は、現在のフェーズに必要最小限の補足文書を作成します。ロック済みの履歴は編集し直しません。