[finding] AppPlugin's inline boot seed costs 3 sequential round trips per seed record, on every boot that reaches it

[os-zhuang]

Measured while establishing the seed-replay cost for objectstack-ai/cloud#1560 (fix: objectstack-ai/cloud#1561). The cloud side is closed; this is the framework half of the same cost, and it comes with an open question I could not settle from outside the container.

The measurement

Rig: scripts/dev-local/bootstrap-curve.mjs in the cloud repo — the real ArtifactKernelFactory.create() over the real TursoDriver in mode: 'remote', with an instrumented @libsql/client counting every round trip and attributing it to a build step.

Synthetic artifact: 10 objects, N seed records spread across them, each record carrying one cel time value so the loader's isNoOpReplay skip cannot fire (--seed-dynamic). Every point is a rebuild — tables present, rows already seeded.

seed records	0	100	200	400	800
bootstrap step round trips	239	552	852	1452	2652

3.02 round trips per seed record, inside bootstrap. Same 3 legs the seed loader's update path always pays — a pre-read, the UPDATE, and a read-back — and they are sequential: charging a synthetic per-call RTT scales the step proportionally.

The source is AppPlugin's inline boot seed (packages/runtime/src/app-plugin.ts, the else branch after the multiTenant check), running SeedLoaderService.load() over normalizedDatasets at plugin start, on every boot.

Why this is a finding and not a bug report

The inline seed is already gated:

const multiTenant = this.organizationWallActive(ctx);
if (this.skipSeedData) { … } else if (multiTenant) {
 seedSource.suppress('multi-tenant-replay');
 // "per-org replay will run on sys_organization insert"
} else { /* inline seed — the 3 legs/record path */ }

In the rig's kernel the gate reads false and the inline seed runs. I could not establish whether it also reads false in the production container — that needs a reading from a live tenant kernel, and cloud#1560's ruling forbids touching the reproduction environment. So the honest statement is:

• The cost is real and measured on a kernel built by the production factory with the production capability slate.
• Whether production reaches this branch is unverified. If it does, every hosted environment pays ~3 sequential legs per seed record inside bootstrap on top of what cloud#1561 just removed from seed-replay — and bootstrap is the step objectstack-ai/cloud#1555 measured at 134 s against a 20 s request waiter.

What would close it

Two separable questions, and the first is cheap:

1. Does a hosted tenant kernel take this branch? One log line, or one assertion in an existing multi-tenant harness, settles it. If it does not, this reduces to a single-tenant os dev cost and can be closed as such.
2. If it does — the same shape as objectstack-ai/cloud#1561: a boot that re-applies a seed union it has already applied has nothing to gain from the round trips, and the fix is to know that rather than to make each leg cheaper. Batching the update path would also help every genuine first seed, which the ledger approach does not.

Related, same family: #10946 (4 sequential round trips per permission set / position at boot), #10945 (registry rescan, quadratic in stored metadata).

[huangyiirene]

Concentration-round first-touch: promoted finding → pm:queue, Task, domain:cli (lands in packages/runtime's AppPlugin).

Scope in the card's own order — the cheap question gates the expensive work: step 1 only as dispatched scope: establish whether a hosted tenant kernel takes the inline-seed branch (one log line or one assertion in an existing multi-tenant harness; the cloud container itself is off-limits per the cloud#1560 ruling the card cites). Branch not taken in production ⇒ report and close as single-tenant os dev cost, no further work. Branch taken ⇒ report back with the reading; the ledger-shaped fix (know the seed union is applied rather than re-pay 3 legs/record) is then re-graded with the measured stakes — it is cloud#1561's shape and may want that PR's author-context. Related bare cards #10946/#10945 (same boot-cost family) are still awaiting sweep — the dev should not fold them in uninvited. Size S for step 1.

---

Generated by Claude Code

[os-elon]

Claim:

• Session: session_019bmVFqoQPq63zhKrxdYG1r (domain:cli lane execution seat, post [PM seat] domain:cli — 🟢 os-zhuang (session_019siH5jDmk5hrayvfyojUqR) · R34 · 在飞 4 卡 / 3 dev · 等维护者 2 #6024)
• Branch: claude/issue-10979-inline-seed-branch-reading
• Worktree: ../objectstack-10979-inline-seed (dedicated, per Prime Directive Migrate documentation site to Fumadocs with monorepo structure and shared content #11)
• Domain: domain:cli — lands in packages/runtime. Triage named that path alongside the label, so the lane assignment is deliberate; nothing to report.
• File surface: packages/runtime/src/app-plugin.ts (read), plus whichever existing multi-tenant harness carries the assertion
• Container & model: remote CCR container, os-dev subagent
• Clause-②: no — no packages/spec/src/** in the diff surface; none declared
• Serial constraints: none known over app-plugin.ts; CI's single-writer-path gate is the authority.

Dispatched scope: step 1 only, per triage

Triage (comment 5380576493) scoped this to the card's own first question and nothing beyond it: establish whether a hosted tenant kernel takes the inline-seed branch. The deliverable is a reading, not a performance fix.

• Branch not taken in production ⇒ report it; the card closes as a single-tenant os dev cost, no further work.
• Branch taken ⇒ report back with the reading; the ledger-shaped fix (know the seed union is already applied rather than re-pay 3 legs/record) gets re-graded with the measured stakes, and may want cloud#1561's author-context. ⛔ Not this dispatch.

⛔ The dev does not implement step 2, however cheap it looks once the reading is in hand. ⛔ The related bare cards #10946 and #10945 are awaiting sweep and are not to be folded in uninvited. ⛔ The cloud reproduction container is off-limits per the cloud#1560 ruling the card cites.

Landing point re-measured at origin/main

packages/runtime/src/app-plugin.ts:

Line
:1069	const multiTenant = this.organizationWallActive(ctx); — the gate
:1070/:1083	the skipSeedData and multi-tenant-replay arms
:1345	private organizationWallActive(ctx: PluginContext): boolean — the mechanism
:1385	a second caller of the same predicate

⭐ Worth the dev's attention before measuring: the comment at :1381 speaks of "the demoted boolean installed", which suggests organizationWallActive reads a value that can be demoted at some point in construction. If so, when the predicate is evaluated may matter as much as what it reads — and a reading taken at the wrong moment answers a different question than the card asks.

⚠️ The trap this card can fall into

The question is about a hosted tenant kernel. A harness kernel is not automatically one. If the assertion lands in a harness that does not reproduce production's capability slate and construction order, the reading is about the harness — a true answer to the wrong question, which is the failure family this lane keeps hitting: a check reporting on a population it was never looking at.

So whatever the answer turns out to be, the report must state exactly what population the reading covers and what it does not. "The branch is not taken" is only useful if it names the kernel it is not taken in.

Dispatching now.

---

Generated by Claude Code