guide-meta-thinking

name: guide-meta-thinking description: | 元思考（MetaThink）方法论：从第一性原理推导系统行为，而非机械查文档。 核心是理解"为什么这样设计"而非"它是什么"，从设计约束推导出不可消除的行为边界， 用这些边界作为代码正确性的 eval 标准，并区分"我们的 bug"与"系统的固有限制"。

有以下意图时必须加载此 skill： (1) 不知道某个行为是 bug 还是系统正常行为 → 用元思考做 fault attribution (2) 面对新的技术系统，需要快速建立正确的心智模型 → 用元思考推导约束 (3) 对一段代码有多种实现方式，不知道哪种正确 → 用元思考找 eval 标准 (4) reconcile 发现异常，不确定根因 → 用元思考的约束链追溯 (5) 需要理解为什么 guide-polymarket-fundamentals 这样设计 → 读本 skill

tags: [meta-thinking, first-principles, methodology, eval, fault-attribution, meta-chain, essence] domain: pm created: 2026-03-23 updated: 2026-04-15

元思考（MetaThink）方法论

Patterns（可复用工作流）

核心定义：元思考不是"知道答案"，而是"知道如何推导答案"。

第一部分：元思考是什么

两种思维模式的对比

文档思维：Polymarket 的 FOK 订单在未完全成交时会被取消。

元思考：如果我设计一个混合撮合系统（链下匹配 + 链上结算），我需要一个机制保证原子性。FOK 是这个机制的自然结果——要么链下能撮合到全部数量，要么不提交链上。这意味着 FOK 的"kill"必然发生在链下，链上不会有任何痕迹。

这一点的差别是根本性的：

元思考的威力在于：当文档缺失、文档错误、或行为未被文档化时，你仍然能推断出正确答案。 更重要的是，你能推断出"哪些代码实现是不可能正确的"——即使这段代码表面上看起来没问题。

元思考的本质

元思考是约束传播（constraint propagation）：

系统要解决的问题
  → 工程不可避免约束（数学/物理层面）
    → 设计者必然选择的方案
      → 该方案带来的不可消除副作用
        → 代码必须尊重这些副作用，否则必然产生 bug

这条链上的每一步都是必然推断，不是猜测。如果你的代码违反了链上的某个节点，不是"可能有 bug"，而是"必然有 bug"。

第二部分：元思考的推导步骤（SOP）

标准流程，5 步：

Step 1: 定义系统要解决的核心问题
  → 不是"Polymarket 是什么"，而是"预测市场要解决什么问题"
  → 问法：这个系统如果不存在，用户面临什么困境？
  → 例：让"我相信 X 会发生"变成有对手方的可交易资产，
        同时保证结果由链上合约结算，不依赖中心化机构

Step 2: 识别不可回避的工程约束
  → 什么是数学/物理/经济层面无法绕过的？
  → 问法：即使无限资金、无限工程师，这个约束还存在吗？
  → 例：链上操作有 gas 成本（物理约束）
        区块有出块时间，确认有延迟（物理约束）
        两个系统之间必然存在信息不对称窗口（信息论约束）

Step 3: 推导设计决策
  → 给定约束，理性设计者必然选择什么？
  → 问法：给定这些约束，有哪些设计空间？最优选择是什么？
  → 例：gas 太贵 → 链下撮合是唯一可行选择
        链下撮合需要可信方 → Operator 模型是自然结果

Step 4: 从设计决策推出不可消除的行为约束
  → 这个设计选择带来了哪些无法消除的副作用（行为约束）？
  → 问法：做了这个选择，哪些事情"必然"成立？哪些事情"绝对不可能"？
  → 例：链下撮合 → 存在"不确定窗口"（从下单到链上确认之间状态不确定）
        不确定窗口 → 任何依赖"下单即确认"的代码必然产生 ghost 仓位

Step 5: 用这些约束评估代码实现
  → 代码是否违反了某个不可消除约束？
  → 问法：这段代码假设了什么？这个假设和约束链矛盾吗？
  → 例：在不确定窗口内做 DB 写入 → 假设"下单即持仓" → 违反 Step 4 约束
        → 这段代码必然产生 ghost 仓位 → 不是 typo，是架构错误

SOP 使用注意

• Step 1-2 是发现约束，Step 3-4 是推导约束，Step 5 是应用约束
• 每一步要明确推断置信度。高置信（数学必然）vs 中置信（设计最优选择）vs 低置信（推断但未验证）
• 低置信推断必须记录到 KNOWLEDGE_GAPS，不能当作高置信使用
• SOP 可以反向使用：从一个已知 bug 反推"哪个约束被违反了"（fault attribution）

第三部分：三个完整的元思考案例

案例 1：为什么 pre-fill DB write 是架构错误而不是 typo

问题：发现代码在 order 提交后、fill 事件收到前就写了 DB 仓位记录。是 typo 还是架构错误？

元思考推导：

Step 1: Polymarket 要解决的核心问题
  → 让预测市场可交易，同时保证结算的可信性（链上合约）
  → 可信性要求：最终状态由链上合约决定，不由任何中心化方决定

Step 2: 不可回避的工程约束
  → 链上操作有 gas 成本（约束 A）
  → 区块确认有不确定延迟（约束 B）
  → 约束 A + B → 链下撮合是必然选择（否则每次下单都要等链上确认，体验不可接受）

Step 3: 设计决策
  → 采用链下 CLOB + 链上 CTF Exchange 的混合架构
  → 订单在链下撮合，撮合结果批量提交链上

Step 4: 不可消除的行为约束
  → 从"用户提交 order"到"链上确认成交"之间，存在不确定窗口
  → 在此窗口内，order 可能：成交、部分成交、被取消、超时、链下拒绝
  → 约束：在链上确认前，任何仓位状态都是"未确定"的
  → 推论：任何依赖"提交 order 即持仓"的代码，必然在某些场景下产生错误仓位

Step 5: 评估代码
  → pre-fill DB write 假设：提交 order 之后，仓位就存在了
  → 这个假设违反了 Step 4 的约束：提交 order ≠ 持仓确认
  → 结论：这不是"漏写了一个 await"，而是违反了混合撮合系统的不确定窗口约束
  → 修复方向：仓位记录必须在 fill 事件确认后写入，不能在 order 提交后写入

结论：这是架构错误。即使把代码改得再"干净"，只要保留 pre-fill write 的时序，ghost 仓位就会必然出现。修复必须改变写入时序。

案例 2：为什么 FAK 的 WS 事件顺序问题无法从"修代码"角度解决

问题：FAK 订单有时 WS 的 USER_TRADE（成交）事件在 USER_ORDER（订单状态）事件之后才到。代码依赖某个顺序，偶发 bug。能通过调整代码处理顺序修复吗？

元思考推导：

Step 1: WS 是什么
  → WebSocket 是 Polymarket 提供的实时推送基础设施
  → 目的：让客户端感知订单/成交的"尽快通知"

Step 2: WS 的工程约束
  → WS 是 best-effort 推送（无法保证消息顺序）
  → 这不是设计选择，是网络层的物理约束：
    - 链下 CLOB 服务和 WS 推送服务是不同进程
    - 成交事件和订单状态事件来自不同来源
    - 任何多路消息系统都无法保证跨来源的消息有序性

Step 3: Polymarket 的设计决策
  → WS 提供 best-effort 通知，不提供顺序保证
  → 链上状态（通过 API/链上查询）是最终真相
  → WS 是"加速感知"，不是"权威来源"

Step 4: 不可消除的行为约束
  → WS 事件顺序不被保证（这是约束，不是 bug）
  → 任何依赖 WS 事件特定顺序的代码，都会在网络波动时失败
  → 最终一致性只能由链上查询（reconcile）保证

Step 5: 评估"修代码"方案
  → 方案 A：调整代码处理顺序（先等 USER_ORDER，再处理 USER_TRADE）
    → 假设：如果等待足够长，顺序会正确
    → 反驳：WS 顺序无法被保证，等待只是降低了失败概率，不是消除
  → 方案 B：用 reconcile 保证最终一致性
    → 假设：WS 是加速通知，reconcile 是权威来源
    → 符合约束：reconcile 通过链上/API 查询，不依赖 WS 顺序
    → 结论：方案 B 是正确架构

结论：试图通过"修代码处理顺序"解决这个问题是错误方向。正确做法是接受 WS 的 best-effort 语义，用 reconcile 保证最终一致性。任何依赖 WS 顺序的代码都是架构上脆弱的。

案例 3：如何判断一个新发现的 discrepancy 是我们的 bug 还是 Polymarket 的行为

问题：reconcile 发现 DB 中一个仓位的数量和 Polymarket API 返回的数量不一致。这是我们的 bug 还是 Polymarket 的问题？

元思考推导：

Step 1: Polymarket 的真相层级
  → 链上合约是最终权威（数学不可篡改）
  → Polymarket API 是链上状态的索引（should mirror 链上）
  → WS 是链上/API 的推送（best-effort）
  → 我们的 DB 是我们对上述的本地记录

Step 2: 不可回避的约束
  → 链上合约状态是最终真相，所有其他层必须与之对齐
  → API 是 Polymarket 的责任范围，链上是公开可验证的

Step 3: 推导判断框架
  → 如果链上 ≠ API：这是 Polymarket 的 indexer/API 问题
  → 如果链上 = API ≠ DB：这是我们的 bug（我们的 DB 没正确跟踪）
  → 如果链上 = API = DB ≠ 期望值：这是我们对"期望值"的理解错误

Step 4: 不可消除约束
  → 链上是公开账本，不可否认
  → 我们的 DB 只是本地快照，必然落后于真相
  → 任何 DB 状态与链上不一致的情况，在没有证明 Polymarket 链上错误的前提下，
    都应假设是我们的 bug

Step 5: 操作化判断步骤
  1. 先查链上（CTF Exchange events / ERC1155 balance）
  2. 再查 Polymarket API（/data/positions 或 /trades）
  3. 比对：链上 vs API
     → 一致 → 这是我们的 bug，检查 DB 写入逻辑
     → 不一致 → Polymarket 问题，记录 discrepancy，等待 Polymarket 自愈
  4. 无论哪种情况，都要记录发现（KNOWLEDGE_GAPS 或 bug report）

结论：判断标准是"链上真相"，不是"API 返回"或"我们的期望"。链上查询和 API 返回一致但与 DB 不一致 = 我们的 bug。链上和 API 不一致 = Polymarket 的问题（极少见，但存在）。这个框架消除了"到底是谁的问题"的模糊性。

第四部分：元思考的局限性

元思考不是万能的

需要基础知识：元思考需要对底层系统有足够了解。没有读过 L1-L4（CTF 合约、CLOB 架构、订单类型、WS 数据层），推导很容易出错。元思考是在知识之上的推理，不是替代知识。

推导可能有错误：推导链中任何一步假设错误，结论都会错。这是为什么 guide-polymarket-fundamentals 使用 confidence 标注，并维护 KNOWLEDGE_GAPS。低置信推断需要用实际验证来确认或推翻。

对实现细节无能为力：Polymarket 的内部实现细节（例如：FAK 订单的链下拒绝具体发生在哪个微服务）无法从第一性原理推导。这类知识只能通过文档、API 测试、或源码（如果开源）获得。

元思考的适用场景

适合：

• 面对设计决策时（我应该用 FOK 还是 FAK？这段代码应该在 fill 前还是 fill 后写 DB？）
• 面对 bug 时（这个 bug 的根本原因是什么？是我们的 bug 还是 Polymarket 的行为？）
• 面对不确定性时（我不知道 Polymarket 怎么处理 X，但我可以推断出它必然遵守哪些约束）
• 评估新代码时（这段代码的假设和系统约束一致吗？）

不适合：

• 需要精确数字（合约地址、API 字段名、费率参数）→ 查文档
• 需要了解具体实现（某个 API 的响应格式）→ 查文档 + 实测
• 已经有高置信知识 → 直接用，不需要重新推导

置信度管理

元思考的输出要标注置信度：

第五部分：MetaThink 在我们项目里的体现

guide-polymarket-fundamentals 是元思考在 Polymarket 上的系统化应用：

结构对应关系

L0 的特殊地位

L0（knowledge/L0-design-reasoning.md）是整个知识库中最重要的文件，因为它是元思考的直接产物。

其他层（L1-L4）是"Polymarket 是什么"，L0 是"为什么 Polymarket 必须这样"。L0 提供的 Eval 标准是高置信约束，可以用来评估任何代码是否正确，不需要读完所有文档。

使用建议

当你需要判断代码正确性时：

1. 先读 L0 — 获取高置信约束和 Eval 标准
2. 按需读 L1-L4 — 补充具体知识验证推断
3. 如果卡住 — 检查 KNOWLEDGE_GAPS 是否有相关 GAP，用元思考 SOP 推导一步

结尾：元思考的核心原则（3条）

原则 1：约束先于功能

理解一个系统，先找它的不可消除约束，再看它的功能。

功能可以改变（Polymarket 可以新增订单类型），约束不会改变（链上确认延迟是物理约束）。基于功能建立的心智模型会随文档更新而过时；基于约束建立的心智模型是稳定的。

应用：当看到一个新功能或 API，先问"它受哪些约束限制"，再问"它能做什么"。

原则 2：推导先于查找

在查文档之前，先推导"应该是什么"，再用文档验证。

推导的过程本身有价值——即使推导结果和文档一致，推导帮助你理解"为什么"，而不只是"是什么"。当文档缺失或错误时，你的推导是唯一的导航工具。

应用：面对一个不确定的行为，先用 SOP 推导"根据约束，这个行为应该是什么"，再查文档或实测确认。

原则 3：归因先于修复

找到 bug 的根本原因（哪个约束被违反了），再决定如何修。

表面修复（改一个变量名、加一个 null check）不能解决架构级违反。归因到约束层面后，修复方向才清晰：要么让代码尊重约束，要么（极少情况）证明这个场景不受该约束限制。

应用：发现 bug 后，不要立即看"怎么修"，先回答"这段代码假设了什么，这个假设违反了哪个不可消除约束"。

元思考的终极目标：在任何陌生系统面前，能从第一性原理推导出"什么代码必然正确、什么代码必然错误"，而不依赖文档的完整性或他人的经验传授。

第六部分：从文档推断未记录行为

这是元思考最重要的扩展能力：用已知文档推断出文档没有明确说的东西。

为什么需要这个能力

Polymarket（或任何复杂系统）的文档永远是不完整的。文档说的是"happy path"，但我们关心的是边界行为：

• FAK 余量取消产生链上事件吗？（文档没说）
• GTD 的过期在链下还是链上执行？（文档没说）
• WS USER_TRADE 事件能否作为成交的最终确认？（文档没说）

元思考允许你从已有文档推断这些答案，并给出置信度评估。

推断的标准模板

[观察] 文档/代码中的 X
[约束] 来自 L0 设计推理的约束 Y（不可消除的）
[推断] 因此，行为应该是 Z
[置信度] HIGH / MEDIUM / LOW
[验证方法] 具体可执行的测试步骤
[代码含义] 这个推断意味着我们的代码应该/不应该做什么

三个完整推断示例

推断示例 1：GTD 过期时间的执行位置

[观察] CLOB API 文档：GTD 订单需要设置 expiration 字段（Unix 时间戳）
[观察] CTF Exchange 合约 ABI：matchOrders() 函数签名不包含 expiration 参数
[约束] 合约只验证签名有效性和代币余额，不验证时间戳（链上没有可靠时钟）
[推断] GTD 的过期检查必然发生在链下（CLOB operator 侧），而非合约层
[置信度] HIGH（合约 ABI 已验证）
[验证方法] 提交一个 10 秒后过期的 GTD 订单，过期后查链上是否有取消记录
[代码含义] GTD 过期事件通过 WS USER_ORDER CANCELLATION 送达，
            不会在链上留下 Transfer 痕迹，reconcile 不能从链上检测 GTD 取消

推断示例 2：FAK 部分成交的 WS 事件数量

[观察] Polymarket 文档：FAK = Fill available, Kill rest
[观察] 我们代码（monitor.ts）观察到：单次 FAK 可触发多个 USER_TRADE 事件
[约束] 链下撮合是逐笔匹配（每个 maker 订单单独匹配）
[推断] FAK 会为每个被匹配的 maker 订单产生一个独立的 USER_TRADE 事件，
        而不是一个汇总事件
[置信度] HIGH（代码实际观测）
[验证方法] 在 orderbook 深度允许的情况下下一个 FAK，监控 WS 接收到几个 USER_TRADE
[代码含义] 处理 FAK 成交时必须累加多个 USER_TRADE 事件的 size，
            不能假设"一个 FAK = 一个 TRADE 事件"

推断示例 3：NegRisk 市场的价格约束

[观察] Polymarket 文档：NegRisk = 多选项共享抵押品，有且只有一个选项 YES 赢
[约束] 因为只有一个选项能赢，所有选项的 YES 价格之和必然接近 1
[推断] NegRisk 市场所有选项的 YES midpoint 之和 ≈ 1（而非标准市场的单个 YES+NO≈1）
[置信度] MEDIUM（逻辑推断，未直接验证）
[验证方法] 取一个有 5 个选项的 NegRisk 事件，查所有选项的 YES midpoint，求和
[代码含义] 对 NegRisk 市场做套利检测时，不能用单市场的 YES+NO≈1 公式，
            而要用所有选项 YES 之和 ≈ 1 的约束

推断的置信度管理

推断的可信度取决于推导链的强度：

关键原则：低置信度推断不能直接用于代码，必须先通过 API 测试验证后才能升级为 HIGH。

推断 vs 猜测的区别

推断是有依据的：每步都要标注来源（文档/合约/代码观测）。 猜测是没有依据的：不能进入知识库。

✅ 推断：文档说 matchOrders() 的 fee 参数类型是 uint256，
         因此 fee 不可能是负数，因此手续费只能是正向收取，不可能返还。

❌ 猜测："我觉得 Polymarket 可能会返还手续费" — 没有文档/合约依据

在 guide-polymarket-fundamentals 中的落地

当你通过上述方法产生了一个新推断：

1. 先在 references/api-verification.md 的"推断示例"部分记录完整推导链
2. 在对应的 Lx 文件里用 FACT 注释记录，标注 source_type: INFERRED，confidence: MEDIUM/LOW
3. 在 KNOWLEDGE_GAPS.md 提交 GAP，等待验证
4. 验证通过后，升级 confidence 为 HIGH，更新 last_verified

第七部分：元思考的元思考（递归应用）

元思考本身是一个工具。工具也有它的第一性原理。

为什么需要元思考？

文档是有限的，系统行为是无限的。在任何足够复杂的系统里，你不可能读完所有文档。但有一件事比功能更持久：约束。

Polymarket 的 API 字段会变，但"混合撮合系统存在不确定窗口"这个约束不会变，因为它来自物理/数学的必然性。研究约束比研究功能有更高的知识 ROI——这就是元思考存在的理由。

元思考自身的不可消除约束（4条）：

约束 A：推导链的强度 = 最弱假设的强度
  → 错误的出发点产生自洽但错误的结论
  → 处理方式：标注每个推断的前提假设，单独验证前提

约束 B：元思考需要种子知识，不能凭空推导
  → 必须有最小可信基础（合约 ABI / 实测数据 / 官方文档）
  → 处理方式：FACT 注释的 source_type 字段，HIGH confidence 必须有来源

约束 C：没有验证的推断会变成"自信的错误"
  → 元思考产生假设，不产生事实
  → 处理方式：所有 INFERRED 节点必须有验证方法，进入 KNOWLEDGE_GAPS

约束 D：Blind Spots — 你不知道你不知道的约束
  → 元思考无法推导出你完全不知道的约束
  → 处理方式：reconcile 作为 ground truth，发现未知约束

元思考的失效边界：

第八部分：元思考应用于 Agent Teams 设计

这是元思考最重要的一个应用场景：如何设计 agent 协作结构。

大多数人设计 agent teams 时是凭直觉（"这个 agent 做 A，那个做 B"）。元思考要求你从约束推导设计：

Agent 信息处理的不可消除约束：

约束 1：上下文污染
  单个 agent 在两个不同信息域（外部文档 / 内部代码）间频繁切换
  → 前一个任务的上下文干扰后一个任务的判断
  → 结论：信息来源不同的任务应该由不同 agent 承担

约束 2：专注度递减
  agent 的注意力是有限的
  → 任务越复杂，越容易在细节中丢失大局
  → 结论：Lead agent 的职责是保持北极星目标，不执行细节

约束 3：信息不对称的价值
  两个 agent 独立研究同一问题 → 结果差异揭示不确定性
  → 交叉验证比单 agent 更可靠
  → 结论：对于高 stakes 问题，parallel agents + Lead 交叉验证

约束 4：合成窗口
  Lead 做合成时，需要看到所有子 agent 的完整输出
  → 如果子 agent 输出太长或太分散，Lead 无法有效合成
  → 结论：子 agent 必须产出结构化、可对比的输出格式

从这些约束推导出的 Agent Teams 设计原则：

原则 1：按信息来源分工，不按功能分工
  ❌ "agent A 做前半部分，agent B 做后半部分"
  ✅ "agent A 研究外部文档，agent B 分析内部代码"
  原因：前者仍然需要共享上下文，后者真正实现了信息隔离

原则 2：Lead 不执行，只合成和决策
  ❌ Lead 同时研究文档和写代码
  ✅ Lead 只看子 agent 的输出，做交叉验证和最终判断
  原因：Lead 进入执行细节 = 丢失北极星目标

原则 3：子 agent 输出必须可对比
  ❌ 子 agent 随意格式输出
  ✅ 统一格式（表格 / FACT 注释）让 Lead 一眼看出差异
  原因：无结构输出 = 信息熵太高 = Lead 合成成本过高

原则 4：设计验证点，不只是分工
  parallel agents 完成后，Lead 必须问：
  "这两份结果哪里一致？哪里矛盾？矛盾意味着什么？"
  一致 → 提高 confidence
  矛盾 → 进入 KNOWLEDGE_GAPS，标注 LOW confidence

实际案例：Polymarket 文档索引的 agent teams 设计

问题：如何建立"场景 → 文档"的映射？

约束分析：
  - 场景知识来自"我们遇到的问题"（内部代码 / bug history）
  - 文档知识来自"Polymarket 提供了什么"（外部网络）
  - 两者信息来源完全不同 → 适合并行 agent

设计决策：
  Agent A：外部文档研究（WebFetch + context7）
  Agent B：内部代码分析（Glob + Read + Grep）
  Lead：交叉验证（文档说有 X API → 代码里是否用了？
                  代码里有 Y 场景 → 文档里是否有对应的 API？）

验证点：
  - 代码里 import 了 DataApiClient → 文档里必须有 Data API 说明
  - 文档里说有 /neg-risk/{token_id} endpoint → 代码里 TradingService 应该调用它
  - 如果代码用了但文档没有 → 可能是 undocumented API（标注 GAP）
  - 如果文档有但代码没用 → 可能是我们的遗漏（标注为待研究）

第九部分：Meta-Think 的形式化定义 (v5.1.1)

补充于 2026-04-13, 基于 v5.1 dogfood session 的反思： "我们的 meta 是带 frontmatter 的笔记，不是 proper meta-think"。

什么是 meta-think vs 什么是 note

Meta-think = 一个自足的推断单元，回答 6 个结构化问题，可以被其他 meta-think 引用、验证、推翻、合并。

Note = 一段自由文本记录，没有结构化的假设/置信度/证伪条件。Notes 有记录价值但没有推理价值 — 它不能被其他 meta-think "推翻"或"验证"，因为它没有明确的 claim。

判断标准：如果你不能写出 ≤200 字的 essence（核心发现），它不是 meta-think — 它是 note。Notes 可以存在，但不应该在 meta chain 上占据 node 位置。

6 必答题 — Meta-Think 的定义

每个 meta-think 必须结构化回答以下 6 个问题：

为什么是这 6 个，不多不少

从 §第七部分 元思考自身的 4 条约束推导：

6 必答题是 §第七部分 4 条约束的可操作化版本。

Essence 的写法

Essence 不是 summary（摘要），是 distillation（蒸馏）：

写法 SOP: 先写 Conclusions，然后问自己"如果只让我说一句话，对方听完能知道什么"。那一句话就是 essence。

Meta-Think Chain 的语义 (metas 之间的关系)

约束传播不止在单个 meta 内部（SOP Step 1-5），也在 meta 之间传播：

Supersedes 的第一性原理：B 推翻 A ≠ "A 错了"。B 说的是 "A 的某个 assumption 被证伪了"（Q2 的哪一条假设被推翻）。这让推翻是可追溯的 — 不是 blanket 否定，是 specific assumption failure。

Consolidation 的第一性原理：当 N 个 meta-think 围绕同一主题从不同角度研究后， Lead 提取本质认知（大 meta）和细枝末节（小 meta）。大 meta 的 essence 是跨 N 个 meta 的 synthesis，小 meta 标记为 status: consolidated 并指向大 meta。

Confidence 衰减

一个 HIGH confidence 的 meta-think，如果满足以下条件之一，confidence 应被降级：

Meta-meta agent 应该在 /loop 扫描中检测 "stale high-confidence" metas， 生成 WARNING: "meta-X confidence=HIGH 但 180 天未被 reference，建议 revalidate"。

Essence 作为元思考的"原子单位"

从 §第二部分 SOP 到 essence 的完整路径：

Step 1: 定义核心问题
  ↓
Step 2: 识别不可回避约束 → Q6 constraints
  ↓
Step 3: 推导设计决策 → Q5 prior_evidence (基于什么推导)
  ↓
Step 4: 推出不可消除行为约束 → Q4 invalidation (反面是什么)
  ↓
Step 5: 评估代码/行为 → Q1 essence (结论)
  ↓
  标注 Q2 assumptions + Q3 confidence

Essence 是 SOP Step 5 的终点。如果你不能从 Step 1 走到 Step 5 并浓缩为 ≤200 字 essence， 说明中间某一步推导不清楚。写 essence 的过程就是验证你是否真正理解了这个 meta-think 的本质。

实际模板（供 v5/03-标准ritual.md 引用）

完整的 meta-think frontmatter + body 模板见 v5/03-标准ritual.md §3.5。

第十部分：总结 — 三条原则的扩展

在 §结尾 的 3 条原则基础上，v5.1.1 补充 3 条：

原则 4：浓缩先于记录

写 meta 之前，先写 essence。如果 essence 写不出来，meta 不值得写 — 你还没想清楚。 记录 1000 行没有 essence 的细节 ≠ meta-thinking。反过来，1 行精准的 essence > 10 页散乱的笔记。

应用：每个 meta 的第一个动作是写 essence（草案），最后一个动作是更新 essence（终版）。

原则 5：假设显式化

每个推断都有隐含假设。不写出来 = 你无法被证伪 = 你也无法被验证。 显式写出 assumptions 让你的 meta-think 变成科学假说而不是个人意见。 科学假说能被推翻和改进，意见只能被争论。

应用：写 meta 时强制填 assumptions: []。如果列表为空，说明你没思考前提。

原则 6：证伪是进步

一个 meta-think 被 supersede 不是失败，是系统在进步。 被 supersede 的 meta 说明了"为什么那个方向不对" — 这个信息本身有巨大价值。 meta chain 上的 supersede edges 是知识进化的路径，不是错误记录。

应用：永远不删除被 supersede 的 meta。标记 status: superseded + superseded_by: [meta-id]，让整条演化路径可追溯。