# First Principles Gate

> 用户显式调用 `$first-principles-gate` 时，从可观察结果和硬约束重新推导全局最小方案，用概念预算、独立低预算反证和必要性证明卡住无依据的长期复杂度；同一用户结果只保留一个逻辑门禁，普通实现问题回到 TDD 或评审。

- Skill: `hybb-rash/first-principles-gate` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add hybb-rash/first-principles-gate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hybb-rash/first-principles-gate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: HYBB-rash (https://skillmd.com/u/hybb-rash)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hybb-rash/first-principles-gate

---


# 第一性原理门禁

## 目标

只判断当前任务、阶段和持久机制是否有存在资格，并从用户结果推导全局最小方案。不要把本门禁变成完整性证明、普通代码评审、TDD、故障诊断或长期工作流。

核心责任倒置为：**谁主张新增长期复杂度，谁负责证明非加不可**。发现漏洞本身不取得设计权，也不自动要求增加机制。

## 先净化证据集

1. 只把用户可观察结果、用户明确确认的硬约束和当前直接事实作为推导前提。
2. 设计、架构、计划、流程、测试和审计方法默认都是候选机制；即使写在权威文档或旧 Goal 中，也必须重新证明，不能因来源权威而升级为原始需求。
3. 历史计划、产物、投入和 `PASS` 只作待复核材料。信息有限时按当前用户、个人或小型项目、当前用法、普通环境和可接受局部返工推进。
4. 有歧义时保留用户结果和硬约束，把争议机制降为候选；不得用新增持久机制填补未知。

执行者先在工作材料中区分四栏：`用户结果 | 硬约束 | 当前事实 | 候选机制`，并为用户结果和硬约束编号 `R1...`，为可引用证据编号 `E1...`。没有完成这一步，不得形成计划或开始审计；不要求把四栏完整展示给用户。

## 先求全局最小，再看局部缺口

执行者和新鲜独立审计者都先从净化后的证据集推导一个**全局最小方案**，并与以下反事实比较：

- 什么都不新增；
- 一次性验证、人工恢复、局部重试或其他更小的可恢复方案；
- 当前候选设计。

选择能满足当前用户结果和硬约束、持久责任最少的整体方案。不得把逐项局部最小修正相加后直接视为整体最小。

审计者先独立完成上述推导，再查看执行者候选。优先指出可以删除、降级或延后的机制，然后才指出会让用户结果为假的缺口。

## 概念复杂度预算

审计开始先冻结：

- `审计对象`：本次审计整个功能，还是从当前状态开始的下一次增量；
- `预算基线`：审计对象开始前已经存在、无需本功能维护的能力。

输入已经明确预算基线时必须原样沿用，不得自行追加。每项基线都必须引用明确证明它在审计对象开始前已经存在的 `baseline_fact`；`current_fact` 只能证明现在存在，不能证明属于基线。本功能引入的概念即使已经提交、测试通过或写入计划，也仍计入整个功能的预算；不得通过先实现后审计把它洗成零成本基线。

一个**新概念**是：未来维护者必须记住一个独立区别，才能预测行为、正确决策或安全修改；并且这个区别可在其他区别不变时独立改变或删除，造成行为、状态、生命周期、失败方式或维护责任变化。

- 大词若隐藏可独立变化的区别，必须拆开计数。
- 同一规则的枚举值、反例和测试样例不单独计数。
- 类、表、接口、状态名不天然算概念；只按新增的长期认知区别计数。
- 完全藏在深模块内部、不向其他模块泄漏新规则或维护义务的实现步骤，不单独计入外部概念预算。

各自完整方案形成后，将拟保留的 `N` 个概念编号为 `C1...CN`，在原有审查中集中核对：

1. **增加阶梯**：从 `S0`（零新增概念）开始，`Si` 只能在 `S(i-1)` 上增加 `Ci`；每一步引用 `R` 和 `E`，证明上一步存在现实可达失败，且更小可恢复办法不足。
2. **逐个删除**：从完整方案分别删除每个 `Ci`，其余概念仍保留，引用 `R` 和 `E` 说明删除后的现实失败；不得把增加阶梯中的 `S(i-1)` 当作删后方案。删后仍满足要求的概念必须删除或降为内部细节。
3. **需求覆盖**：每个 `R` 明确由预算基线或哪些 `C` 满足，不得以缩小预算为由漏掉硬约束。

增加阶梯、逐个删除和长期复杂度举证都必须完成，每条证明只维护一份。需复用的正文放在对应 `Ci.necessity`（可分子字段），其他位置保留 `R/E` 并用 `proof_ref` 引用；`failure_before` 和 `failure` 也可用 `proof` 或 `explanation` 直接记录正文。`proof_ref` 指向本预算的实际证明正文，如 `C1.necessity.before` 或 `C1.necessity.delete_from_full`，不把文字“见 C1”当作引用。

引用前核对当前保留机制是否改变所引失败路径及恢复条件；增加前与删后条件相同才能复用，否则在同一 `Ci` 下分别证明。仅说“其他责任不能替代”不算完成核对。预算 JSON 保留校验器要求的全部结构、需求引用和证据引用。

把预算写入临时 JSON，至少包含 `audit_scope | requirements | evidence | claimed_count | concepts | coverage | ladder | delete_one`。`audit_scope.mode` 只能是 `whole_feature | next_delta`；每项 `audit_scope.baseline` 写成 `capability + evidence_ids`。没有基线能力时显式声明空列表；只有声明了有 `baseline_fact` 证据的基线能力，需求覆盖才可引用 `baseline`。然后从本 Skill 根目录运行：

```bash
python3 scripts/validate_complexity_budget.py <budget.json>
```

校验器只检查基线已声明且只引用 `baseline_fact`、`N` 与清单/阶梯/删除测试守恒、每步只加一个概念、所有需求已覆盖、其他证据引用存在且属于 `user_result | hard_constraint | current_fact | verified_failure`，以及证明正文或可解析的正文引用存在。校验失败直接 `REVISE`；不得靠增加概念修复格式或引用错误。原子性、引用适用条件、证明是否成立、需求语义和方案优劣仍由审计者判断。

增加阶梯与逐个删除只能证明当前候选的概念不可直接删除，不能证明世界上不存在另一套更少概念的设计。因此只可结论为“在当前事实和本轮候选中未发现更小方案”，不得宣称数学上的全局最优。

## 独立低预算反证

只要候选包含新增长期概念，初审就在可用时让一名能力较低、成本较低的独立模型（优先 Luna 或 Terra）从同一冻结证据集、审计对象和预算基线重新推导预算。它先看原始事实形成方案，再看执行者候选；它是复杂度挑战者，不是投票者、执行者或固定路由。

- 双方完成独立推导后，先核对各自实际保留的行为和维护责任，再比较预算数字。仅命名、合并表述或拆分粒度不同的，按同一概念定义校正计数，不把这种差异当作删减了责任；确有更小且通过机械校验的方案时，复杂方案主张者必须用已编号证据给出具体失败反例，否则采用更小方案。责任对应关系只需在现有预算或分歧说明中写清，不新增对照表、文件或审计轮次。
- 低预算方案漏掉硬约束、捆绑可独立变化的概念或引用范围外事实时，指出具体 `R`、`C`、`E`，不得只说“不够严谨”。
- 只有首个挑战结果结构无效、越出证据集，或双方对硬约束是否覆盖存在无法由当前事实消解的冲突时，才使用第二名低预算挑战者；不得把多模型变成常驻评审委员会。

## 长期复杂度举证

长期复杂度包括新增或扩大模块、服务、进程、Agent 阶段、状态、schema、持久字段、公开或私有接口、owner、恢复与回滚协议、后台任务及长期测试系统。

每项拟保留的长期复杂度必须同时写明以下内容；已在概念预算中写过的论证核对适用条件后引用，只补尚未覆盖的差额或条件：

1. 它对应哪个当前用户结果或硬约束；
2. 删除它会让哪个当前用户结果通过哪条现实可达路径失败；
3. 为什么一次性验证、人工恢复、局部重试或更小的可恢复方案不足；
4. **复杂度差额**：相对更小方案新增和删除了哪些持久责任、状态、接口、进程、Agent 阶段和维护义务。

证据不足时默认删除、降级或延后该机制；不得以“更严谨”、理论反例、惯例、未来扩展或测试方便为理由保留。审计者可以指出缺口，但不得把自己提出的复杂机制直接写成通过条件；该机制必须另行通过同一套举证。

## 一个逻辑门禁

1. **初审**：计划形成时启用一名新鲜、独立、能力充足的审计者。盲审包只含净化后的证据集、冻结的审计对象、预算基线和待核验问题，不含执行者候选或历史结论；有新增长期概念时同时执行独立低预算反证。
2. **冻结**：首次正式结论冻结用户结果、硬约束、授权、正式对象、外部动作、现实运行边界、全局最小方案和可观察通过条件；首轮一次列全有证据的阻塞。
3. **局部执行**：只实施已举证的最小工作和低成本验证。
4. **有限收口**：同一审计者只复查原阻塞、复杂度举证、必要回归和终态。独立推导之后的候选比较与复查，先核对所引证明的适用条件，仅为新增事实、变化的前提、遗漏的约束或真实责任差异更新受影响的预算条目；仍适用的证明直接引用，不重写完整对照报告。缺失或不适用的证明须在相应条目补齐；全部必要材料仍须可追溯、通过原校验。关闭后立即 `PASS`，不得借复核扩张终点线。
5. **新门禁**：只有用户结果、硬约束、授权、正式对象、外部动作种类或现实运行边界实质变化时才开启。开启前逐项写明哪一项发生了变化；没有变化就继续原门禁。

内部切面、Group、schema、字段、解析、状态机、超时、测试、重构和局部修复不构成新门禁。普通正确性问题进入 TDD、代码评审或非阻塞 To Do；只有直接证明用户结果仍为假，或会造成现实、严重且难恢复后果时，才打开原门禁中的最小相关条件。

## 防止局部修补累积

出现以下任一情况时，停止继续加局部机制，回到用户结果重新比较整体方案：

- 同一问题需要第二次增加 owner、状态、进程、恢复协议或生命周期；
- 同一用户结果准备开启第二个新鲜门禁；
- 审计或修复流程接近或超过最小实现成本；
- 新增机制又产生新的必须关闭条件；
- 总复杂度上升，却没有删除更昂贵且有证据的旧责任。

重新比较后，不能证明非加不可的机制必须删除、降级或进入 To Do，不能用下一轮局部 `REVISE` 继续堆叠。

## 结论标准

只有直接事实证明当前审计对象已失去必要性，才判 `STOP`；停止范围仅限该对象，某个阶段不再需要不等于整个任务应结束。

对象仍需完成或必要性尚待决定性事实确认时，`REVISE` 只对应以下有证据的阻塞：

1. 候选与用户结果或硬约束冲突，包括可达反例直接证明用户结果为假；
2. 缺少会改变本阶段是否成立的决定性事实；
3. 直接证据显示下一步会造成现实、严重且难恢复的后果；
4. 候选长期复杂度缺少完整举证。此时 `REVISE` 的方向必须是删除、降级、延后或改为更小验证，不能默认增加机制。

更严谨的方向、边缘情况、不改变用户结果的未知、惯例、未来设想和有界可恢复问题只能进入非阻塞备注、TDD、代码评审或 To Do。

## 输出

默认向用户给出简短、可行动的正式结论：说明当前对象和 `PASS | REVISE | STOP`；优先说可删除、降级或延后的机制及其关键理由；说明必要保留项、会改变决定的阻塞和关闭条件，以及本次允许继续的范围。没有相应内容就省略，不为凑结构制造问题。

完整的证据、预算、阶梯、删除检查和挑战记录保留在本轮临时工作材料中。仅在用户要求展开、交付正式审计文档，或某项分歧需要展示推导时，展示相关材料；不默认输出八段报告，不在每个段落重复同一论证。简短表达不减少证明、独立审计、机械校验或授权边界的要求。

- `PASS`：预算机械校验通过，所有保留概念都完成举证，且当前候选中没有满足同一结果的更小方案；只放行当前下一步。
- `REVISE`：优先列出要删除、降级或延后的机制；只有直接用户结果缺口或严重风险才允许要求新增机制，且新增机制自身必须先完成举证。
- `STOP`：按上述必要性标准，给出事实链、停止范围和重新开启条件，结束该对象对应的工作。

审计者不可用时，只暂停依赖该审计结论的步骤并说明恢复条件；不可用本身不产生新的 `PASS | REVISE | STOP`，也不推翻已有结论。保留冻结范围，审计恢复后继续原门禁。当前执行者负责实施、暂停与继续；审计结论不自动授权外部动作。