Prompt file imported from Systems-Design-Co-Ltd/codex-vibecoding-package (.codex/prompts/make-plans.md). Copyright stays with the author.

あなたは、GitHub リポジトリのルートに PLANS.md を作成・更新するエージェントです。 このコマンドが呼び出されたら、次の手順で動作してください。

1. 作業対象のリポジトリルートを確認する（現在開いているワークスペースのルートを想定）。
2. ルートに PLANS.md が存在しない場合は新規作成し、存在する場合は 既存 PLANS.md があればテンプレートに沿った形で書き換え、差分マージする。
3. PLANS.md の内容は、後述する「PLANS.md テンプレート本文」と 完全に一致させる。
4. 可能であれば PLANS.md を開き、先頭数行をユーザーにプレビューとして提示する。
5. 生成が完了したら、「PLANS.md をテンプレートに合わせて作成（または更新）した」ことを短く報告する。

PLANS.md テンプレート本文

以下の本文に従い、PLANS.md を作成・更新してください。

──────────────────── ここから貼り付け ────────────────────

MAKE_PLANS

このドキュメントは、PLANS.mdを作成するうえでのルールと基本原則、記述すべき必須項目について説明するものです。

概要

このファイルでは、Codexによる開発で参照する、PLANS.mdを作成するためのルールを記述する。

4つの指導原則

自己完結型、自己充足型、初心者誘導型、成果重視型

原則1 自己完結型

• 相手に期待せず、自身がすべてを知っている状態にする。
• 前提知識ゼロでも大丈夫にします。

原則2 自己充足型

• 進捗に応じて書き換えていく、だが原則1の自己完結を必ず維持させる。

原則3 初心者誘導型

• 任せるということはしない、初心者に手取り足取り教えるように開発のレールをきっちりと敷く。

原則4 成果重視型

• 見た目の綺麗さなどとかよりも、きちんと動作することが大事。
• 目に見える結果で判断をする。

PLANS.mdの基本構成

PLANS.mdは以下の項目を必ず含むこと。

ExecPlanの主要セクション

• 目的/全体像
• ExecPlansとPLANS.mdの使用方法
• 要件
• フォーマット
• ガイドライン
• マイルストーン
• Living plans and design decisions: 生きた計画と設計の決定
• 進捗
• 決定ログ
• 驚きと発見
• 文脈とオリエンテーション
• 作業計画
• 具体的なステップ
• 検証と受け入れ
• 成果と振り返り（Outcomes & Retrospective）

全体構造の階層図

PLAMS.md - プロジェクト実行計画書（ExecPlan）
│
├── 【前文・メタ情報セクション】
│   ├── 実行計画（ExecPlans）の概要説明
│   ├── ExecPlansとPLANS.mdの使用方法
│   ├── プロジェクトメタ情報（名前、日付、ブランチ、関連ドキュメント）
│   ├── 重要な注意事項（生きた文書、自己完結性）
│   └── このドキュメントの使い方（実装者向け・レビュー者向け）
│
├── 【前提・要件セクション】
│   ├── 要件（ExecPlanの必須要件）
│   ├── フォーマット
│   ├── ガイドライン
│   └── マイルストーン
│
├── 【計画・設計セクション】
│   ├── 1. Purpose / Big Picture: 目的/全体像
│   │   ├── 1.1 プロジェクトの目的（What/Why/Who）
│   │   ├── 1.2 スコープ（対象範囲・対象外）
│   │   └── 1.3 成功指標
│   │
│   ├── 2. Progress: 進捗
│   │   ├── 2.1 現在のステータス
│   │   ├── 2.2 詳細な進捗チェックリスト
│   │   ├── 2.3 次のマイルストーン
│   │   └── 2.4 ブロッカー・課題
│   │
│   ├── 3. Decision Log: 決定ログ
│   │   ├── 3.1 技術選定
│   │   ├── 3.2 アーキテクチャ決定
│   │   └── 3.3 設計原則
│   │
│   ├── 4. Surprises & Discoveries: 驚きと発見
│   │   ├── 4.1 技術的知見
│   │   └── 4.2 要件・仕様の変更
│   │
│   ├── 5. Living plans and design decisions: 生きた計画と設計の決定
│   │   ├── 5.1 継続的な文書更新の方針
│   │   ├── 5.2 設計決定の記録方法
│   │   └── 5.3 計画の改訂プロセス
│   │
│   └── 6. Context and Orientation: 文脈とオリエンテーション
│       ├── 6.1 プロジェクト背景
│       ├── 6.2 技術的背景
│       ├── 6.3 プロジェクト構造
│       └── 6.4 関連ドキュメント
│
├── 【実装計画セクション】
│   ├── 7. Plan of Work: 作業計画
│   │   ├── 7.1 フェーズ1: 基盤構築（Week 1-2）
│   │   ├── 7.2 フェーズ2: コア機能実装（Week 3-5）
│   │   └── 7.3 フェーズ3: 統合・テスト（Week 6-7）
│   │
│   └── 8. Concrete Steps: 具体的なステップ
│       ├── 8.1 フェーズ1の詳細ステップ
│       ├── 8.2 フェーズ2の詳細ステップ
│       └── 8.3 フェーズ3の詳細ステップ
│
├── 【検証・品質セクション】
│   └── 9. Validation and Acceptance: 検証と受け入れ
│       ├── 9.1 機能検証チェックリスト
│       ├── 9.2 非機能要件検証
│       ├── 9.3 コード品質チェック
│       ├── 9.4 受け入れ基準
│       └── 9.5 本番リリース前チェックリスト
│
├── 【運用・保守セクション】
│   ├── 10. べき等性と回復（Idempotence and Recovery）
│   │   ├── 10.1 べき等性の保証
│   │   ├── 10.2 失敗時の回復手順
│   │   ├── 10.3 ロールバック手順
│   │   └── 10.4 環境のクリーンアップ
│   │
│   ├── 11. 成果物とメモ（Artifacts and Notes）
│   │   ├── 11.1 重要なコマンド実行結果
│   │   ├── 11.2 重要なコード差分
│   │   ├── 11.3 テスト実行結果
│   │   ├── 11.4 パフォーマンス測定結果
│   │   └── 11.5 デバッグログと解決策
│   │
│   └── 12. インターフェースと依存関係（Interfaces and Dependencies）
│       ├── 12.1 データベーススキーマインターフェース
│       ├── 12.2 tRPC APIインターフェース
│       ├── 12.3 UIコンポーネントインターフェース
│       ├── 12.4 外部依存関係の詳細
│       └── 12.5 環境変数の完全なリスト
│
├── 【成果・振り返りセクション】
│   └── 13. Outcomes & Retrospective: 成果と振り返り
│       ├── 13.1 プロジェクト成果（達成した目標と成果物）
│       ├── 13.2 成功要因（うまくいったこと）
│       ├── 13.3 改善点（うまくいかなかったこと・課題）
│       ├── 13.4 学んだこと（技術的・プロセス的な学び）
│       └── 13.5 今後の推奨事項（次回への提言）
│
└── 【履歴・参照セクション】
    ├── 14. 変更履歴（Change Log）
    └── 15. 関連リソース
        ├── 15.1 今後の拡張予定
        ├── 15.2 既知の制限事項
        └── 15.3 参考ドキュメント・リンク

各セクションの役割と解説

【前文・メタ情報セクション】 実行計画（ExecPlans）の概要説明

• 目的: ExecPlanの性質と役割を説明
• 内容: ExecPlanとは何か、なぜ必要か、どのように使用するか

ExecPlansとPLANS.mdの使用方法

• 目的: ExecPlanの作成・実装・議論時の使用方法を定義
• 内容: 作成時の厳密なルール遵守、実装時の自律的な進行方法、議論時の決定事項記録

プロジェクトメタ情報

• 目的: プロジェクトの基本情報を明示
• 内容: プロジェクト名、作成日、最終更新日、バージョン、ブランチ、関連ドキュメント

重要な注意事項

• 目的: ExecPlanの性質と運用方針を明示
• 内容: 「生きた文書」であること、自己完結性、継続的更新の必要性

このドキュメントの使い方

• 目的: 実装者とレビュー者への指針
• 内容: 実装者向けの作業手順、レビュー者向けの記録方針

【前提・要件セクション】

• 要件
• 目的: ExecPlanの必須要件を定義
• 内容: 自己完結性、生きた文書、初心者でも実装可能、実証可能な動作、専門用語の平易化
• フォーマット
• 目的: ExecPlanの記述形式を定義
• 内容: Markdown形式、フェンスドコードブロックの使用、見出しレベル、リスト構文
• ガイドライン
• 目的: ExecPlan作成時の指針を提供
• 内容: 自己完結性、平易な言葉、観察可能な結果、冪等性と安全性、検証の重要性
• マイルストーン
• 目的: 作業の段階的な区切りと検証方法を定義
• 内容: マイルストーンの定義方法、独立した検証可能性、ストーリーとしての読みやすさ

【計画・設計セクション】

1. 目的/全体像

• 目的: プロジェクトの目的・スコープ・成功指標を定義
• 内容: What/Why/Who、対象範囲・対象外、成功指標

2. 進捗

• 目的: 現在の進捗と次のアクションを記録
• 内容: ステータス、チェックリスト、次のマイルストーン、ブロッカー

3. 決定ログ

• 目的: 技術選定・設計決定と理由を記録
• 内容: 技術選定表、アーキテクチャ決定表、設計原則

4. 驚きと発見

• 目的: 実装中の発見・課題・変更を記録
• 内容: 技術的知見、要件・仕様の変更

5. 生きた計画と設計の決定

• 目的: ExecPlanの継続的な更新方針と設計決定の記録方法を定義
• 内容: 継続的な文書更新の方針、設計決定の記録方法、計画の改訂プロセス

6. 文脈とオリエンテーション

• 目的: プロジェクトの背景と技術的コンテキストを提供
• 内容: プロジェクト背景、技術的背景、プロジェクト構造、関連ドキュメント

【実装計画セクション】 7. 作業計画

• 目的: フェーズ別の作業計画を提示
• 内容: フェーズ1（基盤構築）、フェーズ2（コア機能）、フェーズ3（統合・テスト）

8. 具体的なステップ

• 目的: 実装可能な詳細ステップを提供
• 内容: 各フェーズの詳細ステップ、コード例、実行コマンド、受け入れ基準

【検証・品質セクション】 9. 検証と受け入れ

• 目的: 検証項目と受け入れ基準を定義
• 内容: 機能検証チェックリスト、非機能要件検証、コード品質チェック、受け入れ基準、本番リリース前チェックリスト

【運用・保守セクション】 10. べき等性と回復

• 目的: 安全な再実行と失敗時の回復手順を定義
• 内容: べき等性の保証、失敗時の回復手順、ロールバック手順、環境のクリーンアップ

11. 成果物とメモ

• 目的: 実装中の成果物とメモを記録
• 内容: コマンド実行結果、コード差分、テスト結果、パフォーマンス測定、デバッグログ

12. インターフェースと依存関係

• 目的: 主要なインターフェースと依存関係を定義
• 内容: データベーススキーマ、tRPC API、UIコンポーネント、外部依存関係、環境変数

【成果・振り返りセクション】 13. 成果と振り返り（Outcomes & Retrospective）

• 目的: プロジェクトの成果を記録し、振り返りを通じて学びを蓄積
• 内容: 達成した目標と成果物、成功要因、改善点、学んだこと、今後の推奨事項
• 備考: 主要なマイルストーンまたは完了時に、達成されたこと、残った課題、学んだ教訓を要約。

【履歴・参照セクション】 14. 変更履歴

• 目的: 重要な変更を時系列で記録
• 内容: 変更記録（日付、内容、理由、影響範囲、変更者）

15. 関連リソース

• 目的: 拡張予定、制限事項、参考資料を提供
• 内容: 拡張予定、既知の制限事項、参考ドキュメント・リンク

構成の特徴

1. 自己完結性

• 外部ドキュメントへの依存を最小化し、必要な情報を文書内に含める

2. 時系列の記録

• 進捗、決定ログ、驚きと発見、変更履歴、成果と振り返りで時系列を追跡可能

3. 実装者視点

• 具体的なステップ、コード例、実行コマンド、受け入れ基準を提供

4. 安全性の重視

• べき等性、回復手順、ロールバック手順を明示

5.継続的更新 「生きた文書」として、進捗・発見・決定を継続的に更新

6. 検証可能性

• 検証チェックリストと受け入れ基準を明確化

ドキュメントの使用フロー

【計画・設計】 ←→ 【実装計画】
     ↓                ↓
【検証・品質】 ←→ 【運用・保守】
     ↓                ↓
【成果・振り返り】 ←→ 【履歴・参照】
     ↓                ↓
【前文・メタ情報】 ←→ 【計画・設計】

セクション間の関係性

【計画・設計】 ←→ 【実装計画】
     ↓                ↓
【検証・品質】 ←→ 【運用・保守】
     ↓                ↓
【成果・振り返り】 ←→ 【履歴・参照】
     ↓                ↓
【前文・メタ情報】 ←→ 【計画・設計】

• 計画・設計 → 実装計画: 設計に基づいて実装ステップを定義
• 実装計画 → 検証・品質: 実装結果を検証
• 検証・品質 → 運用・保守: 検証結果を運用に反映
• 運用・保守 → 成果・振り返り: 運用結果を成果として記録
• 成果・振り返り → 履歴・参照: 振り返りを履歴に反映
• 履歴・参照 → 計画・設計: 過去の知見を計画に反映

この構成により、初心者でも実装を完了でき、AIエージェントが自律的に作業を進められるようになっています。

作成のポイント

• Progress、Surprises & Discoveries、Decision Log、Outcomes & Retrospectiveのセクションは必須であり、作業の進行に合わせて更新し続ける必要があります。

• 以下のプロンプトは、ユーザーへの十分なフィードバックを提供し、モデルが計画で指定された内容を正確に実行できるようにするために慎重に選択されています。ユーザーは、ニーズに合わせてファイルをカスタマイズしたり、必要なセクションを追加または削除したりすることで、メリットを実感できる場合があります。

# Codex 実行計画 (ExecPlans):

本ドキュメントでは、コーディングエージェントが機能やシステム変更を実装する際に従うべき実行計画（「ExecPlan」）、つまり設計ドキュメントの要件について説明します。読者は、このリポジトリに関して全くの初心者であると想定してください。読者が持っているのは、現在の作業ツリーと、あなたが提供する単一のExecPlanファイルのみです。過去の計画の記憶も、外部コンテキストもありません。

## ExecPlansとPLANS.mdの使用方法

実行可能な仕様（ExecPlan）を作成する際は、PLANS.mdに**厳密に従ってください**。もしコンテキストにない場合は、PLANS.mdファイル全体を読んで記憶を更新してください。正確な仕様を作成するため、ソースマテリアルを徹底的に読み（そして再読し）てください。仕様を作成する際は、スケルトンから始めて、調査を行いながら詳細を埋めていきます。

実行可能な仕様（ExecPlan）を実装する際は、「次のステップ」についてユーザーにプロンプトを出さず、単純に次のマイルストーンに進んでください。すべてのセクションを最新の状態に保ち、停止ポイントごとにリストのエントリを追加または分割して、達成した進捗と次のステップを明確に記述します。曖昧さは自律的に解決し、頻繁にコミットしてください。

実行可能な仕様（ExecPlan）について議論する際は、仕様内のログに決定事項を記録し、後世のために残してください。仕様に対する変更がなぜ行われたかが明確にわかるようにする必要があります。ExecPlansは生きたドキュメントであり、**ExecPlanのみ**から、他の作業なしに再開できるようにする必要があります。

困難な要件や大きな未知数を含む設計を調査する場合は、マイルストーンを使用して概念実証や「トイ実装」などを実装し、ユーザーの提案が実現可能かどうかを検証できるようにします。ライブラリを見つけたり取得したりしてソースコードを読み、深く調査し、より完全な実装をガイドするプロトタイプを含めてください。

## 要件

**譲れない要件:**

* すべてのExecPlanは完全に自己完結している必要があります。自己完結とは、現在の形式で、初心者が成功するために必要なすべての知識と指示が含まれていることを意味します。
* すべてのExecPlanは生きたドキュメントです。貢献者は、進捗があるたび、発見があるたび、設計決定が確定するたびに、それを改訂する必要があります。各改訂版は、完全に自己完結したままでなければなりません。
* すべてのExecPlanは、このリポジトリの事前知識がない完全な初心者が、機能をエンドツーエンドで実装できるようにする必要があります。
* すべてのExecPlanは、単に「定義を満たす」ためのコード変更ではなく、実証可能な動作を生成する必要があります。
* すべてのExecPlanは、使用するすべての専門用語を平易な言葉で定義するか、使用しないでください。

目的と意図が最優先です。まず、ユーザーの視点からなぜこの作業が重要なのかを数文で説明することから始めます。この変更後に誰かができるようになること（以前はできなかったこと）と、それが動作していることを確認する方法を説明します。その後、その結果を達成するための正確なステップを読者に案内します。何を編集し、何を実行し、何を観察すべきかを含めます。

計画を実行するエージェントは、ファイルのリスト表示、ファイルの読み取り、検索、プロジェクトの実行、テストの実行ができます。エージェントは過去のコンテキストを知らず、以前のマイルストーンからあなたの意図を推測することはできません。依存する仮定は繰り返してください。外部のブログやドキュメントを指さないでください。知識が必要な場合は、自分の言葉で計画自体に埋め込んでください。ExecPlanが以前のExecPlanに基づいており、そのファイルがチェックインされている場合は、参照によって組み込んでください。そうでない場合は、その計画からの関連コンテキストをすべて含める必要があります。

## フォーマット

フォーマットと構造はシンプルで厳格です。各ExecPlanは、トリプルバッククォートで始まり終わる、`md`とラベル付けされた単一のフェンスされたコードブロックでなければなりません。その中に追加のトリプルバッククォートのコードフェンスをネストしないでください。コマンド、トランスクリプト、差分、またはコードを示す必要がある場合は、その単一のフェンス内でインデントされたブロックとして提示します。ExecPlanのコードフェンスを途中で閉じてしまうことを避けるため、ExecPlan内でコードフェンスではなくインデントを使用して明確にします。すべての見出しの後に2つの改行を使用し、#、##などを使用し、順序付きリストと順序なしリストの正しい構文を使用します。

ExecPlanを、**ExecPlanのみ**がファイルの内容であるMarkdown（.md）ファイルに書き込む場合は、トリプルバッククォートを省略してください。

平易な文章で書いてください。リストよりも文を優先してください。簡潔さが意味を曖昧にする場合を除き、チェックリスト、表、長い列挙は避けてください。チェックリストは`Progress`セクションでのみ許可され、そこでは必須です。ナラティブセクションは、文章を優先したままにする必要があります。

## ガイドライン

自己完結性と平易な言葉が最も重要です。通常の英語ではないフレーズ（「デーモン」、「ミドルウェア」、「RPCゲートウェイ」、「フィルターグラフ」）を導入する場合は、すぐに定義し、このリポジトリでそれがどのように現れるかを読者に思い出させてください（たとえば、それが表示されるファイルやコマンドに名前を付けることによって）。「以前に定義したように」や「アーキテクチャドキュメントによると」などと言わないでください。自分自身を繰り返すことになっても、ここで必要な説明を含めてください。

一般的な失敗モードを避けてください。未定義の専門用語に頼らないでください。結果のコードがコンパイルされても意味のあることを何もしないほど狭く「機能の文字」を記述しないでください。重要な決定を読者に外注しないでください。曖昧さが存在する場合は、計画自体でそれを解決し、そのパスを選んだ理由を説明してください。ユーザーに見える効果を過度に説明し、付随的な実装の詳細を過少に指定する側に誤ってください。

観察可能な結果で計画を固定してください。実装後にユーザーができること、実行するコマンド、および表示されるはずの出力を述べてください。受け入れは、内部属性（「HealthCheck構造体を追加した」）ではなく、人間が検証できる動作（「サーバーを起動した後、[http://localhost:8080/health](http://localhost:8080/health)にアクセスすると、本文がOKのHTTP 200が返される」）としてフレーズ化する必要があります。変更が内部的なものである場合は、その影響をどのように実証できるかを説明してください（たとえば、変更前に失敗し変更後に成功するテストを実行することによって、および新しい動作を使用するシナリオを示すことによって）。

リポジトリコンテキストを明示的に指定してください。完全なリポジトリ相対パスでファイルに名前を付け、関数とモジュールを正確に名前を付け、新しいファイルを作成する場所を説明してください。複数の領域に触れる場合は、初心者が自信を持ってナビゲートできるように、それらの部分がどのように組み合わされているかを説明する短いオリエンテーションパラグラフを含めてください。コマンドを実行する際は、作業ディレクトリと正確なコマンドラインを示してください。結果が環境に依存する場合は、仮定を述べ、合理的な場合は代替案を提供してください。

冪等性と安全性を確保してください。損傷やドリフトを引き起こすことなく、複数回実行できるようにステップを記述してください。ステップが途中で失敗する可能性がある場合は、再試行または適応する方法を含めてください。マイグレーションまたは破壊的な操作が必要な場合は、バックアップまたは安全なフォールバックを詳しく説明してください。進むにつれて検証できる追加的でテスト可能な変更を優先してください。

検証は任意ではありません。テストを実行し、該当する場合はシステムを起動し、有用なことをしているのを観察する指示を含めてください。新しい機能や能力の包括的なテストについて説明してください。初心者が成功と失敗を区別できるように、予想される出力とエラーメッセージを含めてください。可能な場合は、コンパイルを超えて変更が効果的であることを証明する方法を示してください（たとえば、小さなエンドツーエンドシナリオ、CLI呼び出し、またはHTTPリクエスト/レスポンストランスクリプトを通じて）。プロジェクトのツールチェーンに適した正確なテストコマンドと、その結果を解釈する方法を述べてください。

証拠を捕捉してください。ステップがターミナル出力、短い差分、またはログを生成する場合は、単一のフェンスされたブロック内にインデントされた例としてそれらを含めてください。成功を証明するものに焦点を当てて、簡潔に保ってください。パッチを含める必要がある場合は、大きなblobを貼り付けるのではなく、読者が指示に従って再作成できるファイルスコープの差分または小さな抜粋を優先してください。

## マイルストーン

マイルストーンはナラティブであり、官僚主義ではありません。作業をマイルストーンに分割する場合は、スコープ、マイルストーンの終わりに以前は存在しなかったものが何が存在するか、実行するコマンド、および期待する受け入れを説明する短いパラグラフで各マイルストーンを紹介してください。ストーリーとして読みやすく保ってください：目標、作業、結果、証明。ProgressとMilestonesは異なります：milestonesはストーリーを語り、progressは細かい作業を追跡します。両方が存在する必要があります。簡潔さのためだけにマイルストーンを省略しないでください。将来の実装に重要である可能性のある詳細を省略しないでください。

各マイルストーンは、独立して検証可能であり、実行計画の全体的な目標を段階的に実装する必要があります。

## 生きた計画と設計決定

* ExecPlansは生きたドキュメントです。重要な設計決定を行う際は、決定とその背後にある思考の両方を記録するように計画を更新してください。すべての決定を`Decision Log`セクションに記録してください。
* ExecPlansには、`Progress`セクション、`Surprises & Discoveries`セクション、`Decision Log`、および`Outcomes & Retrospective`セクションを含め、維持する必要があります。これらはオプションではありません。
* オプティマイザーの動作、パフォーマンストレードオフ、予期しないバグ、またはアプローチを形作った逆/非適用セマンティクスを発見した場合は、短い証拠スニペット（テスト出力が理想的）とともに`Surprises & Discoveries`セクションでそれらの観察を捕捉してください。
* 実装の途中でコースを変更する場合は、`Decision Log`で理由を文書化し、`Progress`で影響を反映してください。計画は、あなたにとってのチェックリストと同じくらい、次の貢献者のためのガイドです。
* 主要なタスクまたは完全な計画の完了時に、達成されたこと、残っていること、および学んだ教訓を要約する`Outcomes & Retrospective`エントリを書いてください。

# プロトタイピングマイルストーンと並行実装

より大きな変更のリスクを軽減する場合、明示的なプロトタイピングマイルストーンを含めることは許容され、多くの場合奨励されます。例：実現可能性を検証するために依存関係に低レベルの演算子を追加する、またはオプティマイザー効果を測定しながら2つの構成順序を探索する。プロトタイプを追加的でテスト可能に保ってください。スコープを「プロトタイピング」として明確にラベル付けし、実行および結果を観察する方法を説明し、プロトタイプを昇格または破棄するための基準を述べてください。

テストを合格させ続ける追加のコード変更の後に減算を行うことを優先してください。並行実装（たとえば、大規模なマイグレーション中に古いパスと一緒にアダプターを保持する）は、リスクを軽減したり、大規模なマイグレーション中にテストを合格させ続けることを可能にする場合は問題ありません。両方のパスを検証する方法と、テストで安全に一方を廃止する方法を説明してください。複数の新しいライブラリまたは機能領域で作業する場合は、これらの機能の実現可能性を**互いに独立して**評価するスパイクを作成し、外部ライブラリが期待どおりに実行され、必要な機能を単独で実装することを証明することを検討してください。

## 良いExecPlanのスケルトン
```md
# <短い、アクション志向の説明>

このExecPlanは生きたドキュメントです。`Progress`、`Surprises & Discoveries`、`Decision Log`、および`Outcomes & Retrospective`セクションは、作業が進むにつれて最新の状態に保つ必要があります。

PLANS.mdファイルがリポジトリにチェックインされている場合は、リポジトリルートからそのファイルへのパスをここで参照し、このドキュメントはPLANS.mdに従って維持する必要があることに注意してください。

## Purpose / Big Picture

この変更後に誰かが何を得るか、どのようにそれが動作しているのを見ることができるかを数文で説明します。有効にするユーザーに見える動作を述べてください。

## Progress

細かいステップを要約するために、チェックボックス付きのリストを使用します。すべての停止ポイントは、部分的に完了したタスクを2つ（「完了」対「残り」）に分割する必要がある場合でも、ここに文書化する必要があります。このセクションは、常に作業の実際の現在の状態を反映する必要があります。

- [x] (2025-10-01 13:00Z) 完了したステップの例。
- [ ] 未完了のステップの例。
- [ ] 部分的に完了したステップの例（完了：X；残り：Y）。

進捗率を測定するためにタイムスタンプを使用します。

## Surprises & Discoveries

実装中に発見された予期しない動作、バグ、最適化、または洞察を文書化します。簡潔な証拠を提供してください。

- 観察：…
  証拠：…

## Decision Log

次の形式で計画に取り組んでいる間に行われたすべての決定を記録します：

- 決定：…
  根拠：…
  日付/作成者：…

## Outcomes & Retrospective

主要なマイルストーンまたは完了時に、結果、ギャップ、および学んだ教訓を要約します。元の目的に対して結果を比較します。

## Context and Orientation

読者が何も知らないかのように、このタスクに関連する現在の状態を説明します。完全なパスで主要なファイルとモジュールに名前を付けます。使用する非自明な用語を定義します。以前の計画を参照しないでください。

## Plan of Work

編集と追加のシーケンスを文章で説明します。各編集について、ファイルと場所（関数、モジュール）と何を挿入または変更するかに名前を付けます。具体的で最小限に保ってください。

## Concrete Steps

実行する正確なコマンドとどこで実行するか（作業ディレクトリ）を述べてください。コマンドが出力を生成する場合は、読者が比較できるように短い予想されるトランスクリプトを示してください。このセクションは、作業が進むにつれて更新する必要があります。

## Validation and Acceptance

システムを起動または実行する方法と何を観察するかを説明します。受け入れを、特定の入力と出力を持つ動作としてフレーズ化します。テストが関係する場合は、「<プロジェクトのテストコマンド>を実行し、<N>が合格することを期待します。新しいテスト<名前>は変更前に失敗し、変更後に合格します」と言います。

## Idempotence and Recovery

ステップを安全に繰り返すことができる場合は、そう言ってください。ステップがリスクの高い場合は、安全な再試行またはロールバックパスを提供してください。完了後は環境をクリーンに保ってください。

## Artifacts and Notes

インデントされた例として、最も重要なトランスクリプト、差分、またはスニペットを含めてください。成功を証明するものに焦点を当てて、簡潔に保ってください。

## Interfaces and Dependencies

規定的であってください。使用するライブラリ、モジュール、およびサービスに名前を付け、その理由を述べてください。マイルストーンの終わりに存在する必要がある型、トレイト/インターフェイス、および関数シグネチャを指定します。`crate::module::function`や`package.submodule.Interface`などの安定した名前とパスを優先してください。

例：

crates/foo/planner.rsで、次のように定義します：

    pub trait Planner {
        fn plan(&self, observed: &Observed) -> Vec<Action>;
    }

上記のガイダンスに従えば、単一のステートレスなエージェント、または人間の初心者が、あなたのExecPlanを最初から最後まで読んで、動作する観察可能な結果を生成できます。それが基準です：自己完結、自己充足、初心者ガイド、結果重視。

計画を改訂する際は、変更が生きたドキュメントセクションを含むすべてのセクションに包括的に反映されていることを確認し、計画の最後に変更とその理由を説明するメモを書く必要があります。ExecPlansは、ほとんどすべてについて、何をするかだけでなく、なぜ行うのかも説明する必要があります。

──────────────────── ここまで貼り付け ────────────────────