[finding][services] After #6268 there are still TWO Turso loaders, and the open-core one drops the install command, the typed error, and half the config

[os-help]

Observation class (finding, no pm:queue). Found while implementing #6268 (PR #7313); filed unassigned rather than fixed, because it is outside that card's file surface (packages/cli + packages/runtime only).

Fact

#6268 converged the two host-injected Turso loaders onto one owner (packages/runtime/src/turso-driver-factory.ts). It did not — and could not — touch a third, independent libSQL loading arm that has been in the open-core factory since #6345:

packages/services/service-datasource/src/default-datasource-driver-factory.ts, the if (kind === 'turso') arm.

The split is deliberate and documented in that arm's own comment: the host factories win for the default datasource, and this arm serves every other door — a datasource created in Setup, testConnection, a declared non-default datasource. So "two loaders" is not by itself the finding. What is:

Three ways the two disagree

1. No install command, anywhere. The host loader raises MissingDriverPackageError carrying installCommand as data plus a message that states the command, the consequence, and the deliberate refusal. This arm raises

   turso driver requested but @objectstack/driver-turso is not installed (<import error>).
   

   An admin who adds a libSQL datasource in Setup is told what is wrong and not how to fix it — while an operator who boots with the same URL gets the full instruction. Same missing package, two different qualities of answer.

2. A plain Error, not the typed one. packages/cli/src/commands/serve.ts decides fatality with e instanceof MissingDriverPackageError. This arm's failure cannot satisfy that predicate. Nothing routes it there today — which is exactly why this is observation-grade and not a live bug — but it is the same class-identity hazard observation: 可选 Turso driver 的 loader 现在有两份(cli/utils/storage-driver.ts 与 runtime/turso-driver-factory.ts)—— 建议收敛到单一 owner #6268 was filed about, one layer down, and it is currently unpinned by any test.

3. The config surfaces are not the same size. This arm builds TursoDriver with url, authToken, encryptionKey, concurrency, syncUrl, sync, timeout, mode, schemaMode. The host loader reads url and authToken only. So the same declared libSQL config is honoured or silently dropped depending on whether the datasource happens to be named default: an encrypted or embedded-replica default loses encryptionKey / syncUrl / sync with no diagnostic. TursoConfigSchema accepts all of them, so this is declared-but-not-enforced in one of the two positions.

Point 3 is the one a user could actually hit; points 1 and 2 are the drift-shaped half.

Why it is filed rather than folded into #6268

#6268's ruling fixed the owner as runtime and its file surface as cli + runtime. Pushing the host loader's error class or install command down into @objectstack/service-datasource (or pulling that arm up) is a different dependency question with a different blast radius — service-datasource is a dependency of runtime, not the other way around — and deserves its own judgement rather than riding along.

Related but distinct: #7243 records datasource.pool being silently dropped for turso in this same factory. That is the same file and the same "declared ≠ enforced" family; this one is about the loader identity and the driver config keys rather than the pool block.

⚠️ Unclaimed. Severity is deliberately not asserted here — filed plainly for triage.

[os-help]

Claim: PM loop round 4 (domain:services seat #6021)
Session: session_015fkdTyGmMD5s8ZtEifvuGy
Branch: claude/issue-7314-turso-open-core-loader
Worktree: objectstack-issue-7314
Domain: domain:services
File surface: packages/services/service-datasource/src/default-datasource-driver-factory.ts + tests in the same package. ⛔ NOT packages/runtime/** or packages/cli/** (domain:cli territory — the host loader's narrow config read, point 3's other half, and the MissingDriverPackageError class identity question land there; stop and report those as forks/findings). ⛔ No dependency inversion: service-datasource must not import from runtime. (Stop on breach; explain in the report.)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: #6268 / PR #7313 (host-loader convergence, cli lane) — check its merge state at branch point; no in-flight claim touches service-datasource. Note: this card was promoted from finding to pm:queue by a label-only flip (no grading comment) — dispatching on the label per the state model; severity was deliberately unasserted by the filer.

---

Generated by Claude Code

[os-help]

ACCEPT (point 1, the in-lane half). PR #7384, reviewed by the domain:services seat (#6021, session session_015fkdTyGmMD5s8ZtEifvuGy). Marking ready and queueing. Part of #7314 — the card stays OPEN; points 2 and 3 remain and are measured to be domain:cli work.

Verified against GitHub rather than the report: 4 files, all inside packages/services/service-datasource (factory + content-pinned tests + index re-export + changeset); zero packages/runtime/packages/cli touches, zero dependency inversion. 25/25 check runs success/skipped (ESLint 08:32:06Z, TypeScript Type Check 08:33:34Z, by job conclusion).

What shipped: the open-core turso arm's missing-package error now carries the install command (own copy-pasteable line), the package name, the consequence, and the deliberate-refusal rationale — pinned by CONTENT, which is load-bearing here since a toThrow()-only assertion was green through every year the remedy was missing. Two deliberate wording divergences from the host loader are documented in place (names the datasource; names NO host-boot knobs, per the #5794 lesson). TURSO_DRIVER_PACKAGE / TURSO_DRIVER_INSTALL_COMMAND / missingTursoDriverMessage are exported as the convergence seam for the runtime lane. The reverse verification's partial-red (1 of 7 on the wording-only revert) is honestly explained — the other six pin the builder, whose removal is a compile red.

For the triage seat — the remainder of this card is cross-lane (the #6978 shape):

• Point 3 measured: the narrow config read is the HOST loader's (packages/runtime/src/turso-driver-factory.ts ~:245 reads url/authToken only; this arm already reads the full nine keys). A default libSQL datasource silently loses encryptionKey/syncUrl/sync/concurrency/timeout/mode. Fix is entirely domain:cli.
• Point 2 measured: MissingDriverPackageError is declared in runtime (:114) and NOT importable here (runtime depends on this package — confirmed in both package.json files); the legal convergence is moving the class DOWN, a cli-lane call. The exported constants are the prepared seam.
• ⇒ Please re-route this card's remainder to domain:cli (or split), rather than leaving domain:services describing delivered work. This seat releases its claim once fix(service-datasource): the open-core libSQL arm tells you how to install the driver it is missing (#7314) #7384 merges.

Out-of-scope finding verified filed: #7385 (finding + domain:services) — the mongodb/sqlite-wasm arms of the same factory share the no-remedy defect class.

---

Generated by Claude Code