fix(service-settings): tell operators where @objectstack/knowledge-turso comes from instead of naming a package this repo does not build

[os-sam]

Fixes #10920

The prior question, answered by measurement rather than assumed

The card turned on one prior fact and said so in its own body — is @objectstack/knowledge-turso published anywhere? — so this branch begins with the measurement, not the edit.

Absence in this repo, with a reverse control (on f24c90df3d, the ref this branch was cut from):

git ls-tree -r --name-only HEAD | grep -c "/knowledge-turso/"    # -> 0
git ls-tree -r --name-only HEAD | grep -c "/knowledge-memory/"   # -> 8   (control)
git ls-tree -r --name-only HEAD | grep -c "/knowledge-ragflow/"  # -> 8   (control)

Identical command shape, so the zero is a fact about the package and not a broken pattern.

Publication, against the public npm registry (2026-08-23, unauthenticated GET https://registry.npmjs.org/@objectstack%2F<name> — the method PR #11266 established, with the same control discipline):

package	HTTP	latest	role
@objectstack/knowledge-turso	200	6.9.0 (2026-05-27, 9 versions from 6.4.0)	the subject
@objectstack/spec	200	—	positive control
@objectstack/cli	200	—	positive control
@objectstack/security-enterprise	404	—	known-private negative control
@objectstack/knowledge-sqlite-vec	404	—	negative control

The answer: it IS published. So this PR takes the record-where-it-ships branch. Dropping the turso adapter option — the other branch the card offered — would have deleted a working adapter on the strength of a package not being in this directory tree, which is not the same claim.

One thing the measurement adds that neither branch anticipated: knowledge-turso@6.9.0 exact-pins @objectstack/spec@6.9.0 (also core and service-knowledge at 6.9.0) while this repo ships 17.2.0. It is published, and it is not co-installable with this platform version — mounting it resolves a second @objectstack/spec rather than reusing this one. An operator told only "mount it" walks into that.

What changed

Two sites in packages/services/service-settings/src/manifests/knowledge.manifest.ts, the two the card names.

The runtime operator message (:158) — the sharp one, spoken inside Settings → AI & Embedder. Before:

Turso adapter configured (…). Mount @objectstack/knowledge-turso to exercise live calls.

After, it names the package, says this platform does not ship it, points at where it is built, and gives the operator the check to perform — the framework#3366 discipline that an install hint must carry its own edition/version boundary, applied here the way PR #11266 applied it to @objectstack/organizations.

The adapter-list comment (:13-15) loses Adapter list mirrors the plugin packages currently published: — an undated, unowned claim that stopped being true with nothing to catch it — and gains the three-way split (built here / built here / NOT built here) plus the measurement above with its date and method, so the next reader can re-run it instead of inheriting it.

No behaviour change. ok and severity are untouched on every branch of the test action. Leaving severity: 'info' as-is is deliberate: changing it is a change to what the Settings UI renders, which is outside what this card was graded for. Flagging it here rather than doing it.

Tests

Two added to knowledge.manifest.test.ts, pinned as properties, not literals, so the wording can improve without the guard going stale:

• the turso hint must name the package and where it ships, and must not be the retired bare-mount form;
• a contrast case — ragflow's plugin is built here, so its hint stays the plain mount line. Without it, the first assertion could be satisfied by blanket-rewording every hint in the file.

Verified green on 7372c21015:

pnpm --filter @objectstack/service-settings test       -> Test Files 27 passed (27), Tests 483 passed (483)
pnpm --filter @objectstack/service-settings typecheck  -> tsc --noEmit, exit 0

(The package's tsconfig.json is include: ["src"] with no test exclusion, and the test file lives under src/, so tsc --noEmit really does read the new test code.)

Local gate union derived with node scripts/pm/dispatch-gates.mjs (no hand-supplied paths), run on 7372c21015, exit codes captured before any pipe. All 18 green, each quoted from the gate's own verdict line — for example:

check-type-check-coverage: OK — 65/78 workspace packages type-checked (plus the root), 13 in the DEBT ledger …
check-engine-double-contract: OK — 384 pinned, 133 in the DEBT ledger, 2 exempt.
✓ check-changeset-no-major: This diff introduces no `major` bump.
OK: all 88 declared cross-package glob(s) (76 unique) are covered by `core` or `crosspkg` …

check:type-check-debt (the 19th, which needs the whole workspace closure built first) is running as this PR is opened; its verdict is reported on the card.

Scope

The packages/spec/src/contracts/embedder.ts half of the original finding — the IEmbedder docblock naming knowledge-turso and knowledge-sqlite-vec — is not touched here, per the scope fence on the card. #11318 is not addressed here either: it is the sibling case filed out of this work, where ai.manifest.ts prints the same un-followable mount instruction for @objectstack/service-ai, a package PLATFORM_CAPABILITY_PROVIDERS declares edition: 'cloud'.

A note for triage, since the unlock scan's condition pointed at it: PLATFORM_CAPABILITY_PROVIDERS is present on this ref (PR #11266 merged as a2ec377078), but it does not answer this question in either direction. It is keyed by requires: platform service capability tokens and contains no knowledge adapter at all — not knowledge-turso, and not the two this repo does build. Its silence here is category silence, so reading "absent from the roster" as "ships nowhere" would have produced the wrong repair. The registry measurement above is what actually answered it.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them. ✅

What this run could not see

• the SDK route bridge reached 45 of 221 client-bound route-ledger rows — the other 176 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run: node scripts/docs-audit/affected-docs.mjs --bridge-coverage

Coarse fallback — 7 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json e278a2970d2dbdb662db66dd61bc07264157fa51 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from fb8e5d0539e2a44e3a7c825940765fc64278357d — the merge of head 7372c2101593838fb368392cf24da0982bca5cbe into base e278a2970d2dbdb662db66dd61bc07264157fa51, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin fb8e5d0539e2a44e3a7c825940765fc64278357d && git checkout fb8e5d0539e2a44e3a7c825940765fc64278357d
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin e278a2970d2dbdb662db66dd61bc07264157fa51 7372c2101593838fb368392cf24da0982bca5cbe && git checkout -B drift-repro e278a2970d2dbdb662db66dd61bc07264157fa51 && git merge --no-ff 7372c2101593838fb368392cf24da0982bca5cbe

node scripts/docs-audit/affected-docs.mjs --json e278a2970d2dbdb662db66dd61bc07264157fa51

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-sam]

Correction — the probe command in the PR body lost its placeholder to the body sanitizer

The description presents the registry probe as a re-runnable method, and as rendered it is not runnable. It reads:

unauthenticated GET https://registry.npmjs.org/@objectstack%2F

The package-name placeholder that followed %2F was written in angle brackets and GitHub's body sanitizer ate it. Anyone re-running the command as printed would request a URL with no package name and get an error that says nothing about the question.

The correct form is:

GET https://registry.npmjs.org/@objectstack%2FPACKAGE

— i.e. %2F is the URL-encoded / in the scoped name, and PACKAGE stands for the unscoped package name (knowledge-turso, spec, cli, …). Concretely, the measurement in the body was taken with:

curl -s -o /dev/null -w "%{http_code}" https://registry.npmjs.org/@objectstack%2Fknowledge-turso

I am correcting this in a comment rather than editing the description: the body carries escaped entities throughout, and a full rewrite to fix one line risks mangling quoting elsewhere for no gain. The measurement itself is unaffected — only its printed spelling was damaged, not the result. I re-ran every registry claim in the body independently before flipping this PR (knowledge-turso 200 / latest 6.9.0 / published 2026-05-27 / 9 versions from 6.4.0 / @objectstack/spec pinned at exactly 6.9.0 with no caret; spec 200 at 17.2.0; knowledge-sqlite-vec and security-enterprise both 404) and all of them hold.

Noting the general hazard, since this will recur: a command written into a PR body with an angle-bracket placeholder silently loses it, and what survives looks like a complete command rather than a truncated one — which is the bad failure mode. Use a bare word placeholder (PACKAGE) instead.

This does not affect the merge — a description edit or comment does not change the head SHA, and the PR stays queued on 7372c21015.

---

Generated by Claude Code