Skip to content
Apothem
ガバナンス

対外コンフォーマンス登録簿 — ホストプロジェクト上での操作時

ホストプロジェクト内で生成されるすべての成果物のコンフォーマンス要件を規定する十五のマンデート登録簿(M1–M15)。エコシステム内部マンデートとの相互マッピング付き。

十五の本番マンデートの正規登録簿。 この文書は十五のマンデート登録簿(M1–M15)の全体、トリビアル対非トリビアル閾値の批准、M↔CM 相互マッピング方針、およびマンデート導入プロトコルを担います。実質的な列挙はここに置かれ、マンデートごとのルールファイルによって操作可能にされます。

このエコシステムがホストプロジェクト(ユーザーの呼び出し対象——git リポジトリ、ドキュメントツリー、研究コーパス、インフラストラクチャマニフェスト、スクラッチパッド)内のいずれかの成果物を生成、編集、再作成、改修、拡張、または削除するとき、生成されるすべての成果物は下記に宣言される**十五マンデート基準(M1–M15)**を満たします。これは交渉の余地がなく、エコシステムのあらゆる面(ヘルパー、アシスタント、コマンド、フック、応答、diff、メッセージ)に適用されます。強制は事前発行ゲートによって行われます(site/content/docs/governance/pre-emission-gate-registry.mdx を参照)。機械的部分の強制は src/apothem/conformity/*-grep.py に存在し、src/apothem/conformity/gate.py によってオーケストレーションされます。

十五のマンデートは、並行語彙方針に従って 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十の品質次元すべての成果物が十項目のチェック(厳密性、一貫性、構成可能性、可読性、孤立性、構造性、アーキテクチャ、命名、学術的参照、例/テスト/ドキュメント)に合格するsrc/apothem/rules/ten-dimension-check.md
M4自己適用意味のあるスコープのすべての発行の前に十五項目の事前発行ゲートを実行し、リリース証明を記録する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コード技巧何ではなくなぜを述べるコメント、単位付きの意図を明かす命名、型付き例外処理、名前付き定数、ホストのリンター/フォーマッター/型チェッカーを尊重する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、または別の harness 用の同等のプロジェクト単位の表面)。

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 スキーマ
開示台帳エントリ具体的なドライバー(観察されたパターンの再発、露呈したセキュリティギャップ、既存十五が網羅しない能力)に根ざした根拠とともにマンデートの導入を記録するsrc/apothem/rules/disclosure-ledger.md に従う変更セットのコミット本文または PR 説明

適用規律。 バンドルなしに到着するマンデート提案はレビューで却下されます。提案者はバンドルを完成させるか、提案を既存マンデートの拡張へ格下げします。既存の十五のマンデートは、仕様の対外軸として共に採択されました。将来の追加は、断片的に着地するのではなく、同じ全コンポーネントか無コンポーネントかの採択ケイデンスを尊重します。

格下げ/廃止プロトコル。 確立された M-N が既存の CM-N または別の M-N と冗長であると判明したとき(具現化ルール本文の相互マッピング網羅マップが双方向に direct 隣接を示す)、格下げは対称的な逆操作です。登録簿行が廃止され、ゲート行が廃止され、正規ルールが廃止され(その内容は src/apothem/rules/clean-room-generation.md §3 再記述プロトコルに従い吸収側ルールへ折り込まれる)、コンフォーマンスフィクスチャが廃止され、リリース証明スキーマの bars: ブロックが行を落とし、変更セットが吸収側ルールの引用とともに開示台帳に記録されます。格下げは同じ全コンポーネントか無コンポーネントかの不変条件を保ちます。

On this page