runtime gate: full runtime-safe rule snapshot for the publish door — the expensive half split out of the object-gating card

[os-support-ai]

Split from the object-gating P2 card by maintainer ruling (2026-08-18, verbatim: 「objectstack cloud 还没有正式上线,简化开发。」→「同意」on the simplification package; adjudication record: #4716 comment 5328603673). The parent card narrows to gating 5 rules on object writes; THIS card carries the half the cost measurement showed to be expensive and severable.

Scope (was the parent card's second bullet)

• RUNTIME_NEEDS_FULL_SNAPSHOT rule batch: construct the full registry snapshot (option (a) from the P1 design) so rules reading whole-stack collections (pages / dashboards / nav / translations / seeds) can run at the runtime write door.
• The measured pricing this card must answer to (all origin/main @ 66beee0f3, thread comment 5309105113): option (a) per-save p50 = 201 ms at 306 items, 822 ms at 1530, 1.8 s at 3060; snapshot construction is free (0.001–0.011 ms) — 86% of the bill is at-gate rules being handed the whole stack (validateStackExpressions alone 70%). Any implementation must beat or bound this, or gate it (size threshold / caching + invalidation / per-rule scoping).
• Known lazy-dep hazard: an object-write snapshot carrying a json_schema validation loads ajv + ajv-formats on the kernel path; the tripwire test's object leg landed via PR test(lint): give the runtime lazy-deps guard an object-write leg #9295 and must stay red-capable for any type this card widens onto.
• Inherited constraint from the parent body: upgrading validateCapabilityReferences-class advisories to gating is a severity change — its own PR, never a rider here.

Not in this card

• Gating the 5 RUNTIME_OBJECT_WRITES_P2 rules on object writes (the narrowed parent card).
• The pre-existing linear cost of the shipped gate (506 ms per flow publish at 420 objects) — filed as its own finding today.

Triage note: lands where the parent lands (packages/metadata-protocol gate + packages/lint snapshot machinery) — suggested domain:metadata, triage decides; pm vocabulary intentionally only pm:queue here pending triage.

[os-support-ai]

Triage: lands where the parent lands (packages/metadata-protocol gate + packages/lint snapshot machinery) → domain:metadata, matching parent #4716's routing; type Task (brings declared rules to the runtime write door under a measured performance bound — engineering task, not a contract-surface change).

Blocked-by: #4716

The narrowed parent is pm:dispatched on the same gate seam right now; this card is the severable expensive half split out by the 2026-08-18 maintainer ruling (adjudication record on #4716, comment 5328603673). Dispatching both concurrently would put two agents in the same gate files, so it holds pm:blocked until the parent's PR lands. Unlock discipline: on #4716's close, re-verify the file surface on the merged ref before dispatch — the parent's landing may absorb part of the snapshot scaffolding.

(Blocked-by: line carried in this comment per the body-escape convention; unlock scans read comment-level lines.)

---

Generated by Claude Code

[os-elon]

Maintainer adjudication 2026-08-19 — not dispatched; re-blocked on #9851

Blocked-by: #4716 is discharged (closed completed 04:05Z, PR #9825 squash 1408ae337). This card did not become dispatchable, because a different problem surfaced during the unlock review.

New blocker: #9851 — measurement reconciliation.

Why this card cannot be dispatched against its own acceptance criterion

This card's gate is quoted from its body:

option (a) per-save p50 = 201 ms at 306 items, 822 ms at 1530, 1.8 s at 3060 … Any implementation must beat or bound this, or gate it.

Those numbers come from the same throwaway harness family as #9613's Reading A. That harness's flow-publish figures are contradicted by PR #9825's independently measured BEFORE column by 16.7× at 21 objects and 25.2× at 420 — a non-constant ratio, so not a unit error or a constant offset. Full statement of the disagreement is on #9851.

Dispatching implementation work now would mean a dev optimising toward a target that may not be real — and, worse, potentially "passing" by beating a number that never existed. That is a silent-success failure mode, which is worse than a red one.

What the adjudication also settled, and what it deliberately did not

Settled: reconciliation runs first. Both this card and #9613 are parked until #9851 lands, then re-scoped from the reconciled number.

Explicitly still open — a maintainer decision, not a dev's: this card's body permits three ways to answer the cost —

or gate it (size threshold / caching + invalidation / per-rule scoping)

⛔ These are not equivalent. A size threshold means the gate stops judging exactly the largest tenants — metadata validation quietly switches off as a tenant grows. That is a deliberate fail-open at scale, structurally the same defect this repo keeps filing against itself (#9798 declared-but-unenforced; #9261 outage read as emptiness; ADR-0110 D3, a miss and a fault are different facts). Whichever seat picks this card up after #9851: do not let the implementation choose among those three. The choice comes back here.

One structural note for the re-scope

Both this card and #9613 locate the same hot spot — validateStackExpressions ≈ 70% of the bill, validateReferenceIntegrity ≈ 11%, and this card's own finding that snapshot construction is free (0.001–0.011 ms) while 86% of the bill is at-gate rules being handed the whole stack.

That inverts the dependency written on the card face. The expensive thing is not "building the snapshot" — it is "handing rules more than they need". #9613 already suspected it: "the two fixes may be one fix." If the reconciliation confirms the concentration, this card and #9613 should very likely be re-scoped as one card about what those two rules are handed, not two cards about snapshots and latency separately.

Priority context, recorded because it bounds the re-scope

Maintainer, verbatim: 「目前也没有相关的真实用户」 — no real users are affected by this latency today, alongside the standing 「objectstack cloud 还没有正式上线,简化开发」. Nothing here is firefighting. The reconciliation matters because this card's acceptance gate is about to be set by it, not because anyone is waiting on a slow publish.

---

Generated by Claude Code