多数架构规范死于同一种方式：它们是一份没人再维护的散文清单。三个月后源码已经改名换姓，规范还在描述一个不存在的系统——而 CI 对此毫无感知，直到问题在客户环境里爆发。
BitzOrcas 把治理反转过来：生产就绪契约被编码为机器可读的 JSON 清单与编译期门禁测试，而不是文档里的承诺。“哪些表面允许交付”由清单回答，“系统实现了什么”由源码声明回答，架构测试则持续证明两者仍一致。任何一边变化而另一边未更新，门禁都会在合并前失败——规则因此对每个贡献者和每个 Consumer 以同一方式强制执行。
治理负责什么
| 关注点 | 页面 |
|---|---|
| 完整的质量门禁契约——CI 矩阵、测试分层、状态码语义、AOT/反射/T-SQL 门禁、完成定义 | 质量门禁 |
| 清单驱动的生产就绪——表面到清单的映射与棘轮 | 生产就绪 |
| 新增模块、适配器、后台作业或端点的产品化接入契约 | 扩展接入 |
编译期 AppModule 类型化标记系统与收敛后的模块集合 | 模块治理 |
| 逐模块的 Ready / Out-of-Scope 矩阵与”Ready”的含义 | 就绪矩阵 |
| Framework/Profile/Host 的行业中立规则与所有权边界 | 行业中立表面 |
治理清单
清单位于源代码仓库的 docs/architecture/00-governance/manifests/ 下，是机器可读的事实来源。完整表格（含每个清单的范围与用途）见商业 GA 门禁。要点：
0008-error-catalog.json——1,968 条强类型错误目录（见定义错误）0013-runtime-license-policy-catalog.json——共享运行时许可策略与静态组合边界（见 Runtime License）0002-production-adapter-readiness.json——适配器就绪守卫与五级风险分层0004-template-upgrade-map.json——模板版本升级映射（由 bitz-upgrade 消费）
这些数字不是文档手工维护的：架构测试（如 ProductionReadinessNamingTests）强制每个清单声明 "scope": "production-readiness" 并锁定命名结构；当源码扩张而清单停滞时，构建会在最容易修复的时刻失败，而不是在客户环境中。
决策记录
架构决策——为何做出某项选择、拒绝了哪些替代方案、哪些已被取代——以 ADR 形式记录。见架构决策查看索引与生命周期。
治理刻意排除的内容
内部流程状态（迭代账本、编排器跟踪）与过渡期迁移说明保留在源代码仓库中，不属于面向读者的文档。
本章核心导航
- 01/07
质量门禁
verify-all 流程、CI 矩阵、测试分层、API 状态码契约、数据一致性测试矩阵、AOT/反射/T-SQL 门禁，以及门禁一次 BitzOrcas 合并的模板完成定义。
- 02/07
生产就绪
清单驱动的生产就绪模型——表面到清单的映射、遗留账本棘轮，以及在 Production/Staging 中失败关闭的适配器就绪守卫。
- 03/07
扩展接入
新增模块、适配器、后台作业或端点的产品化接入契约——能力 EXT-1 至 EXT-8、默认语义、强制运维可见性与固定验证块。
- 04/07
模块治理
编译期 AppModule 类型化标记系统、当前 36 个标记与 36 份模块手册的不同口径、中央 legacy 边界，以及治理模块标识与依赖的账本棘轮。
- 05/07
模块就绪矩阵
当前 36 个 Platform 根的 Ready / Out-of-Scope 矩阵、ProductionDepth 口径，以及门禁生产持久化的全仓库闭环状态。
- 06/07
行业中立表面
保持 Framework、通用 Profile 与 Host 无垂直行业属性的所有权规则、模板采纳契约，以及 AssignedLawyerId 到 AssignedOwnerId 的迁移。
- 07/07
外部技术规范引用清单
平台实现与开发手册显式引用的外部规范总清单：ProblemDetails（RFC 9457）、HTTP QUERY（RFC 10008）、OAuth 令牌族、TOTP、CSV 等逐条给出标准链接、源码落点与采纳方式。