现象
@objectstack/lint 导出 validateFormLayout，有完整单测（validate-form-layout.test.ts），发布了四条规则 id：
FORM_COLSPAN_ABSOLUTEFORM_FIELD_UNKNOWNFIELD_GROUP_UNDECLAREDFIELD_GROUP_EMPTY
没有任何命令调用它。 全仓搜索，除了它自己的实现、index.ts 的导出行和单测，零个调用点：
packages/lint/src/index.ts:104: validateFormLayout,
packages/lint/src/validate-form-layout.ts:82:export function validateFormLayout(...)
不在 os validate / os build / os lint，不在 REFERENCE_INTEGRITY_RULES，不在 #4409 新建的 AUTHORING_RULES，不在 os doctor。也就是说：一条表单布局规则完整存在于代码库里，从来没有对任何一个 stack 跑过一次。
（严重性：severity: 'error' 出现 0 次，四条都是 advisory。所以这不是门禁盲区，是一条从未产生过任何输出的规则——成本更低，但性质更纯粹。）
为什么这是同一型缺陷的上一层
#4409 修的是"规则接进了哪几个命令"的漂移，落地为一张 registry + 棘轮守卫。那个守卫能挡住的是：
- 一条 registry 里的规则被某个命令手工另接一次（
DIRECT_CALL_RATCHET）
- 一条 gating 规则只接了部分命令（
GATING_COVERAGE_DEBT）
- 一条 gate 伪装成
advisory 来换取部分覆盖（回读源码核对）
它挡不住的是：一条规则哪里都没接。守卫是从 registry 出发往命令看的，validateFormLayout 从来没进过 registry，所以它在守卫的视野之外——和 #4402 的守卫看不见 suite 之外的规则，是同一个形状，只是又高了一层。
这也正好命中 AGENTS.md Prime Directive #10 的推论：never advertise a capability the runtime doesn't actually deliver。这条规则在 @objectstack/lint 的公开导出面上，任何读导出列表的人（或 AI）都会认为表单布局在作者时被检查了。它没有。
建议
AUTHORING_RULES 已经是"哪条规则跑在哪些命令上"的唯一账本，缺的是反方向的闭合：一条 @objectstack/lint 导出的规则，必须要么进 registry，要么进一份带理由的清单。 具体形态和现有的 TEST_DEBT / FLOW_WRITE_NODE_TYPES_DEFERRED 同款：
- 加一条守卫：枚举
@objectstack/lint 导出的 validate* / lint* 规则函数，减去 AUTHORING_RULES ∪ REFERENCE_INTEGRITY_RULES，差集必须为空或落在 UNWIRED_RULE_LEDGER 里，每项带理由（例如"给 Studio 的 X 面板复用，不在 CLI 作者时跑"这类真实理由——如果确实存在的话）。
复现这个统计的一行：把两个 registry 的 name 与 packages/lint/src/index.ts 的规则导出做 comm -23。今天差集恰好是 validateFormLayout 一条。
validateFormLayout 本身二选一——接进 AUTHORING_RULES（advisory，三命令，成本可忽略：它只走结构化 metadata，不加载任何重依赖），或者按 ADR-0049 enforce-or-remove 删掉。它检查的东西（colSpan 绝对值、表单字段名解析、Field.group 指向）看起来是真实有用的，倾向前者，但那是个需要写下来的决定，不是默认。
相关
发现自 #4409 的收尾核对（#4445）。相关：#4402、#4394、#3782、#3583，以及 ADR-0049 的 enforce-or-remove 纪律。
现象
@objectstack/lint导出validateFormLayout，有完整单测（validate-form-layout.test.ts），发布了四条规则 id：FORM_COLSPAN_ABSOLUTEFORM_FIELD_UNKNOWNFIELD_GROUP_UNDECLAREDFIELD_GROUP_EMPTY没有任何命令调用它。 全仓搜索，除了它自己的实现、
index.ts的导出行和单测，零个调用点：不在
os validate/os build/os lint，不在REFERENCE_INTEGRITY_RULES，不在 #4409 新建的AUTHORING_RULES，不在os doctor。也就是说：一条表单布局规则完整存在于代码库里，从来没有对任何一个 stack 跑过一次。（严重性：
severity: 'error'出现 0 次，四条都是 advisory。所以这不是门禁盲区，是一条从未产生过任何输出的规则——成本更低，但性质更纯粹。）为什么这是同一型缺陷的上一层
#4409 修的是"规则接进了哪几个命令"的漂移，落地为一张 registry + 棘轮守卫。那个守卫能挡住的是：
DIRECT_CALL_RATCHET）GATING_COVERAGE_DEBT）advisory来换取部分覆盖（回读源码核对）它挡不住的是：一条规则哪里都没接。守卫是从 registry 出发往命令看的，
validateFormLayout从来没进过 registry，所以它在守卫的视野之外——和 #4402 的守卫看不见 suite 之外的规则，是同一个形状，只是又高了一层。这也正好命中 AGENTS.md Prime Directive #10 的推论：never advertise a capability the runtime doesn't actually deliver。这条规则在
@objectstack/lint的公开导出面上，任何读导出列表的人（或 AI）都会认为表单布局在作者时被检查了。它没有。建议
AUTHORING_RULES已经是"哪条规则跑在哪些命令上"的唯一账本，缺的是反方向的闭合：一条@objectstack/lint导出的规则，必须要么进 registry，要么进一份带理由的清单。 具体形态和现有的TEST_DEBT/FLOW_WRITE_NODE_TYPES_DEFERRED同款：@objectstack/lint导出的validate*/lint*规则函数，减去AUTHORING_RULES∪REFERENCE_INTEGRITY_RULES，差集必须为空或落在UNWIRED_RULE_LEDGER里，每项带理由（例如"给 Studio 的 X 面板复用，不在 CLI 作者时跑"这类真实理由——如果确实存在的话）。validateFormLayout本身二选一——接进AUTHORING_RULES（advisory，三命令，成本可忽略：它只走结构化 metadata，不加载任何重依赖），或者按 ADR-0049 enforce-or-remove 删掉。它检查的东西（colSpan绝对值、表单字段名解析、Field.group指向）看起来是真实有用的，倾向前者，但那是个需要写下来的决定，不是默认。相关
发现自 #4409 的收尾核对（#4445）。相关：#4402、#4394、#3782、#3583，以及 ADR-0049 的 enforce-or-remove 纪律。