横断的マンデートレジストリ（CM-1–CM-28）
すべてのやり取りとパイプライン操作を統制する、エコシステム内部の横断的マンデート（CM-1–CM-28）の完全なレジストリと定義。
横断的マンデートの正規レジストリ。 このドキュメントは CM-N レジストリの本文全体を収めています。実質的な列挙はここにあり、
src/apothem/rules/配下のルールファイルによって運用されます。詳細な CM-N の本文を必要とするすべてのセッションは、このドキュメントをオンデマンドで読み込みます。
レジストリの自己参照の免除
このドキュメントこそが正規の CM-N レジストリです — CM-1 から CM-28 までのトークンが定義されるソースです。これらのトークンをレジストリ自身の本文内で再記述することは正規のものであり、プラン内部の用語の漏洩ではありません。コードベース分離の不変条件は、公開ドキュメントではないその他のすべてのアーティファクト（ルール、ヘルパー、コマンド、フック、スキーマ、スクリプト、ツール、テスト、README、CONTRIBUTING、変更履歴、コミットの件名 / 本文、ブランチ名、PR のタイトル / 説明）に引き続き全面的に適用されます。CM-N / TM-N / CP-N トークンは使わず、自然なドメイン言語のみを使用します。
site/content/docs/ 配下の公開ドキュメントページは、マンデートをその CM-N ID で引用してもかまいません。このレジストリとルールのリファレンスページが、読者向けにそれらの ID を定義しているためです。ID を引用するページは、その横でマンデートを平易な言葉で名指しすべきであり（SHOULD）、マンデートのプラン内部のセクション番号を引用してはなりません（MUST NOT）。TM-N と CP-N のトークンは公開ドキュメントに含めず、下記の CM-7 ブロックにあるその他の禁止用語も同様です。
名前空間
CM-N = 設定マンデート（ここ、または site/content/docs/reference/rules.mdx のルール表に従って src/apothem/rules/*.md で定義）。TM-N = テンプレートマンデート（src/apothem/skills/plan-suite/master-template.md §4「General Mandates」、TM-1–28 で定義）。CP-N = コア原則（同じテンプレートの §6「Core Principles」、CP-1–27 で定義）。プランスイートのテンプレートが正規の TM/CP レジストリです — /plan コマンドはそのファイルを通じて相互参照を解決します。ヘルパーアーティファクト（ルール、ヘルパー、コマンド、フック）は、このレジストリを参照によって引用します。
有効化
CM-1–10 と認知アイデンティティは、すべてのやり取りを統制します。CM-11、CM-13（サブルール A から C）、CM-15、CM-16、CM-20 は /plan パイプライン内でのみ適用されます。CM-13 のサブルール D はすべての git 書き込みに、サブルール E は git mv / git rm の対象とコミット本文内のパスに適用され、どちらもそのパイプラインの内外を問いません。CM-12、CM-14、CM-17–19、CM-21–22、CM-24–26 は普遍的に適用されます。CM-23、CM-27、CM-28 は、それぞれが宣言したパスフィルターの範囲内で普遍的に適用されます。アドホック作業のデフォルトのシリアスネス: PERSONAL_USE。マンデートは、そのルールが起動時に読み込まれるかどうかにかかわらず統制します。4 つのルール（agnostic-posture、authority-inquiry、session-closure、context-management）はすべてのセッションで読み込まれ、その他のルールは、一致するパス、ルールインデックス、またはそれらを引用するルール、スキル、コマンドを通じて読み込まれます。
CM-1–10（運用）
(1) 批判的評価（→TM-10）、(2) 前提ゼロ（→TM-1）、(3) 設定駆動（→TM-2）、(4) 実装前の検索（→TM-4）、(5) 最良の解決策（→TM-7）、(6) 自己改善（→CP-20）、(7) 一貫した製品（→TM-11）、(8) ボトルネック優先の集中、(9) 意思決定の速度、(10) 容赦ない正直さ。違反の兆候を含む完全な定義: src/apothem/rules/operational-mandates.md。
CM-7（プラン内部の分離）
これは CM-7 のコードベース向けの側面です。製品の完全性の側面は、
src/apothem/rules/operational-mandates.md §CM-7に 一貫した製品（→TM-11） として記載されています。どちらのラベルも同じマンデートを指します。
コードベースのアーティファクトは、プラン内部の参照を絶対に含んではなりません。禁止用語（正規ブロック — 兄弟コンシューマーはこの列挙を相互参照します）: TM-N、CM-N、CP-N、「Resumption Contract」、「Phase Output Registry」、「convention anchors」、フェーズフォルダー名、プランスイートのファイル名（PROGRESS.md、PLAN-NOTES.md、PREAMBLE、MASTER-PLAN）、シリアスネスレベル名（EXPLORING、PERSONAL_USE、SHARED、PUBLIC_LAUNCH）。保護対象のアーティファクト: ソースコード、テスト、設定、スキーマ、ビルドスクリプト、データ、アセット、コミットメッセージ、ブランチ名、PR のタイトル / 説明、README、CONTRIBUTING、API ドキュメント、変更履歴 — Apothem のソースツリーの外から見えるあらゆるアーティファクト（Claude Code 向けの ~/.claude/ のような、ハーネスごとのインストール先）。自然なドメイン言語のみを使用します。唯一の例外は site/content/docs/ 配下の公開ドキュメントで、上記のレジストリの自己参照の免除で説明しているとおり、CM-N ID を引用してもかまいません。兄弟コンシューマー（それぞれがこのブロックを再列挙せず、参照によって引用します）: src/apothem/hooks/messages/pretooluse-bash.md、src/apothem/hooks/messages/pretooluse-write.md、src/apothem/hooks/messages/pretooluse-edit.md、src/apothem/hooks/messages/pretooluse-notebookedit.md、src/apothem/rules/operational-mandates.md §CM-7 の違反の兆候。
CM-11（プランの整合性）
A — 散文への忠実性: すべての要件が散文↔プランで追跡可能であること。スコアカード: PASS ≥90% STRONG/0 ABSENT。 B — 内部一貫性: プランスイート内のドキュメント間の整合性。スコアカード: PASS 100%。 C — ゲート: FAIL は SHARED+ で実行をブロックします（SHARED では根拠を記録したうえでのプロダクトオーナーによるオーバーライドが許可され、PUBLIC_LAUNCH ではハードブロックです）。PERSONAL_USE では助言的です。
CM-12（コンテキストスチュワードシップ）
常にリーンなコンテキスト管理を行います — CM-24 のルールを参照してください。4 つのサブティアは、後述のサブ参照の規約セクションで列挙されています。コンパクションの規律（CM-19）はコンパクションを行う行為を統制し、CM-12 は定常状態の規律を統制します。
CM-13（コミット）
- A — タスクごとの頻度: SHARED+ ではタスクごと。PERSONAL_USE ではフェーズごと。EXPLORING では任意。
- B — 品質 / 是正のコミット: 品質ゲートの修正と是正の変更は、機能作業とは分けて即座にコミットします。
- C — フェーズ終了ゲート: コミットされていない変更がフェーズ境界を越えることはありません。CM-7 の分離はすべての git アーティファクトに適用されます。PUBLIC_LAUNCH では、GPG 署名付きコミット（
git commit -S）が必須です。 - D — 人間のみの作成者表示: すべての git アーティファクトにおけるすべての作成者表示面（コミットの件名、コミットの本文、
Author:、Co-Authored-By:トレーラー、Signed-off-by:トレーラー、ブランチ名、タグ名、タグの注釈、スタッシュ名、git-notes の本文、PR のタイトル、PR の説明）は、人間のコントリビューターのみを記載します。アシスタントは、自分自身、基盤となる言語モデル、ランタイム / ハーネス / IDE / 拡張機能 / ベンダー、その他いかなる自動化ツールも、これらの面のいずれにも作成者として記載することは決してありません。禁止パターンはsrc/apothem/rules/production-ready-prs.md§6（Commit-Message Discipline → Human-only authorship）で列挙され、機械的に強制されます。マッチャーはsrc/apothem/hooks/messages/pretooluse-bash.mdの Scan 3 にあり、git に書き込むすべての Bash 呼び出しで発火します。 - E — git-mv / git-rm の対象における数値プレフィックスの規律: ファイルシステムパス上の数値プレフィックス（
NN-）は順序を伝えるものであり、順序が本質的な場合にのみ適用されます — フェーズフォルダーの連番、サブフェーズの連番、ホストが発見した序数による命名スキームです。兄弟となる連番を持たないルートレベルの単独の項目には、数値プレフィックスを付けません。付けても無意味な装飾にすぎず、存在しない順序関係を誤って示すことになります。完全な仕様はsrc/apothem/rules/canonical-layout.md§2.1 にあります。git mv/git rmとコミット本文内のパス参照に対して、src/apothem/hooks/messages/pretooluse-bash.mdの Scan 2 で機械的に強制されます。
CM-14（セッションプロトコル）
開始: ブラインドブートストラップを実行します（CM-24 §6）。終了: フェーズ終了（CM-24 §2.5）+ メモリ評価（CM-26）+ アーティファクトの進化（CM-22 §2+§4）を実行します。
CM-15–21（パイプライン）
CM-15 と CM-16 はここでインライン定義されています（個別のルールはありません）。CM-17–21 は、site/content/docs/reference/rules.mdx のルール表に従ってルールに委譲されます。この見出しは、これらのマンデートをトピックでまとめたものです。適用範囲は「有効化」の段落に従います。CM-15、CM-16、CM-20 は /plan パイプライン内でのみ適用され、CM-17–19 と CM-21 は普遍的に適用されます。
- CM-15 集団的一貫性: 変更後もプランのアーティファクトが一貫していることを検証します。
- CM-16 自律実行: SHARED+ では、フェーズ間で決して停止しません。フェーズの移行時のコンパクションは必須です（PERSONAL_USE+）。
- CM-17 ワーカーチーム: 並列化可能な作業には、委任ワーカーのチームを展開します — CM-25 のルールを参照してください。
- CM-18 エラー回復: 6 つの一般クラス（CM-24 §8）。プラン実行のクラスは TM-18 にあります。3 回の失敗後にエスカレーションします。
- CM-19 コンパクションの規律: 先回りのコンパクションのトリガー — CM-24 §3 を参照してください。
- CM-20 パイプラインのオーケストレーション: 散文→[承認]→生成→[承認]→レビュー→[承認]→実行(01→NN)。レビューの技法:
src/apothem/rules/planning-techniques.md。 - CM-21 創造的品質: 認知フィルターは装飾ではなく品質ゲートです。スケーリングは認知アイデンティティのルール §2 に従います。
CM-22–28（ルール委譲）
ルール委譲マンデートの 1 行アンカー（完全な仕様は引用先のファイルにあります）:
- CM-22 規約への警戒 — エコシステムの規約と、先回りのアーティファクト進化。
src/apothem/rules/persistent-conventions-vigilance.mdを参照してください。 - CM-23 大規模ファイルの生成 — 1 回の書き込みのしきい値を超えるファイルのための、増分追記プロトコル。
src/apothem/rules/large-file-generation.mdを参照してください。 - CM-24 コンテキストスチュワードシップ・プロトコル — 外部化、コンパクション、ブラインドブートストラップ、予算の規律。
src/apothem/rules/context-management.mdを参照してください。 - CM-25 ワーカーオーケストレーション — 展開パターン、リターンコントラクト、コンテキストの分離。完全な仕様はワーカーオーケストレーションのルールにあります。
- CM-26 自動メモリのライフサイクル — メモリの規律、トピックファイルの構成、セッション終了時の評価。
src/apothem/rules/auto-memory.mdを参照してください。 - CM-27 クリーンアーキテクチャのレイヤー — ドメイン / アプリケーション / インフラストラクチャ / プレゼンテーションの分離。
src/apothem/rules/clean-architecture-layers.mdを参照してください。 - CM-28 Python シニアアーキテクト — Python アーティファクトのための SOLID、スタイル、テスト、セキュリティのガードレール。
src/apothem/rules/code-craft-python.mdを参照してください。
ルール委譲型とインライン定義型のマンデート
- ルール委譲型（完全な仕様は
src/apothem/rules/にあります）:site/content/docs/reference/rules.mdxのルール表の「Implements」列を参照してください。CM-1–10、CM-12、CM-14、CM-17–28 を対象とします。 - インライン定義型（完全な仕様はここにあり、個別のルールはありません）: CM-11（プランの整合性）、CM-13（コミット。サブルール D と E は、詳細な仕様についてルールファイルを引用します）、CM-15（集団的一貫性）、CM-16（自律実行）。
サブ参照の規約
コマンドは、マンデート内の特定のサブセクションを参照するために、文字の接尾辞を使用します。パターン: CM-N + 接尾辞の文字 = ルールのセクション。大文字・小文字の規約: 大文字の接尾辞はマンデート内の構造的なサブセクションを表し、小文字の接尾辞はスチュワードシップのティア内のより細かい指示を表します。正規のサブ参照キー対応表（レジストリ内部の定義）は、以下の囲みブロックにあります。
CM-11A = Prose Fidelity
CM-11B = Internal Consistency
CM-11C = Gates
CM-12a = lean ingestion / demand loading (context-management §7.2)
CM-12b = budget awareness (§7.1)
CM-12c = budget pressure response (§7.3)
CM-12d = per-task effort calibration (context-management §7.4 — D3 stratified taxonomy; PHASE.md frontmatter is the per-phase override surface)
CM-13A = per-task commits
CM-13B = quality / remediation commits
CM-13C = end-of-phase commit gate
CM-13D = human-only authorship
CM-13E = numeric-prefix discipline on git mv / git rm targets
CM-23A = pre-generation size assessment (§1)
CM-23B = incremental generation protocol (§2)
CM-24B = proactive externalization (§2)
CM-25A = worker-team patterns (§1)
CM-25C = return-contract enforcement (§4)
CM-25E = isolation / non-duplication (§5)