計画ディシプリン — プロジェクトローカルな一時的作業メモリ

下流のコントリビューター向けの、正規の規範的な参照です。 本ドキュメントは、プロジェクト仕様の計画ディシプリンのセクション（仕様 §3）を反映したものです。公開リポジトリに同梱される、独立した参照です。ここで導入されるディシプリンは基礎的なものであり、以下のすべての指令は、明示的に別の記載がない限り MUST です。アーキテクチャ上の根拠は ADR-0001 に記録されています。

1. 定義と境界Copy Anchor Link

計画（plan）とは、プロジェクトについての推論の過程で生み出される、意図的で一時的な作業成果物であり、次を含むがこれに限りません:

• アーキテクチャのスケッチ、システム設計のウォークスルー、コンポーネント分解。
• 作業分解構造、多段階のタスクリスト、分解ツリー。
• リファクタリング戦略、移行のウォークスルー、ロールアウトのシーケンス。
• デバッグ日誌、仮説ログ、再現メモ。
• 探索メモ、スパイクの記述、プロンプトの下書き、後で使うために保持されたアシスタントのトランスクリプト。
• 出荷するためではなく、思考するために書かれたあらゆるドキュメント。

計画は、これらの隣接するクラスとはカテゴリとして明確に異なります:

計画は ADR に先行します。計画が永続的な決定へと収束したとき、その決定は ADR へ 昇格 されます（§4 ライフサイクル）。計画そのものはアーカイブされるか、破棄されます。

2. 場所、可視性、命名Copy Anchor Link

• パス。 <project-root>/.apothem/plans/ が唯一の正規ホームです。レガシーな <project-root>/.plans/ ツリーはもはや正規ではありません。apothem migrate-workspace（§5）でアップグレードしてください。ハーネスの設定ディレクトリ（例: ~/.claude/plans/、~/.claude/.plans/、~/.codex/.plans/）ではありません。デスクトップのスクラッチフォルダーでもありません。~/notes/ でもありません。tmp/plans/ でもありません。
• 可視性。 このフォルダーは、§6 の正規スニペットに従ってプロジェクトの .gitignore に登録されます。ハーネスは、いかなる書き込みの前にも、このエントリの存在を検証しなければなりません。存在しない場合は、一行のヘッダーコメントと本ドキュメントへのリンクを添えて、エントリを追記します。
• ファイル名の規約。 YYYY-MM-DD--<kebab-case-slug>.md。より大きなワークスペースでは、.apothem/plans/<area>/YYYY-MM-DD--<slug>.md の下でサブカテゴリ化します。
  • 例: .apothem/plans/2026-04-30--auth-refactor-strategy.md、.apothem/plans/api/2026-04-30--rate-limit-rollout.md。
• インデックス。 任意の .apothem/plans/INDEX.md（これも gitignore 対象）は、リンクとステータスを集約してもよく、存在する場合は、ハーネスがすべての計画の書き込み時にそれを維持します。
• アーカイブ。 収束した、または放棄された計画は .apothem/plans/_archive/ に移動します。明示的な構造化照会による確認なしに削除されることは決してありません。
• 計画の著作者ヘッダー。 計画は、著作者ヘッダーの SPDX 行から 免除 されます（site/content/docs/reference/authorship-header.mdx の §Exception List による）。それらは gitignore 対象の一時的なものであり、一時的な作業メモリに永続的な来歴マーカーを適用するのはカテゴリの誤りです。フロントマター（§3）が計画の来歴を担います。

3. フロントマターのスキーマ（検証済み）Copy Anchor Link

すべての計画ファイルには、次が含まれます:

---
title: <human-readable title>
project: <git-remote-url-or-canonical-local-path>
created: <ISO-8601 timestamp>
updated: <ISO-8601 timestamp>
status: draft | in-progress | converged | abandoned
tags: [<kebab>, ...]
supersedes: <prior-plan-relative-path or null>
promotes-to: <ADR path or null>
---

計画用の JSON スキーマは src/apothem/schemas/plan.schema.json にあります。/plan スラッシュコマンド（および plans-discipline-language バリデーター）は、すべての書き込み時にこれに対して検証します。

4. ライフサイクルと昇格のワークフローCopy Anchor Link

1. ドラフト — 初回の作成。status: draft。
2. 進行中 — 活発に反復されている。status: in-progress。実質的な編集ごとに updated を更新します。
3. 収束 — 永続的な決定が結晶化する:
   1. その決定を、プロジェクトが批准した ADR の場所に、新しい ADR として抽出します。
   2. 計画の promotes-to を ADR のパスに設定します。
   3. status: converged を設定します。
   4. 任意で .apothem/plans/_archive/ に移動します。
4. 放棄 — 方向性が放棄される。status: abandoned。アーカイブするか、明示的な構造化照会を伴って破棄します。
5. 置換 — 新しい計画が古い計画を置き換えるとき、新しい計画の supersedes を古い計画のパスに設定し、古い計画の status もそれに応じて設定します。

昇格は、計画の内容が永続的になり、バージョン管理され、チームメイトから見えるようになる 唯一の 経路です。いかなる計画も、丸ごとコミットされたソースに移行されることはありません。

5. 移行プロトコル — 一度限り、ハーネスの計画ディレクトリからプロジェクトごとの .apothem/plans/ へCopy Anchor Link

注。 このプロトコルは、計画ディシプリンを初めて採用する下流プロジェクトに適用されます。従前の計画成果物がハーネスの設定ディレクトリ（例: ~/.claude/plans/、~/.claude/.plans/、または別のハーネスの同等のパス）の中にある場合です。エコシステム自体に対する再帰的なケースは、ハーネスローカルな計画の状態をソースに物理的に移すのではなく、gitignore することで解決されます。

ツール。 すでにレガシーなレイアウトにあるプロジェクト（隣接する <project-root>/.plans/ ツリーと、ハーネスごとの <project-root>/.apothem/<harness>/{memory,contexts,learning} ストア）では、apothem migrate-workspace コマンドが両者を、共有の <project-root>/.apothem/{plans,memory,learning,contexts} ワーキングディレクトリに統合します。このコマンドは冪等かつ非破壊的です。消費するすべてのソースをバックアップし、.plans/ を .apothem/plans/ に移動し、ハーネスごとのメモリとコンテキストのストアを和集合でマージし、学習シグナルを連結のうえ重複排除し、衝突するレコードを決して上書きしません。まずは apothem migrate-workspace --dry-run を実行して、移動をプレビューしてください。

移行は冪等であり、ハーネスローカルな計画ディレクトリが削除される直前まで可逆です（削除後は、./.audit/plans-backup-<timestamp>.tar.gz のバックアップ tarball がロールバック用の成果物を提供します）。以下の例では ~/.claude/plans/ を使います。アクティブなハーネスの同等のパスに読み替えてください。

ステップ 1 — インベントリ。 ハーネスローカルな計画ディレクトリ配下のすべてのファイルを列挙し、plan-artifact (quarantined) に分類します。

ステップ 2 — 来歴マップ。 各計画について、推測された宛先プロジェクトと信頼度スコアを伴う来歴記録を構築します。信頼度は、フロントマターの project フィールド、本文スキャンのシグナル（リポジトリの URL、パッケージ名、絶対パス）、文脈上の手がかりから導出されます。

ステップ 3 — マッピングの確認。 完全なマップが、単一の統合された構造化照会としてオペレーターに提示されます（ファイル数が快適な単一プロンプトのサイズを超える場合は、密にバッチ化された一連の照会として）。各計画について、オペレーターは次のいずれかを選びます:

• 確認（Confirm） — 推測された宛先プロジェクトを確定します。
• 再割り当て（Reassign） — 別のプロジェクトに割り当てます（オペレーターが把握しているプロジェクトの一覧を提示します）。
• 延期（Defer） — 後で仕分けるために ~/.claude/.audit/orphan-plans/<original-name> に移動します。
• 破棄（Discard） — 明示的で別途確認された構造化照会がある場合に限ります（これは破壊的な操作です）。

多くの計画で信頼度が high の場合、プロンプトは、ログ内のすべての個別の決定を依然として表示しつつ、ラウンドトリップを減らすための confirm-all-high-confidence の操作を提示します。

ステップ 4 — 移動前のプロジェクト準備。 一意の宛先プロジェクトごとに:

1. プロジェクトのルートが存在し、読み取り可能であることを検証します。
2. それが git リポジトリであることを検証します（git ではないルートについては、続行、初期化、またはスキップのいずれを行うかを構造化照会チャネル経由で提示します）。
3. <project-root>/.apothem/plans/ が存在することを確認します。存在しなければ mkdir -p で作成します。
4. プロジェクトの .gitignore に §6 の正規スニペットが含まれていることを検証します。含まれていなければ、この移行をクレジットするヘッダーコメントとともに追記します。
5. <project-root>/.apothem/plans/ が git によってすでに追跡されていないことを検証します。追跡されている場合（過去のコントリビューターのミス）は、untrack-and-keep、untrack-and-remove-from-history、abort のオプションを添えて、構造化照会チャネル経由で提示します。

ステップ 5 — 移動。 確認された各計画 → 宛先のペアについて:

1. 宛先のファイル名を計算します。ソースにフロントマターがあれば §3 に従って正規化します。なければ、本文をフロントマター（status draft、project フィールドを設定、created は mtime から、tags は [migrated]）で包み、YYYY-MM-DD--<slug>.md にリネームします。
2. 宛先に名前の衝突がある場合は、-imported-<unix-timestamp> を付加し、リネームをログに記録します。
3. ファイルをコピーし（mtime を保持）、宛先で SHA-256 が一致することを検証してから、ソースを unlink します。
4. <project-root>/.apothem/plans/_migration-manifest.md（これも gitignore 対象）にエントリを追記し、元のハーネスローカルのパス、宛先のパス、元の SHA-256、タイムスタンプ、この移動を承認した構造化照会の回答を記録します。

ステップ 6 — 検証。 すべての移動の後:

1. ハーネスローカルな計画ディレクトリが空であることを確認します（孤立した計画がある場合は、そのハーネスの監査／隔離ディレクトリ内にあり、まもなく削除されるディレクトリの外にあります）。
2. 各宛先プロジェクトに、中身のある .apothem/plans/ とマニフェストがあることを確認します。
3. SHA-256 によって、移行された内容が元のものと一致することを抜き取りで確認します。

ステップ 7 — tarball と削除。 ステップ 1 で取得した一時スナップショットから抽出した、移動前のハーネスローカルな計画ツリー全体を含む ./.audit/plans-backup-<ISO-timestamp>.tar.gz を作成します。その後、準備完了を確認する最終的な構造化照会を経て、いまや空になったハーネスローカルな計画ディレクトリを削除します。

ステップ 8 — 監査記録。 すべての移動、延期されたすべてのファイル、すべての破棄、すべての衝突リネーム、すべての gitignore の追記を要約した ./.audit/plans-migration.md を出力します。

6. 下流の .gitignore スニペット（正規、コピー＆ペースト用）Copy Anchor Link

このエコシステムを採用するすべてのプロジェクトは、次のブロックをその .gitignore に追加しなければなりません:

# Apothem working directory (project-local shared state: plans, memory,
# learning, contexts; gitignored — never committed). The sole canonical plans
# home is `.apothem/plans/`.
# See: <repo-url>/blob/main/site/content/docs/reference/plans-discipline.mdx
# Ignore the CONTENTS of this directory (not the directory) so the
# `.keep` negation below can take effect.
.apothem/*
!.apothem/.keep

任意の .keep の免除は、内容を漏らすことなく、空のパスを刈り込むツールの中でディレクトリの存在を保ちます。.keep を含めるかどうかは、/plan の初回呼び出し時に構造化照会チャネルを通じて、プロジェクトごとに決定されます。.apothem/* と !.apothem/.keep の行が正規のスニペットです。レガシーな <project-root>/.plans/ ツリーをまだ持つプロジェクトは、apothem migrate-workspace（§5）を実行して .apothem/plans/ へアップグレードします。

7. 自己強制のメカニズムCopy Anchor Link

このディシプリンは、今後のあらゆるセッションを生き延びなければなりません。以下の強制の面は必須であり、公開されたエコシステムに組み込まれています:

1. AGENTS.md およびミラーの指示面 — トップレベルの必須の挙動ブロックで、次の内容を述べます。"Planning artifacts are written to <project-root>/.apothem/plans/ — the sole canonical plans home (a legacy <project-root>/.plans/ tree is upgraded via apothem migrate-workspace) — never to any harness configuration directory (for example ~/.codex/ or ~/.claude/) and never to a global location. This rule is non-negotiable; cite §3 of the project spec on every related decision." このブロックは plans-discipline-language バリデーターによって検出されます。
2. ハーネスごとのリポジトリ内指示ファイル — そのハーネスの指示面に適したフレーミングで、同じ指令をミラーします（§4 Plans Discipline）。登録された各ハーネスの面で、同じバリデーターによって検出されます。
3. デフォルトの出力スタイル — 応答が計画の形状を持つ内容（多段階の戦略、分解、設計のウォークスルー、デバッグ日誌）を生み出す場合、スタイルはその成果物をインラインで出力して破棄するのではなく、プロジェクトローカルの .apothem/plans/ への書き込みへ振り向けます。スタイルは明示的に次のように指示します: 「プロジェクトルートが発見できない場合、どこで計画するかをオペレーターに尋ねる構造化照会で停止する。」
4. すべての委任ワーカープロンプト — 計画の成果物の宛先として .apothem/plans/ を指定する Output Surface のスタンザと、ハーネスローカルの計画ディレクトリを禁止として指定する Anti-Pattern のスタンザを持ちます。
5. 専用の /plan スラッシュコマンド — スラッグと本文を受け取り、正しいフロントマターを付けて <project-root>/.apothem/plans/YYYY-MM-DD--<slug>.md に書き込みます。宛先の .gitignore が正しいことを確かめ、ハーネス設定ルートのパスへの書き込みは拒否します。
6. pre-tool-use フック — plan-write-guard — すべてのファイル書き込みツールの呼び出しをインターセプトします。対象パスが、ハーネスローカルの計画の場所（例: ~/.claude/plans/... や ~/.codex/.plans/...）、またはヒューリスティックが計画の形状を持つと判定する他のグローバルなエコシステムのパスに一致する場合、フックは書き込みをブロックし、現在のプロジェクトの .apothem/plans/ へのリダイレクトを提案する構造化照会を提示します。
7. CI バリデーター — no-global-plans は、コミットされた計画の作業メモリが公開ツリーに再び現れると、ビルドを失敗させます。plans-discipline-language は、正規の指令がいずれかの登録済みハーネスの指示ファイル、またはデフォルトの出力スタイルから抜け落ちると失敗します。バリデーターの正規のターゲットの面（ファイルシステム契約として保持）は、下のフェンスブロックに列挙されています。

AGENTS.md
CLAUDE.md
.github/copilot-instructions.md

8. Pre-commit フック — 上記をローカルにミラーし、いかなるコミットも取り込まれる前にディシプリンが強制されるようにします。

8. アンチパターン（カテゴリとして禁止）Copy Anchor Link

• ハーネスの設定ディレクトリ（例: ~/.claude/plans/ や ~/.codex/.plans/）、またはその他のグローバルな場所の中に計画を書くこと。
• 計画をプロジェクトの git 履歴にコミットすること（コミット時のフックはこれを拒否すべきです）。
• 計画と ADR を混在させること（ライフサイクル、場所、コミットの状態がそれぞれ異なります）。
• フロントマターのない計画、日付で始まるファイル名のない計画、project フィールドのない計画。
• プロジェクトをまたぐ計画（一つの計画、二つのプロジェクト）。分割してください。プロジェクトごとに一つの計画です。
• ハーネス設定の同期（例: Claude Code 用の ~/.claude）によって計画をマシン間で共有すること。計画をプロジェクトローカルに保つための構造的な論拠は、次のとおりです。プロジェクトのリポジトリ こそが 同期の仕組みであり、計画の共有が正当化される稀な場合にも、その正当化自体が、内容を ADR へ昇格させるべきというシグナルになります。
• 委任ワーカーのプロンプト、スキルの本文、または出力スタイルの内部に計画の内容を埋め込むこと。これらの面は 永続的な挙動設定 であり、計画は 一時的な作業メモリ です。
• 計画ファイルに著作者ヘッダーの SPDX 行を適用すること（計画は設計上免除されています。§2 と、site/content/docs/reference/authorship-header.mdx の §Exception List を参照）。

関連項目Copy Anchor Link

• ADR-0001 — アーキテクチャ上の根拠、検討された代替案、受け入れられたトレードオフ。
• site/content/docs/reference/authorship-header.mdx — 著作者ヘッダーの SPDX 行のディシプリン（計画はカテゴリとして免除されています）。
• ハーネス規約のページ — マルチサーフェスのハーネス規約（計画ディシプリンは、登録済みのすべてのハーネス指示ファイルと、オプトインされたすべての任意の面にわたる共有された主張として現れます）。パス:

site/content/docs/reference/ai-conventions.mdx

• プロジェクト仕様 §3 — ここに反映されている完全な正規テキストです。