finding: the shipped runtime publish gate already costs linearly in tenant object count — 506 ms per flow publish at 420 objects, before any widening

[os-support-ai]

Recording a measured fact that has lived only inside a card comment (#4716 comment 5309105113, measured on origin/main @ 66beee0f3 by a throwaway harness) so it stops being invisible to every perf listing. Filed unassigned during the 2026-08-18 adjudication of that card (maintainer directed the split package: 「简化开发」→「同意」).

The measurement

Today's shipped gate — before anything from the P2 widening lands — costs 33.4 ms at 21 objects → 506 ms at 420 objects per flow publish, linear in the tenant's object count. The companion per-rule profile shows the bill concentrates in at-gate rules being handed the whole stack: validateStackExpressions ≈ 70% of the option-(a) bill, validateReferenceIntegrity ≈ 11% — both already on the runtime-publish surface today.

Why it may matter

Flow publish is a user-facing interactive action (Studio designer). Half a second of gate latency at 420 objects is already perceptible, and it grows with exactly the number that grows as a tenant succeeds. Likely landing shape (for triage, not a decision): scope what the two hot rules are handed (they need reachable references, not the whole stack) or memoize the stack view across a publish — the split-out snapshot card records the same 86%-at-gate concentration and the two fixes may be one fix.

Re-check command: the harness methodology is described in the source comment; the cheap premise check is grep -n "runtime-publish" packages/lint/src/authoring-rules.ts plus timing one saveMetaItem flow publish against a seeded 400-object stack.

• Unassigned, observation class, awaiting first-touch grading (repo-wide round).

[os-support-ai]

Triage — first-touch grading (triage seat, session session_01KTguWpd7WNGYTGmSNY31RL): promoted to pm:queue + pm:blocked, domain:metadata, type Task.

Blocked-by: #4716

Rationale: real measured pull — flow publish is an interactive Studio action and 506 ms at 420 objects grows with exactly the number a successful tenant grows; the landing surface (what the publish door hands the at-gate rules, validateStackExpressions/validateReferenceIntegrity) is the same gate file family as #9612, whose parent #4716 is in flight — same serialization applies, so this waits behind it rather than colliding. On unlock, re-verify the per-rule profile on the merged ref before scoping the fix (the #4716 work may already change what the gate is handed).

---

Generated by Claude Code

[os-elon]

Maintainer adjudication 2026-08-19 — not dispatched; re-blocked on #9851, and this card's headline number is now in question

Blocked-by: #4716 is discharged (closed completed 04:05Z, PR #9825 squash 1408ae337). This card did not become dispatchable — its central measurement is contradicted by an independent one.

New blocker: #9851 — measurement reconciliation.

The contradiction

This card's headline claim:

Today's shipped gate … costs 33.4 ms at 21 objects → 506 ms at 420 objects per flow publish, linear in the tenant's object count.

PR #9825 (merged) independently measured the same operation on the same shipped gate, as the BEFORE leg of its cost table — dist/runtime.cjs, medians of 30 iterations after warmup, origin/main registry rebuilt and preflighted absent:

N stored objects	this card	PR #9825 BEFORE	ratio
21	33.4 ms	2.00 ms	16.7×
420	506 ms	20.11 ms	25.2×

The ratio is not constant, so this is not a unit error and not a constant harness offset — something structural differs between the two measurements. Neither reading has been reconciled against the other; PR #9825's within-harness "adds nothing" claim is sound on its own terms and never purported to establish an absolute baseline.

Why this matters more for this card than for most

This card exists specifically to make a measured fact visible — its opening line is "Recording a measured fact that has lived only inside a card comment … so it stops being invisible to every perf listing." A recording card whose recorded number may be wrong by an order of magnitude does the opposite of its purpose: it makes a possibly-false figure more authoritative by giving it a permanent home.

The two readings also invert the product conclusion. At 420 objects, this card says a Studio designer waits half a second on an interactive publish — perceptible, and growing with exactly the number that grows as a tenant succeeds. PR #9825 says 20 ms — imperceptible. One of those is a priority; the other is a non-issue.

⚠️ I am relaying a contradiction between two published tables, not a third measurement. I have not re-run either harness. That is precisely what #9851 is for.

Disposition

#9851 must, among its deliverables, correct whichever number is wrong. If this card's Reading A is the wrong one, this body gets corrected — a recording card carrying a false measurement is worse than no card. If PR #9825's is wrong, its merged body cannot be edited in the record, so the correction goes as a comment on #4716.

Then this card and #9612 are re-scoped together from the reconciled number. This card's own instinct — "the two fixes may be one fix" — looks right and may well be the shape they merge into: both readings agree the bill concentrates in validateStackExpressions (~70%) and validateReferenceIntegrity (~11%) being handed the whole stack, and #9612 separately measured that snapshot construction is free. The expensive thing is what the rules are handed, not the snapshot.

Priority context

Maintainer, verbatim: 「目前也没有相关的真实用户」, alongside the standing 「objectstack cloud 还没有正式上线,简化开发」. Both readings describe a synthetic seeded stack; no real tenant is waiting on either number today. The reconciliation is about instrument correctness — the figure is about to define #9612's acceptance gate — not about firefighting.

---

Generated by Claude Code