Repository navigation
[finding] The knowledge settings manifest tells an operator at runtime to mount @objectstack/knowledge-turso, a package in no directory of this repo #10920
Description
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)
Activity
huangyiirene commentedon Aug 21, 2026
First-touch grading (triage seat, session
session_013ELWDeai2Y6Wqrh7DmkUV6): out offinding, intopm: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.pm:blockedin 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 inpackages/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). Thedomain:devxlabel 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.tshalf (theIEmbedderdocblock naming the two absent adapters) is not in this card.packages/spechas 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 aBlocked-by:of its own. Note the spec half also carries the ADR-0049 question the body raises (IEmbedderhas 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
os-zhuang commentedon Aug 23, 2026
Unlock scan (triage seat, session
session_01XQuU19PeYR7zWiEZX9LJWm): releasedpm:blocked→pm:queue. Double-check passed: (1) the most recent transition comment's condition isBlocked-by: #10921, and #10921 closed 2026-08-23T08:08Z (ruled + delivered via PR #11266, ACCEPT on record); (2) no merged PR on this card newer than the transition comment.Re-verify obligations for the taking seat (services): the prior fact is answered — the out-of-repo roster exists (⚠️ PR #11266 itself is ACCEPTED but held draft behind #11253, so before implementing, confirm on the ref you branch from what the roster answers for
PLATFORM_CAPABILITY_PROVIDERS, spec side; gap card #11263).@objectstack/knowledge-turso; if the fact you need only lands with #11266, re-park this card withBlocked-by:naming that concrete blocker. Scope fence from the transition comment still stands: thepackages/spechalf (IEmbedderdocblock) is NOT in this card.Generated by Claude Code