# Governance Principles

本文件定义 Loom 治理内核中的稳定原则。

这些原则来自当前已标记为 `core` 的提取条目：

- `EXT-0001`
- `EXT-0002`
- `EXT-0006`
- `EXT-0023`
- `EXT-0034`

## 1. 文档定位

`governance/principles.md` 是治理原则真相源。

它承接：

- 真相源分层
- 事项入口与分流
- 规格准入
- 载体职责边界
- 仓库知识库模型
- 机械化治理最小能力边界

审查职责与 checkpoint 审查分工见 [review-model.md](./review-model.md)。
成熟度与关闭语义见 [maturity-and-closing.md](./maturity-and-closing.md)。

## 2. 真相源分层

调度真相与仓库语义真相必须分层，不并行维护同一份完整真相。

### 2.1 调度侧真相

调度侧（例如 Issue / Project）负责：

- 事项本体、目标、边界、关闭条件
- 状态、优先级、依赖、阶段位置
- 执行分解与排期

### 2.2 仓库侧真相

仓库侧负责：

- 长期稳定规则
- 边界事项规格与计划
- 当前改动事实、验证与风险
- checkpoint、恢复入口、handoff 等执行工件

### 2.3 载体职责矩阵

最小职责分离如下：

- Issue
  - 事项本体、目标、边界、关闭条件
- Project
  - 调度位置、优先级、阶段归属
- PR
  - 本次改动范围、验证证据、风险与回滚信息
- 规则文档
  - 长期稳定规则
- 规格文档
  - 边界事项的正式说明与计划
- 执行工件
  - checkpoint、恢复入口、handoff、阻断项

禁止事项：

- 在两个载体并行维护同一份完整事项状态
- 让 PR 承担长期规则真相
- 让执行工件承担调度层状态真相

## 3. 受控执行入口与事项分流

事项不得从意图直接进入实现，必须先进入受控入口。

默认顺序：

1. 判断事项类型
2. 判断是否触发规格准入
3. 确认进入实现的最低条件

最小分流：

- 轻量事项
  - 默认可直接实现，但不得改动共享契约或运行模型
- 中等事项
  - 进入实现前需要简化设计说明
- 边界事项
  - 进入实现前必须通过规格准入

## 4. 规格准入

规格准入是治理准入机制，不是可选文档活动。

### 4.1 触发条件

以下任一成立时默认触发规格准入：

- 共享契约变化
- 公共边界变化
- 运行模型变化
- 部署方式变化
- 高风险核心抽象变化

### 4.2 最小工件

边界事项至少应有：

- `spec.md`
- `plan.md`

### 4.3 准入问题

进入实现前至少应收口：

- 为什么值得做
- 本次改什么、不改什么
- 影响哪些边界
- 如何验证达标
- 已知风险与应对方式

## 5. 单一规则落点与知识库模型

同一条规则必须有唯一权威落点；其他文档只做摘要、映射或引用。

Loom 的知识库模型采用两层结构：

- 短入口文档
  - 负责指路、权威来源与读取顺序
- 深知识文档
  - 承接规则、方案、模板与运行机制

禁止事项：

- 把完整规则复制到多个文档并行维护
- 把所有知识压成一个超大根文档
- 让关键规则只留在会话中

## 6. 三个 checkpoint 的治理不变量

治理层必须有三个正式 checkpoint：

- `admission checkpoint`
  - 确认事项路径与准入条件
- `build checkpoint`
  - 在实现中纠偏并识别边界变化
- `merge checkpoint`
  - 只承担主干放行，不补做前序高质量判断

三者的审查职责分工见 [review-model.md](./review-model.md)。

## 7. 机械化治理能力边界

治理规则应逐步具备可机械检查能力，至少覆盖：

- 规则落点存在性
- 核心文档结构完整性
- 关键交叉引用可达性
- 关键模板存在性
- 明显职责越界信号

机械检查不替代 reviewer 的语义判断。

## 7.1 宿主平台硬门禁

若 Loom 把仓内 gate 作为主干放行前提，宿主平台必须把这组 gate 配置成 fail-closed 的硬门禁，而不是只作为提示型检查。

最小要求：

- 主干分支存在受保护的合并路径
- required checks 或等价 ruleset 已生效
- 失败检查不得进入主干
- 仓内 gate 通过，与宿主平台 gate 已强制，必须被明确区分并分别可复核

Loom 不固化具体 GitHub UI、按钮名称或宿主产品细节，但必须把“仓内 gate 已定义”与“宿主 gate 已强制”区分为两个独立事实。

## 8. 一句话结论

治理原则的目标不是增加流程层数，而是让事项在正确入口进入、在正确载体承接、在正确时点收口。
