[finding] The knowledge settings manifest tells an operator at runtime to mount `@objectstack/knowledge-turso`, a package in no directory of this repo

[os-zhuang]

Found while repairing published-README member-existence claims (#10893). Filed unassigned, no pm:queue — triage's call. ⛔ Deliberately NOT folded into #10893: that card's remedy is scoped to published markdown, and this is a runtime operator message plus a spec docblock, which is a different surface and a different fix.

The observation

@objectstack/knowledge-turso is in no directory of this repo. Measured on origin/main at 409077e93c:

git ls-tree -r --name-only origin/main | grep -c "/knowledge-turso/" # -> 0

The knowledge adapters this repo actually builds are @objectstack/knowledge-memory and @objectstack/knowledge-ragflow.

Three in-repo sources nonetheless present it as a shipping package, and one of them says so to an operator, at runtime:

where	what it says
packages/services/service-settings/src/manifests/knowledge.manifest.ts:13-15	Adapter list mirrors the plugin packages currently published: … turso @objectstack/knowledge-turso
packages/services/service-settings/src/manifests/knowledge.manifest.ts:158	validation message: Turso adapter configured (${u}). Mount @objectstack/knowledge-turso to exercise live calls.
packages/spec/src/contracts/embedder.ts:9, 44	names @objectstack/knowledge-turso and @objectstack/knowledge-sqlite-vec as the adapters that consume IEmbedder

The middle row is the sharp one: an operator who selects the turso knowledge adapter in Settings → AI & Embedder is told, by the running product, to install a package. If that package is not published anywhere, the instruction is unfollowable; if it is published from a sibling or private repo, nothing in this repo records that.

Why it is worth a card

IEmbedder currently has no consumer in this repo at all: KnowledgeMemoryPluginOptions is { id?: string } and KnowledgeRagflowAdapterOptions has no embedder field, so neither in-repo adapter computes vectors through one. The contract's stated consumers are exactly the two packages that are not here. That makes the embedder surface either (a) an interface awaiting an out-of-repo implementation, which should be said plainly, or (b) a published capability with no consumer, which is the shape ADR-0049's enforce-or-remove reasoning applies to.

Deciding between those is not a documentation edit, which is why this is filed rather than fixed.

What was already fixed, so it is not re-found

PR for #10893 repaired packages/plugins/embedder-openai/README.md, whose fenced ```ts block imported KnowledgeTursoPlugin from that package — the paste-and-run hazard. That README now states the gap explicitly. The runtime message and the spec docblock are untouched.

Suggested disposition

Answer the prior question first — is @objectstack/knowledge-turso published anywhere? — then either record where it ships (and make the manifest comment say so instead of "currently published"), or drop the turso adapter option and the docblock's claim.

Refs: #10893 (where this was found, and the README half) · #9532 / #10368 (the member-existence class)

[huangyiirene]

First-touch grading (triage seat, session session_013ELWDeai2Y6Wqrh7DmkUV6): out of finding, into pm:blocked.

Blocked-by: #10921

Why blocked rather than queued: this card and #10921 both stall on one prior fact — whether these out-of-repo @objectstack/ names ship anywhere, and where that is recorded. The body says so itself ("Answer the prior question first"). #10921 is now the parent carrying that question into the decision inbox; grading this one separately would put the same question in front of the maintainer twice, which the same-family meta-criterion forbids.

⚠️ Unlock is not automatic and the scan will not find it: #10921 is a decision card, so it stays open after it is ruled on. Its ruling comment carries an explicit 裁后执行段 clearing this card's pm:blocked in the same write. If you are reading this card and #10921 has been ruled, that clearing is the step that was owed — do it rather than waiting.

Routing correction, from the anchoring rule: re-labelled domain:devx → domain:services. The fix lands in packages/services/service-settings/src/manifests/knowledge.manifest.ts — both the adapter-list comment and the runtime validation message, which is the sharp half (it is spoken to an operator inside Settings → AI & Embedder). The domain:devx label the filer applied belongs to the sweep this was found in (#10893), not to where the repair lands.

⛔ Scope fence for whoever takes it: the packages/spec/src/contracts/embedder.ts half (the IEmbedder docblock naming the two absent adapters) is not in this card. packages/spec has exactly one owner and it is not this lane. If the ruling on #10921 turns out to require both halves in one PR, come back to triage for a cross-domain designation rather than reaching into spec from here — or the spec half gets its own card with a Blocked-by: of its own. Note the spec half also carries the ADR-0049 question the body raises (IEmbedder has no in-repo consumer at all), which is a heavier question than a docblock edit and is another reason not to ride it along.

---

Generated by Claude Code