first-principles-review

第一性原理审查

用途

在另一个 Aegis 工作流做出方向性选择前，将此审查用作轻量级决策审查。它是一项组合式技能，而非独立工作流。

不要用它替代 brainstorming、systematic-debugging、writing-plans、requesting-code-review 或 verification-before-completion。用它梳理这些技能将要处理的决策面。

如果这项审查实质性地改变了方向，请用自然语言说明 Aegis Visibility：指出改变决策的第一性原理、被舍弃的假设、足够满足需求的最小路径，或负责人／退役判定条件。保持建议性质，并针对具体任务；不要将这一视角变成审批权，也不要变成泛化的技能追踪。

适用场景

• 用户要求采用第一性原理、第一性原理思维或奥卡姆剃刀。
• 某项设计、计划或修复有多个合理路径，但选择标准不明确。
• 任务目标含糊、约束相互冲突，或存在产品／架构方向风险。
• 调试陷入反复修复、不断增加回退方案、负责人重复、在消费者端打补丁或“再加一个分支就好”的思路。
• 审查发现实现局部上可能正确，但方向上可能有误。

不适用场景

• 简单问答、状态检查、细小的措辞／配置修改，或界定清晰且只有单一负责人的变更。
• 按已批准的计划机械执行，除非出现新的方向冲突。
• 将其作为每项任务、每轮对话或每个 TDD 周期的必经步骤。

五行审查

检查约定目标是否有遗漏或缺乏依据的新增内容，包括数量、排除项、关系和条件。审查标准来自已授权的需求；这一视角不能新增标准，也不能仅仅因为形式不同就否决已授权的转换。

只回答必要内容，通常用五行简述：

First Principle: What irreducible outcome must this satisfy?
Non-negotiables: What constraints cannot be broken?
Assumptions to Drop: What is habit, inherited shape, or unproven preference?
Smallest Sufficient Path: What is the least complex path that satisfies the first principle?
Escalation Signal: What finding would require spec/design/architecture review?

如果方向取决于一种新机制或陌生领域，请在路径与升级处理之间插入一行可选内容：

Known Prior Art: proven external pattern worth adopting or adapting to project
constraints (cite source), or `unknown` when precedent cannot be verified here

对于修复和优化，在保留解决方案前，要求提供原因或瓶颈的证据。解决可能改变选择的未知因素；实验可以先于决策。此处的“最小”是指在保留所需行为的前提下，涵盖相关因果路径所需的最少干预，而不是最小差异或最少负责人。独立原因可能需要分别修复；共用承载体并不能证明原因相同。因果覆盖范围尚未明确时，使用 systematic-debugging；情况已明确时，无需额外检查清单：

Minimality Check:
- Smallest textual diff:
- Correct owner:
- Bug class fixed:
- New branch/fallback added:
- Old path retired or scheduled:
- Verdict: sufficient repair | local patch | needs first-principles review

决策规范审查

只有当设计、修复或计划需要在写入规范或实施计划前获得认可时，才使用此升级流程。

出现以下任一风险信号时，从五行审查升级：

• 存在多个合理路径，但没有明确的选择标准
• 新增负责人、重复负责人、回退方案、适配器或仅用于兼容的承载体
• 旧路径可能需要优先删除处理或退役触发条件
• 提案依赖未经验证的假设
• 用户使用了“更优雅”“长期稳定”“第一性原理”或“奥卡姆”等表述
• 计划可能写入错误的负责人、抽象、兼容性边界或退役时间表
• 现有对象、行为、职责、契约或关系可能被重新解释、缩小范围、替换或退役，而提案在移除无效权限时可能会丢失其合理作用或明确引用

使用以下精简格式：

First-principles invariants:
- Non-negotiable goal:
- Non-negotiable constraints:
- Historical assumptions to delete:

Bounded preservation reminder:
- Evidence-backed behavior that must remain correct:
- Highest-risk counterexample:
- Material unknown / uninspected surface:
- Known explicit anchors / upstream-downstream refs and disposition:
- Role-before-value ambiguity, if any:

Owner / retirement matrix:
- New canonical owner:
- Old owner:
- Compat-only carrier:
- Delete-first / retirement trigger:

Falsification matrix (evaluate in order; stop at the first failing gate):
- Gate 0 - Premise evidence (stage-graded): design stage accepts spec/logic
  refs; implementation/runtime stage requires log, telemetry, or test
  evidence. No evidence -> park as watch-listed, do not enter value
  evaluation.
- Gate 1 - Decidability: no obtainable evidence to judge it -> park as a
  watched falsifier, do not act.
- Gate 2 - Value (any one): lowers future fix probability / shrinks the
  solution set / exposes a missing actionable acceptance criterion / the same
  broken assumption is reused elsewhere. Passing here still requires
  gates 3-5.
- Gate 3 - Cost match: change cost vs business priority, costed at the
  current stage; a valid but deferred counterexample is recorded in the owner
  doc, never parked orally.
- Gate 4 - Goal regression: the constrained solution still meets the original
  goal; re-read the accepted-constraint list at existing checkpoints (design
  review, plan approval, pre-completion verification).
- Gate 5 - Minimize then classify: boundary-shaped destructive claims must be
  minimized first; premise attacks classify as destructive directly.
  Classes: destructive (refactor/retirement track) | supplementary (boundary
  constraint) | watch-listed (falsifier). Conflicting counterexamples are
  decided by business-goal ranking, never by stacking constraints.
- Gate 6 - Adoption trace: the cheapest checkable form (regression test for
  destructive; contract, assertion, or checklist line for supplementary),
  written into the existing owner doc.

Verdict:
- Adopt / revise / reject / needs evidence:
- Blocking gaps:
- Next evidence:

架构完整性审视

当提案可以执行，但仍可能包含错误的责任归属、抽象、契约边界或退役路径时，请使用这个范围更窄的审视方式。它是方法包提供的建议性输出；如果这样就足够，也可以嵌入 Decision Hygiene Review。

如果在选择方案、分解任务、评审或报告完成风险之前出现以下任一情况，就触发此审视：

• 责任可能重叠，或不清楚哪个是规范归属方
• 最小差异会在调用方一侧增加回退逻辑、保护措施、适配器或仅用于兼容的载体
• 现有的事实来源或契约可以在更高层级解决这一类问题
• 过时的归属方、回退逻辑或旧路径可能仍在承载实际逻辑
• 这项工作声称能带来长期稳定性、“更清晰的架构”或更高层级的简化

使用以下精简格式：

Architecture Integrity Lens:
- Invariant: What must remain true for the system to be coherent?
- Canonical owner / contract: Which owner, contract, or source-of-truth should carry the behavior?
- Responsibility overlap: What duplicate owner, caller-side patch, fallback, or stale path might still carry real logic?
- Higher-level simplification: Can the problem be solved at the owner / contract / source-of-truth layer instead of by another local branch?
- Retirement / falsifier: What old path retires, or what evidence would disprove this architecture judgment?
- Responsibility / capability boundary: Which invalid authority retires, and
  does the same carrier still serve a separately evidenced legitimate role?
- Verdict: proceed | revise design | split owner | return to baseline | needs ADR/baseline sync

Bounded preservation reminder 是由风险触发的推理辅助工具，不是通用产物，也不是详尽的行为清单。检查最小范围内相关的契约、使用方、测试或历史证据。对每个已知的明确引用，决定予以保留、重新绑定、退役或拒绝；将未解决的关系标记为未知，而不是重新推断或声称语义完整。Method Pack 不会构建权威关系图，不会证明引用完整性或输入沿袭，不会计算完整的行为覆盖率，也不会发布运行时门禁。

不要对每项低风险任务都运行此审视。如果它不会改变决策范围，请立即回到当前工作流。

组合使用

• 与 brainstorming 配合：当请求范围较广、含义模糊、可能沿袭不佳的产品形态，或涉及归属方／退役／回退／适配器风险时，在选择方案前运行。当出现这些信号时，在推荐或选择方案前，使用 Decision Hygiene Review 或范围更窄的 Architecture Integrity Lens。
• 与 systematic-debugging 配合：当证据显示修复反复出现、回退逻辑增加、归属方重复或在使用方一侧打补丁时运行。
• 与 writing-plans 配合：当计划可能包含错误的归属方、抽象、兼容边界、回退逻辑、适配器或退役计划时，在分解任务前运行。如果已批准的规范尚未涵盖这些内容，请在编写任务前使用 Decision Hygiene Review 或 Architecture Integrity Lens。
• 与 requesting-code-review 配合：当评审需要检查方向和归属完整性，而不仅是代码质量时运行。
• 与 verification-before-completion 配合：仅用于指出残余的方向性风险。它不授予完成审批权。

边界

• 优先依据当前项目文件、基线文档、测试、日志和用户要求中的证据。如果缺少证据，将相关内容标记为未知，而不是凭空编造原则。
• 保持结果的建议性质。此技能可以建议升级处理，但不会创建权威的 GateDecision、PolicySnapshot 或完成审批权。
• 如果五行评审不会改变决策范围，请立即回到当前工作流。