対外コンフォーミティレジストリ — ホストプロジェクト上での操作時
ホストプロジェクト内で生成されるすべての成果物のコンフォーミティ要件を規定する 15 のマンデートレジストリ（M1–M15）。エコシステム内部マンデートとの相互マッピング付き。
15 の本番マンデートの正規レジストリ。 この文書は 15 のマンデートレジストリ（M1–M15）の全体、トリビアル対非トリビアル閾値の批准、M↔CM 相互マッピング方針、およびマンデート導入プロトコルを担います。実質的な列挙はここに置かれ、マンデートごとのルールファイルによって操作可能にされます。
このエコシステムがホストプロジェクト（ユーザーの呼び出し対象——git リポジトリ、ドキュメントツリー、研究コーパス、インフラストラクチャマニフェスト、スクラッチパッド）内のいずれかの成果物を生成、編集、再作成、改修、拡張、または削除するとき、生成されるすべての成果物は下記に宣言される**15 マンデート基準（M1–M15）**を満たします。これは交渉の余地がなく、エコシステムのあらゆる面（ヘルパー、アシスタント、コマンド、フック、応答、diff、メッセージ）に適用されます。強制は事前出力ゲートによって行われます（site/content/docs/governance/pre-emission-gate-registry.mdx を参照）。機械的部分の強制は src/apothem/conformity/*-grep.py に存在し、src/apothem/conformity/gate.py によってオーケストレーションされます。
15 のマンデートは、並行語彙方針に従って CM-N マンデートと並んで動作します（site/content/docs/governance/cross-cutting-mandates.mdx を参照）。M と CM は直交するガバナンス次元です（M は対外軸——ホストプロジェクトの成果物。CM は対内軸——エコシステム内部の成果物）。下記に列挙される各ルールは、そのマンデートの正規の本拠地です。このレジストリはインデックスです。
| ID | マンデート | 一行要約 | 正規ルール |
|---|---|---|---|
| M1 | ホストプロジェクト非依存 | ホストのスタック、フォーマッター、リンター、レイアウト、慣用法を発見し、それらを尊重する。沈黙は M5 に従い、M7 の注釈付きで照会として表面化させる | src/apothem/rules/host-discovery.md |
| M2 | 編集の規律 | すべての修正、拡張、改良を根拠とともに開示する。沈黙した過剰遵守も、沈黙した越権もしない | src/apothem/rules/disclosure-ledger.md |
| M3 | 10 の品質次元 | すべてのアーティファクトが 10 バーのチェック（厳密性、一貫性、構成可能性、可読性、孤立性、構造性、アーキテクチャ、命名、学術的参照、例・テスト・ドキュメント）に合格する | src/apothem/rules/ten-dimension-check.md |
| M4 | 自己適用 | 意味のあるスコープのすべての出力の前に 15 バーの事前出力ゲートを実行し、ゲート結果を記録する | src/apothem/rules/pre-emission-gate.md |
| M5 | 権威の原則 | 照会せよ、捏造するな。アイデンティティ、スコープ、好み、セキュリティ、命名、インフラ、バージョン固定のデータは決して捏造しない | src/apothem/rules/authority-inquiry.md |
| M6 | 専門知識の取り込み | 意図を読み取り、先回りして修正し、隣接するギャップで拡張し、引用した根拠で改良し、二次的な帰結を予測する | src/apothem/rules/expertise-posture.md |
| M7 | 選択肢の注釈 | 複数の選択肢を伴うすべての選択には、推奨マーカーと、原則に結びついた根拠が付く。権威ある領域では、沈黙した選択は禁止される | src/apothem/rules/option-annotation.md |
| M8 | 確定性と緻密性 | 拘束力のある規定が可能な箇所では、ぼかさない。分岐を列挙せずに「場合による」と書かない。すべての契約は、事前、事後、失敗の条件を持つ | src/apothem/rules/definitiveness.md |
| M9 | 視覚的レバレッジ | 構造的な主題は、出所と検証日付を伴う現状の図（既定は Mermaid）を担う | src/apothem/rules/visual-leverage.md |
| M10 | 双方向バインディング | 実質的な構造要素は、相互的なバインディングを宣言する（Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔） | src/apothem/rules/bidirectional-binding.md |
| M11 | アジャイルスプリント | 自明でない複数ステップの作業は、規律あるスプリント（ゴール / バックログ / DoR / DoD / レビュー / レトロスペクティブ）として実行される | src/apothem/rules/agile-sprints.md |
| M12 | フェーズ報告と正規レイアウト | 複数フェーズの作業は、サブフェーズごとの報告とフェーズレベルの集約を出力する。出力は正規レイアウトに置かれる | src/apothem/rules/canonical-layout.md |
| M13 | コードクラフト | 何ではなくなぜを述べるコメント、単位付きで意図を明かす命名、型付きの例外処理、名前付き定数、ホストの lint / フォーマット / 型チェックの尊重 | src/apothem/rules/code-craft-{python,shell,markdown,conventions}.md（言語ごと） |
| M14 | エコシステムのシステム性 | 新しいコンポーネントは、上流、下流、同位、強制者を宣言する。ホストのレジストリに索引付けされる。サイロも孤児も持ち込まない | src/apothem/rules/systemic-participation.md |
| M15 | 本番対応の形態 | コードの変更は、同じ変更セットの中で、テスト、ドキュメント、CHANGELOG の項目、準拠したコミットメッセージ、CI グリーンとともに出荷される | src/apothem/rules/production-ready-prs.md |
1. トリビアル対非トリビアル閾値（確定済み）
トリビアルな作業と非トリビアルな作業を分ける閾値——非トリビアルな作業は M11 ＋ M12 の装置を起動する——は、行数＋スコープのハイブリッドです。変更がトリビアルなのは、それが ≤ 5 行の単一ファイル編集であり、かつ公開 API 表面の変更を導入せず、かつ振る舞いの変化もない場合です。それ以外はすべて非トリビアルです。M5 の一度確定する規律に従い一度だけ確定されます。閾値はここにユーザースコープで存在し、M1 ホスト発見を尊重する明示的なプロジェクトスコープ宣言によってのみ上書きされます（例: Claude Code 用の <project>/.claude/CLAUDE.md、または別のハーネス用の同等のプロジェクト単位の表面）。
2. M↔CM 相互マッピング
各 M 番号ルール本文は、並行語彙方針を用いて、その CM-N 相互マッピングをインラインで（その Cross-bound with ↔ バインディング内に）宣言します。M マンデートが最も近い CM-N アナログを持つ場合、両方が適用される箇所で両方のルールが適用されます（置換なし）。マッピングはルール本文に内在します。このレジストリはマッピング表を複製することなく軸方針を要約します。
3. マンデート導入プロトコル
新しい M 番号マンデート（例: 将来の M16）の追加は、バンドルされた変更です。下記の各コンポーネントが同一の変更セット内に存在する場合にのみ、バンドルはレジストリに到達します。沈黙した追加——支持バンドルなしにレジストリ表へ新しい M 行を加えること——はマンデート軸ドリフトを生み、M14 体系参加に従い非準拠です。
| 必須コンポーネント | 目的 | 着地先 |
|---|---|---|
| レジストリの表にあるマンデートの行 | マンデート、その一行要約、その正規ルールを命名する | このレジストリの上の表 |
| CM-N 相互マッピングのセル | §2 の並行語彙方針に従い、最も近い CM-N の類似物を宣言する（または新しい軸として (no direct CM-N analog) とマークする） | 新しいルールの Cross-bound with ↔ の行 |
| 正規ルールの本文 | マンデートの実質的な仕様（事前条件、必要な振る舞い、開示面、失敗の兆候、五方向のバインディング） | src/apothem/rules/<mandate-name>.md |
| 事前出力ゲートの行 | バーのチェック種別（機械的、推論的、混合）と、その Failure → action を命名する | 事前出力ゲートのレジストリ表（site/content/docs/governance/pre-emission-gate-registry.mdx） |
| 強制面 | gate.py によってオーケストレーションされる src/apothem/conformity/<name>-grep.py の機械的な grep、または、オペレーター自己点検のアンカーを伴う推論的バーの明示的な宣言のいずれか | src/apothem/conformity/（機械的）、または reasoned とマークされたゲートの行（オペレーター自己点検） |
| コンフォーミティフィクスチャ | tests/conformity-scenarios/fixtures/F-<N>-<name>/ 配下のフィクスチャで、マンデートの失敗モードを演習する。検証器のマンデート一覧は、新しいバーを含むよう更新される | tests/conformity-scenarios/ |
| ゲート結果スキーマの更新 | ゲート結果の bars: ブロックは新しい行を獲得する。既存のアーティファクトのゲート結果ブロックは、再監査されるまで、新しい行を n/a (with reason: pre-mandate-N artifact) として扱う | site/content/docs/governance/pre-emission-gate-registry.mdx の §1 スキーマ |
| 開示台帳のエントリ | 具体的な動機（観察されたパターンの再発、露呈したセキュリティギャップ、既存の 15 が網羅しない能力）に根ざした根拠とともに、マンデートの導入を記録する | src/apothem/rules/disclosure-ledger.md に従う、変更セットのコミット本文または PR の説明 |
適用規律。 バンドルなしに到着するマンデート提案はレビューで却下されます。提案者はバンドルを完成させるか、提案を既存マンデートの拡張へ格下げします。既存の 15 のマンデートは、仕様の対外軸として共に採択されました。将来の追加は、断片的に着地するのではなく、同じ全コンポーネントか無コンポーネントかの採択ケイデンスを尊重します。
格下げ／廃止のプロトコル。 確立された M-N が既存の CM-N、または別の M-N と冗長であると判明した場合（具現化するルールの本文にある相互マッピング網羅マップが、双方向の direct 隣接を示す）、格下げは対称的な逆操作になります。レジストリの行が廃止され、ゲートの行が廃止され、正規ルールが廃止されます（内容は src/apothem/rules/clean-room-generation.md §3 の再記述プロトコルに従い、吸収側のルールへ折り込まれます）。コンフォーミティフィクスチャが廃止され、ゲート結果スキーマの bars: ブロックから行が落とされ、変更セットは吸収側ルールの引用とともに開示台帳に記録されます。格下げは、すべてのコンポーネントか、またはコンポーネントなしか、という同じ不変条件を保ちます。