Measure the two unknowns blocking #9612/#9613: what per-rule scoping would actually buy, and where the object door's 285 ms goes

[os-elon]

Maintainer adjudication 2026-08-19: measure before committing to an implementation. #9612 and #9613 stay parked until this lands, then are re-scoped from these numbers.

This card produces two numbers and a written finding. ⛔ It ships no optimisation.

Why these two, and not an implementation card

Both remaining routes for #9612/#9613 need numbers that do not exist yet, and one of the two most load-bearing facts about the problem was only established on 2026-08-19.

Unknown 1 — "scoping saves 83–85%" is an UPPER BOUND, not an estimate

#9851 measured that ablating validateStackExpressions off the runtime-publish surface entirely removes 83–85% of the real-shape flow-publish bill (and only 36% of the stub-shape bill — the asymmetry is what makes it a mechanism rather than a correlation).

⛔ That is the saving from deleting the rule, not from scoping it. Scoping keeps the rule and hands it less: the reachable references it actually needs rather than the whole stack. The saving is somewhere in (0, 85%] and depends entirely on how much smaller the reachable closure is than the full stack — which nobody has measured.

Treating 85% as scoping's payoff is the same error class this repo has now paid for twice in one round: scaling a total by a ratio it was not measured against. #9859 forbids the identical move for #4716's delta. Do not repeat it here.

Unknown 2 — the object door's cost has never been profiled at all

Verified on origin/main at a065e4655, from the registry:

door	rules
flow	validateStackExpressions, validateReferenceIntegrity, validatePresetComparands, validateEmptyCombinators, validateFlowTriggerReadiness, validateApprovalApprovers, lintFlowPatterns
object	validateFunctionalCompleteness, validateManagedApiMethods, validatePresetComparands, lintAutonumberFormats, validateSecurityPosture, validateRuleCompilability, validateRuleSchemaFormats

⭐ Both hot rules are runtimeTypes: ['flow']. Neither is on the object door. The only rule on both doors is validatePresetComparands.

So every profile either card carries — the 86%-at-gate concentration, validateStackExpressions at 70–85%, validateReferenceIntegrity at ~11% — describes flow publishing. The object door costs 16.48 ms @ 21 → 285.08 ms @ 420 on real-shape stacks (#9851's measurement) and its cost driver is unidentified.

That matters for prioritisation, in the maintainer's terms: publishing a flow is a low-frequency action; saving an object or field edit is what a Studio user does dozens of times a day, and #4716's own body calls it the hottest metadata path in the product — the reason P1 deliberately stopped at flow. #4716 has since widened that door from 2 rules to 7. The high-frequency path is the one we have never looked at.

Deliverable 1 — what would scoping actually buy

For the two flow-door hot rules, measure how much of the stack each one actually needs versus what it is handed:

• Compute, for a real written item against a real-shape stack at several N, the transitive closure of references the rule must resolve, and report |closure| / N. If a flow publish at N=420 only reaches 6 objects, scoping is worth doing; if it reaches 300, it is not.
• Then obtain a timed figure, not only a size ratio: feed the rule the closure instead of the full stack and time it. A throwaway measurement prototype is fine and is the only way to get a real number — but it is measurement scaffolding, not a fix: it must not ship as production code, and this PR must not change any rule's behaviour on any surface.
• Report the answer as a range with its method, and say plainly which part is measured and which is projected.

⚠️ Do not stop at the size ratio. A closure that is 5% of the stack does not automatically mean 95% saving — the rule's cost may not be linear in input size. Time it.

Deliverable 2 — profile the object door

Using the landed instrument (scripts/bench/runtime-publish-gate.bench.mts --type object), attribute the 285 ms @ 420 real-shape across the 7 object-door rules. Report a per-rule breakdown at N=21 and N=420 on both shapes.

Anti-vacuity, mandatory: the per-rule shares must account for the measured total (say what fraction is unattributed rather than rounding it away), and removing the top contributor must move the total by roughly its stated share. If it does not, the attribution method is wrong and that is the finding.

Note validatePresetComparands sits on both doors — if it is a large share of the object door too, that is a single change benefiting both, and worth calling out explicitly.

Standing rule from #9851 — applies to every number in this card

Quote the stack shape with every figure. A number given as "X ms at N objects" without its shape is not reproducible; real and stub differ ~25× at identical N. The instrument prints both by default; keep it that way in anything you report.

Scope fences

• ⛔ No optimisation, no behaviour change. Do not scope what any rule is handed in shipped code, do not add caching, do not touch any rule's surfaces / runtimeTypes / surfaceReason. The how remains an open maintainer decision, and one option in runtime gate: full runtime-safe rule snapshot for the publish door — the expensive half split out of the object-gating card #9612's body (a size threshold) is a deliberate fail-open at scale that is explicitly not a dev's pick.
• ⛔ Any ablation is a control only, restored byte-identical, proven with scripts/ablation-dist-preflight.mjs in both directions.
• ⛔ Stay out of content/docs/releases/**.
• ⭐ scripts/** is inside the ROOT package's tsc scope, whose program is defined by exclusion — so dispatch-gates.mjs will not name check:type-check-debt for your paths. Run pnpm check:type-check-debt (both legs) regardless of what the union derives. Baselines may only shrink: if the root entry drifts up, fix your own errors — raising the ledger is maintainer-only and is not authorised. Background: finding: dispatch-gates cannot name check:type-check-debt for a scripts/** card — the root package's tsc scope is defined by EXCLUSION, so no path literal will ever describe it #9873. This cost the previous card a CI round-trip.

Rollback clause

If either measurement falsifies its premise — the closure turns out to be the whole stack (scoping buys nothing), or the object door's 285 ms turns out not to reproduce — STOP and report. That is a valid and valuable answer; do not convert the card into an implementation to salvage it.

Priority

Low, and deliberately bounded. Maintainer, verbatim: 「目前也没有相关的真实用户」, alongside the standing 「objectstack cloud 还没有正式上线,简化开发」. Nobody is waiting on a slow save today. A short PR reporting two numbers honestly is the intended outcome — do not pad it toward looking proportionate to the discussion that produced it.

Refs: #9612 · #9613 · #9851 / PR #9853 (the instrument, squash fb62bd19e) · #9859 · #9873 · #4716.

[os-elon]

Claimed by the metadata / engine-core / drivers PM seat — session session_019yDEhPBC3tcGkW9bkce1HM, branch claude/issue-9905-gate-cost-two-unknowns.

⭐ DELIVERABLE 3, added by maintainer direction — and it may subsume the other two

The maintainer, on reading the cost table, questioned the premise rather than the fix. Verbatim, in three parts:

大客户(420 个对象),就不应该出现在一个软件包中啊,这就是划分软件包的价值。

客户开发开发,校验是否也应该基于软件包

当然这里面要考虑系统对象

Restated: a tenant with 420 objects does not have one 420-object application — they have several packages. Packaging is the platform's own unit of decomposition. So should the runtime gate validate against the written item's package (plus its declared dependencies, plus the platform/system objects every package implicitly depends on) rather than against the tenant's entire stack?

Why this is a real question and not a parameter tweak

Today, packaging does not reduce the gate's cost at all. The gate loads the tenant's whole objects collection regardless of how the customer has packaged it, so a 420-object tenant pays the 420-object price whether that is one package or fifteen. The value of decomposition, at this door, is currently zero. That is the honest answer to the maintainer's second question: validation is not package-based, and that is deliberate.

⚠️ And the proposal argues against a documented, measured decision. RuntimeStackContext's own docblock states the intent:

This is where the runtime is strictly BETTER informed than os lint, which sees one package's config file and has to hedge.

with a measured cost for narrowing, recorded on the permissions key: with a per-write snapshot holding only the written item, security-master-detail-ungranted produced 38 phantom findings per-write versus 4 whole-stack over the shipped corpus (PR #7886). Narrowing the resolution universe is exactly the action that manufactured those false positives. A false refusal on the tenant's only editing surface is the failure mode #4716 spent its whole adjudication guarding against.

The condition that decides it — and it is measurable

Package-scoping is viable iff cross-package references are rare. Measure it:

1. Over the shipped corpus (examples/app-showcase, plus any other real multi-package example in the repo), compute what fraction of metadata references — lookup targets, formula field refs, CEL record.<field> paths, flow node targets, permission-set grants, master-detail pairs — cross a package boundary, versus staying inside the declaring package or pointing at platform/system objects.
2. Report the closure size under a package-scoped rule: package + declared dependencies + platform objects. Express it as a fraction of the full stack, at realistic package sizes. ⭐ The maintainer's own caveat is the crux — system objects are in their own package and everything depends on them, so if that dependency is transitive and wide, the closure may approach the whole stack anyway and the saving evaporates.
3. Say explicitly whether the three cross-collection security rules (the 38-vs-4 family) can be satisfied by that closure, or whether they are the rules that force whole-stack. If they are, the answer may be per-rule: package-scope the cheap majority, keep whole-stack for the three that provably need siblings.

If cross-package references are rare and the platform-object dependency is narrow, this is a better fix than anything in #9612's body: it uses a boundary the customer already declares and the platform already models, rather than a closure the implementation has to derive and defend. It would also collapse the realistic N — a well-packaged tenant would never reach the slow case, which would make deliverables 1 and 2 largely moot.

If they are common, this reproduces PR #7886's phantoms and the answer is no — say so with the number, and deliverables 1 and 2 stand on their own.

⛔ Measure only. Do not implement package-scoping. This deliverable produces the fraction, the closure size, and a verdict on whether the three security rules survive it. The design decision stays the maintainer's.

Notes carried from the dispatch

• ⭐ scripts/** is inside the ROOT package's tsc scope, whose program is defined by exclusion, so dispatch-gates.mjs will not name check:type-check-debt for those paths. Run pnpm check:type-check-debt (both legs) regardless of the derived union. Baselines may only shrink — if the root entry drifts up, fix your own errors; raising the ledger is maintainer-only and is not authorised. This cost the previous card a CI round-trip (finding: dispatch-gates cannot name check:type-check-debt for a scripts/** card — the root package's tsc scope is defined by EXCLUSION, so no path literal will ever describe it #9873).
• Quote the stack shape with every number. Real and stub differ ~25× at identical N (Two published measurements of the same runtime publish gate disagree by 16–25× — reconcile them and leave a repo-resident benchmark behind #9851).
• The rollback clause in the body applies to all three deliverables. A measurement that falsifies its premise is a valid and valuable answer — report it, do not convert the card into an implementation to salvage it.

---

Generated by Claude Code

[os-elon]

{
 "issue": 9905,
 "status": "done",
 "branch": "claude/issue-9905-gate-cost-two-unknowns",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9920",
 "premise_still_valid": true,
 "summary": "All three deliverables measured; no optimisation shipped. D1: the flow-door reference closure for the shipped showcase_task_completed flow is 3 objects and CONSTANT in N (closure/N = 14.3% @21, 0.7% @420, real shape); feeding the gate only that closure saves 80.5% @21, 95.6% @105, 98.7% @420 real, and the differential verdict is identical across five probes, four of which carry a genuine finding. Scoping at N=420 real BEATS deleting the rule (98.7% vs 83-85%) because it shrinks all seven flow-door rules' input, not one rule's existence; at N=21 real it is below that figure, so the honest answer is a range 80-99% rising with N, not a single number. D2: the object door's driver is validateRuleCompilability at 81.3% of 275.81 ms @420 real (unattributed 5.6%; at N=21 real unattributed is 21.1% and is reported, not rounded away); the two doors have DISJOINT drivers, since validateRuleCompilability is object-only and appears in no published flow profile. validatePresetComparands sits on both doors at the same absolute cost (23.28 ms object / 23.34 ms flow @420 real) but is only 8.4% / 4.9% of each bill, so it is one change benefiting both doors and a rounding error against either driver. D3: over the shipped corpus (191 reference edges, 3 packages) cross-package references are ZERO (88.5% same-package, 10.5% platform), and the platform dependency is narrow -- app-showcase names 3 sys_ objects directly, 4 of 44 transitively -- so a package+platform closure is 6.2-15.2% of a packaged 420-object tenant. The three cross-collection security rules survive it: PR #7886's phantoms came from narrowing `permissions`, whereas package-scoping narrows `objects`; with a positive control that does reproduce 8 phantoms, every objects-scoping configuration reached the whole-stack verdict exactly. HONEST LIMIT: the corpus has no multi-package tenant (three standalone apps never installed together), so 'zero cross-package' is a necessary condition met, not an observation of a real integrated multi-package tenant.",
 "tests": "Gate union re-derived with `node scripts/pm/dispatch-gates.mjs` (no path list passed) at the FINAL commit 3171ee40b -- it derived 2 gates from the 1 changed path. `pnpm check:cross-package-test-inputs` OK ('All 33 self-test cases passed. OK: 12 package(s) read outside themselves, all declared'). `pnpm check:nul-bytes` OK ('scanned 6285 text file(s) ... no raw ASCII control bytes'). `pnpm check:type-check-debt` run per the card's standing instruction regardless of the derived union (scripts/** is in the ROOT program, defined by exclusion, so no path literal can name it): first leg refused on an unbuilt closure as designed, so the full package closure was built (`turbo run build --filter='./packages/*' --filter='./packages/*/*'`, 70/70 successful) and both legs then passed -- self-test 23+24+25+28+9 cases, and '--re-measure: OK -- 33 ledger entr(ies) re-measured in 334.2s, 1926 raw tsc error(s) total, none above its recorded number. surplus: none'. The root entry did not move. ABLATION (anti-vacuity control for D2, and its REBUILD is stated): validateRuleCompilability was taken off the object door by editing its `runtimeTypes` to a unique marker `os_ablation_9905`; @objectstack/lint was REBUILT and `node scripts/ablation-dist-preflight.mjs @objectstack/lint os_ablation_9905` confirmed 'marker present in 4 built files'; `rules dispatched` went 7 -> 6 in the bench output, which is the instrument's own staleness detector agreeing. Ablated real @420 = 38.31 ms vs shipped 332.08 ms = an 88.5% drop against a stated share of 81-88% across runs, so the attribution method holds. The RESTORE leg was also rebuilt and proven: `git checkout --` then `sha256sum -c` OK (byte-identical), lint REBUILT, and the preflight re-run with `--absent` confirmed 'marker absent from all 14 built files'; the restored bench printed 7 rules dispatched and 303.89 ms. Every bench figure was taken under the shared /tmp/os-heavy-verify.lock so no parallel agent's build corrupted a timing. Attribution cross-check: the flow door re-profiled with the same instrument gives validateStackExpressions 81.4% @420 real, reproducing the independently published 70-85% band the method did not produce.",
 "open_questions": [
 {
 "question": "Deliverable 3 recommends package-scoping, but the evidence has a hole the repo cannot fill: the corpus contains no multi-package tenant (app-showcase / app-crm / app-todo are standalone apps never installed together), so the measured 0/191 cross-package references shows that references stay in-package where we can see them, not how often two packages a customer deliberately installs together reference each other. How should that gap be closed before #9612/#9613 are re-scoped onto package-scoping?",
 "options": [
 "A -- treat the measured result as sufficient: the boundary is already enforced (manifest.zod.ts requires the namespace prefix on every object name) and a cross-package reference can only ever be to an explicitly declared dependency, so the closure is bounded by construction rather than by the corpus",
 "B -- build a deliberately integrated two-package example (package B extending / referencing package A) and re-run the scan against it before deciding",
 "C -- defer: keep whole-stack, and revisit when a real multi-package tenant exists"
 ],
 "recommendation": "A, with B as cheap insurance if the maintainer wants the number rather than the argument. The reason A is defensible is structural rather than statistical: a package's declared `dependencies` bound what it may reference, so `package + declared deps + platform` is a closure the platform can compute exactly instead of estimating -- and the measurement already answers the maintainer's stated crux (the platform dependency is 4 of 44, not 44, so it does not swallow the stack). B is worth doing only if the packaging story itself is about to be exercised; it is a new example app, not a measurement."
 },
 {
 "question": "Deliverable 2 changes the prioritisation input for #9612/#9613: the object door's cost is validateRuleCompilability (81.3% @420 real), which is object-only and is in none of the flow profiles those cards carry. Should the object door be re-scoped onto that rule specifically, given the maintainer's framing that saving an object/field edit is the high-frequency Studio action?",
 "options": [
 "A -- re-scope #9612/#9613 around input narrowing, which by D1's measurement covers BOTH doors at once and needs no per-rule work",
 "B -- open a separate card for validateRuleCompilability alone (it lazily loads ajv and compiles JSON-schema validation rules; whether it needs the whole objects collection is unexamined)",
 "C -- do nothing yet -- nobody waits on a slow save today"
 ],
 "recommendation": "A. Input narrowing is the single change that addresses both doors' drivers without touching any rule, and D1 measures it at 80-99% on the flow door with an unchanged differential verdict; per-rule work on validateRuleCompilability would buy the object door only. That said, C remains the maintainer's standing position and nothing here contradicts it -- these are numbers for a decision, not a case for scheduling one."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code