Skip to content

Design check: kb_scopes — keep as global registry or move to per-call? #136

Description

@Gumbees

Same body as the failed #135 attempt — see comments below for the design question.

Why

#80 added kb_scopes to GlobalSettings as a named-scope registry: operators define { "policies": { "book_ids": [12, 34] } } once in /settings, then callers reference scopes: ["policies"] on semantic_search. Convenient for repeat-use cuts.

#122 (just shipped) made a similar judgment call about indexed_shelves: that conflated indexing-side and querying-side concerns; querying-side scoping is per-call only.

Same question for kb_scopes: is the registry pulling its weight, or is it just a stored shorthand that makes the surface harder to reason about? Two callers picking the same scope name could mean different things if the registry mutates between calls.

Options

(a) Keep as-is.
(b) Drop the registry; explicit ID lists only.
(c) Keep but client-local (MCP client maintains the name→IDs mapping, not the server).

Decision needed

Likely after v0.13.0 ships and operators have used the cascade for a few weeks. Filing now so it doesn't get forgotten.

Related: #80 (closed), #122 (closed).

Metadata

Metadata

Assignees

No one assigned

    Labels

    category:refactorDesign or structure redo (the shape was wrong)type:enhancementHalo-equiv ticket type: improvement or new capability

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions