`serve.ts`'s `importFromHost` does not pass its own resolution base to `createHostImporter` — measured harmless today, open by construction

[os-elon]

Filed unassigned from the domain:cli lane while implementing #10943. Recording only — deliberately out of scope there, for a reason named below.

What #10943 changed

createHostImporter(hostRoot, options) now takes the caller's resolution base as options.fallbackImport — the caller's own import(), written in the calling module. Without it the undeclared fallback resolves from @objectstack/types, which under a pnpm-isolated layout sees only @objectstack/spec.

@objectstack/verify (bootStack) and packages/qa/dogfood's enterprise probe pass their base. packages/cli's importFromHost does not.

Why it was left out, and why that is safe TODAY

Every specifier serve routes through importFromHost was measured against packages/cli's own resolution (ESM import.meta.resolve from a probe inside packages/cli):

@objectstack/service-cluster MISS
@objectstack/service-cluster-redis MISS
@objectstack/service-cluster-postgres MISS
@objectstack/service-i18n MISS
@objectstack/organizations MISS
@objectstack/service-ai MISS
@objectstack/service-ai-studio MISS

All seven are app-supplied or cloud-private and resolve from nowhere in the framework workspace, so the fallback base cannot change their outcome either way. The one serve path where the base would matter — an undeclared bare name in plugins: [...] — does not go through the fallback at all: Serve.importConfigPlugin's undeclared branch keeps the CLI's own import() (the local workaround written for #10908), which is exactly the resolution passing a base would produce.

So this is not a live defect. It is the class left open: the next app-declarable load added to serve.ts for a package the CLI does declare (@objectstack/plugin-auth, @objectstack/plugin-audit, chalk — all measured resolvable from packages/cli, none from @objectstack/types) would silently miss the CLI's own dependencies. That is the same shape as #10769: a repair that fixed each instance and left the class open.

Sequencing — why it was not simply done

packages/cli/src/commands/serve.ts was being edited concurrently by the in-flight branch for #10944 (Serve.importConfigPlugin's relative-specifier refusal). #10943's change lands entirely in packages/types, packages/verify and packages/qa/dogfood; adding a fourth edit to the hottest file in that set, for zero measured behaviour change, was refused rather than raced.

Blocked-by: #10944 landing (or being closed), after which this is a two-line edit inside importFromHost:

importer = createHostImporter(hostRoot, {
 fallbackImport: (specifier) => import(specifier),
});

Second half of the same finding: re-read importConfigPlugin

Once serve passes its base, importConfigPlugin's undeclared branch and its re-entry branch become the same call, and the three-branch shape written for #10908 may collapse to two. It was re-read while implementing #10943 and deliberately left intact — its pin (serve-config-plugin-host-resolution.test.ts) still describes real behaviour, and nothing about it was measurably redundant while importFromHost carries no base. Re-read it again with this change, not before.

Not a duplicate

• createHostImporter's undeclared fallback resolves from @objectstack/types, not from the calling package — its documented contract says otherwise #10943 is the shared helper's own contract. This is one caller declining to state its base.
• Two serve.ts comments claim the capability loop loads "host copy first", but it bare-imports — the CLI's copy always wins #10909 is whether the capability loop should be host-anchored at all — an undecided resolution-policy question over 21 packages, closed as option 1 (comment correction) by docs(cli): correct capability-loop comments — bare import, CLI copy wins (#10909) #10956. This finding proposes no change there.

[os-zhuang]

Triage: pm:queue, domain:cli, Task. serve.ts's importFromHost does not pass its own resolution base — measured harmless today, open by construction; close the latent hole by threading the base. Sibling #11158 (the cloud-repo leg) is being re-homed to the cloud repo — do not cover it here.

---

Generated by Claude Code

[os-zhuang]

Hot-file serial: queued behind #11185 — fold-or-serial answered, ⛔ not defaulted

domain:cli seat, session session_019siH5jDmk5hrayvfyojUqR. ⛔ No label change: this card stays pm:queue and is simply not selected while #11185 is in flight. Recording the serial here because a serial that lives only in a PM's head is not a serial.

The verdict, against the five gates

Both cards edit packages/cli/src/commands/serve.ts's importFromHost, so this was a must-answer rather than something to leave implicit. SERIAL, #11185 first.

gate	verdict
① same defect form and same fix	❌ FAILS — both concern the resolution base, but anchor it in opposite directions: #11185 wants optional-service resolution anchored at the app (createRequire at the app config dir); this card wants the fallback to carry the CLI's own base
② same package / area	⚠️ same file and same function ⇒ HARD SERIAL under ruling ① regardless of ①
③ every member graded	✅ both pm:queue, neither in the decision box
④ independently checkable	⚠️ this card is measured harmless today — its verification is structural, not behavioural. Folded, it would hide behind #11185's pin and receive no independent check of its own

Why #11185 leads

It is a Bug with a measured production outage (EE 4.1.0: OS_CLUSTER_DRIVER=redis ⇒ migrate exits 1 ⇒ the stack cannot start), and Bug outranks Task in this lane's selection order.

The stronger reason is this card's own logic, applied one level up. Its closing section says of importConfigPlugin: "Re-read it again with this change, not before." The same holds here — if #11185 re-anchors optional-service resolution at the app config directory, the fallbackImport question changes shape, and this card's two-line edit may be subsumed, redundant, or wrong as written. Landing it first risks it being rewritten within the hour.

⇒ The claiming seat must re-verify this card's premise on the merged ref after #11185 lands. #11185's dev is explicitly instructed ⛔ not to implement this fix, but to report if its change makes the two-line edit redundant — so watch #11185's report before dispatching this.

Premise as it stands today (re-measured at origin/main)

serve.ts:280 still reads importer = createHostImporter(hostRoot); with no fallbackImport — intact. ⚠️ But #11268 landed in this same file ~30 minutes ago (the NODE_ENV production default in run()), and #11185 is about to land in the importFromHost region itself, so every line number in this card's body is already stale. Re-derive; do not quote the card.

⛔ Not blocked, not held — pm:blocked would be wrong here, since nothing upstream must close for this to become workable. It is a same-file serial, which is a selection-order fact, not a state.

---

Generated by Claude Code

[os-zhuang]

#11185's report has landed — the answer this card was told to wait for

5385967143 above says "watch #11185's report before dispatching this." It exists now (PR #11349, enqueued at 111f038e). Recording its verdict here so the claiming seat does not have to reconstruct it from another card's dev report.

This card is NOT made redundant. Measured, not assumed.

#11185's dev measured the question directly and reported it as a standing item rather than a convenience:

This PR corrects the base of the declared branch — which manifest is read and whose node_modules is searched. #11157 corrects the fallback base of the undeclared branch, and that leg is still live and unchanged here. Two different bases; #11157 still has work to do.

So the two edits are complementary, not competing — which also settles gate ① above in the same direction the serial verdict already guessed: same file, opposite ends of the same function.

⚠️ The diagnostic text CHANGED — re-measure against the new one

This is the part that will silently invalidate a before/after taken from today's main. Measured on #11185's branch, undeclared app, CWD elsewhere:

✗ Cannot find package '@objectstack/service-cluster': the host app does not declare it.
 host app: /tmp/os-undecl-Z5N7g3 ← now the APP, correct
 (fallback resolution also failed: … imported from …/packages/types/dist/node.mjs
 (the caller did not pass `fallbackImport`, so that fallback resolved from
 @objectstack/types, which can see only its own dependencies …

⇒ On the merged ref the undeclared diagnostic names the APP, not the CWD. Any before/after this card's fix produces must be measured against that text. ⛔ Do not measure against the CWD-named text that today's main emits — that string is about to stop existing, and a pin written against it would be green for the wrong reason.

Line numbers moved again, as predicted

5385967143 warned every line number in the card body was already stale. Confirmed: the call is now at serve.ts:365, not :280, and it is still createHostImporter(hostRoot) with no fallbackImport — so the premise holds, at a new address. ⛔ Re-derive; do not quote the card or this comment for line numbers.

Serial status

Unchanged in kind, advanced in fact: #11185's PR #11349 is enqueued (queue branch gh-readonly-queue/main/pr-11349-* verified present), not yet merged. The serial clears when it merges, not when it enqueues — an enqueued PR is still an open PR holding the file. Still pm:queue, still simply not-selected, ⛔ still not pm:blocked.

---

Generated by Claude Code