wren-enrich-context

Wren Enrich Context — 填补业务上下文缺口

此技能之所以存在，是因为大多数业务上下文并不在数据库架构中，而是存在于手册、术语表、财务报告、支持工作手册、代码注释和 Slack 经验法则中。Agent 会读取这些原始资料，找出 Wren 项目中缺失的内容，然后要么一次问用户一个问题（逐问模式），要么直接应用最佳推断并提交审计结果（自动驾驶模式），之后再写回。输出会进入每个项目已有的三个（或四个）目标位置，不会新增文件，也不会新增工具。

版本检查

静默获取 https://raw.githubusercontent.com/Canner/WrenAI/main/skills/versions.json。 将 wren-enrich-context 键与此技能的版本（见上方 frontmatter）进行比较。 如果远程版本较新，请在继续之前通知用户：

有较新版本的 wren-enrich-context 技能可用。 使用以下命令更新：

npx skills add Canner/WrenAI --skill wren-enrich-context

CLI 会自动检测已安装的 Agent。若要指定某个 Agent，请添加 --agent <name>（例如 claude-code、cursor、windsurf、cline）。

无论更新状态如何，都继续执行。

---

硬性规则 — 请先阅读

通用规则（两种模式均适用）

1. 只能新增，绝不修改现有内容。 如果发现现有的 MDL 描述 / 关系 / 规则似乎有误，不要编辑。请在步骤 9 中显示的“请手动修复”列表中指出。
2. 每次 MDL 编辑都必须通过验证。 每次更改 MDL YAML 后，立即运行 wren context validate。如果验证失败，撤销那一项更改并反馈错误。绝不让项目处于无效状态。
3. 所有提议都要先拟好草稿。 无论是向用户展示草稿（逐问模式），还是直接应用（自动驾驶模式），都要生成具体内容，绝不要偷懒地问“描述应该写什么？”。
4. 明确说明置信度。 在逐问模式中，Lane 3 推断问题开头要写“我猜测——”。在自动驾驶模式中，步骤 9 的审计中每项 Lane 3 推断和 Lane 2 部分匹配都要标注置信度（高 / 中 / 低）和来源。

仅适用于逐问模式

5. 一次只问一个问题。持续追问。 从上到下逐一处理所有缺口，在进入下一项之前先解决当前决策。每个问题都要提供建议答案。
6. 跳过即为本次会话的最终决定。 不保留待处理队列，也不在下一轮催促。用户若想重新处理，需要重新运行此技能。

仅适用于自动驾驶模式

7. 以下三种情况切换到逐问模式。 遇到以下情况时，始终中断自动驾驶并询问用户：

   • (a) Lane 2 冲突 — 原始资料与当前 MDL 不一致。
   • (b) 影响范围大的提议（任何 Lane） — 新增 cube、新增 view、新增关系，或新增 MDL 指标 / 计算列。这些会成为所有未来 Agent 会话都可见的公共产物，因此影响范围不取决于触发依据是原始证据（Lane 2）还是推断（Lane 3）。
   • (c) Lane 2 路由不明确 — 无法有把握地选择目标位置（MDL / instructions.md / queries.yml / cubes/）。

   其他情况：直接应用并记录到审计列表。

步骤 0 — 模式选择（首先执行）

在操作项目或读取任何文件之前，先询问用户要使用哪种模式。整个会话期间锁定选择 — 不得在会话中途切换；用户需要重新运行才能更改。

本次会话有两种模式：

a) 逐项探讨模式 — 我会逐个与你梳理所有缺口，每次只问一个问题，提出草案，然后等待你接受、修改或跳过。由你掌控进度。适用于原始材料敏感、你想了解我对项目有哪些不了解之处，或你宁愿审核而不是返工的情况。

b) 自动模式 — 我会读取原始材料和当前上下文，尽力推断并应用结果。只有在以下情况下才会停下来与你逐项探讨：（1）原始材料与现有 MDL 之间存在冲突；（2）影响范围较大的新增内容，例如新指标、视图或关系。会话结束时，我会提供完整差异和带置信度标签的推断列表，供你审核。

选哪种？（a / b）

记住此选择为 MODE = grill | autopilot，并据此执行步骤 6 和 9。

---

预检

步骤 1 — 选择 Wren 项目

在执行任何操作之前，务必先询问用户要完善哪个项目 — 不要假设当前工作目录（cwd）。用户可能有多个 Wren 项目，而且当前的 ~/.wren 配置文件可能与他们想要完善的项目不匹配。

在提问中提供具体提示，让用户一次就能回答：

# Hint 1 — does cwd look like a project?
test -f wren_project.yml && pwd

# Hint 2 — does ~/.wren/config.yml point at a default project?
grep -E '^project_path:' ~/.wren/config.yml 2>/dev/null

然后询问：

你想让我完善哪个 Wren 项目？ a) $PWD（当前目录） ← 如果提示 1 匹配 b) <path from ~/.wren/config.yml> ← 如果提示 2 匹配 c) 其他位置 — 请粘贴绝对路径

用户回答后，在整个会话期间锁定该路径：

cd <chosen-path>
test -f wren_project.yml || {
  echo "Error: <chosen-path> is not a Wren project (no wren_project.yml)."
  exit 1
}
wren context show >/dev/null 2>&1 || {
  echo "Error: wren context show failed — manifest may be invalid."
  exit 1
}

如果任一检查未通过，请停止并告知用户 — 如果该目录不是项目，建议使用 wren-onboarding；如果清单有问题，建议运行 wren context validate。

从此之后，本技能中的所有命令和文件路径均相对于所选项目根目录。不要在会话中途切换项目 — 如果用户想处理其他项目，请结束本次会话并重新运行。

步骤 2 — 检测记忆是否可用

wren memory --help >/dev/null 2>&1

• 退出代码为 0 → 设置 MEMORY_AVAILABLE = true。第四个存储目标（直接执行 wren memory store）可用。
• 退出代码非 0 → 设置 MEMORY_AVAILABLE = false。跳过下文仅适用于记忆的路径。

步骤 3 — 确保 raw/ 文件夹存在

从项目根目录执行（步骤 1 已将 cwd 设为该目录）：

mkdir -p raw

如果刚刚创建了该目录（目录原本为空或不存在）：

我已在项目根目录创建 raw/。请将任何有助于说明此项目业务背景的内容放进去 — PDF、术语表、手册、财务报告、数据字典、示例查询、带注释的代码、仪表盘截图等。

**提醒：**其中的内容可能敏感。是否将 raw/ 提交到 git，请自行决定 — 我不会修改 .gitignore。

添加完文件后告诉我，我就开始读取。

等待用户确认后再继续。

---

步骤 4 — 读取所有内容

在形成任何判断之前，先读取两方面内容 — 原始材料和当前 Wren 上下文。

原始材料

读取 raw/ 下的每个文件。使用 Agent 原生具备的任何能力（文本、Markdown、代码、PDF）。如果确实无法读取某个文件，只告知用户一次，指出文件名并建议将其转换为文本或粘贴相关摘录 — 然后继续处理其余文件。不要安装额外的 Python 包，不要使用新的 CLI 子命令。

当前 Wren 上下文

来源	命令
MDL（完整）	wren context show --output json
项目说明	wren context instructions
现有立方体（名称）	wren cube list
现有立方体（度量 + 维度）	对上方列出的每个名称运行 wren cube describe <cube>
精选 NL-SQL 对	直接读取 queries.yml
（记忆）存储的对	wren memory list -n 200 --output json
（记忆）文本格式的架构	wren memory describe

只有当 MEMORY_AVAILABLE = true 时，记忆行才有用。在提出任何 Lane 3 指标之前，必须先读取立方体 — 参见 references/cube_proposals.md 了解防重复规则。

---

第 4.5 步 — 真实数据探测（grill 模式默认开启；auto-pilot 可选择退出）

当 raw 未明确说明某列的枚举值、单位、空值、特殊值或时间语义时，可以直接从实时 DB 抽取不同值，确定目录中列级的类别（references/gap_catalog.md 里的 #1、#2、#3、#5、#7）。在此步骤前阅读 references/gap_catalog.md — 其 Trigger 列会指出哪些列适合探测。

按模式设置的默认策略：

模式	默认设置	如何覆盖
Grill	开启探测。在执行第一个查询前，只询问用户一次：“我想对 N 列分别使用 LIMIT 30 抽样，以查找枚举值 / 哨兵值 / 时间粒度 — 可以吗？”本次会话中按用户的回答执行。	用户拒绝 → 完全跳过第 4.5 步；改用 Lane 2 + Lane 3。
Auto-pilot	关闭探测。该技能在 auto-pilot 模式下绝不查询实时 DB。	无 — 如果探测有助于提高推断置信度，用户必须在 grill 模式下重新运行。

候选列筛选（暂不调用 DB）：

满足以下所有条件的列才是探测候选列：

• 描述为空，或尚未包含相关的 [tag]（目录写入格式）。
• 列类型 / 名称模式符合目录 #1（枚举）、#3（NULL）、#5（特殊值）或 #7（时间粒度）。
• 对于 #3 和 #7，描述中也缺少事件与记录或 TZ 相关说明。

类别 #2（单位）、#4、#6、#8、#9、#10 不适合探测 — SELECT DISTINCT 无法揭示单位、默认筛选条件、同义词、外部映射、货币惯例或规范表偏好。这些需要 raw 证据或人工判断。

探测查询：

wren --sql "SELECT DISTINCT <col> FROM <model> LIMIT 30" --output json
# For magic sentinels (catalog #5), also fetch min/max:
wren --sql "SELECT MIN(<col>) AS lo, MAX(<col>) AS hi FROM <model>" --output json

• 返回值 ≤ 30 个 → 可作为枚举值 / 哨兵值 / 粒度候选。起草 [tag] 行并向用户展示（grill 模式），置信度标为“中 — 已探测值，语义仍为推断”。
• 返回值为 30 个（达到 LIMIT） → 基数过高；不能作为枚举值 / 哨兵值候选。跳过。
• 查询失败（权限、连接、大表超时）→ 不要重试。将失败记录到审计列表，在第 9 步展示，然后仅使用 Lane 2 + Lane 3 继续。

安全要求：

• 每个（模型、列）每次会话最多探测一次。
• 绝不探测已有匹配 [tag] 行的列 — 通用规则 1。
• 探测结果只保留在工作内存中；不要写入磁盘。

---

第 5 步 — 三条缺口检测通道（在脑中处理，不产出文件）

将三条通道的所有内容保留在工作内存中。不要写入 gaps.yml。

开始扫描前，加载 references/gap_catalog.md — 其中列出了架构无法承载的十类业务语义。每条通道处理目录的方式不同：Lane 1 将其作为类型感知的机械触发条件逐项检查；Lane 2 先将每条原子级 raw 声明归入 10 个类别之一，再进行路由；Lane 3 则在触发条件出现但 raw 未明确说明时，提供推断提示。

Lane 1 — 结构覆盖（机械检查）

扫描当前 MDL 并检查：

• 每个模型都有非空的 properties.description 吗？
• 每个列都有描述吗（至少非 PK、非 FK 列）？
• 每个模型都有 primary_key 吗？
• 每个模型至少有一个关系吗（孤立模型值得怀疑）？
• instructions.md 是否不止是默认脚手架内容？
• queries.yml 至少包含几组规范配对吗？

另外，根据 references/gap_catalog.md 中的触发条件，逐一检查每个列 / 模型：

• 对于每个符合目录 #1 / #2 / #3 / #5 / #7 触发条件的列 → properties.description 中是否包含对应的 [tag] 行？
• 对于每个包含软删除列（deleted_at、is_active、archived_at 等）的模型 → instructions.md 中是否有涵盖该列的 ## Default filters 规则（目录 #4）？
• 对于每组名称相似的表（例如 users / users_v3）→ 是否有 ## Canonical tables 规则（目录 #10）？
• 对于每个 *_currency / fx_rate / 外部系统 ID 列 → 是否有匹配的 ## Currency（#9）或 ## External identifiers（#8）章节？
• instructions.md 或原始资料中的业务术语若与模型 / 列名不完全一致 → 是否缺少目录 #6 的 ## Naming conventions 规则？

每项未满足的检查都是候选项。与第 4.5 步的探测结果（如果有）合并后，再进入 Lane 2。

Lane 2 — 声明差异（原始资料 vs 当前上下文）

针对每个原始文件，在内部提取 5–15 条原子声明——即可以判断真假的单一陈述，例如“一个订单恰好对应一个客户”“默认情况下，user 表示 type=default”“ARR 等于 MRR × 12 减去退款”。然后根据当前 Wren 上下文对每条声明进行分类：

类别	含义	处理结果
covered	已反映在 MDL / instructions / 配对中	跳过
partial	已涉及该主题，但措辞 / 范围不同	建议收紧
new	当前上下文中没有匹配内容	路由到相应目标
conflict	原始资料说 A，当前上下文说 B	向用户确认（两种模式都要），但不要编辑现有内容 — 提交给人工修正

Lane 3 — 推断（你自己的猜测）

阅读原始资料和当前 MDL 后，提出用户在原始资料中没有明确说明、但显然能帮助 Agent 后续工作的补充内容。例如：

• “我看到 finance.pdf 中五次提到了 quarterly_churn。目前没有现有 cube 覆盖它。要我添加 cubes/quarterly_churn/metadata.yml，并将 measure 设为 COUNT(*) FILTER (WHERE churned_at IS NOT NULL) / NULLIF(COUNT(*), 0) 吗？” — YAML 模板和重复检查规则请参阅 references/cube_proposals.md。
• “你的支持手册一直提到 core users，却没有定义它。它指的是 users WHERE tier = 'premium' 吗？要我创建一个视图吗？”
• “数据字典说明 events.payload 是 JSON，但该列没有描述——我来起草一段吧。”

对于任何类似聚合的提案（SUM、COUNT、AVG、“按月 / 按状态 / 按客户”等模式），默认使用 cube。先运行 wren cube list + wren cube describe，确认没有现有 cube 已覆盖该度量表达式；如果有，则跳过该提案，改为添加一条指向现有 cube 的 queries.yml 示例。完整的决策树、命名规则和验证流程见 references/cube_proposals.md。

在 grill 模式下，每个 Lane 3 问题都以 “I'm guessing — ” 开头。 在 auto-pilot 模式下，为审计条目添加 agent inference 标签，让用户知道这是你的推断。

---

第 6 步 — 解决缺口

根据第 0 步中锁定的 MODE 进行分支处理。

深挖模式

对第 1–3 轮中发现的每个缺口，都使用以下对话模式：

针对每个缺口，持续追问用户，直到双方达成共识。逐一梳理决策树的每个分支，并依次解决决策之间的依赖关系。每个问题都要提供你推荐的答案。

一次只问一个问题。

如果可以通过检查代码库或原始文件来回答问题，就自行检查，不要提问。

每轮深挖时：

1. 说明缺口及其来源（第 1 / 2 / 3 轮；对于第 2 轮，引用原始文件并摘录一小段）。
2. 提出具体答案——草拟描述、规则、SQL 对或关系。
3. 提出存放位置（“我会将此规则添加到 instructions.md”／“我会将此内容添加到 MDL 中 users 模型的描述里”）。
4. 让用户选择接受／修改／跳过。
5. 接受后：写回（第 7 步）。
6. 修改后：采用用户的表述，然后写回。
7. 跳过后：舍弃此项，继续处理下一个缺口。不要重新排入队列。

如果用户给出出乎意料的回答（“其实我们不跟踪这个”），就调整方向。目标是达成共识，而不是强推预先准备好的清单。

自动驾驶模式

直接处理第 1–3 轮中的所有发现——以下通用规则 7 中的三种升级情况除外：

• 第 2 轮冲突——针对此问题进入深挖模式，不要自动解决。
• 第 3 轮提出新指标／视图／关系——应用前先进入深挖模式。
• 第 2 轮存放位置不明确——仅针对存放位置进入深挖模式，然后自动应用。

对于其他所有情况（第 1 轮机械性修正、第 2 轮明确的新声明、第 3 轮低影响描述调整）：

1. 根据最佳推断，综合形成具体方案（描述／规则／SQL 对）。
2. 使用路由表（第 7 步）确定存放位置。
3. 写回。
4. 每次编辑 MDL 后，立即运行 wren context validate。如果失败：还原这项修改，并记录还原操作及错误。
5. 将以下内容追加到审计列表：发现项、存放位置、置信度标签（高／中／低）和来源（第 2 轮记录原始文件及摘录，第 3 轮记录 agent inference，第 1 轮记录 structural）。

自动驾驶模式下，无需逐项暂停并等待确认——用户会在第 9 步审核完整差异和审计列表。他们是审核者，而不是把关者。

---

步骤 7 — 路由与回写

将目标位置作为提案的一部分确定下来（grill 模式下为步骤 6.3；auto-pilot 模式下为步骤 6.2），这样用户可以在 grill 模式下更正路由，并在 auto-pilot 模式下进行审计。

发现类型	目标位置	写入方式
Schema 结构／关系／视图／模型或列描述	models/、views/、relationships.yml 下的 MDL YAML	直接编辑 YAML 文件。对于目录 #1 / #2 / #3 / #5 / #7 / PII，在 properties.description 中追加一行 [tag]（先写描述，再为每个类别各写一个标签）。具体标签格式和触发条件请参阅 references/gap_catalog.md。
聚合指标／命名度量（包含度量和维度）	cubes/<name>/metadata.yml	每个 cube 新建一个文件。任何 SUM / COUNT / AVG 比率指标原始定义或 Lane 3 推断的指标，默认写入此处。YAML 模板、命名策略、重复检查和验证流程请参阅 references/cube_proposals.md。写入后运行 wren context validate + wren cube query --cube <name> --sql-only；任一命令失败时都应撤销更改。在 auto-pilot 模式下始终升级到 grill 模式（通用规则 7b）。
默认筛选条件／隐式规则／业务惯例／命名惯例／外部映射／货币／规范表	instructions.md	在目录指定的 ## 标题下追加（#4 → ## Default filters，#6 → ## Naming conventions，#8 → ## External identifiers，#9 → ## Currency，#10 → ## Canonical tables）。如果标题不存在，则创建标题；绝不修改现有文本。
团队应共享的规范 NL→SQL 示例	queries.yml	在 pairs: 下追加一条新记录
临时 NL→SQL 对（用户本地使用，不提交到仓库）——仅当 MEMORY_AVAILABLE = true 时	wren memory store	wren memory store --nl "..." --sql "..." --tags "source:enrich"

由目录驱动的路由意味着，每个列级提案都写入该列的 properties.description，并追加一行 [tag]；每条跨模型规则都写入 instructions.md 中的固定标题下。这样可确保重新丰富时结果具有确定性（可通过 grep 查找），并避免另行发明写入位置。

每次编辑 MDL 后

wren context validate

如果失败：

1. 撤销刚才所做的单项更改。
2. 向用户显示验证错误（grill 模式），或将其记录在审计中（auto-pilot 模式）。
3. 在 grill 模式下，针对该具体缺口重新进行 grill，并将错误作为新的上下文。
4. 在 auto-pilot 模式下，将该发现标记为“revert: validation failed”，然后继续处理。

格式提示

• queries.yml 的 schema 遵循 wren memory dump 的输出格式：version: 1，以及由 {nl, sql, source} 条目组成的 pairs: 列表（使用 source: enrich）。
• MDL YAML 使用 snake_case 键（例如 primary_key、is_calculated、not_null）。wren context build 会将其转换为 camelCase，写入 target/mdl.json。
• instructions.md 使用自由格式的 Markdown。使用标题按主题归类规则。

---

步骤 8 — 结束会话

步骤 6 结束后（用户在 grill 模式下说停止，或 auto-pilot 模式下处理完所有发现）：

wren context build

这会根据 YAML 编辑内容重新编译 target/mdl.json。

如果 MEMORY_AVAILABLE = true：

wren memory index

这会为新增的 schema 项目、更新后的 instructions.md 和新增的 queries.yml 条目重新生成嵌入向量。

---

步骤 9 — 总结

两种模式通用部分

输出简明的会话报告：

Wren Enrich Context — session summary  (mode: <grill|autopilot>)

Added:
  MDL              : N model descriptions, N column descriptions, N relationships, N views
                     by tag: [enum]=N [unit]=N [null]=N [magic]=N [time]=N [pii]=N
  cubes            : N new (names: <list>)                                    via cubes/<name>/metadata.yml
  instructions.md  : N new rules across sections
                     by section: Default filters=N | Naming conventions=N | External identifiers=N | Currency=N | Canonical tables=N
  queries.yml      : N new NL→SQL pairs
  memory store     : N ad-hoc pairs                                          (only if MEMORY_AVAILABLE)
  Probe            : N columns sampled, M failed                             (grill mode only)

Please fix manually (we don't edit existing fields):
  - models/orders/metadata.yml: existing description seems to contradict raw/glossary.pdf p.3
  - relationships.yml: existing orders↔customers is MANY_TO_ONE but raw/data_dict.md p.7 says MANY_TO_MANY
  - …

Grill 模式附加内容

追加：

Skipped this session: N gaps (re-run /wren-enrich-context to revisit)

Auto-pilot 模式附加内容

追加详细审计，以便用户检查推断是否合理：

Inferred items (please review):
  high   | MDL model:orders.description           | from raw/glossary.pdf p.2 — "Order = ..."
  high   | instructions.md rule                    | from raw/handbook.md §4 — "default tier ..."
  med    | MDL column:users.signup_source.desc    | agent inference from raw/onboarding.md
  low    | queries.yml: "weekly active customers"  | agent inference, no direct raw evidence

Validation:
  K successful applies, M reverted after wren context validate failed:
    - relationships.yml: <error> → reverted

Escalated to grill (raw vs MDL conflicts / high-impact additions):
  - <count> items — see grill transcript above

应鼓励用户快速浏览审计，并选择原样接受、手动调整低置信度条目，或者在希望以交互方式重新检查时改用 grill 模式重新运行。

---

应避免的事项

• 不要编写 gaps.yml、state.yml 或任何其他跟踪文件。整个会话都在对话中进行。
• 不要修改任何现有的 MDL 字段、指令规则或 queries.yml 条目——只能追加或新增。将不一致之处列入手动修复清单。
• 不要安装新的 Python 包（pypdf、docling 等）来读取原始文件。使用 Agent 已有的工具；对于无法打开的文件，请用户转换。
• 不要自动解决原始文件与当前 MDL 之间的冲突——无论在何种模式下，都要始终向用户追问。
• 不要把 Lane 3 推断说成是从原始文件中引用的内容。开头使用 "I'm guessing — "（grill 模式）或标注 agent inference（auto-pilot 模式）。
• 当 MEMORY_AVAILABLE = false 时，不要调用 wren memory store——改为写入 queries.yml，确保这组内容能在未来运行 wren memory index 时保留下来。
• 不要向 git 提交任何内容。提交与否由用户决定。
• 不要追问用户跳过的问题。跳过的问题在本次会话中就视为跳过（仅限 grill 模式——auto-pilot 模式没有跳过的概念）。
• 不要在每次编辑 MDL 后都运行 wren context build——最后运行一次即可。每次编辑后都要运行 wren context validate。
• 不要假设 raw/ 是由 wren context init 创建的——它不会创建。此技能会创建该目录。
• 不要在会话中途切换模式。用户需要重新运行才能更改模式。
• 如果同一类别的标签已存在于该列中，不要再追加 [tag] 行——遵循 Universal Rule 1。将矛盾之处列入手动修复清单。
• 不要编造新的 instructions.md 章节标题。仅使用目录中定义的五个标题（## Default filters、## Naming conventions、## External identifiers、## Currency、## Canonical tables）。不适合归入这些标题的内容应列入手动修复清单。
• 在 auto-pilot 模式下，不要探查实时数据库。默认情况下，步骤 4.5 仅适用于 grill 模式。
• 不要提议一个其度量表达式已存在于同一 base_object 的其他 cube 中的 cube——改为编写一个指向现有 cube 的 queries.yml 示例。参见 references/cube_proposals.md 中的重复项检查规则。
• 即使原始文件与现有 cube YAML 相矛盾，也不要修改它——遵循 Universal Rule 1。将此情况列入手动修复清单。
• 如果旧 MDL 中的 metrics: 条目已覆盖相同逻辑，不要同时新增 cube。将其列为“consider migrating to cube”，并放入手动修复清单。
• 创建 cube 后，不要跳过 wren cube query --cube <name> --sql-only。结构性检查 wren context validate 无法发现无法解析的度量或维度表达式。
• 在 auto-pilot 模式下，不要自动应用 Lane 2 冲突或新的度量 / 视图 / 关系推断——遇到这些情况时，务必转入 grill 模式。

---

另请参阅

• references/gap_catalog.md — 十种业务语义缺口类别，包含触发条件、默认写入位置和写入格式。请在步骤 4.5 和步骤 5 之前阅读。
• references/cube_proposals.md — 何时提议 cube、视图或计算列的决策树、cube YAML 模板、命名规范、重复项检查规则和验证流程。任何 Lane 3 聚合型提议之前都要阅读。