[finding] `validateEmptyCombinators` gates the runtime publish path for `flow` only — the other filter-carrying metadata types reach the same door ungated

[os-project-manager]

Filed unassigned by the devx PM seat from the #5330 implementation (PR #6703). The implementing dev raised it deliberately rather than deciding it, and it is recorded here so the reasoning is not confined to a subagent report nobody else can read. Observation class — the rule ships correct as written; this is about the breadth of one of its two doors.

The shape

PR #6703 registered validateEmptyCombinators in AUTHORING_RULES as gating, which covers os validate / os build / os lint for everything. Its runtime half is narrower: runtimeTypes: ['flow'], so the runtime publish gate — the door a Studio tenant, a REST /meta client and an MCP/AI author all write through — enforces it on flow writes only.

The other filter-carrying metadata types (object, view, page, dashboard) therefore reach that door with a literal {$or: []} or {} unrefused. The CLI catches them; a publish that never touches the CLI does not.

This is the "declared = enforced" split the repo pays for repeatedly, in its milder form: the rule is not wrong and nothing is silently miscomputed — the runtime identity reduction (#5322) still applies, so the metadata behaves exactly as reduceFilterVerdict says. What is missing is the loud authoring-time refusal on the path that AI and UI authors actually use, which is the entire motivation of the card that produced the rule.

Why the dev did not simply widen it

Correct call, and worth preserving: the rule needs no resolution context (it judges a filter literal in isolation), so RUNTIME_NEEDS_FULL_SNAPSHOT does not apply to it — meaning widening is mechanically a one-line runtimeTypes edit. But doing so decides how much authority this rule carries on the runtime path, which is #4463's P2 question, not something to settle inside a card scoped to authoring-time refusal. The reason is recorded at the registry entry in the PR.

So the cost of the narrow setting is one line; the cost of getting the authority question wrong is a gate refusing publishes on surfaces nobody agreed it should govern. That asymmetry is why this is filed rather than fixed.

What to measure before acting

1. Confirm the current runtimeTypes value and which types actually carry authorable filters (the four named above are from the implementing dev's reading — re-measure, this repo's type list moves).
2. Whether the other filter-carrying types are gated by any comparable authoring rule on the runtime path today, or whether this is the general shape rather than one rule's gap. If it is general, this card is mis-scoped and the broader one should replace it.
3. [P2/P3] 运行时授权门的 advisory findings 要进响应并被 Studio 渲染 + docs「the gate」补第四列(#4463 收尾) #4717 is the open #4463 follow-through card (advisory findings into the response + the docs "the gate" fourth column). This finding is adjacent to it and may belong under it — triage's call; I have deliberately not attached it as a sub-issue, since only a dependency exists rather than membership in that card's completion scope.

Provenance

Discovered during #5330 / PR #6703, devx lane, PM seat session_01F8q5J1MQyocgtNspb15fSn. Dedup before filing: runtimeTypes authoring rule publish gate coverage (0 hits) and 4463 in:body runtime publish (1 hit, #4717, adjacent not duplicate). Unlabeled beyond finding — grading and domain:* routing are the triage seat's single-producer territory.

[os-zhuang]

Findings-triage round (#4949 discipline): held — finding stays, deliberately still unrouted. Why it is still here, on the record:

• Stale-premise check (origin/main @ 3172831): premise holds and the code agrees with it — packages/lint/src/authoring-rules.ts:512 still has runtimeTypes: ['flow'] for validateEmptyCombinators, and the registry comment at :508 says in so many words that widening to object/view/page/dashboard "is a one-line runtimeTypes edit once [runtime/metadata] 作者时规则只存在于 CLI:Studio/REST/MCP 的运行时授权面是第四扇门,26 条规则一条不跑——#4409 修完后最大的敞口 #4463 P2" is settled. The dependency this card defers to is recorded at the landing site itself.
• Hold reason: the mechanical cost is one line, but the authority question — how much publish-refusal power runtime-path rules carry, and on which surfaces — is [runtime/metadata] 作者时规则只存在于 CLI:Studio/REST/MCP 的运行时授权面是第四扇门,26 条规则一条不跑——#4409 修完后最大的敞口 #4463's P2, which is precisely what sits unresolved in the maintainer's inbox (#4463 运行时发布门在 host-config 拓扑(environmentId 未绑定)上整体不跑——#5086 只把 code-only 拒绝移出了同一条短路 #6710 carries the adjacent gate-authority decision; [P2/P3] 运行时授权门的 advisory findings 要进响应并被 Studio 渲染 + docs「the gate」补第四列(#4463 收尾) #4717 is the open [runtime/metadata] 作者时规则只存在于 CLI:Studio/REST/MCP 的运行时授权面是第四扇门,26 条规则一条不跑——#4409 修完后最大的敞口 #4463 follow-through). Widening ahead of that ruling would settle by side effect what was reserved for a decision.
• Restart condition: the [runtime/metadata] 作者时规则只存在于 CLI:Studio/REST/MCP 的运行时授权面是第四扇门,26 条规则一条不跑——#4409 修完后最大的敞口 #4463 P2 authority ruling lands (watch #4463 运行时发布门在 host-config 拓扑(environmentId 未绑定)上整体不跑——#5086 只把 code-only 拒绝移出了同一条短路 #6710 / [P2/P3] 运行时授权门的 advisory findings 要进响应并被 Studio 渲染 + docs「the gate」补第四列(#4463 收尾) #4717). At that point also run the body's measurement 2 (whether other filter-carrying types are gated by any comparable rule on the runtime path) — if the gap is general, this card is mis-scoped and should be replaced by the broader one rather than widened alone.
• Routing left blank on purpose: the one-line edit lands in packages/lint (devx), but if measurement 2 reclassifies this as the general runtime-gate shape it becomes a metadata-lane card; routing before the ruling would pre-commit the wrong lane with even odds. This is the documented straddle from the 13:30Z brief, unchanged.
• Dedup: [P2/P3] 运行时授权门的 advisory findings 要进响应并被 Studio 渲染 + docs「the gate」补第四列(#4463 收尾) #4717 adjacent-not-duplicate (the body's own search, re-confirmed); #4463 运行时发布门在 host-config 拓扑(environmentId 未绑定)上整体不跑——#5086 只把 code-only 拒绝移出了同一条短路 #6710 is the decision card, not the work.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code