software-engineering-workflow-skill

ソフトウェアエンジニアリングのワークフロースキル

概要

ソフトウェア変更に対して、段階的なソフトウェアエンジニアリングのデリバリーワークフローを実行します。チケットのコンテキストを整え、要件を調査して具体化し、設計と将来状態のランタイム成果物を作成します。安定したベースラインと進行状況の追跡の両方を担う単一の実装成果物を用いて実装を進め、システムに適した API／E2E 検証やその他の実行可能な検証証跡で動作を検証し、独立したコードレビューを実施します。長期にわたって維持するドキュメントを同期し、ユーザーによる明示的な検証を経た引き渡しとリポジトリの最終処理で完了します。中規模または大規模なスコープでは、データフローの中核となる項目の一覧、責務、周辺の懸念事項、そこから導かれる関心の分離を軸に構成した、提案設計の完全なドキュメントを含めます。 このワークフローはステージごとのゲート制です。デフォルトでは、すべての成果物をまとめて生成しないでください。 このスキルにおける将来状態のランタイム呼び出しスタックは、将来状態（to-be）の実行モデルです。現在（as-is）の実装動作のトレースではありません。

スキルの構成

• SKILL.md はワークフローのルーターです。ステージのルールを定義し、各ステージが所有するテンプレートやリファレンスを示します。
• shared/ には、複数のステージで再利用する共通のリファレンスを格納します。
  • shared/design-principles.md
  • shared/workflow-state-template.md
• stages/ には、各ステージが所有するテンプレートやリファレンスを格納します。
  • stages/00-bootstrap/
  • stages/01-investigation/
  • stages/02-requirements/
  • stages/03-design/
  • stages/04-future-state-runtime-call-stack/
  • stages/05-future-state-runtime-call-stack-review/
  • stages/06-implementation/
  • stages/07-api-e2e/
  • stages/08-code-review/
  • stages/09-docs-sync/
  • stages/10-handoff/
• ステージ固有の内容は、対応するステージフォルダーに置いてください。shared/ は、本当に複数のステージで共通して参照するものに限って使用してください。
• ステージに専用のガイドやチェックリストがある場合は、汎用的なワークフローの説明を参照する前に、そのステージが所有するファイルを使用してください。

用語

• Subsystem／capability area：より広いカテゴリの作業を担う大きな機能領域です。複数のファイルと、任意のモジュールグループを含む場合があります。
• Module：コードベースに適している場合に、サブシステム内に設ける任意の中間的なグループです。このスキルでは、module は単一ファイルの同義語ではなく、デフォルトの責務単位でもありません。
• Folder／directory：ファイルや任意のモジュールグループを整理するための物理的なグループです。
• File：具体的なソースファイルです。具体的な関心事を配置する主要な単位です。

ワークフロー

チケットフォルダーの規約（プロジェクト内）

• 各タスクにつき、tickets/in-progress/ の下にチケットフォルダーを1つ作成するか、既存のものを使用してください。
• フォルダー名には、わかりやすく短いケバブケースを使用してください（先頭に日付を付ける必要はありません）。
• 作業中は、タスクの計画成果物をすべて in-progress チケットフォルダーに保存してください。
• 標準の状態：
  • 作業中のパス：tickets/in-progress/<ticket-name>/
  • 完了後のアーカイブパス：tickets/done/<ticket-name>/
• 移動ルール（必須）：ユーザーが完了を明示的に確認した場合（例：「done」「finished」「verified」）、または移動を明示的に依頼した場合に限り、チケットを in-progress から done に移動してください。
• 最終アーカイブの順序ルール（必須）：ユーザーによる完了または検証の明示的な確認によってリポジトリの最終処理も行う場合は、最終コミットの前にチケットフォルダーを tickets/done/<ticket-name>/ に移動してください。これにより、アーカイブ済みのチケットパスがコミットに含まれます。
• 再開ルール（必須）：ユーザーが完了済みチケットの続行または再開を依頼した場合、新たな更新を行う前に、tickets/done/<ticket-name>/ から tickets/in-progress/<ticket-name>/ にチケットを移動してください。
• 内部評価だけを根拠に、チケットを自動で done に移動してはいけません。
• ユーザーが別の場所を指定した場合は、その指定されたパスに従ってください。

チケットと作業ツリーのブートストラップ（必須の最初のアクション）

• 調査を始める前に、次の順序で作業コンテキストをブートストラップします。
  • tickets/in-progress/<ticket-name>/ を作成または使用します。
  • プロジェクトが Git リポジトリの場合：
    • 明示的なユーザー指示がある場合はそれに従ってブートストラップのベースブランチを決定し、ない場合は追跡対象のリモートのデフォルトブランチ／統合ブランチを最も確度の高い方法で推定します。
    • チケット用の作業ツリー／ブランチを新規作成する場合は、追跡対象のリモート参照を先に更新し、古いローカルの HEAD ではなく最新のリモート状態からブートストラップを開始します。
    • 成果物を書き込む前に、そのチケットブランチ専用のチケット作業ツリーを作成または再利用します。
    • チケットブランチを新規作成する場合は、最新の追跡対象リモートのベースブランチから codex/<ticket-name> を作成します。
  • ユーザーが提示した要件の意図に基づき、ステータスを Draft として requirements.md を作成または更新します。
• チケットのブートストラップと requirements.md の Draft が実際に書き込まれる前に、調査を開始してはいけません。
• チケット専用の作業ツリーがすでに存在する場合は、新規作成せず再利用します。
• ユーザーがベースブランチを指定した場合は、ローカルコピーから推測せず、そのブランチの最新の追跡対象リモート状態を必ず使用します。
• リモートの更新またはベースブランチの特定に失敗した場合は、Stage 0 を Blocked のままにし、調査の前にブロッカーを記録します。
• 環境が Git リポジトリではない場合は、作業ツリーのセットアップを行わずに進め、チケットフォルダーの作成と Draft 要件の記録は引き続き必須とします。

ワークフロー状態ファイル（必須の管理成果物）

• 正式なステージ管理成果物として tickets/in-progress/<ticket-name>/workflow-state.md を作成し、維持します。
• Stage 0 でチケットのブートストラップ直後に初期化し、次の内容を記載します。
  • Current Stage = 0
  • Code Edit Permission = Locked
  • Stage 0 Bootstrap Record に、ブートストラップモードと、Git リポジトリの場合は要求されたベースブランチ（指定がある場合）、特定したベースリモート／ベースブランチ、実施したリモート更新の結果、作業ツリーのパス、チケットブランチを記録します。
  • ステージゲートの行を Not Started／In Progress の状態で記載します。
• 更新モデル（必須）：
  • ステージ遷移のたびに Current Snapshot をその場で書き換えます。
  • 遷移／再入のたびに Transition Log に1行追加します。
  • 証拠へのリンク／パスを含め、Stage Gates の行を最新の状態に保ちます。
• ソースコード編集ロック（厳守ルール）：
  • workflow-state.md に Code Edit Permission = Unlocked と明記されていない限り、ソースコードを編集してはいけません。
  • デフォルト状態は Locked です。Stage 6 の前提条件が満たされた場合に限り、ソースコード編集のロックを解除します。
• 再入時のロックルール：
  • Stage 7／8 で失敗した場合は、再入の作業を始める前に Code Edit Permission = Locked に設定します。
  • 先に workflow-state.md にトリガー／分類／戻り先を記録してから進めます。
• 違反時の手順：
  • Code Edit Permission = Locked の状態でソースコードが編集された場合は、workflow-state.md に違反の記録を残します。
  • それ以上のソースコード編集を中断し、再入を宣言して、指定された上流ステージの経路に戻ります。

音声通知（Speak ツール、必須）

• ユーザーが実行状況と次の作業を把握できるよう、ワークフローの状態遷移を知らせるときは Speak ツールを使用してください。
• 再生ルール（必須）：必須の音声通知では、play=true を明示して Speak を呼び出してください。
• 必須の状態遷移通知では、既定で play=false を設定しないでください。
• 例外：ユーザーがサイレントモードを明示的に要求した場合に限り、play=false を設定してください。
• 状態遷移に応じた読み上げルール（必須）：
  • workflow-state.md がステージ遷移、ゲート判定、再参加判定、またはコード編集ロック／ロック解除の変更のために更新された場合に限り、読み上げてください。
  • 低レベルのコマンド実行、中間分析メモ、途中段階の草稿については読み上げないでください。
• 必須の音声通知イベント：
  • ワークフローの開始（task accepted、next stage）。
  • workflow-state.md に遷移ログを追記した後の、すべてのステージ遷移（From Stage -> To Stage）。
  • ゲートの根拠を記録した後の、すべてのゲート判定（Pass／Fail／Blocked）。
  • workflow-state.md の再参加セクションを更新した後の、すべての再参加宣言（分類＋復帰先）。
  • スナップショットを更新した後の、すべての Code Edit Permission の変更（Locked／Unlocked）。
• 読み上げの順序ルール：
  • 最初に workflow-state.md を更新してください。
  • 次に、保存済みの状態を反映した音声通知を行ってください。
• 読み上げるメッセージの内容（必須）：
  • 現在のステージ。
  • 直前に完了または変更された内容（遷移またはゲート結果）。
  • 次のステージまたは作業。
  • コード編集ロックの状態が変更された場合は、その状態。
• 複数の遷移が短時間に続く場合は、最後の更新を保存した後、短いメッセージにまとめてください。
• 各音声メッセージは簡潔に、状況を先に示し、次の行動につながる1～2文にしてください。
• Speak ツールが失敗した場合、または利用できない場合もワークフローを続行し、同じ内容をテキストで通知してください。
• 秘密情報、トークン、機密性の高いペイロード全体を読み上げないでください。

実行モデル（厳格なステージゲート）

• 明示的な段階に分けて作業し、後続の成果物を作成する前に各ゲートを完了してください。
• 段階を移行する前に、まず workflow-state.md を更新してください（スナップショット＋移行ログ＋ゲートのステータス）。その後、次の段階に進んでください。
• workflow-state.md は任意のドキュメントではなく、実行ロックを制御するものとして扱ってください。
• 移行権限のルール（必須）：段階の移行は、Stage Transition Contract と Transition Matrix に従って制御します。トリガー条件を満たしたら、マッピングされたパスへ直ちに移行してください。任意で現在の段階を続けないでください。
• 移行実行ルール（必須）：workflow-state.md を更新して段階の移行または分類済みの再エントリーを宣言したら、別のユーザーメッセージを待たず、デフォルトで直ちに対象段階に入り、作業を実行してください。移行を記録して次のステップを説明するだけでは不十分です。対象段階で実際に作業を再開するまで、移行は完了していません。実際のブロッカー、またはユーザーのみが対応できる明示的なゲートがある場合に限り、停止してください。
• 要件は、ユーザーの入力やバグ報告の成果物をもとに、大まかな Draft として開始できます。
• チケットとワークツリーのブートストラップが完了し、requirements.md のステータス Draft が実際に書き込まれるまで、調査を開始しないでください。
• investigation-notes.md が実際に書き込まれ、現在のチケットの内容に更新されるまで、理解フェーズの合格を確定しないでください。
• 詳細な理解フェーズが完了し、requirements.md が Design-ready に達するまで、設計成果物（proposed-design.md または implementation.md の小規模スコープ向け解決策の概要）を作成しないでください。
• 対象スコープの将来状態のランタイムコールスタックレビューゲートを完全に満たすまで、implementation.md のベースラインセクションを確定したり、実行追跡セクションを開始したりしないでください。
• implementation.md のベースラインが確定し、その実行追跡セクションが初期化されるまで、実装の実行を開始しないでください。
• 次のすべてが workflow-state.md で満たされるまで、ソースコードの編集を開始しないでください。
  • Current Stage = 6。
  • Code Edit Permission = Unlocked。
  • Stage 5 ゲートが Go Confirmed。
  • 必要な上流成果物が、証拠とともに Pass と記録されている。
• 実装の実行が完了し、必要な単体／統合検証と Stage 6 のモダナイゼーション／所有権依存関係チェックが満たされるまで、Stage 7 の実行可能な検証の実装と実行を開始しないでください。
• Stage 7 の実行可能な検証ゲートが Pass になるまで、コードレビューを開始しないでください。
• コードレビューが完了するまで、テスト後の docs/ 同期を開始しないでください（Stage 7 で実現不可能な受け入れ基準がある場合は、明示的なユーザーの免除、制約、補完証拠、および残存リスクを記録してください）。
• テスト後の docs/ 同期が完了する（または影響なしとの判断を根拠とともに明示的に記録する）まで、タスクを終了しないでください。また、必要な Stage 10 のユーザー検証／アーカイブ／最終処理が完了するまで、最終完了を確定しないでください。
• ユーザー検証保留ルール（必須）：Stage 9 が合格したら、引き継ぎ概要を保存し、ユーザーが完了／検証を明示的に確認するまで Stage 10 を開いたままにしてください（たとえば、手動テスト後の確認など）。そのユーザーからの合図があるまで、コミット、プッシュ、マージ、リリース／公開／デプロイ作業の実行、チケットの done への移動を行わないでください。
• リリースノート成果物ルール（該当する場合は必須）：チケットによってユーザー向けアプリリリース、または GitHub Release の本文が作成される場合、Stage 10 では最終リリース前に、機能についてユーザー向けに簡潔に記した tickets/in-progress/<ticket-name>/release-notes.md も保存してください。該当しない場合は、その根拠として release-notes not required と引き継ぎ概要に明記してください。
• リポジトリ最終処理ルール（Git リポジトリでは必須）：ユーザーから完了／検証の明示的な合図を受け取り、Stage 10 を完了とする前に、まずチケットフォルダーを tickets/done/<ticket-name>/ に移動してください。その後、チケットブランチ上で対象範囲内のすべての変更（移動したチケットファイルを含む）をコミットし、チケットブランチをリモートにプッシュし、リモートから解決済みの最終処理先ブランチを更新したうえで、チケットブランチを更新済みの対象ブランチにローカルでマージし、更新済みの対象ブランチをプッシュしてください。
• リリース／公開／デプロイルール（条件付き）：リポジトリの最終処理後、プロジェクトに該当するリリース、公開、タグ付け、またはデプロイの手順が文書化されている場合は、そのプロジェクト固有の方法で実行してください。リリーススクリプト、文書化されたコマンド、git タグのワークフロー、GitHub Release の作成、その他の文書化されたデプロイ／公開手順などが該当します。該当する手順がない場合は、リポジトリの最終処理を妨げるのではなく、引き継ぎ概要に release/publication/deployment not required（または同等の根拠）を記録してください。
• リリース公開の引き継ぎルール（リリースノートが必要な場合は必須）：チケットを tickets/done/<ticket-name>/ に移動した後、該当するリリース／公開手順がある場合は、アーカイブ済みのチケット内 tickets/done/<ticket-name>/release-notes.md 成果物を、その手順に引き渡してください（リリーススクリプト、文書化されたコマンド、タグ／リリースのワークフロー、リポジトリのリリース本文ソースファイルなどを通じて渡します）。
• 最終処理先ルール（必須）：ユーザーが後から明示的に対象を上書きしない限り、Stage 0 の Resolved Base Remote と Resolved Base Branch を Stage 10 のデフォルトのマージ先として使用してください。対象を高い確度で特定できない場合は、推測せず Stage 10 を一時停止し、マージ／最終処理の前に一度だけ確認してください。
• 最終処理後のクリーンアップルール（専用のチケット用ワークツリー／ブランチがある場合は必須）：リポジトリの最終処理と、該当するリリース／公開／デプロイ作業の完了（または不要との明示的な記録）後、Stage 0 に記録された専用のチケット用ワークツリーを削除し、worktree-prune のクリーンアップを実行してください。また、ローカルのチケットブランチが解決済みの最終処理先に完全にマージされ、不要になった場合は、そのローカルのチケットブランチを削除してください。ユーザーの明示的な指示または文書化されたプロジェクト方針で求められていない限り、リモートブランチは削除しないでください。クリーンアップのためにチケット用ワークツリーから出る必要がある場合は、安全な親リポジトリのチェックアウトから実行し、省略しないでください。
• Stage 10 のブロッカールール（必須）：ユーザー確認後に tickets/done/ への移動、コミット、プッシュ、対象ブランチの更新、マージ、または必要な最終処理後のクリーンアップに失敗した場合は、Stage 10 を In Progress／Blocked のままにし、ブロッカーを workflow-state.md に記録してください。最終的な引き継ぎを完了としないでください。該当するリリース／公開／デプロイ手順に失敗した場合、または手順が文書化されていない場合も、そのブロッカーを記録してください。ただし、完了済みのリポジトリ最終処理は取り消さないでください。
• ユーザーから完了の明示的な確認を受け取るまで、チケットフォルダーを tickets/in-progress/ の下に置いてください。
• エンジニアリングの完了、ユーザー検証、チケットのアーカイブ、リポジトリの最終処理、リリース／公開／デプロイ、および最終処理後のクリーンアップは、それぞれ独立したゲートとして扱ってください。エンジニアリングの完了は、実装＋Stage 7 の実行可能な検証ゲート＋コードレビュー＋ドキュメント同期の完了時点です。その後はユーザーから完了／検証の明示的な確認があるまで待機してください。それを受け取った後にのみ、チケットを tickets/done/ に移動し、必要な Stage 10 のリポジトリ最終処理を行い、該当するリリース／公開／デプロイ作業を実施し、必要なワークツリー／ブランチのクリーンアップを完了してください。
• Small スコープの例外：レビュー前に implementation.md（解決策の概要セクションのみ）を設計の入力資料として作成してもかまいません。ただし、このドラフトによって実装開始が許可されるわけではありません。
• 将来状態のランタイムコールスタックレビューは、1 回で済ませず、複数回の詳細レビューを反復して実施する必要があります。
• ブロッカーがあるラウンドで必要な上流成果物を更新した直後に Go Confirmed と宣言することはできません。
• 安定性ルール（必須）：ブロッカーなし、保存が必要な成果物の更新なし、新たに発見されたユースケースなしと報告する詳細レビューが 2 回連続するまで、Go Confirmed を解除しないでください。
• 最初の問題なしのラウンドは暫定的な判定（Candidate Go）です。2 回目の連続した問題なしのラウンドで確定（Go Confirmed）とします。
• ユースケースの見落とし発見ルール（必須）：Stage 5 の各ラウンドで、ユースケースの見落としを見つけるための専用調査を必ず実施してください（要件の網羅性、境界をまたぐ処理、フォールバック／エラー分岐、設計リスクのシナリオ）。
• 新たなユースケースが見つかった、保存が必要な成果物の更新が必要になった、またはブロッカーが見つかった場合、Stage 5 のラウンドは問題なしとは見なされません。
• 設計／レビューの更新が必要なレビュー指摘はすべてブロッカーです。影響する成果物を再生成し、進行前に再レビューしてください。
• 設計／レビューによって理解不足または要件の曖昧さが明らかになった場合は、理解フェーズと要件定義フェーズに戻り、requirements.md を更新してから設計／レビューを続けてください。
• Stage 5 の分類済み再エントリーのマッピング（必須）：
  • Design Impact（背骨／所有権／境界／命名／アーキテクチャに関する明確な問題で、確度が高い）：Stage 3 -> Stage 4 -> Stage 5 に戻ります。
  • Requirement Gap（要件または受け入れ基準の不足／曖昧さ）：Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 に戻ります。
  • Unclear（スコープを横断する問題、または根本原因の確度が低い）：Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 に戻ります。
• Stage 5 のブロッカーがあるラウンドでは、次のラウンドを開始する前に、future-state-runtime-call-stack-review.md と workflow-state.md の両方に分類と戻り先のパスを記録してください。
• Stage 6 の非局所的な再エントリールール（必須）：Stage 6 の問題を Design Impact、Requirement Gap、または Unclear と分類した場合は、分類と戻り先のパスを workflow-state.md に記録し、Code Edit Permission = Locked に設定して、ソースをさらに編集する前にマッピングされた上流段階のパスへ移行してください。
• 再エントリー宣言ルール（必須）：実装後のゲート（Stage 7 の実行可能な検証、または Stage 8 のコードレビュー）で問題が見つかった場合は、次の事項を明示的に記録してください。
  • トリガーとなった段階（7／8）。
  • 分類（Local Fix／Validation Gap／Design Impact／Requirement Gap／Unclear）。
  • コードを編集する前に戻る必要がある段階のパス。
• アーティファクト／コードの更新作業を始める前に、再エントリー宣言を workflow-state.md に記録する必要があります。
• 再エントリー完了ルール（必須）：分類済みの再エントリーが記録され、戻り先のパスが workflow-state.md に保存されたら、別のユーザーメッセージを待たず、デフォルトで直ちに最初の戻り先段階の作業を再開してください。状態を更新して次にすべきことを説明するだけで停止しないでください。実際に戻り先の段階で作業を再開するまで、再エントリーは完了していません。
• 直接修正禁止ルール（必須）：実装後のゲートで指摘が見つかった場合、最初にソースコードを編集しないでください。分類パスに従って、まず必要な上流成果物を更新してください。
• 再エントリーのマッピング（必須）：
  • Local Fix：必要に応じて実装成果物（implementation.md／api-e2e-testing.md／code-review.md）を更新してから修正を実装し、その後 Stage 6 -> Stage 7 を再実行します。Stage 7 が合格したら、Stage 8 に進みます。
  • Design Impact：Stage 1 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 に戻ります。Stage 7 が合格したら、Stage 8 に進みます。
  • Requirement Gap：Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 に戻ります。Stage 7 が合格したら、Stage 8 に進みます。
  • Unclear（または根本原因が複数領域にまたがる場合）：Stage 0 -> Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 に戻ります。Stage 7 が合格したら、Stage 8 に進みます。
• 再エントリーパスにおける Stage 0 は、同じチケット／ワークツリー内でブートストラップ制御（workflow-state.md、ロック状態、成果物のベースライン）を再開することを意味します。新しいチケットフォルダーは作成しないでください。
• ユーザーが 1 回のやり取りですべての成果物を求めている場合も、そのやり取りの中で段階ゲートを必ず守ってください（まずレビューラウンドを反復し、その後に実装成果物を作成します）。
• 段階優先の保存ルール：Stage 5 のラウンドで問題が見つかった場合は、まず分類と戻り先のパスを記録して workflow-state.md を必要な上流段階に移行し、その後、その段階で必要な成果物の更新を保存してください。
• 頭の中だけでレビュー指摘を修正しないでください。未解決の更新を記憶したまま次のラウンドに進まないでください。
• 各レビューラウンドでは、実際に保存された成果物の更新を future-state-runtime-call-stack-review.md に明記してください。
  • 更新したファイル。
  • 新しい成果物バージョン。
  • 変更したセクション。
  • 解消した指摘。
• 必要なファイルの更新が実際に書き込まれるまで、レビューラウンドは完了したと見なせません。
• レビューラウンドの状況を伝える場合は、ラウンドの記録と必要な段階別成果物の更新が実際に書き込まれ、関連する Stage 5 ゲートのステータスが workflow-state.md に保存された後に限ってください。

標準ステージ順序（クイックマップ）

ステージ	名前	主な成果物／ゲート	コード編集の許可
0	ブートストラップ＋要件ドラフト	チケット／ワークツリーのブートストラップ完了（チケットパス、および Git リポジトリの場合は追跡対象リモートからのベースブランチの解決、新規ブートストラップ時のリモートの最新状態の処理、専用チケット用ワークツリー／ブランチの作成または再利用）＋ requirements.md = Draft	ロック
1	調査＋トリアージ	investigation-notes.md が最新＋スコープのトリアージ完了	ロック
2	要件の精緻化	requirements.md が Design-ready／Refined に到達	ロック
3	設計の基礎	implementation.md のソリューション概要（Small）、または proposed-design.md（Medium/Large）	ロック
4	未来状態のランタイムコールスタック	future-state-runtime-call-stack.md が最新	ロック
5	未来状態のランタイムコールスタックレビュー	Go Confirmed（ブロッカー、永続化される更新、新しいユースケースがない状態で、連続して2回のクリーンなラウンドを完了）	ロック
6	ソース実装＋ユニット／統合	ソースコード＋必須のユニット／統合チェック完了＋後方互換性／レガシー保持なし＋所有権主導の依存関係の品質を維持＋権威ある境界ルールを維持＋変更ファイルを正しく配置	ロック解除
7	API／E2E＋実行可能な検証ゲート	実行可能な検証シナリオを実装し、受け入れ基準と主要フローのカバレッジを完全に網羅	ロック解除
8	コードレビューゲート	コードレビューの判定（Pass／Fail）を記録。変更されたソースファイルのみを対象とする実効行数の上限 <=500、変更されたソースファイルのみを対象とする必須の >220 差分ゲート評価、データフローの主要フローのインベントリ／所有権／主要フロー外の懸念事項のチェック、既存機能の再利用、再利用可能な所有構造の抽出、共有構造／データモデルの適切さ、共有ベースの一貫性、繰り返し行われる調整の所有権、空の間接化、スコープに応じた関心の分離、所有権主導の依存関係の品質、権威ある境界ルールの維持、正しいサブシステムおよびフォルダーへのファイル配置（任意のモジュール分類を行う場合は、その妥当性を説明）、フラット構成と過剰分割構成の判断、インターフェース境界の明確さ、ファイル／フォルダー／API／型／関数／パラメーター／変数全体の命名品質、命名と責務の整合性、変更範囲内に正当化できないコードや繰り返し構造の重複がないこと、パッチを重ねることで生じる複雑さの制御、テストの品質、テストの保守性、検証エビデンスの十分性、後方互換性なし／レガシーなしのチェック	ロック
9	ドキュメント同期	docs-sync.md が最新＋docs/ の更新完了、または影響なしの根拠を記録	ロック
10	最終引き継ぎ	提供内容の概要を用意＋ユーザーによる明示的な検証 → チケットを done に移行 → リポジトリを解決先ブランチに最終化（Git リポジトリの場合）＋該当するリリース／公開／デプロイ手順を完了、または不要であることを明示的に記録＋該当する場合は最終化後に必要なワークツリー／ブランチのクリーンアップを完了＋チケット状態の判断を記録	ロック

ステージ遷移の契約（適用）

ステージ	終了条件（次へ進むために満たす必要がある条件）	失敗時／ブロック時	合格時の次のステージ
0 ブートストラップ＋要件ドラフト	チケット／ワークツリーのブートストラップが完了し、ベースブランチ／ワークツリーの判断が記録され、requirements.md のステータスが Draft である	ブートストラップが完了するまで 0 にとどまる	1
1 調査＋トリアージ	investigation-notes.md が最新で、スコープのトリアージ（Small／Medium／Large）が記録されている	調査の証拠がそろうまで 1 にとどまる	2
2 要件	requirements.md が、要件／受け入れ基準の対応表を含む Design-ready（または Refined）である	要件が設計可能な状態になるまで 2 にとどまる	3
3 設計の基礎	設計の基礎となる成果物が最新である（Small の場合は implementation.md の解決策の概要、Medium/Large の場合は proposed-design.md）	3 にとどまり、設計の基礎を修正する	4
4 将来のランタイムコールスタック	対象範囲内のユースケースについて future-state-runtime-call-stack.md が最新である	4 にとどまり、将来のランタイムコールスタックを再生成する	5
5 将来のランタイムコールスタックのレビュー	将来のランタイムコールスタックのレビューで Go Confirmed に達している（ブロッカー、必須の永続化された成果物の更新、新たに発見されたユースケースがないクリーンなラウンドが2回連続している）	次のレビューラウンドの前に分類に応じて再開する（Design Impact: 3 -> 4 -> 5、Requirement Gap: 2 -> 3 -> 4 -> 5、Unclear: 1 -> 2 -> 3 -> 4 -> 5）	6
6 ソース＋ユニット／統合	ソース実装が完了し、必須のユニット／統合チェックに合格しており、後方互換性／レガシー保持の経路が対象範囲に残っておらず、所有関係に基づく依存関係が有効なままである（新たに正当化されていない循環依存／密結合がない）。権威ある境界ルールが有効なままである（権威ある境界を新たに迂回する経路がない）。変更したファイルは、正しい所有サブシステム内の正しいフォルダーに配置されている	ローカルの問題：6 にとどまる。ローカル以外の問題：分類に応じて再開する（Design Impact: 1 -> 3 -> 4 -> 5 -> 6、Requirement Gap: 2 -> 3 -> 4 -> 5 -> 6、Unclear: 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6）	7
7 API／E2E＋実行可能な検証ゲート	実行可能な検証シナリオが実装され、実行可能な対応済み受け入れ基準がすべて Passed（または実行不可能なケースについてユーザーにより明示的に Waived）であり、関連する実行可能なスパインすべてに合格したシナリオの証拠（または明示的な N/A の根拠）がある	実行不可能で免除もない場合は Blocked。それ以外は分類に応じて再開する（Local Fix: 6 -> 7、Design Impact: 1 -> 3 -> 4 -> 5 -> 6 -> 7、Requirement Gap: 2 -> 3 -> 4 -> 5 -> 6 -> 7、Unclear: 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7）	8
8 コードレビュ​​ーゲート	コードレビューの判断が Pass で、必須のレビュー項目をすべて満たしている（変更したソースファイルのみを対象とする実効行数の上限 <=500 ＋変更したソースファイルのみを対象とする必須の >220 差分ゲート評価＋データフロースパインの一覧／所有権／スパイン外の懸念事項チェック＋既存機能の再利用＋再利用可能な所有構造の抽出＋共有構造／データモデルの密結合度＋共有基盤の一貫性＋繰り返される調整の所有権＋空の間接参照＋スコープに応じた関心の分離＋所有関係に基づく依存関係の品質＋権威ある境界ルールの維持＋正しいサブシステムおよびフォルダー内へのファイル配置（任意のモジュールグループ化には根拠が必要）＋フラットなレイアウトと過剰分割されたレイアウトの判断＋インターフェース／API／クエリ／コマンド／サービスメソッドの境界の明確さ＋ファイル／フォルダー／API／型／関数／パラメーター／変数全体の命名品質＋命名と責務の一致＋変更範囲内に正当化されていないコードの重複／繰り返し構造がないこと＋パッチの重ね合わせによる複雑さの制御＋テスト品質＋テストの保守性＋検証証拠の十分性＋後方互換性なし／レガシーなし）	分類に応じて再開する（Local Fix: 6 -> 7 -> 8、Validation Gap: 7 -> 8、Design Impact: 1 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8、Requirement Gap: 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8、Unclear: 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8）	9
9 ドキュメント同期	docs-sync.md が最新で、ドキュメントの更新が完了しているか、影響がないことの明示的な根拠が記録されている	ドキュメントを正確な状態にできない場合は、分類して再開する（Local Fix: 6 -> 7 -> 8 -> 9、Requirement Gap: 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9、Unclear: 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9）。上流の成果物の変更を必要としない外部ドキュメントのブロッカーがある場合に限り、9 (Blocked) にとどまる	10
10 最終引き継ぎ	引き継ぎの概要が完成しており、ユーザーから明示的な完了／検証の指示を受け取り、チケットが tickets/done/<ticket-name>/ に移動されており、Git リポジトリ内の場合はリポジトリの最終処理が完了しており、該当するリリース／公開／デプロイの手順が完了しているか、不要であることが明示的に記録されており、該当する場合は必須の最終処理後のワークツリー／ブランチのクリーンアップが完了している	ユーザーによる完了確認と、ステージ10のアーカイブ／最終処理／クリーンアップが完了するまで Stage 10 にとどまる	終了

Transition Matrix (Pass/Fail/Blocked)

トリガー	必須の遷移パス	備考
通常の前進	0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> 10	各ステージゲートが Pass の場合にのみ使用します。
Stage 5 のブロッカーが Design Impact に分類された場合	3 -> 4 -> 5	問題が明らかに、スパイン／オーナーシップ／スパイン外の懸念／境界／命名の判断に関する場合に使用します。
Stage 5 のブロッカーが Requirement Gap に分類された場合	2 -> 3 -> 4 -> 5	要件または受け入れ基準の不足や曖昧さが見つかった場合に使用します。
Stage 5 のブロッカーが Unclear に分類された場合	1 -> 2 -> 3 -> 4 -> 5	根本原因が不確か、または複数の領域にまたがっており、まず調査をやり直す必要がある場合に使用します。
Stage 6 の失敗が Local Fix に分類された場合	Stage 6 にとどまる	Stage 6 内で実装／テストを修正し、Stage 7 には進まないでください。
Stage 6 の失敗が Design Impact に分類された場合	1 -> 3 -> 4 -> 5 -> 6	調査のチェックポイントを再開し、実装を続ける前に設計／ランタイムの流れに戻ってください。
Stage 6 の失敗が Requirement Gap に分類された場合	2 -> 3 -> 4 -> 5 -> 6	まず要件を更新し、実装を続ける前に後続の流れを再実行してください。
Stage 6 の失敗（Unclear／複数の領域にまたがる根本原因）	0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6	同じチケットのコンテキスト内で Stage 0 の管理項目を再開し、実装を続ける前に全体の流れを再実行してください。
Stage 7 の失敗が Local Fix に分類された場合	6 -> 7	まず成果物を更新し、次にコードを修正してから、Stage 7 のシナリオを再実行してください。
Stage 7 の失敗が Design Impact に分類された場合	1 -> 3 -> 4 -> 5 -> 6 -> 7	調査を再開し、Stage 7 を再試行する前に設計／ランタイムの流れに戻ってください。
Stage 7 の失敗が Requirement Gap に分類された場合	2 -> 3 -> 4 -> 5 -> 6 -> 7	まず要件を更新し、後続の流れを再実行してください。
Stage 7 の失敗（Unclear／複数の領域にまたがる根本原因）	0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7	同じチケットのコンテキスト内で Stage 0 の管理項目を再開し、全体の流れを再実行してください。
ユーザーの免除がない実行不可能なシナリオ	Stage 7 (Blocked) にとどまる	制約と代替となる証拠を記録し、ユーザーによる明示的な免除または環境の修正を待ってください。
Stage 8 の失敗が Local Fix に分類された場合	6 -> 7 -> 8	修正を適用し、再レビューの前にテストゲートを再実行してください。
Stage 8 の失敗が Validation Gap に分類された場合	7 -> 8	まず Stage 7 のカバレッジ／証拠を強化し、その後コードレビューを再実行してください。
Stage 8 の失敗が Design Impact に分類された場合	1 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8	調査を再開し、再レビューの前に設計の流れに戻ってください。
Stage 8 の失敗が Requirement Gap に分類された場合	2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8	要件に戻り、後続の流れ全体を再実行してください。
Stage 8 の失敗（Unclear／複数の領域にまたがる根本原因）	0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8	同じチケットのコンテキスト内で Stage 0 の管理項目を再開し、再レビューの前に全体の流れを再実行してください。
Stage 9 のドキュメント同期がブロックされ、その結果が Local Fix に分類された場合	6 -> 7 -> 8 -> 9	小規模で具体的な実装、またはチケット成果物の修正が完了するまでドキュメントを事実に即した内容にできない場合に使用します。
Stage 9 のドキュメント同期がブロックされ、その結果が Requirement Gap に分類された場合	2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9	不足または曖昧な意図された動作により、ドキュメントを事実に即した内容にできない場合に使用します。
Stage 9 のドキュメント同期がブロックされ、その結果が Unclear に分類された場合	0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9	最終的な動作が不明瞭すぎる、または複数の領域にまたがっており、事実に即して文書化できない場合に使用します。
外部のドキュメント／アクセス上の問題のみが原因で Stage 9 がブロックされた場合	Stage 9 (Blocked) にとどまる	上流の成果物を変更する必要がなく、ブロッカーがドキュメント環境またはドキュメントアクセスのみに関係する場合に使用します。
Stage 10 でユーザーによる明示的な検証を待っている場合	Stage 10 (In Progress) にとどまる	チケットを done に移動してリポジトリの最終処理を開始する前に、ユーザーによる明示的な完了確認／検証を待ってください。
Stage 10 のアーカイブ／リポジトリの最終処理／リリース公開／デプロイ／クリーンアップがブロックされた場合	Stage 10 (Blocked) にとどまる	移動／コミット／git／リリース公開／デプロイ／クリーンアップのブロッカーを記録し、解消してから引き継ぎを完了してください。

0) ブートストラップチケット＋要件ドラフトの記録

• stages/00-bootstrap/bootstrap-checklist.md を使用します。
• 次の必須の初動手順を実行します。
  • tickets/in-progress/<ticket-name>/ を作成または使用します。
  • git リポジトリの場合、ブートストラップのベースブランチは、ユーザーから明示的な指示があればそれに従い、指示がない場合は、追跡対象のリモートのデフォルトブランチ／統合ブランチを最も確度の高い情報に基づいて推定します。
  • git リポジトリで、新しいチケット用ワークツリー／ブランチが必要な場合は、最初に追跡対象のリモート参照を更新します。
  • git リポジトリの場合、codex/<ticket-name> 用の専用チケットワークツリーを作成または再利用します。新しいチケットブランチを作成する場合は、追跡対象のリモートベースブランチの最新状態から分岐させます。
  • shared/workflow-state-template.md を基に tickets/in-progress/<ticket-name>/workflow-state.md を作成または更新し、Current Stage = 0、Code Edit Permission = Locked に設定して、Stage 0 Bootstrap Record を記入します。
  • ユーザー入力／バグ報告の根拠（テキスト、画像、ログ、再現メモ、制約）から、初期要件スナップショット（ステータス Draft の requirements.md）を最初に記録します。
• Stage 0 のブートストラップと requirements.md の Draft が実際に書き込まれる前に、詳細な調査を実行しないでください。
• リモート参照の更新、ベースブランチの解決、またはチケットワークツリーの作成に失敗した場合は、Stage 0 をブロックしたままにし、古いローカルブランチにフォールバックするのではなく、失敗の内容を workflow-state.md に記録します。
• Stage 1 に移行する前に、workflow-state.md のスナップショット、遷移ログ、ステージゲートの根拠を更新します。

1) 調査＋理解の確認＋トリアージ

• stages/01-investigation/investigation-guide.md を使用します。
• 調査中は継続的に tickets/in-progress/<ticket-name>/investigation-notes.md を作成・更新します。これは簡潔な要約ではなく、長期的に参照できる証拠ログとして扱います。調査結果をメモリ内だけに留めないでください。
• 調査は読み取り専用ではありません。現状の動作を確認したり、根本原因を切り分けたりする必要がある場合は、問題を積極的に再現し、目的を絞ったコマンドやテストを実行し、小規模な診断スクリプトを作成し、一時的な調査コードや計測処理を追加し、問題を観察するために最低限必要な環境設定やモックを行い、公開 API／仕様／課題を読み、証拠の収集に実用的な方法であれば上流／ベンダー／サンプルリポジトリを調査またはクローンします。
• Stage 1 の手法は問題に応じて選択し、網羅的なものではないと考えてください。設計に進む前に、不確実性を減らし、前提を検証するために必要な、範囲を限定した証拠収集を行います。
• 設計に進む前に、コードベースを最低限理解します。
  • 対象となるフローのエントリーポイントと実行境界を特定します。
  • 変更対象ファイル、影響を受けるモジュール／サブシステム、およびそれらが担う責務を特定します。
  • 変更対象の責務に対応する標準的なファイル配置場所／フォルダーの所有者を特定します（例：プラットフォーム固有と共有）。
  • 現在の命名規則（サブシステム名、ファイル名、該当する場合はモジュール名、API スタイル）を特定します。
  • 設計上の前提を無効にする可能性のある不明点を特定します。
• investigation-notes.md には、後続ステージで同じ大規模な検索や調査を繰り返さずに済むよう、十分な詳細を記録します。ただし、事実が変わった場合はこの限りではありません。
  • 調査の目的／質問。
  • 詳細な情報源ログ（local file paths、Web リンク、オープンソースの参照先、論文、実行した正確なコマンド、結果を大きく左右した検索クエリ）。
  • 主な調査結果、制約、確認された動作と、それぞれの正確な情報源との対応。
  • 該当する場合は、正確なファイル／シンボル／エントリーポイント／所有者を含むコードベースの調査結果。
  • ファイル配置に関する所見（適切な所有フォルダーにすでに配置されているファイル、配置が不適切なファイル、標準的な配置場所）。
  • 再現、トレース、スクリプトを使用した場合の、実行時／調査コードの結果。
  • 調査結果に大きく影響した再現の前提条件や環境／設定の詳細。
  • 理解に大きく影響した外部依存関係、公開 API、上流ソース、課題トラッカー、サンプルアプリの調査結果。
  • 未解決の不明点／質問。
  • 要件／設計への影響。
• 簡潔な要約よりも、構造化された詳細なメモを優先します。読みやすさのために短い要約セクションを設けてもかまいませんが、後続ステージで同じ事実を一から再発見する必要がないよう、成果物には具体的な証拠を十分に残します。
• 境界ルール：証拠収集を目的とする、対象を絞った再現スクリプト／テスト、一時的なログ、調査専用の設定、破棄可能なクローンリポジトリ、使い捨てハーネスは Stage 1 の作業です。永続的な本番環境の修正や永続的な検証資産は、後続ステージで扱います。
• 再開ルール：後続の実装／テストで大規模または不明瞭な問題が判明した場合は、この理解ステージに戻り、要件／設計の成果物を変更する前に、新たな証拠、不明点、影響を追記します。
• この理解作業が完了し、requirements.md が Design-ready に達するまでは、設計成果物や実行時の呼び出しスタックを作成しないでください。
• 実用的な指標を使って、Small、Medium、Large に分類します。
  • 変更が見込まれるファイル数（おおむね 3 ファイル以下で、複数領域にまたがらない場合は通常 Small）。
  • 新設／変更されるインターフェース境界、スキーマ／ストレージの変更、複数領域にまたがる動作。
  • 複数の境界に及ぶ影響（API + サービス + 永続化 + 実行時フロー）またはアーキテクチャへの影響。
• ワークフローの深さを選択します。
  • Small：ドラフトの implementation.md に解決策の概要を作成し、それを基にユースケースごとの将来状態の実行時呼び出しスタックを作成してレビューします。安定性ゲートが Go Confirmed に達するまで改良を続け、その後、同じ implementation.md 成果物に実行状況をリアルタイムで追跡する情報を追加します。
  • Medium：まず提案設計書を作成し、それを基に将来状態の実行時呼び出しスタックを作成します。安定性ゲートが Go Confirmed に達するまで、反復して詳細レビューを行います。その後に限り、実装の基準と実行状況のリアルタイム追跡を兼ねる implementation.md を作成します。
  • Large：まず提案設計書を作成し、それを基に将来状態の実行時呼び出しスタックを作成します。安定性ゲートが Go Confirmed に達するまで、反復して詳細レビューを行います。その後に限り、実装の基準と実行状況のリアルタイム追跡を兼ねる implementation.md を作成します。
• 実装中も分類を見直します。対象範囲が拡大した場合や懸念が見つかった場合は、Small から完全なワークフローへ移行します。
• Stage 2 に移行する前に、workflow-state.md のスナップショット、遷移ログ、ステージゲートの証拠を更新します。
• トリアージの深さ（Small／Medium／Large）が確定し、investigation-notes.md が最新になった後は、保存済みの workflow-state.md の遷移／ゲート更新のみをもって通知します。

2) 要件ドキュメントを設計可能な状態にする（必須）

• stages/02-requirements/requirements-refinement-guide.md を使用します。
• すべての規模（Small、Medium、Large）について、tickets/in-progress/<ticket-name>/requirements.md を作成または更新します。
• 小さなタスクでも要件の記述は必須です（簡潔にまとめてもかまいません）。
• 正式なファイルパスは1つだけにします。requirements.md を直接更新し、requirements-v2.md のようなバージョン付きの重複ファイルは作成しないでください。
• 要件の成熟度の流れ：
  • Draft：報告／入力の根拠から大まかに整理します。
  • Design-ready：深い理解の工程を経て精緻化します。
  • Refined：設計／レビュー／実装からのフィードバックで不足が明らかになった場合、さらに更新します。
• requirements.md に最低限必要なセクション：
  • ステータス（Draft／Design-ready／Refined）
  • 目標／問題の記述
  • 対象範囲内のユースケース
  • 受け入れ基準
  • 制約／依存関係
  • 前提条件
  • 未解決の質問／リスク
• 要件の品質ルール（必須）：要件は説明的な記述だけでなく、検証可能な動作仕様でなければなりません。
• 各要件に、安定した requirement_id と明示的な期待結果を含めます。
• 各受け入れ基準に、安定した acceptance_criteria_id（例：AC-001）と、明示的かつ測定可能な期待結果を含めます。
• 受け入れ基準はテスト可能であり、主要な動作と関連するエッジケース／エラーケースを網羅する必要があります。
• コールスタックのユースケースに対する要件カバレッジマップを含めます（すべての要件が少なくとも1つのユースケースに対応する必要があります）。
• Stage 7 のシナリオに対する受け入れ基準カバレッジマップを含めます（すべての受け入れ基準が少なくとも1つの実行可能な検証シナリオに対応する必要があります）。
• トリアージの結果（Small、Medium、Large）とその根拠を要件ドキュメントで確認します。
• 記憶だけに基づいて調査から要件を導き出さず、最新の investigation-notes.md に基づいて要件を精緻化します。
• 設計可能な状態の要件ゲートでは、設計と実行時のコールスタックを作成できる程度に期待される動作を明確にする必要があります。
• Design-ready に到達するのに十分な理解が得られていない場合は、まず理解を深める工程を続けて要件を精緻化します。
• requirements.md が Design-ready となり、設計への入力として確認された後は、永続化された workflow-state.md の遷移／ゲート更新のみをもって通知します。

中核的なモダナイゼーション方針（必須）

• 必須方針：後方互換性を維持せず、レガシーコードも残しません。
• レガシー動作、レガシー API、互換ラッパー、二重書き込み経路、旧フローのためだけに残されたフォールバック分岐を維持しないでください。
• クリーンな置き換えを優先し、不要になったコード、ファイル、テスト、フラグ、アダプターを同じチケット内で明示的に削除します。
• このワークフローに互換性に関する例外を追加しないでください。

共有設計原則（設計＋レビュー、必須）

• 設計とレビューでは、同じ原則と用語を使用する必要があります。レビューは設計品質の確認であり、異なるルール体系ではありません。
• ステージ 3 の設計作業、ステージ 5 のレビュー、ステージ 8 の構造レビューでは、共有の参照資料として shared/design-principles.md を使用してください。
• shared/design-principles.md には、以前は 2 つ目の補助ファイルに分けられていた、適用ワークフロー、構造上のトリガー、局所的な仕組み、例の形式も含まれています。
• ステージ 8 のレビューの参照資料として stages/08-code-review/code-review-principles.md を使用してください。
• 中核となる原則は次のとおりです。
  • データフローの背骨の一覧化と明確さ,
  • 所有権の明確さと境界のカプセル化,
  • 背骨を取り巻く周辺関心事。
• 関心事の分離は引き続き必須であり、このワークフローでは弱めるのではなく、より強化する必要があります。違いは順序です。まず背骨と所有権から始め、その構造を軸に関心事を分解して、各境界の一貫性を保ちます。
• 所有権は関心事の分離を具体化したものです。明確な所有者がいない関心事があれば、構造に問題があります。
• 依存関係の方向は所有権に従います。設計上のリスクがある場合は、許可される方向と禁止される近道を明示してください。
• 権威ある境界のルール（必須）：ある境界がドメイン対象の権威ある公開エントリポイントである場合、その境界より上位の呼び出し元は、その境界と内部で所有する仕組みの両方に同時に依存するのではなく、その境界に依存する必要があります。これは「境界の迂回禁止／異なる階層への混在依存」ルールです。
• 呼び出し元が内部の関心事を迂回する理由が、外側の境界で利用可能な API が十分に公開されていないことだけである場合、その迂回を常態化させるのではなく、権威ある境界を強化するか、所有権の分割を明示的に再設計してください。
• 背骨以外の関心事の再利用も所有権に従います。新しいヘルパーや背骨以外の関心事を追加する前に、既存の機能領域やサブシステムがその責務をすでに所有しているか確認してください。
• 背骨、所有者、背骨以外の関心事はアーキテクチャ上の関係を示す用語であり、命名テンプレートではありません。これらをファイル、フォルダー、クラス、サービス、型の名前にそのまま使わないでください。
• モジュールの配置とファイルの配置は所有権に従います。ファイルのパスが実際の関心事と一致しなくなった場合は、不一致を正当化するのではなく、移動、分割、または名前変更をしてください。
• サブシステム、フォルダー、ファイルの対応付けは、背骨と所有権を基準に行う必要がありますが、機械的に行ってはいけません。任意のモジュールグループ化は、境界を読み取りやすくする場合にのみ補助的な構造として用います。
• 構造の深さが異なるものには、異なるフォルダーが適していることがよくありますが、人為的に分割しすぎないでください。よりフラットな構成のほうが明確な場合は、その理由を明示してください。
• インターフェース境界のルール：API、クエリ、コマンド、再利用されるサービスメソッドも、所有権と関心事の分離に従う必要があります。対象と責務ごとに境界を 1 つ設け、識別子の形式を明示してください。曖昧な ID や汎用セレクターから対象の種類を推測する汎用的な境界は避けてください。
• 明確さが大きく向上する場合は例を使ってください。短い例で意図する形をより早く説明できる場合、分かりにくい設計を完全に抽象的なままにしないでください。
• 現在の構造が、読み取りやすい背骨、明確な所有権、背骨と競合しない周辺関心事をすでに保っている場合は、維持が有効な選択肢です。

3）提案する設計ドキュメントを作成する

• Medium/Large では必須です。Small では任意です。
• 前提条件：このチケットの requirements.md が Design-ready（または Refined）であり、最新の状態であること。
• Small では、完全な設計提案書を必須としないでください。ランタイム呼び出しスタックの軽量な設計基盤として、implementation.md のドラフトにあるソリューションスケッチを使用します。
• アーキテクチャ優先のルール：既存ファイルに作業を割り当てる前に、目標とするアーキテクチャの形を定義します。
• まずデータフローの幹から設計します。
  • 主要な実行／データフローの幹を特定します。
  • 設計の理解に関係するすべての幹を列挙します。
  • 各幹にある主要なドメイン対象ノードを命名します。
  • 各メインラインノードの所有範囲を定義します。
  • それらの所有者を支える幹の外の関心事を特定します。
  • 新しいものを作成する前に、幹の外のニーズが既存の機能領域／サブシステムを再利用または拡張すべきか確認します。
  • 変更が非同期またはイベント駆動の場合は、戻り／イベントの幹を記録します。
  • ループ、ワーカーサイクル、状態マシン、またはディスパッチャーが所有者の振る舞いを大きく左右する場合は、範囲を限定したローカル／内部の幹を記録します。
• 関心の分離ルール（必須）：幹と所有者が明確になったら、幹の外の責務を分割し、各メインノードと幹の外の各関心事をそれぞれ自己完結させます。メインライン上にあるという理由だけで、1つの幹ノードにあらゆる関心事を過剰に集約しないでください。
• Authoritative Boundary Rule（必須）：権威ある公開エントリーポイントと、内部で所有される下位レイヤーの境界を特定します。権威ある境界より上位の呼び出し元が、その境界と、その内部のマネージャー、リポジトリー、ヘルパー、または低レベルの関心事の両方に同時に依存してはなりません。
• 目標とする振る舞いに対して構造的に不適切な場合、現在のファイル配置を設計の基準にしないでください。
• ファイル配置ルール（必須）：目標とするファイルパスは、所有する関心事／境界／プラットフォームに一致させます。codex 固有、cloud 固有、UI 固有、infra 固有、またはその他の範囲に限定されたファイルは、現在それをインポートしている呼び出し元の近くではなく、正式な配置領域に置きます。
• フォルダー構成ルール（必須）：幹と所有モデルに基づいてサブシステム／フォルダー／ファイルを割り当てます。任意のモジュールグループ化は、既定で追加するのではなく、可読性を実質的に高める場合に限って追加します。硬直的に各ステップを1つのフォルダーへ投影するのではなく、適切に判断してください。よりフラットな構成のほうが明確な場合は、その理由を説明します。分割する場合は、実際の所有者または境界を反映させます。
• インターフェース境界ルール（必須）：API、クエリー、コマンド、再利用するサービスメソッドは、明示的な対象所有権と明示的な識別子の形に基づいて設計します。曖昧な ID や汎用セレクターを受け取り、対象がエージェント実行、チーム実行、チームメンバー実行などのどれかを推測する、汎用的な境界を使用しないでください。
• 現状把握ルール（必須）：目標設計を確定する前に、既存のメインフロー、現在の所有者、結合の問題、ファイル配置のずれ、実際の移行上の制約を理解できるだけ、現在の実装を読みます。
• 新しいサブシステム内部のモジュールグループ、境界インターフェース、またはオーケストレーション所有者を導入すべきか、明示的に評価します。
• 既存のサブシステム／所有者を分割、統合、移動、削除すべきか、明示的に評価します。
• 新しい幹の近くに新たなヘルパーを導入するのではなく、既存の機能領域またはサブシステムが新しい幹の外の責務を担うべきか、明示的に評価します。
• 呼び出し元間で調整ポリシー（プロバイダー選択、フォールバック、再試行、集約、ルーティング、ファンアウト）が繰り返されている場合は、そのポリシーを明確な所有者に抽出し、分散したままにしないでください。
• 空の間接化は避けます。提案するレイヤーや任意のモジュールグループが、実質的なポリシー、境界、または順序制御を所有せず、処理をそのまま通すだけの場合は、構成をよりフラットに保ちます。
• アーキテクチャの方向性と、その根拠（complexity、testability、operability、evolution cost）を記録します。
• 単純なローカル変更では、簡潔な判断を1つ示すだけで十分です。代替案は任意です。
• 非自明なアーキテクチャ変更や不確実性の高い変更では、決定前に簡潔な代替案の比較を含めます。
• 問題に適した構造変更（Keep、Add、Split、Merge、Move、Remove）を選びます。編集を最小限にすることを優先しないでください。
• 削除を優先する整理ルール（必須）：目標設計で、より明確な所有者、再利用可能な構造、またはより適切なファイル境界を導入する場合は、不要になる冗長な断片や分散した要素を明示的に特定し、可能な限りスコープ内で削除／廃止します。
• 現在のデータフローの幹、所有権の境界、幹の外の関心事に一貫性がある場合、Keep も有効な判断です。
• ファイルの関心事とフォルダーが一致しない場合、通常 Keep は適切ではありません。明示的な Move、Split、または根拠を示した Promote Shared を優先します。
• 機能／ローカルの正しさだけでは不十分です。バグ修正が「動作」してもデータフローの幹、所有権の境界、または幹の外の関心事を損なう場合は、そのパッチを受け入れず、構造を再設計します。
• ローカルな変更をコンパイル可能にするためだけに、明確な境界を迂回する継ぎはぎの回避策は避けます。
• 目標とするアーキテクチャの方向性を決めた後は、関心を分離します。各ファイルは明確な責務を持ち、各サブシステムは一貫した作業カテゴリを担う必要があります。構成を読みやすくする場合は、サブシステム内に任意のモジュールグループを設けても構いません。これは、関心の分離を弱めるのではなく、より厳格に確認するものです。幹の外の関心事も、汎用的な一枚岩に流れ込ませず、明確な所有者に配置する必要があります。
• 所有権に基づく依存ルール（必須）：サブシステム、サービス、コンポーネントの境界を明確に定義して維持し、許可される依存関係が所有権に従うようにするとともに、禁止される近道を明示します。
• 既存機能の再利用ルール（必須）：既定で新しいヘルパーや幹の外の関心事を作成しないでください。適合する既存の適切な所有サブシステムを再利用または拡張し、適切な既存領域がない場合は Create New の根拠を示します。
• 再利用可能な所有構造のルール（必須）：複数のファイルに繰り返し現れるデータ構造、型、正規化器、コンバーター、マッパー、またはスキーマは、重複させず、適切なサブシステム内の再利用可能な所有ファイルに抽出します。
• データモデルの厳密化ルール（必須）：共有構造を抽出または改訂する際は、構造を厳密化します。冗長な属性を削除し、同じ対象を表す並行した表現が重複しないようにして、各フィールドの意味を単一かつ明確に保ちます。
• 共有ベースの一貫性ルール（必須）：共有ベース／コアは、実際に共通の形を表す場合にのみ使用します。あるケースで追加のフィールドや振る舞いが必要な場合は、何でも入りの構造に任意属性を追加していくのではなく、意味のある特化したバリアントまたはコンポジションを優先します。
• Small では、implementation.md のソリューションスケッチにも、簡潔なアーキテクチャスケッチを含める必要があります（目標とする所有権の境界と新しいファイル、さらに可読性に役立つ場合に限って任意のモジュールグループを記載します）。
• スタックに適した技術境界で関心の分離を適用します。
  • フロントエンド／UI の範囲：ビュー／コンポーネントレベルで責務を評価します（各コンポーネントが明確な関心事を担う必要があります）。
  • 非 UI の範囲（バックエンド／サービス／ワーカー／ドメイン）：サブシステムの構成を読みやすく保ちながら、ファイルとサービスのレベルで責務を評価します。
  • インテグレーション／インフラの範囲：各アダプターまたはインテグレーションに関わるファイル／グループが、明確な契約を備えた1つのインテグレーション関心事を担う必要があります。
• 設計提案書は目標状態だけでなく、差分を意識した内容にします。
  • 現状の要約（as-is）を含めます。
  • 目標状態の要約（to-be）を含めます。
  • Add、Modify、Rename/Move、Remove の変更項目を明示した一覧行を含めます。
• 設計提案書の構成ルール（必須）：ファイル優先ではなく、幹を優先して設計を記述します。文書の主要な構成は、幹の一覧、主要なドメイン対象ノード、所有権、幹の外の関心事とします。
• 設計の具体化順序（必須）：幹と所有モデルを明確にした後、サブシステム／機能領域への割り当てに進み、次にファイルの責務を草案化し、繰り返しが現れた場合は再利用可能な所有構造を抽出し、ファイルの責務を確定してから、フォルダー／パスに割り当てます。
• ファイルのセクションは必須です。サブシステムの構成と任意のモジュールグループは、明確さを高める場合に含めても構いませんが、幹を中心とした説明が明確になった後に、実装への割り当てとして示します。
• 例のルール（必要な場合は必須）：短い適切な例や不適切な構成のアンチパターン例によって、直感的でない設計が大幅に明確になる場合は、抽象的なままにせず、設計提案書に含めます。
• 各ファイルについて、対応する幹、目標とする所有者／境界の配置、責務、主要 API、入力／出力、依存関係、変更種別を記載します。関連する場合は、サブシステムの配置と任意のモジュールグループも記載します。
• 新しい幹の外の関心事ごとに、既存の機能領域を再利用／拡張するのか、新しい領域が必要な理由を記載します。
• 各ファイルについて、目標とするパスが所有する関心事に一致するかを記載し、配置変更が必要な場合は移動／分割の根拠を記録します。
• 命名方針のセクションを設けます。
  • 提案するファイル名、サブシステム名、関連する場合は任意のモジュール名、API 名を記載します。
  • 各命名の根拠を記載します。
  • 名前を変更する場合は、旧名から新名への対応を記載します。
• 自然で、違和感がなく、実装しやすい名前を使います。命名は、ドメイン固有の内部知識がなくても理解できるものにします。
• 設計文書に命名のずれを確認するセクションを追加します。
  • スコープ拡大後も、各ファイル名とサブシステム／モジュール名が現在の責務に一致しているか確認します。
  • ずれた名前（名前が実際の振る舞いを表さなくなっているもの）を特定します。
  • ずれた項目ごとに是正措置（Rename、Split、Move、または根拠を示した N/A）を選びます。
  • 各是正措置を変更項目と実装タスクに対応付けます。
• 依存関係の流れと相互参照のリスクを明示的に文書化します（循環をどう回避するか、または一時的に許容するかを含みます）。
• 所有権の境界間で許可される依存方向を文書化し、撤廃計画を伴う一時的な違反があれば記載します。
• Rename/Move と Remove には、廃止／クリーンアップの意図（インポートの整理とデッドコードの削除）を含めます。
• 実際の改善が、より明確な所有者の追加と、その所有者によって不要になる冗長な断片の削除の両方から得られる場合、追加だけの設計を作成しないでください。
• 関連する場合は、データモデルとエラー処理の想定を記録します。
• 設計文書にユースケース網羅性マトリクスを追加し、少なくとも次の項目を含めます。
  • use_case_id
  • 対応する主要パス（Yes／No）
  • フォールバックパスの対応状況（Yes／No／N/A）
  • エラーパスの対応状況（Yes／No／N/A）
  • ランタイム呼び出しスタック文書内の対応セクション
• レビューループ中は設計のバージョン（v1、v2 など）を付け、各ラウンドでの変更内容を記録します。
• 出発点として stages/03-design/proposed-design-template.md のテンプレートを使用します。
• 後方互換性を持ち込まない設計ゲート（必須）：提案する設計に、互換性ラッパー、二重読み取り／二重書き込みのフロー、レガシーアダプター、または旧来の振る舞いだけを維持するフォールバック分岐を導入してはなりません。
• 設計を成立させるために後方互換性またはレガシー保持の仕組みが必要な場合は Fail と判定し、先へ進む前にアーキテクチャの方向性を再設計します。
• proposed-design.md が変更されたという理由だけで発言しないでください。関連する workflow-state.md の遷移／ゲート更新が永続化された場合にのみ通知します。

4) ユースケースごとに将来状態のランタイムコールスタックを作成する

• すべての規模（Small、Medium、Large）で必須です。
• Small の場合は簡潔にまとめつつ、対象となる各ユースケースについて、主要なパスと、該当する場合は重要なフォールバック／エラーブランチも記載します。
• スコープに応じた根拠：
  • Small：設計の基礎として、ドラフトの implementation.md にあるソリューションの概要を使用します。
  • Medium/Large：設計の基礎として、提案された設計ドキュメントを使用します。
• 各ユースケースについて、エントリーポイントから完了までの将来状態のランタイムコールスタックを、デバッグトレース形式で記述します。
• 安定した use_case_id の値を使用し、IDが設計カバレッジマトリクスおよびレビュードキュメントと一致するようにします。
• 各ユースケースについて、対応するスパイン ID、スパインのスコープ、設計の基礎となるドキュメントで定められた責任者を記録します。
• 使用できるユースケースのソースタイプは次の2種類です。
  • Requirement：明示的な要件の振る舞いから導出されます。
  • Design-Risk：検証が必要なアーキテクチャ上または技術上のリスクから導出されます。
• カバレッジルール（必須）：対象となるすべての要件を、少なくとも1つの Requirement ユースケースでカバーする必要があります。
• 各 Design-Risk ユースケースについて、技術的な目的／リスクの根拠と、想定される観測可能な結果を記録します。
• このドキュメントは、現状のコードをトレースするものではなく、提案された設計（または小規模スコープのソリューション概要）から導出した、アーキテクチャの to-be の振る舞いとして扱います。
• 現在のコードが目標とする設計と異なる場合は、目標とする設計の振る舞いをモデル化し、移行／移行期間中の注記は別途記録します。
• すべてのフレームに、path/to/file.ts:functionName(...) 形式でファイル名と関数名を含めます。
• アーキテクチャの境界（例：controller -> service -> repository -> external API）を明示します。
• 正常系だけでなく、主要なパスとフォールバック／エラーパスも含めます。
• ユースケースごとに、カバレッジの状態（primary/fallback/error）を明示し、意図的に対象外とするブランチには N/A と記載します。
• ユースケースでローカルに範囲が限定されたスパインを使用する場合は、汎用的なエンドツーエンドのスタックに隠さず、そのことを明示します。
• 非同期／イベント境界（await、キューへの追加／取り出し、ワーカーループへの引き渡し）を明示します。
• 状態の変更と永続化ポイント（in-memory state、cache write、DB/file write）を明示します。
• 分岐を決定する条件と判定ポイントを記録します。
• 主要なデータ変換（入力スキーマ -> ドメインモデル -> 出力ペイロード）を記録します。
• レビューの反復における設計の改訂に合わせて、コールスタックにバージョンを付けます（v1、v2、...）。
• stages/04-future-state-runtime-call-stack/future-state-runtime-call-stack-template.md のテンプレートを使用します。
• future-state-runtime-call-stack.md が変更されたという理由だけで通知しないでください。関連する workflow-state.md の遷移／ゲートの更新が永続化された場合にのみ通知します。

5) 将来状態のランタイムコールスタックをレビューする（将来状態＋アーキテクチャ＋命名＋整合性ゲート）

• 必須のレビュー成果物として future-state-runtime-call-stack-review.md を作成します。
• レビューでは、現在のコード構造との同等性ではなく、対象設計の基準（Medium/Large では proposed-design.md、Small では implementation.md の小規模スコープ向けソリューション概要）に照らして、将来状態の正しさと実装可能性を重点的に確認します。
• レビューでは、ファイル単位の関心事の分離だけでなく、アーキテクチャの選択そのもの（スパイン／オーナーシップ／スパイン外の関心事／割り当て）にも異議を唱えます。
• レビューでは、Stage 3 と同じ共有設計原則を再利用します。レビューで別の原則セットを適用しないでください。
• Stage 3 の設計基準に照らして、ファイルの配置を明示的に検証します。誤ったフォルダー配置は、見た目だけの細かな問題ではなく、構造上の欠陥です。
• 提案されたレイアウトがスコープに対して読みやすいか、平坦すぎるか、あるいは不自然に細分化されすぎているかを明示的に判定します。
• 設計で例を使用している場合、または設計が抽象的なままになる場合には、例による明確さを明示的に確認します。
• レビューは明示的なラウンドに分けて実施し、各ラウンドを同じレビュー成果物に記録します。
• 各ラウンドでは、判定を下す前に、専用のユースケース漏れ発見スイープを実施します。
• 各ユースケースを次の基準でレビューします。
  • アーキテクチャ適合性チェック（Pass／Fail）：選択したアーキテクチャの形が、このユースケースと想定される成長に適切か。
  • データフロースパインの明確さチェック（Pass／Fail）：エンドツーエンドの主要な流れと、範囲が限定されたローカルスパインが読みやすく、ピアのコーディネーター間で分断されていないか。
  • スパイン一覧の完全性チェック（Pass／Fail）：関連するすべてのスパインが、明確な開始点・終了点とオーナーシップの関係とともに明示されているか。
  • オーナーシップの明確さチェック（Pass／Fail）：主要経路のノードとスパイン外の関心事に、具体的な権限を持つ明確なオーナーがいるか。
  • スパイン外の関心事の明確さチェック（Pass／Fail）：スパイン外の関心事がスパインを支え、競合したり、隠れた順序制御を担ったりしていないか。
  • 境界配置チェック（Pass／Fail）：責務が適切なオーナーまたはサブシステム境界に割り当てられているか。
  • オーナーシップに基づく依存関係チェック（Pass／Fail）：依存関係がオーナーシップに従い、サブシステム間の密結合や、正当化されていない相互参照の循環を避けているか。
  • Authoritative Boundary Rule チェック（Pass／Fail）：呼び出し側が、外側のオーナーとその内部の下位関心事の両方に依存するのではなく、権威ある境界を使用しているか。
  • ファイル配置の整合性チェック（Pass／Fail）：各ファイルパスが、対象となる関心事／境界／プラットフォームに一致しており、共有配置がある場合は明示的に正当化されているか。
  • 平坦さと過剰分割のレイアウト判定（Pass／Fail）：スコープに対してレイアウトが平坦すぎず、不自然に細分化されすぎてもいないか。
  • インターフェース／API／サービスメソッド境界の明確さチェック（Pass／Fail）：API、クエリ、コマンド、再利用されるサービスメソッドが、明確な対象と責務を一つずつ公開し、汎用的で曖昧な ID や、対象が混在したセレクターではなく、明示的な識別子の形式を使用しているか。
  • 既存構造への偏重チェック（Pass／Fail）：対象アーキテクチャに悪影響を与える形で、現在のファイル構成を模倣するよう設計が強制されていないか。
  • ハック回避チェック（Pass／Fail）：局所的な修正でアーキテクチャ上の問題を隠すような、継ぎ足しの対処法がないか。
  • 局所修正による劣化チェック（Pass／Fail）：機能する修正であっても、データフロースパイン、オーナーシップ境界、またはスパイン外の関心事を劣化させていないか。
  • 例による明確さ（Pass／Fail／N/A）：必要に応じて、直感的でない領域に例が使われ、その例が対象となる形を実際に明確にしているか。
  • 用語と概念の語彙が自然で直感的か（Pass／Fail）。
  • ファイル名と API 名が、実装への対応付けにおいて明確で予測しやすいか（Pass／Fail）。
  • スコープの変化に対する名前と責務の整合性（Pass／Fail）。
  • 対象設計の基準との将来状態の整合性（Pass／Fail）。
  • ユースケース網羅性（主要／フォールバック／エラーの網羅）（Pass／Fail）。
  • ユースケースの出典追跡可能性（Pass／Fail）（出典参照とともに Requirement または Design-Risk を記載）。
  • 要件網羅の完了（Pass／Fail）（すべての要件が少なくとも一つのユースケースに対応付けられているか）。
  • 設計リスクに関するユースケースの正当性の品質（Pass／Fail）（目的／リスクと期待される結果が明確か）。
  • ビジネスフローの完全性（Pass／Fail）。
  • ギャップの指摘事項。
  • オーナーシップに適した関心事の分離チェック（Pass／Fail）（フロントエンド／UI：ビュー／コンポーネントの境界。非 UI：読みやすいサブシステムのグループ化を伴うファイルおよびサービスの境界）。
  • 依存関係の流れに関する懸念事項。
  • 冗長性／重複チェック（Pass／Fail）。
  • 簡素化の余地に関するチェック（Pass／Fail）。
  • 影響を受ける変更における削除／廃止と、旧式／非推奨／デッドパスのクリーンアップの完全性（Pass／Fail）。
  • レガシー保持のクリーンアップチェック（Pass／Fail）（影響範囲について、旧動作／非推奨／デッドパスが削除されているか）。
  • 後方互換性の仕組みのチェック（Pass／Fail）（互換性ラッパー、二重経路の動作、レガシーへのフォールバック分岐が残されていないか）。
  • 全体判定（Pass／Fail）。
• ラウンドの方針：
  • すべてのラウンドで詳細レビューを行います（前提、エッジケース、クリーンアップの品質に異議を唱えます）。
  • ラウンドでブロッカーが見つかった場合、永続化される成果物の更新が必要な場合、または新しいユースケースが見つかった場合は、そのラウンドを分類（Design Impact／Requirement Gap／Unclear）し、分類されたステージ経路に従って必要な上流の更新を適用し、クリーンレビュー連続回数を 0 にリセットします。
  • ブロッカーがなく、永続化される成果物の更新も必要なく、新しいユースケースも発見されなかった場合は、Candidate Go とし、クリーンレビュー連続回数を増やします。
  • クリーンレビュー連続回数が 2 回に達した場合にのみ、Go を確定します。
• ラウンドを通じて品質の推移を追跡します。問題の数や重大度が減少するか、より局所化される必要があります。そうでない場合は、先へ進む前に設計の洗練を強化します。
• ラウンドでのステージ再突入の手順（必須）：
  • Step A：レビューとユースケース漏れ発見を実施し、現在のラウンドに所見を記録します。
  • Step B：ブロッカーを Design Impact／Requirement Gap／Unclear のいずれか一つに分類します。
  • Step C：所見に更新が必要な場合は、まず分類された上流ステージ経路へ移行し、そのステージで必要な成果物を修正して、バージョンを上げます（vN -> vN+1）。
  • Step D：分類と戻り先を含め、何を、どこで、なぜ変更したかを記載した「Applied Updates」エントリーをレビュー成果物に記録します。
  • Step E：更新済みファイルのみを使って次のラウンドを開始します。未解決の編集内容をメモリ上に持ち越さないでください。
  • Step F：クリーンレビュー連続回数の状態（Reset、Candidate Go、または Go Confirmed）をレビュー成果物に記録します。
• Go ゲートの基準（すべて必須）：
  • 対象範囲内のすべてのユースケースで、アーキテクチャ適合性チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、データフロースパインの明確さチェックが Pass であること。
  • 設計基準に対するスパイン一覧の完全性チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、オーナーシップの明確さチェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、スパイン外の関心事の明確さチェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、境界配置チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、オーナーシップに基づく依存関係チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、Authoritative Boundary Rule チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、ファイル配置の整合性チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、インターフェース／API／サービスメソッド境界の明確さが Pass であること。
  • 対象範囲内のすべてのユースケースで、既存構造への偏重チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、ハック回避チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、局所修正による劣化チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、用語／概念の語彙チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、ファイル名と API 名の明確さチェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、スコープの変化に対する名前と責務の整合性チェックが Pass であること。
  • 対象範囲内のすべてのユースケースにおいて、将来状態の動作が対象設計の基準と整合していること。
  • 対象範囲内のすべてのユースケースで、オーナーシップに適した関心事の分離チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、ユースケース網羅性が Pass であること。
  • 対象範囲内のすべてのユースケースで、ユースケースの出典追跡可能性が Pass であること。
  • 対象範囲の要件全体について、要件網羅の完了が Pass であること。
  • すべての設計リスクに関するユースケースで、正当性の品質が Pass であること。
  • 対象範囲内のすべてのユースケースで、冗長性／重複チェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、簡素化の余地に関するチェックが Pass であること。
  • 対象範囲内のすべてのユースケースの全体判定が Pass であること。
  • 未解決のブロッキング所見（必要な設計／コールスタックの更新を含む）がないこと。
  • 影響を受ける Add／Modify／Rename/Move／Remove のスコープ項目について、廃止／クリーンアップと旧式／非推奨／デッドパスのチェックが Pass であること。
  • 2 回のクリーンラウンドで新しいユースケースが発見されないこと。
  • 対象範囲内のすべてのユースケースで、レガシー保持のクリーンアップチェックが Pass であること。
  • 対象範囲内のすべてのユースケースで、後方互換性の仕組みのチェックが Pass であること。
  • 連続する 2 回の詳細レビューで、ブロッカーも、永続化される成果物の更新も、新しいユースケースの発見もないこと。
• 問題が見つかった場合：
  • ブロッカーのある各ラウンドを Design Impact／Requirement Gap／Unclear のいずれか一つに分類し、その分類を future-state-runtime-call-stack-review.md と workflow-state.md に記録します。
  • Design Impact（明確で確度の高い設計上の問題）：Stage 3 で設計基準を更新し（Medium/Large：proposed-design.md、Small：implementation.md の設計セクション）、Stage 4 でコールスタックを再生成してから、Stage 5 に戻ります。
  • Requirement Gap：まず Stage 2 で requirements.md を更新し（ステータスは Refined）、次に Stage 3 で設計基準を更新し、Stage 4 でコールスタックを再生成してから、Stage 5 に戻ります。
  • Unclear（横断的／確度の低い問題）：まず Stage 1 で investigation-notes.md を更新し、その後 2 -> 3 -> 4 -> 5 の順に進みます。
• 命名のずれが見つかった場合は、古い名前をそのまま持ち越すのではなく、同じレビューサイクル内で明示的に名前変更／分割／移動する更新を優先します。
• ラウンドで所見がない場合でも、ラウンドの記録をファイルに必ず完了し、連続する 2 回のクリーンレビューという安定性ルールが満たされるまで、さらに詳細レビューを実施します。
• すべてのゲート Go Confirmed 基準が満たされるまで繰り返します。
• stages/05-future-state-runtime-call-stack-review/future-state-runtime-call-stack-review-template.md のテンプレートを使用します。

6）ソースの実装とユニットテスト／統合テストの実施および進捗の追跡

• ボトムアップのテスト駆動アプローチを採用し、基盤となる依存関係から実装します。
• 以下の順序は必須です。
  • まず、implementation.md のベースラインを確定します。
  • 次に、implementation.md の実行追跡セクションを初期化または更新します。
  • その後、必要な単体テスト／統合テストによる検証を行いながら、ソースを実装します。
• ステージ分離ルール（必須）：
  • ステージ 6 では、読みやすいサブシステム単位のグループ分けを保ちながら、ソースコードを実装し、ファイルとサービスの境界を検証します。また、単体テスト／統合テストを実施します。
  • ステージ 7 では、実行可能な検証アセットを実装し、受け入れ基準に照らして、対応するステージ 7 のシナリオを実行します。
  • ステージ 8 では、ステージ 7 の合格後にコードレビューゲートを実施します。
• 計画／進捗には要件のトレーサビリティを含めます（requirement -> design section -> call stack/use_case -> implementation tasks/tests）。
• 計画／進捗にはスパインのトレーサビリティを含めます（spine -> owner -> use case -> implementation tasks -> validation scenarios）。
• モジュール境界、プロセス境界、ストレージ境界、または外部 API 境界をまたぐ動作には、統合テストによるカバレッジが必要です。こうした動作がテストでカバーされていない場合は、具体的な根拠を記録します。
• キックオフ前に計画成果物を確定します。
  • Small：将来状態のランタイムコールスタックのレビューが最終安定性ゲート（Go Confirmed）を通過するまで、implementation.md の解決策の概要を精緻化します。
  • Medium/Large：将来状態のランタイムコールスタックのレビューが最終安定性ゲート（Go Confirmed）を通過した後にのみ、implementation.md を作成します。
• 実装キックオフ時に、実装前に必要な成果物（Medium/Large の場合は提案設計ドキュメントを含む）が準備できてから、implementation.md の実行追跡セクションを初期化します。
• すべての規模（Small、Medium、Large）で、ベースライン計画と進捗のライブ追跡を統合した実装成果物を 1 つ用意する必要があります。
• ステージ 7、ステージ 8、ステージ 9 の詳細な記録は、それぞれの正規成果物に残します。implementation.md には、実装が担当する計画／追跡情報と、後続工程への引き継ぎ情報、簡潔なステータスのみを記載します。
• 将来状態のランタイムコールスタックとレビューは、実装前検証ゲートとして扱います。コーディング開始前に、各ユースケースが記載され、レビュー済みであることを確認します。
• レビューゲートで実装開始が許可され、対象範囲内のすべてのユースケースが Pass になった後にのみ、実装を開始します。
• ステージ 6 で最初のソースコードを編集する前に、workflow-state.md を更新します。
  • Current Stage = 6 に設定します。
  • Code Edit Permission = Unlocked に設定します。
  • ステージ 5 のゲートが Go Confirmed であり、編集前チェックリストが満たされていることを示す遷移の証跡を記録します。
• 提案設計ドキュメントがある場合は、トレーサビリティを確保します。設計変更インベントリの各行（特に Rename/Move と Remove）を、実装タスクおよび検証手順に対応付けます。
• クリーンカット実装を徹底します。対象範囲内にレガシー互換経路、デッドコード、置き換え後に休止している経路を残してはいけません。
• 後方互換性なしの実装ルール（必須）：ロールアウトを容易にする場合であっても、互換ラッパー、二重経路での読み書き、旧動作へのフォールバック分岐は認めません。
• 共通原則の実装ルール（必須）：ファイル単位の詳細を詰める際も、共通の設計原則と一般的な設計プラクティスを適用し続ける必要があります。レビュー済みの設計成果物は現在の目標であり、コーディング中に判明した、より厳しい実情を無視してよいという許可ではありません。
• オーナーシップと依存関係の維持ルール（必須）：オーナー間またはサブシステム境界をまたぐ、新たな密結合、禁止されている近道、循環依存を導入してはいけません。
• ファイル配置の維持ルール（必須）：編集量を抑えるためだけに、変更対象ファイルを誤った関心事フォルダーに残してはいけません。現在のパスがオーナーシップに合わなくなった場合は、ファイルを移動または分割します。
• 実装完了ルール（必須）：対象範囲内の不要なコード経路、デッドコード、未使用のヘルパー／テスト／フラグ／アダプター、置き換え後に休止している経路、互換シムを削除するまで、実装は完了したとみなされません。
• ソースファイルサイズの先行管理ルール（必須）：ステージ 8 のソースファイルサイズゲートを、変更対象のソース実装ファイルに対するステージ 6 の有効なガードレールとして扱います。実効行数が 500 行を超える変更済みソース実装ファイルを、認識したうえで増やしたり、そのまま残したりしてはいけません。変更対象のソース実装ファイルがこの上限に近づいている場合、または 1 ファイルあたりの現在の差分が変更行数 220 行を超える場合は、ステージ 8 の不合格を待たずに、実装中に分割／リファクタリング／エスカレーションを行います。テストファイルは、このソースファイルの上限の対象外です。
• ステージ 6 の失敗分類ルール（必須）：
  • Local Fix：要件／設計／コールスタックの更新を必要としない、範囲の限定された問題です。ステージ 6 に留まります。
  • Design Impact：上流の設計／ランタイム更新が必要となる、アーキテクチャ／オーナーシップと依存関係／互換性ポリシー違反を示す問題です。Stage 1 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 に再度進みます。
  • Requirement Gap：実装中に判明した、欠落または曖昧な要件／受け入れ基準です。Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 に再度進みます。
  • Unclear：根本原因が横断的、または確信度が低い問題です。Stage 0 -> Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 に再度進みます。
• 詳細な実装作業によって、レビュー済み設計が不完全、脆弱、または誤っていると判明した場合、局所的な回避策で補ってはいけません。問題を記録し、Design Impact に分類して、ソース編集を続ける前に上流の設計／ランタイム成果物を修正します。
• 変更が「機能する」ようにするためにファイルを誤ったフォルダーに残したり、新たな誤配置ファイルを追加したりする必要がある場合、Local Fix に分類してはいけません。実際の問題が要件の欠落でない限り、Design Impact として扱います。
• 絶対的な規則ではなく、通常の実行戦略として「一度に 1 ファイル」を採用します。
• まれに相互参照を避けられない場合は、限定的な並行／未完了状態での実装を認めますが、以下を明示的に記録します。
  • 相互参照に関する懸念点
  • ブロックされている依存エッジ
  • ブロックを解除する条件
  • 必要な提案設計ドキュメントの更新
• 実装中は、進捗をリアルタイムで更新します（ファイルの状態変更、テスト実行、ブロッカーの発見、設計フィードバックループの更新の直後）。
• 進捗には変更 ID と変更種別（Add／Modify／Rename/Move／Remove）を記録し、リファクタリングの差分が実行中も明確に追跡できるようにします。
• ファイルのビルド状態を明示的に追跡します（Pending、In Progress、Blocked、Completed、N/A）。
• 単体テスト／統合テストの状態は、ビルド状態とは別に追跡します（Not Started、In Progress、Passed、Failed、Blocked、N/A）。
• ファイルが未完了の依存関係によってブロックされている場合、そのファイルを Blocked とし、依存関係とブロック解除条件を記録します。
• 実装が完了し、必要なテストが合格した場合にのみ、ファイルを Completed とします。
• 次の条件をすべて満たした場合にのみ、ステージ 6 を完了とします。
  • 実装ベースラインの対象範囲が提供されている（または逸脱が明示的に記録されている）。
  • 必要な単体テスト／統合テストが合格している。
  • 対象範囲内に後方互換性シムや旧動作へのレガシー分岐が残っていない。
  • 対象範囲内のデッドコード、不要なファイル、未使用のヘルパー／テスト／フラグ／アダプター、置き換え後に休止している経路が削除されている。
  • オーナーシップに基づく依存関係が妥当な状態に保たれ、新たに正当化できない密結合／循環依存が導入されていない。
  • 変更対象ファイルの配置が適切であるか、オーナーの関心事にパスが合うよう移動／分割されている。
  • 変更対象のソース実装ファイルについて、サイズ超過を避ける先行対応（>500 の回避、および必要に応じた >220 変更行の負荷評価と対処）が記録されている。
• stages/06-implementation/implementation-template.md を使用します。
• 通常の implementation.md の編集については告知しません。永続化された workflow-state.md のイベント（ステージ 6 への移行、ロック／ロック解除の変更、ゲート／遷移の結果）についてのみ告知します。

7）API／E2E およびその他の実行可能な検証を実装し、ステージ 7 のゲートを実行します（必須）

• Stage 6 が完了した直後に、このステージを実行します。
• Stage 7 の開始時に workflow-state.md を更新し、Stage 7 の検証アーティファクトを実装・実行している間は Code Edit Permission = Unlocked を維持します。
• 正式なシナリオおよび結果のアーティファクトとして、tickets/in-progress/<ticket-name>/api-e2e-testing.md を作成または更新します。
• 複数ラウンドのアーティファクト規則（必須）：チケットごとに正式な api-e2e-testing.md のパスを1つ維持します。デフォルトでは、バージョン別のコピーを作成しないでください。再実行のたびに、まず未解決の過去の失敗を確認してから、検証を続行します。最新ラウンドの結果を正式な結果とし、以前のラウンドは履歴として残します。
• ラウンド解決規則（必須）：Stage 7 のラウンドが >1 の場合、新しいゲート結果を宣言する前に、前回の失敗に対する解決確認を更新します。
• Stage 7 の範囲には、必要に応じて以下が含まれます。
  • リポジトリに永続的に置く検証アセットの実装
  • 必要に応じた、API、ブラウザー/UI、ネイティブデスクトップ/UI、CLI、プロセス／ライフサイクル、統合、複数サービス、複数ノードのハーネスの実装
  • 受け入れ基準から割り当てられた Stage 7 シナリオの実行
• 検証優先の永続化規則（必須）：まず、将来の変更にも適用され、リポジトリに残すべき検証テスト、ハーネス、アセットを実装または更新します。
• より広範な実行可能検証規則（必須）：リポジトリに永続的に置く検証だけでは動作を証明できない場合は、必要に応じて、より広範な実行可能検証を続けます。これには、一時スクリプト、プローブ、環境設定、コンテナー化された環境設定、依存関係のモック化またはエミュレート、CLI ハーネス、ネイティブデスクトップの自動化、ライフサイクル／更新／再起動の確認、複数プロセスまたは複数ノードのオーケストレーション、あるいはフローを検証する妥当な方法としてのブラウザー／コンピューターの自動化が含まれます。
• 永続性規則（必須）：将来の変更にも役立つ検証は、コードベースに残します。一度限りの検証用の足場は、一時的なものでもかまいません。
• クリーンアップ規則（必須）：結果の記録後、一時的な検証専用の足場は、永続的なカバレッジとして残す明確な価値がない限り削除します。
• Stage 7 の失敗にソースコードの変更が必要な場合は、再入場を宣言し、まず Stage 6 に戻ります。
• シナリオの情報源（必須）：
  • 要件主導のシナリオ（重要な要件とフローをすべて網羅する必要があります）
  • 設計リスク主導のシナリオ（アーキテクチャ／設計上の選択によって生じた技術的リスクを網羅する必要があります）
• スパインの網羅規則（必須）：承認済みの設計基準にある、該当するすべてのスパインを少なくとも1つの Stage 7 シナリオに対応付けるか、根拠を示して明示的に N/A とします。
• 受け入れ基準の完了ループ（必須）：
  • requirements.md を情報源とする、明示的な Stage 7 受け入れ基準マトリックスを作成し、維持します（acceptance_criteria_id -> 対応するシナリオ ID -> 実行ステータス）。
  • 対象範囲内のすべての受け入れ基準を、実行開始前に少なくとも1つの実行可能な Stage 7 シナリオに対応付ける必要があります。
  • 明示的に N/A とされている場合を除き、該当するすべてのスパインを、実行開始前に少なくとも1つの実行可能な Stage 7 シナリオに対応付ける必要があります。
  • ステータスが Unmapped、Not Run、Failed、または Blocked の受け入れ基準が1つでもあれば、ユーザーの判断で実行不可能なケースについて明示的に Waived とされた場合を除き、Stage 7 は未完了のままとなり、再入場が必要です。
  • 対象範囲内のすべての受け入れ基準が Passed または明示的に Waived となるまで、必要な再入場チェーンを再実行して Stage 7 に戻ります。
• 各シナリオについて、最低限、次の内容を記録します。
  • scenario_id
  • 対応付けられた spine_id の値
  • 対応付けられた acceptance_criteria_id の値
  • 対応付けられた requirement_id および use_case_id の値
  • ソース種別（Requirement／Design-Risk）
  • 検証モード（API／Browser-E2E／Desktop-UI／CLI／Integration／Process／Lifecycle／Other）
  • プラットフォーム／ランタイムの対象
  • 期待される結果
  • 該当する場合、追加または更新した永続的な検証アセット
  • 該当する場合、使用した一時的な検証方法／設定
  • 実行コマンド／ハーネス
  • 結果（Passed／Failed／Blocked／N/A）
• 安定したシナリオ ID の規則（必須）：再実行でも、同じシナリオには同じ scenario_id を再利用します。新たに網羅対象が見つかった場合にのみ、新しい scenario_id を追加します。
• シナリオパターンの例（例示であり、網羅的ではありません）：
  • バックエンド／サービスの API 変更：リクエスト -> ハンドラー -> ドメイン／サービス -> 永続化 -> レスポンス契約
  • ブラウザー UI のフロー：ユーザー操作 -> UI 状態の変更 -> ネットワークへの影響 -> 描画された確認／エラー状態
  • ネイティブデスクトップのアップデーターのフロー：バージョン from -> アップデートのダウンロード／適用 -> 再起動／再起動 -> バージョン to -> 永続化された状態／マイグレーションの確認
  • ワーカー／プロセスのフロー：キューへの登録／トリガー -> ワーカーループ／プロセスへの引き渡し -> 副作用 -> 完了／確認応答の状態
  • 分散／複数ノードのフロー：ノード A の操作 -> レプリケーション／同期 -> ノード B で確認できる状態またはフェイルオーバーの動作
• API テストの深度に関する規則（必須）：検証モードが API の場合、対応付けられた受け入れ基準について、必須フィールド／スキーマ形状、ステータスコード、エラーペイロードの動作を含む契約レベルの動作を検証します。
• ライフサイクル／更新規則（必須）：シナリオがインストール／更新／起動／再起動／シャットダウン／マイグレーション／復旧の動作を対象とする場合、該当するバージョン from／to、プラットフォーム／ランタイムの対象、該当するパッケージ／更新チャネルまたはフィード、再起動の証拠、永続化された状態の結果を記録します。
• 境界横断テスト規則（必須）：クライアント／サーバー、複数サービス、または複数プロセスの範囲では、境界をまたぐ連携動作（トリガー -> 境界を越えた引き渡し -> 下流への影響 -> 返却または観測可能な状態）を検証する Stage 7 シナリオを含めます。
• 手動テスト方針：構造化されていない手動のみのテストは、デフォルトのワークフローに含まれません。OS／プラットフォームの制約により人の補助を伴う実行手順が避けられない場合は、正確な手順、自動化によって取得した証拠、制約、残存リスクを記録します。場当たり的な手動確認を、十分な Stage 7 のカバレッジとして扱わないでください。
• 実現可能性に関する方針：
  • 現在の環境でシナリオを実行できない場合（シークレット／トークンの不足、連携先システムの利用不可、インフラの制限など）、具体的な実行不可能の理由と制約を api-e2e-testing.md に記録します。必要に応じて、後続のステータスへの短いポインターのみを implementation.md に記録します。
  • 実行不可能な重要シナリオごとに、代替となる自動検証の証拠と残存リスクの注記を記録します。
  • ユーザーが実行不可能な受け入れ基準への免除を明示的に承認しない限り、Stage 7 を Blocked とします。
• 検証保持方針：
  • 将来のリポジトリの動作を担保する検証アセットであれば、保持してそのパスを記録します。
  • 現在のチケットを一時的な方法で検証する目的のみで存在するアセットは、一時的なものとして記録し、保持する明確な価値がない限り、使用後に削除します。
• テストフィードバックのエスカレーション方針（必須）：
  • 失敗した各 Stage 7 シナリオを、必ず Local Fix、Design Impact、Requirement Gap、Unclear のいずれか1つに分類します。
  • 最終分類の前に、調査の判定を実施します。
    • 問題の影響範囲が横断的である場合、未知のランタイムパスに関わる場合、または根本原因の確度が低い場合は、Investigation Required とし、まず理解ステージを再開します（設計／要件のアーティファクトを更新する前に investigation-notes.md を更新する必要があります）。
    • 問題の範囲が明確に限定され、根本原因の確度が高い場合は、そのまま分類を続けます。
  • 責務の境界が維持され、新しいユースケース／受け入れ基準が不要で、要件／設計の変更も不要な場合に限り、Local Fix として扱えます。
  • 修正が機能上は動作しても、データフローのスパイン、所有権の境界、またはスパイン外の懸念事項を損なう場合、Local Fix にはなりません。Design Impact と分類します。
  • ファイルを誤ったフォルダーに残したり、新たに誤った場所へファイルを追加したりしなければ機能しない修正は、Local Fix にはなりません。Design Impact と分類します。
  • 失敗した動作から、機能／ユースケースの不足、または受け入れ基準の不足／曖昧さが明らかになった場合は、Requirement Gap と分類します。
  • ソースコードの編集が必要で、設計または要件の更新が必要な場合は、編集前に再入場を宣言します。
  • Local Fix の経路：まずアーティファクトを更新し、その後 Stage 6 -> Stage 7 を再実行します。
  • Design Impact の経路：Stage 1 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7
  • Requirement Gap の経路：Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7
  • Unclear／横断的な根本原因の経路：Stage 0 -> Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7
• ステージ完了ゲート：
  • リポジトリに残すべき、永続的で実行可能な検証を実装または更新していること
  • requirements.md の対象範囲内のすべての受け入れ基準を Stage 7 シナリオに対応付けていること
  • 設計基準にある該当するすべてのスパインを Stage 7 シナリオに対応付けるか、明示的に N/A としていること
  • 実行可能な対象範囲内のすべての受け入れ基準の実行ステータスが Passed であること
  • 実行可能な該当スパインすべてに、合格したシナリオの証拠があること
  • 対応付けられた実行可能な Stage 7 シナリオがすべて解決済み（Passed）で、未解決の失敗／ブロッカーがないこと
  • 一時的な検証専用の足場を削除するか、根拠を明示して保持していること
  • 環境の制約により実行不可能な受け入れ基準がある場合、制約、代替検証の証拠、残存リスクを含むユーザーの明示的な免除を記録するまで、Stage 7 を Blocked のままとすること
• Stage 8 へ移行する前に、Stage 7 のゲート結果と移行の証拠を workflow-state.md に更新します。
• stages/07-api-e2e/api-e2e-testing-template.md を使用します。
• api-e2e-testing.md の編集だけについて発言しないでください。workflow-state.md に Stage 7 の開始、ゲート結果、および再入場の宣言／ロック状態の変更が記録された時点で、その旨を知らせてください。

8）コードレビューゲートの実行（必須、テスト後）

• このステージは、Stage 7 の実行可能ファイル検証ゲートが Pass の場合にのみ実行してください。
• Stage 8 の開始時に workflow-state.md を更新し、Code Edit Permission = Locked に設定してください。
• 正式なコードレビュー成果物として tickets/in-progress/<ticket-name>/code-review.md を作成または更新してください。
• 調査コンテキストのルール（必須）：変更範囲、現在の動作に関する調査結果、外部制約、またはレビュー所見を実質的に説明する場合、Stage 8 は最新の investigation-notes.md を上流コンテキストとして参照できます。調査ノートはコンテキストであり、レビューの判断根拠ではありません。
• 複数ラウンド成果物のルール（必須）：チケットごとに正式な code-review.md のパスを1つ維持してください。既定ではバージョン付きのコピーを作成しないでください。再実行のたびに、まず未解決の過去の所見を再確認してから、新たにレビューを実施してください。最新のレビューラウンドが正式な判断となり、以前のラウンドは履歴として残ります。
• ラウンド解決ルール（必須）：Stage 8 のラウンドが >1 の場合、新しいゲート結果を宣言する前に、過去の所見に対する解決状況の確認を更新してください。
• 対象範囲：
  • ソースファイルとテストファイル。
  • 変更ファイル、および構造上のリスクがある場合は直接影響を受ける関連ファイルを含めてください。
• ファイルサイズゲートの対象範囲（必須）：>500 の実効行数上限と >220 の変更行数差分ゲートは、変更されたソース実装ファイルのみに適用されます。テストファイルも正確性、保守性、検証品質の観点からレビュー対象に含めますが、ソースファイル向けのこれらのサイズ基準を超えただけでゲート失敗とはなりません。
• 必須レビュースコアカードのルール（必須）：Stage 8 の各ラウンドで、優先順位順の詳細なスコアカードを code-review.md に記録してください。次の10項目を 1.0 から 10.0 まで 0.5 刻みで採点し、各行について、その点数にした理由、弱点、改善すべき点を記録してください。
  • 1 データフロースパインの把握と明確さ、
  • 2 所有権の明確さと境界のカプセル化、
  • 3 API／インターフェース／クエリ／コマンドの明確さ、
  • 4 関心事の分離とファイル配置、
  • 5 共有構造／データモデルの簡潔さと再利用可能な所有構造、
  • 6 命名品質と局所的な可読性、
  • 7 検証の強度、
  • 8 エッジケースにおける実行時の正確性、
  • 9 後方互換性なし／レガシーの保持なし、
  • 10 クリーンアップの完全性。
• レビュー順序のルール（必須）：設計上の推論が、データフロースパインの把握 -> 所有権／境界の権限 -> API の形状 -> 関心事の分離と配置 -> 共有構造 -> 命名 -> 検証 -> 実行時のエッジケース -> 後方互換性なし／レガシーの保持なし -> クリーンアップの完全性、の順に進むよう、記載順にスコアカードを評価してください。
• スコアカード全体のルール（必須）：概要／傾向の把握のみを目的として Overall: X.X / 10 と YY / 100 を報告してください。全体スコアを報告する場合、単純平均でもかまいませんが、平均値を Stage 8 の合否基準として使用してはいけません。
• 項目別ゲートのルール（必須）：スコアカードのすべての項目が必須です。Stage 8 を問題なく通過する目標は、すべての項目で >= 9.0 です。9.0 未満の項目は実際の問題であり、通常は Stage 8 を失敗とすべきです。
• スコアカードの解釈ルール（必須）：スコアカードは診断と比較のためのものであり、平均値で不合格を回避するためのものではありません。全体スコアが高くても、優先度の低い項目の不合格や、必須の Stage 8 チェックの不合格を覆すことはできません。
• スコア項目の所有権に関する注記（必須）：所有権に基づく依存関係の品質と近道の回避は、独立した最上位のスコア項目ではなく、主に 所有権の明確さと境界のカプセル化、API／インターフェース／クエリ／コマンドの明確さ、関心事の分離とファイル配置 の中で評価してください。この領域で最も重要なシグナルとなるチェックは Authoritative Boundary Rule です。
• 必須レビュー項目：
  • データフロースパインの把握を維持していること。
  • 所有権の境界を維持していること。
  • スパイン外の関心事が明確であること。
  • 既存の機能／サブシステムを再利用していること。
  • 繰り返し使われる構造を重複したままにすべきでない場合、再利用可能な所有構造を抽出していること。
  • 共有構造／データモデルが簡潔で、共有ベースの一貫性があること。
  • 繰り返し発生する調整処理の所有権が明確であること。
  • 空の間接化を抑制していること。
  • 対象範囲に見合った関心事の分離と、ファイルの責務が明確であること。
  • 所有権に基づく依存関係の品質（疎結合、不当な循環がないこと、禁止された近道がないこと）。
  • Authoritative Boundary Rule を維持していること（呼び出し元が、権威ある境界とその内部の下位レベルの関心事の両方に依存しないこと）。
  • 共有設計原則および一般的な設計慣行に照らしたアーキテクチャ／境界の品質。
  • 共有設計原則および一般的な設計慣行に照らしたファイル配置とフォルダー所有権の品質。
  • フラットなレイアウトと過剰分割されたレイアウトの判断。
  • 明示的な識別子の形状を備えたインターフェース／API／クエリ／コマンド／サービスメソッドの境界が明確であること。
  • ファイル／フォルダー／API／型／関数／パラメーター／変数全体の命名品質。
  • 命名と責務の整合性、およびその乖離。
  • 変更範囲に不当なコードの重複や繰り返し構造がないこと。
  • パッチを重ねることによる複雑さの兆候。
  • 変更範囲における不要／陳腐化したコードのクリーンアップが完了していること。
  • 後方互換性の仕組みがなく、レガシーコードが保持されていないこと。
  • テスト品質、テストの保守性、検証エビデンスの十分性。
• 安定した所見 ID のルール（必須）：複数のレビューラウンドにわたって同じ未解決の問題には、同じ所見 ID を再利用してください。新たな所見 ID は、新たに発見された問題に限り作成してください。
• 過去の設計成果物は Stage 8 のコンテキストとしてのみ扱い、判断根拠にはしないでください。独立したレビューで過去の設計根拠が弱い、不完全、または誤りだと判明した場合は、Design Impact に分類してください。
• ソースファイルサイズのポリシー（必須）：
  • 変更されたソースファイルごとに、行数を明示的に測定してください。
    • 実効空白行以外の行数コマンド：rg -n "\\S" <file-path> | wc -l
    • ファイルごとの変更行数差分コマンド：git diff --numstat <base-ref>...HEAD -- <file-path>
  • 適用基準には、実効空白行以外の行数を使用してください。
  • 実効空白行以外の行数が <= 500 の変更ソースファイルには、通常のレビュー項目を適用してください。
  • 上限ルール：変更されたソースファイルの実効空白行以外の行数が > 500 の場合、既定では Design Impact に分類し、Stage 8 の判断を Fail としてください。
  • 上限 > 500 の場合、既定では続行せず、まず調査チェックポイントを経由して再実行してください（Stage 1 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8）。
  • このワークフローには中間の緩和帯（501-700）も既定の例外経路もありません。
  • 差分ゲート（必須）：単一の変更ソースファイルで、現在の差分における変更行数が > 220 の場合、ファイルサイズが <= 500 であっても、設計への影響を評価して記録してください。
• ゲート判定：
• Pass：必須レビュー項目（<=500 の上限 + 必要な >220 差分ゲートの評価 + データフロースパインの把握／所有権／スパイン外の関心事のチェック + 既存機能の再利用 + 再利用可能な所有構造の抽出 + 共有構造／データモデルの簡潔さ + 共有ベースの一貫性 + 繰り返し発生する調整処理の所有権 + 空の間接化の抑制 + 対象範囲に見合った関心事の分離 + ファイルが正しいサブシステムとフォルダーに配置されていること（任意のモジュール分けには正当な理由があること）+ フラットなレイアウトと過剰分割されたレイアウトの判断 + インターフェース／API／クエリ／コマンド／サービスメソッドの境界の明確さ + ファイル／フォルダー／API／型／関数／パラメーター／変数全体の命名品質 + 命名と責務の整合性 + 変更範囲に不当なコード／繰り返し構造の重複がないこと + パッチを重ねることによる複雑さの抑制 + 変更範囲における不要／陳腐化したコードのクリーンアップの完全性 + テスト品質 + テストの保守性 + 検証エビデンスの十分性 + 後方互換性なし／レガシーなしのチェック）がすべて Pass であり、詳細なレビュースコアカードが正式な優先順位順で記録され、スコアカードのどの項目も 9.0 未満でない場合に限り、Stage 9 に進んでください。
  • Fail：ソースコードの編集を行う前に、再実行の宣言を適用し、再実行マッピングに従ってください。
• Stage 8 の失敗分類ルール（必須）：
  • Local Fix：設計または要件成果物の更新は不要で、共有設計原則と意図された動作の範囲内にとどまるものの、ソースの変更が必要な問題です。Stage 6 -> Stage 7 -> Stage 8 を再実行してください。
  • Validation Gap：主な問題が Stage 7 のカバレッジまたはエビデンスの不足である場合です。既定では設計やソースの変更を強制せず、Stage 7 -> Stage 8 を再実行してください。
  • Design Impact：独立したレビューでコード内のアーキテクチャ上または構造上の問題が見つかった場合、または過去の設計根拠が弱い／誤り／不完全だと明らかになった場合です。Stage 1 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8 を再実行してください。
  • Requirement Gap：レビューで、意図された動作が欠落または曖昧だと判明した場合です。Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8 を再実行してください。
  • Unclear：根本原因が複数の領域にまたがるか、確信度が低い場合です。Stage 0 -> Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8 を再実行してください。
• パスによって所有権が不明瞭になる場合（たとえば、明示的な共有境界の根拠なくプラットフォーム固有のコードがそのプラットフォームのフォルダー外にある場合）、誤った場所に配置されたファイルはレビュー不合格として扱ってください。
• コードレビューでソースの変更が必要な場合は、Stage 6 -> Stage 7 -> Stage 8 を再実行してください。
• コードレビューで必要なのが検証エビデンスの強化のみの場合は、Stage 7 -> Stage 8 を再実行してください。
• stages/08-code-review/code-review-template.md を使用してください。
• code-review.md の編集だけを根拠に報告しないでください。workflow-state.md に Stage 8 の開始、ゲート結果、および再実行の宣言が記録された時点で報告してください。

9) プロジェクトドキュメントの同期（テストとレビュー後に必須）

• stages/09-docs-sync/docs-sync-guide.md を使用します。
• 正式な Stage 9 成果物として、tickets/in-progress/<ticket-name>/docs-sync.md を作成または更新します。
• stages/09-docs-sync/docs-sync-template.md を使用します。
• Stage 7 の実行可能な検証と Stage 8 のコードレビューが完了した後、プロジェクトの docs/ フォルダー（および影響を受ける場合は ARCHITECTURE.md などのその他の正式なアーキテクチャドキュメント）を更新し、ドキュメントに最新のコードベースの動作を反映させます。
• docs/ は、現在のコードベースに関する長期的な正式な信頼できる情報源として扱います。
• tickets/ 配下のチケット成果物は、タスク固有の期間限定の記録として扱います。長期的な信頼できる情報源ではありません。
• Stage 9 は、永続的な設計や実行時の知見を、期間限定のチケット成果物から長期的なプロジェクトドキュメントへ移すためのものです。
• 目的は変更点を説明するだけではなく、チケットのアーカイブ後にコードベースをより理解しやすくすることです。
• 関連するドキュメントがまだない場合は、現在の機能に合った明確で自然な名前のドキュメントを docs/ に新規作成します。
• 関連するドキュメントがすでにある場合は、重複するドキュメントを新たに作成せず、既存のドキュメントを更新します。
• Stage 9 では、次の点を説明します。
  • 何が変わったか。
  • なぜ変わったか。
  • サブシステム、境界、または実行時の構成が現在どのようになっているか。
  • 何が削除または置き換えられたか。
  • 運用や検証に関する期待事項がどう変わったか。
• 次の内容についてドキュメントを更新します。
  • 新しいファイル、モジュール、または API。
  • 変更された実行時のフロー。
  • 名前変更、移動、削除されたコンポーネント。
  • 動作の変更に伴い更新された運用手順やテスト手順。
• ドキュメントへの影響がない場合は、その理由とともに「No docs impact」という明示的な判断を docs-sync.md に記録します。
• Stage 9 のブロック時の対応／再開ポリシー（必須）：
  • 最終的な実装状態またはチケット成果物に小さく具体的な修正が必要で、まだ正確なドキュメントを作成できない場合は、Local Fix に分類し、Stage 6 -> Stage 7 -> Stage 8 -> Stage 9 を再実行します。
  • ドキュメントの作成中に、意図された動作に不足や曖昧さがあると判明した場合は、Requirement Gap に分類し、Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8 -> Stage 9 を再実行します。
  • 最終的な実装状態または意図された動作が不明瞭すぎる、あるいは影響範囲が広すぎて正確にドキュメント化できない場合は、Unclear に分類し、Stage 0 -> Stage 1 -> Stage 2 -> Stage 3 -> Stage 4 -> Stage 5 -> Stage 6 -> Stage 7 -> Stage 8 -> Stage 9 を再実行します。
  • 外部のドキュメントシステムまたはドキュメントへのアクセスが妨げとなっている場合に限りドキュメント作成を完了できないときは、Stage 9 を Blocked のままにして、妨げが解消するまで Stage 9 に留まります。
  • Stage 9 の再開経路を workflow-state.md に記録した後は、その説明だけで止めず、直ちに再開先の最初のステージに進みます。
• ドキュメントの内容が最終的に実装された動作と一致した場合にのみ、ドキュメントの同期は完了です。
• ドキュメント同期の結果（Updated／No impact）を記録した後は、永続化された workflow-state.md の遷移／ゲート更新のみを告知します。

10) 最終引き継ぎ

• 実装の実行、ステージ 7 の実行可能な検証、ステージ 8 のコードレビュー、ドキュメントの同期がすべて完了してから、ハンドオフを完了してください。
• ステージ 10 の正式な成果物として、tickets/in-progress/<ticket-name>/handoff-summary.md を作成または更新してください。
• stages/10-handoff/handoff-guide.md と stages/10-handoff/handoff-summary-template.md を使用してください。
• ハンドオフサマリーには、以下を含めてください。
  • 提供した範囲と計画していた範囲
  • 検証の概要（ユニットテスト／統合テストに加え、ステージ 7 の実行可能な検証、受け入れ基準の完了状況、実現不可能な基準については制約の記録、自動化された代替エビデンス、明示的なユーザーによる免除の参照先）
  • 更新したドキュメントファイル（または影響がないことの明示的な理由）と、docs-sync.md 成果物のパス
  • リリースノートの状況（作成済みの場合は成果物のパス、不要の場合は明示的な理由）
• リリースノートが必要な場合は、ユーザーの検証を待つ前に tickets/in-progress/<ticket-name>/release-notes.md を作成または更新してください。
• リリースノートの内容に関するルール（リリースノートが必要な場合は必須）：
  • ユーザー向けの機能に関する短い説明のみを記載してください。
  • 内部リファクタリング、依存関係の更新、テスト、ドキュメントのみの変更、低レベルの実装詳細は記載しないでください。
  • すべてのセクションを通じて、箇条書きは合計 3〜7 個を目安にしてください。
  • stages/10-handoff/release-notes-template.md のテンプレートを使用してください。
  • デフォルトのセクションは ## 新機能、## 改善、## 修正 です。
  • 内容のないセクションは、埋め草を書かずに省略してください。
  • ユーザーから明示的に求められない限り、アップグレード手順を記載しないでください。
• ハンドオフサマリーの作成後も、ユーザーが完了／検証を明示的に確認するまで、ステージ 10 をオープンのままにしてください（たとえば、手動テストの後など）。ユーザーからその合図があるまでは、チケットを done に移動したり、コミット、プッシュ、マージを行ったり、リリース／公開／デプロイ作業を実行したりしないでください。
• ユーザーから完了／検証の明示的な確認を受けた後は、最終コミットの状態にアーカイブ済みチケットのパスが含まれるように、まずチケットフォルダーを tickets/done/<ticket-name>/ に移動してください。
• プロジェクトが git リポジトリの場合、リポジトリの最終処理は必須です。チケットフォルダーの移動後、ステージ 10 のクリーンアップを開始する前に、以下の順序で実行してください。
  • 移動したチケットファイルを含む、チケットブランチ／ワークツリー上の対象範囲内の変更をすべてコミットする
  • チケットブランチをリモートにプッシュする
  • マージ前に、解決済みの最終化先ブランチをリモートから更新する
  • 更新済みの最終化先ブランチにチケットブランチをマージする
  • 更新済みの最終化先ブランチをリモートにプッシュする
• リポジトリの最終処理後、プロジェクトでリリース／公開／デプロイが適用される場合は、ドキュメントに記載されたプロジェクトの方法を実行してください。これには、リリーススクリプト、ドキュメントに記載されたコマンド、git タグのワークフロー、GitHub Release の作成、その他のドキュメントに記載されたデプロイ／公開手順が含まれます。
• リリース／公開／デプロイの手順が適用されない場合は、その旨を明記してください。その場合も、リポジトリの最終処理を妨げないでください。
• リポジトリの最終処理と、該当するリリース／公開／デプロイ作業の後、ステージ 0 にこのチケット専用のワークツリー／ブランチが記録されている場合は、ステージ 10 の完了とする前に、以下のクリーンアップを必ず行ってください。
  • 必要であれば、チケットのワークツリーを削除する前に、安全な親リポジトリのチェックアウト先に移動する
  • ステージ 0 に記録された、チケット専用のワークツリーを削除する
  • ワークツリーのプルーンによるクリーンアップを実行する
  • ローカルのチケットブランチが解決済みの最終化先ブランチに完全にマージされ、不要になった場合は、ローカルのチケットブランチを削除する
  • ユーザーから明示的な指示がある場合、またはドキュメントに記載されたプロジェクトポリシーで求められる場合を除き、リモートブランチを削除しない
• デフォルトでは、ステージ 0 のブートストラップ記録から最終化先ブランチを解決してください。ユーザーが後から明示的に指定して上書きした場合は、その指示に従ってください。ブランチを確実に特定できない場合は、推測せず、マージ／最終処理の前に一度だけ確認してください。
• チケットを done に移動できない場合、またはリポジトリの最終処理のいずれかの手順（コミット／プッシュ／マージ競合／リモートによる拒否）に失敗した場合は、ブロッカーを workflow-state.md に記録し、ステージ 10 をオープンのままにしてください。ブロッカーの解決後にのみ再開してください。
• 適用されるリリース／公開／デプロイ手順が後で失敗した場合、またはその手順がドキュメントに記載されていない場合は、ブロッカーを workflow-state.md に記録し、リポジトリの最終処理を取り消さずにステージ 10 をオープンのままにしてください。
• リポジトリの最終処理後に、必須のワークツリー／ブランチのクリーンアップが失敗した場合は、ブロッカーを workflow-state.md に記録し、ステージ 10 をオープンのままにしてください。チケットを完了扱いにする前に、クリーンアップを完了してください。
• チケットの状態遷移：
  • ハンドオフ後、ユーザーから完了／検証の明示的な確認があるまで、チケットはデフォルトで tickets/in-progress/<ticket-name>/ に保持してください。
  • ユーザーがチケットの完了／検証を明示的に確認した場合（または明示的に移動を指示した場合）は、まずチケットを tickets/done/<ticket-name>/ に移動し、その後、該当する場合はリポジトリの最終処理を行ってください。
  • ユーザーが完了済みのチケットを再開した場合は、追加の成果物を更新する前に tickets/in-progress/<ticket-name>/ に戻してください。
• 必要な成果物とドキュメントの出力をすべて書き込み、最終的な workflow-state.md の遷移／ゲート状態を保存した後にのみ、ハンドオフ完了を最終的に伝えてください。

出力のデフォルト

ユーザーがファイルパスを指定しない場合は、ステージ順にプロジェクト内のチケットフォルダーへ書き込みます。 これらのデフォルトはファイルを生成するステージを示しています。ゲートと引き継ぎのルールには、引き続き上記のワークフロー全体が適用されます。

• ステージ 0（ブートストラップ＋要件ドラフト）：
  • tickets/in-progress/<ticket-name>/ を作成または使用します
  • Git リポジトリの場合、ブートストラップのベースブランチは、ユーザーから明示的な指示があればそれに従って特定し、なければ追跡対象のリモートデフォルト／統合ブランチから最も確度の高いものを推定します
  • Git リポジトリで、新しいチケットのワークツリー／ブランチが必要な場合は、先に追跡対象のリモート参照を更新します
  • Git リポジトリの場合、codex/<ticket-name> 用の専用チケットワークツリーを作成または再利用します。新しいチケットブランチを作成する場合は、最新の追跡対象リモートベースから分岐させます
  • tickets/in-progress/<ticket-name>/workflow-state.md を作成／更新します（Current Stage = 0、Code Edit Permission = Locked、Stage 0 Bootstrap Record を記入）
  • tickets/in-progress/<ticket-name>/requirements.md（Draft）
• ステージ 1（調査＋理解＋トリアージ）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（0 -> 1）を更新します
  • tickets/in-progress/<ticket-name>/investigation-notes.md
• ステージ 2（要件の精緻化から Design-ready まで）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（1 -> 2）を更新します
  • tickets/in-progress/<ticket-name>/requirements.md をその場で更新します
• ステージ 3（設計の基礎）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（2 -> 3）を更新します
  • Small：tickets/in-progress/<ticket-name>/implementation.md を開始／精緻化します（設計の基礎として、ソリューションの概要セクションのみ）。
  • Medium/Large：tickets/in-progress/<ticket-name>/proposed-design.md を作成／精緻化します。
• ステージ 4（将来状態のランタイム呼び出しスタック）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（3 -> 4）を更新します
  • tickets/in-progress/<ticket-name>/future-state-runtime-call-stack.md
• ステージ 5（将来状態のランタイム呼び出しスタックのレビュー、反復）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（4 -> 5）を更新します
  • tickets/in-progress/<ticket-name>/future-state-runtime-call-stack-review.md
• ステージ 6（ゲートが Go Confirmed になった後のみ）：
  • tickets/in-progress/<ticket-name>/workflow-state.md を更新します（Current Stage = 6、事前編集チェックリストが Pass の場合のみ Code Edit Permission = Unlocked）
  • tickets/in-progress/<ticket-name>/implementation.md を仕上げ／更新します
  • ソースコードを実装し、必要なユニット／統合検証を実施して、進捗をリアルタイムで記録します
  • 後方互換性／レガシー維持の経路がスコープに残っておらず、所有関係に基づく依存関係が有効で、変更したファイルが正しいオーナーサブシステム配下の適切なフォルダーに配置されている場合にのみ、ステージ 6 を完了します
• ステージ 7（API／E2E＋実行可能な検証の実装とゲート）：
  • tickets/in-progress/<ticket-name>/workflow-state.md を更新します（Current Stage = 7、Code Edit Permission = Unlocked）
  • tickets/in-progress/<ticket-name>/api-e2e-testing.md を作成／更新します
  • 受け入れ基準マトリクス（acceptance_criteria_id -> シナリオのカバレッジ -> 合格ステータス）を維持します
  • スパインカバレッジマトリクス（spine_id -> シナリオのカバレッジ -> 合格ステータス）を維持します
  • シナリオの実行結果とエスカレーションの判断を tickets/in-progress/<ticket-name>/api-e2e-testing.md に記録します
• ステージ 8（コードレビュゲート、Stage 7 = Pass の後のみ）：
  • tickets/in-progress/<ticket-name>/workflow-state.md を更新します（Current Stage = 8、Code Edit Permission = Locked）
  • tickets/in-progress/<ticket-name>/code-review.md を作成／更新します
  • 詳細なレビュースコアカード、ゲート結果（Pass／Fail）、およびステージ 9 への再移行宣言があればその内容を記録します
• ステージ 9（テスト後のドキュメント同期）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（8 -> 9）を更新します
  • tickets/in-progress/<ticket-name>/docs-sync.md を作成／更新します
  • 影響を受ける既存ドキュメント（例：docs/**/*.md、ARCHITECTURE.md）をその場で更新します
  • 実装した機能を扱う既存ドキュメントがない場合は、関連する不足ドキュメントを docs/ に作成します
  • ドキュメント同期の結果を tickets/in-progress/<ticket-name>/docs-sync.md に記録します（Updated／No impact とその根拠）
• ステージ 10（最終引き継ぎ＋ユーザー検証待ち＋チケットを完了に移動＋リポジトリの最終処理＋クリーンアップ）：
  • tickets/in-progress/<ticket-name>/workflow-state.md の遷移（9 -> 10）と最終状態の記録を更新します
  • stages/10-handoff/handoff-summary-template.md を使用して、tickets/in-progress/<ticket-name>/handoff-summary.md を作成／更新します
  • 引き継ぎサマリーを保存し、ユーザーから明示的な完了／検証の指示があるまで待ちます
  • リリースがユーザー向けである場合、または GitHub Release 本文を公開する場合は、stages/10-handoff/release-notes-template.md を使用して tickets/in-progress/<ticket-name>/release-notes.md を作成／更新します。それ以外の場合は、引き継ぎサマリーにリリースノートが不要である明確な理由を記録します
  • ユーザーから明示的な完了／検証の指示があったら、まずチケットフォルダーを tickets/done/<ticket-name>/ に移動します
  • Git リポジトリで、ユーザーが完了／検証を明示的に確認した場合は、移動したチケットファイルを含むスコープ内のすべての変更をチケットブランチ／ワークツリーでコミットします
  • Git リポジトリで、ユーザーが完了／検証を明示的に確認した場合は、チケットブランチをリモートにプッシュします
  • Git リポジトリで、ユーザーが完了／検証を明示的に確認した場合は、特定済みの最終処理対象ブランチをリモートから更新し、チケットブランチをそこにマージして、更新した対象ブランチをプッシュします
  • Git リポジトリで、ユーザーが完了／検証を明示的に確認し、プロジェクトに該当する文書化済みのリリース／公開／デプロイ手順がある場合は、リポジトリの最終処理後にその手順を実行します。リリースノートが必要な場合は、アーカイブ済みのチケットリリースノート成果物（通常は tickets/done/<ticket-name>/release-notes.md）をその手順に渡します
  • Git リポジトリで、ステージ 0 にこのチケット専用のワークツリー／ブランチが記録されている場合は、リポジトリの最終処理と該当するリリース／公開／デプロイ作業の後に、その専用ワークツリーを削除してワークツリーのプルーニングを実行します。また、ローカルのチケットブランチが特定済みの最終処理対象ブランチに完全にマージされ、不要になった場合は削除します
  • ユーザーが完了／検証を明示的に確認するか、移動を依頼しない限り、チケットは tickets/in-progress/<ticket-name>/ に保持します
  • 後日ユーザーが再開した場合は、新たな更新を行う前に tickets/in-progress/<ticket-name>/ に戻します

テンプレートと参考資料

• 共通：
  • shared/design-principles.md
  • shared/workflow-state-template.md
• ステージ 0：ブートストラップ：
  • stages/00-bootstrap/bootstrap-checklist.md
• ステージ 1：調査：
  • stages/01-investigation/investigation-guide.md
• ステージ 2：要件：
  • stages/02-requirements/requirements-refinement-guide.md
• ステージ 3：設計：
  • stages/03-design/proposed-design-template.md
• ステージ 4：将来状態のランタイムコールスタック：
  • stages/04-future-state-runtime-call-stack/future-state-runtime-call-stack-template.md
• ステージ 5：将来状態のランタイムコールスタックのレビュー：
  • stages/05-future-state-runtime-call-stack-review/future-state-runtime-call-stack-review-template.md
• ステージ 6：実装：
  • stages/06-implementation/implementation-template.md
  • stages/06-implementation/implementation-example.md
• ステージ 7：API/E2E と実行可能な検証：
  • stages/07-api-e2e/README.md
  • stages/07-api-e2e/api-e2e-guide.md
  • stages/07-api-e2e/api-e2e-testing-template.md
• ステージ 8：コードレビュー：
  • stages/08-code-review/README.md
  • stages/08-code-review/code-review-guide.md
  • stages/08-code-review/code-review-principles.md
  • stages/08-code-review/code-review-template.md
• ステージ 9：ドキュメントの同期：
  • stages/09-docs-sync/docs-sync-guide.md
  • stages/09-docs-sync/docs-sync-template.md
• ステージ 10：引き継ぎ：
  • stages/10-handoff/README.md
  • stages/10-handoff/handoff-guide.md
  • stages/10-handoff/handoff-summary-template.md
  • stages/10-handoff/release-notes-template.md