HYBB-rash 第一性原理门禁
目标
只判断当前任务、阶段和持久机制是否有存在资格，并从用户结果推导全局最小方案。不要把本门禁变成完整性证明、普通代码评审、TDD、故障诊断或长期工作流。
核心责任倒置为：谁主张新增长期复杂度，谁负责证明非加不可。发现漏洞本身不取得设计权，也不自动要求增加机制。
先净化证据集
- 只把用户可观察结果、用户明确确认的硬约束和当前直接事实作为推导前提。
- 设计、架构、计划、流程、测试和审计方法默认都是候选机制；即使写在权威文档或旧 Goal 中，也必须重新证明，不能因来源权威而升级为原始需求。
- 历史计划、产物、投入和
PASS只作待复核材料。信息有限时按当前用户、个人或小型项目、当前用法、普通环境和可接受局部返工推进。 - 有歧义时保留用户结果和硬约束，把争议机制降为候选；不得用新增持久机制填补未知。
执行者先在工作材料中区分四栏：用户结果 | 硬约束 | 当前事实 | 候选机制，并为用户结果和硬约束编号 R1...，为可引用证据编号 E1...。没有完成这一步，不得形成计划或开始审计；不要求把四栏完整展示给用户。
先求全局最小，再看局部缺口
执行者和新鲜独立审计者都先从净化后的证据集推导一个全局最小方案，并与以下反事实比较：
- 什么都不新增；
- 一次性验证、人工恢复、局部重试或其他更小的可恢复方案；
- 当前候选设计。
选择能满足当前用户结果和硬约束、持久责任最少的整体方案。不得把逐项局部最小修正相加后直接视为整体最小。
审计者先独立完成上述推导，再查看执行者候选。优先指出可以删除、降级或延后的机制，然后才指出会让用户结果为假的缺口。
概念复杂度预算
审计开始先冻结：
审计对象：本次审计整个功能，还是从当前状态开始的下一次增量；预算基线：审计对象开始前已经存在、无需本功能维护的能力。
输入已经明确预算基线时必须原样沿用，不得自行追加。每项基线都必须引用明确证明它在审计对象开始前已经存在的 baseline_fact；current_fact 只能证明现在存在，不能证明属于基线。本功能引入的概念即使已经提交、测试通过或写入计划，也仍计入整个功能的预算；不得通过先实现后审计把它洗成零成本基线。
一个新概念是：未来维护者必须记住一个独立区别，才能预测行为、正确决策或安全修改；并且这个区别可在其他区别不变时独立改变或删除，造成行为、状态、生命周期、失败方式或维护责任变化。
- 大词若隐藏可独立变化的区别，必须拆开计数。
- 同一规则的枚举值、反例和测试样例不单独计数。
- 类、表、接口、状态名不天然算概念；只按新增的长期认知区别计数。
- 完全藏在深模块内部、不向其他模块泄漏新规则或维护义务的实现步骤，不单独计入外部概念预算。
各自完整方案形成后，将拟保留的 N 个概念编号为 C1...CN，在原有审查中集中核对：
- 增加阶梯：从
S0（零新增概念）开始，Si只能在S(i-1)上增加Ci；每一步引用R和E，证明上一步存在现实可达失败，且更小可恢复办法不足。 - 逐个删除：从完整方案分别删除每个
Ci，其余概念仍保留，引用R和E说明删除后的现实失败；不得把增加阶梯中的S(i-1)当作删后方案。删后仍满足要求的概念必须删除或降为内部细节。 - 需求覆盖：每个
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 根目录运行：
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、恢复与回滚协议、后台任务及长期测试系统。
每项拟保留的长期复杂度必须同时写明以下内容；已在概念预算中写过的论证核对适用条件后引用，只补尚未覆盖的差额或条件：
- 它对应哪个当前用户结果或硬约束；
- 删除它会让哪个当前用户结果通过哪条现实可达路径失败；
- 为什么一次性验证、人工恢复、局部重试或更小的可恢复方案不足；
- 复杂度差额：相对更小方案新增和删除了哪些持久责任、状态、接口、进程、Agent 阶段和维护义务。
证据不足时默认删除、降级或延后该机制；不得以“更严谨”、理论反例、惯例、未来扩展或测试方便为理由保留。审计者可以指出缺口，但不得把自己提出的复杂机制直接写成通过条件；该机制必须另行通过同一套举证。
一个逻辑门禁
- 初审：计划形成时启用一名新鲜、独立、能力充足的审计者。盲审包只含净化后的证据集、冻结的审计对象、预算基线和待核验问题，不含执行者候选或历史结论；有新增长期概念时同时执行独立低预算反证。
- 冻结：首次正式结论冻结用户结果、硬约束、授权、正式对象、外部动作、现实运行边界、全局最小方案和可观察通过条件；首轮一次列全有证据的阻塞。
- 局部执行：只实施已举证的最小工作和低成本验证。
- 有限收口：同一审计者只复查原阻塞、复杂度举证、必要回归和终态。独立推导之后的候选比较与复查，先核对所引证明的适用条件，仅为新增事实、变化的前提、遗漏的约束或真实责任差异更新受影响的预算条目；仍适用的证明直接引用，不重写完整对照报告。缺失或不适用的证明须在相应条目补齐；全部必要材料仍须可追溯、通过原校验。关闭后立即
PASS，不得借复核扩张终点线。 - 新门禁：只有用户结果、硬约束、授权、正式对象、外部动作种类或现实运行边界实质变化时才开启。开启前逐项写明哪一项发生了变化；没有变化就继续原门禁。
内部切面、Group、schema、字段、解析、状态机、超时、测试、重构和局部修复不构成新门禁。普通正确性问题进入 TDD、代码评审或非阻塞 To Do；只有直接证明用户结果仍为假，或会造成现实、严重且难恢复后果时，才打开原门禁中的最小相关条件。
防止局部修补累积
出现以下任一情况时，停止继续加局部机制，回到用户结果重新比较整体方案：
- 同一问题需要第二次增加 owner、状态、进程、恢复协议或生命周期；
- 同一用户结果准备开启第二个新鲜门禁；
- 审计或修复流程接近或超过最小实现成本；
- 新增机制又产生新的必须关闭条件；
- 总复杂度上升，却没有删除更昂贵且有证据的旧责任。
重新比较后，不能证明非加不可的机制必须删除、降级或进入 To Do，不能用下一轮局部 REVISE 继续堆叠。
结论标准
只有直接事实证明当前审计对象已失去必要性，才判 STOP；停止范围仅限该对象，某个阶段不再需要不等于整个任务应结束。
对象仍需完成或必要性尚待决定性事实确认时，REVISE 只对应以下有证据的阻塞：
- 候选与用户结果或硬约束冲突，包括可达反例直接证明用户结果为假；
- 缺少会改变本阶段是否成立的决定性事实；
- 直接证据显示下一步会造成现实、严重且难恢复的后果；
- 候选长期复杂度缺少完整举证。此时
REVISE的方向必须是删除、降级、延后或改为更小验证，不能默认增加机制。
更严谨的方向、边缘情况、不改变用户结果的未知、惯例、未来设想和有界可恢复问题只能进入非阻塞备注、TDD、代码评审或 To Do。
输出
默认向用户给出简短、可行动的正式结论：说明当前对象和 PASS | REVISE | STOP；优先说可删除、降级或延后的机制及其关键理由；说明必要保留项、会改变决定的阻塞和关闭条件，以及本次允许继续的范围。没有相应内容就省略，不为凑结构制造问题。
完整的证据、预算、阶梯、删除检查和挑战记录保留在本轮临时工作材料中。仅在用户要求展开、交付正式审计文档，或某项分歧需要展示推导时，展示相关材料；不默认输出八段报告，不在每个段落重复同一论证。简短表达不减少证明、独立审计、机械校验或授权边界的要求。
PASS：预算机械校验通过，所有保留概念都完成举证，且当前候选中没有满足同一结果的更小方案；只放行当前下一步。REVISE：优先列出要删除、降级或延后的机制；只有直接用户结果缺口或严重风险才允许要求新增机制，且新增机制自身必须先完成举证。STOP：按上述必要性标准，给出事实链、停止范围和重新开启条件，结束该对象对应的工作。
审计者不可用时，只暂停依赖该审计结论的步骤并说明恢复条件；不可用本身不产生新的 PASS | REVISE | STOP，也不推翻已有结论。保留冻结范围，审计恢复后继续原门禁。当前执行者负责实施、暂停与继续；审计结论不自动授权外部动作。