横切强制规定登记册（CM-1–CM-28）
治理所有交互与流水线操作的生态系统内部横切强制规定（CM-1–CM-28）的完整登记册与定义。
横切强制规定的规范登记册。 本文档承载 CM-N 登记册的完整正文；实质性的枚举位于此处，并由
src/apothem/rules/下的规则文件付诸实施。每个需要详细 CM-N 正文的会话都会按需加载本文档。
登记册自引用豁免
本文档正是规范的 CM-N 登记册——它是 CM-1 到 CM-28 这些标记被定义的来源。在登记册自身的正文中重述这些标记是规范做法，而不是泄露计划内部术语。代码库隔离不变量继续完全适用于所有不属于已发布文档的其他工件（规则、辅助器、命令、钩子、schema、脚本、工具、测试、README、CONTRIBUTING、变更日志、提交主题/正文、分支名、PR 标题/描述）：不得出现 CM-N / TM-N / CP-N 标记，只使用自然的领域语言。
site/content/docs/ 下的已发布文档页面可以通过 CM-N 编号援引某条强制规定，因为本登记册和规则参考页面为读者定义了这些编号。援引编号的页面应当（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。无论其规则是否在启动时加载，强制规定都具有约束力：四条规则在每个会话中加载（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）。受保护的工件： 源代码、测试、配置、schema、构建脚本、数据、资产、提交消息、分支名、PR 标题/描述、README、CONTRIBUTING、API 文档、变更日志——任何在 Apothem 源码树之外可见的工件（按工具划分的安装目标位置，例如 Claude Code 的 ~/.claude/）。只使用自然的领域语言。唯一的例外是 site/content/docs/ 下的已发布文档，它可以按照上文登记册自引用豁免中所述援引 CM-N 编号。同级消费方（各自以引用方式援引此块，而不是重新枚举）：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——闸门： 在 SHARED+ 级别，FAIL 会阻断执行（在 SHARED 级别允许产品负责人凭记录在案的理由覆盖；在 PUBLIC_LAUNCH 级别为硬阻断）。在 PERSONAL_USE 级别为建议性。
CM-12（上下文管理）
始终进行精简的上下文管理——见 CM-24 规则。四个子层级在下文子引用约定一节中列举。压缩纪律（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:尾注、分支名、标签名、标签附注、stash 名称、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.mdScan 3，在每次写入 git 的 Bash 调用时触发。 - E——git-mv / git-rm 目标上的数字前缀纪律： 文件系统路径上的数字前缀（
NN-）表达顺序，仅在顺序是内在属性的地方适用——阶段文件夹序列、子阶段序列、由宿主发现的序数命名方案。没有同级序列的根级单例不带数字前缀；添加数字前缀是毫无意义的装饰，会错误地暗示一种并不存在的顺序关系。完整规范见src/apothem/rules/canonical-layout.md§2.1。由src/apothem/hooks/messages/pretooluse-bash.mdScan 2 在git mv/git rm以及提交正文中的路径引用上机械地强制执行。
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 错误恢复： 六个通用类别（CM-24 §8）；计划执行类别见 TM-18。3 次失败后升级处理。
- CM-19 压缩纪律： 主动压缩触发条件——见 CM-24 §3。
- CM-20 流水线编排： prose→[approval]→generate→[approval]→review→[approval]→execute(01→NN)。评审技巧：
src/apothem/rules/planning-techniques.md。 - CM-21 创意质量： 认知过滤器是质量闸门，而不是装饰。按认知身份规则 §2 进行缩放。
CM-22–28（规则委托）
规则委托强制规定的单行锚点（完整规范位于所援引的文件中）：
- CM-22 约定警觉——生态系统约定与主动的工件演进。见
src/apothem/rules/persistent-conventions-vigilance.md。 - CM-23 大文件生成——针对超过单次写入阈值的文件的增量追加协议。见
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中规则表的“实现”列。涵盖 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)