feat: Vector/semantic search backend (sqlite-vss / Qdrant / pgvector)

[tgosoul2019]

Context

Suggested by multiple LLMs (Claude 3.7, Grok) during protocol evaluation (see kcp-outreach/prompts/llm-scorecard.md).

Problem

Current search uses SQLite FTS5 (BM25 full-text search). This is excellent for keyword search but misses semantic similarity — e.g., searching rate limiting won't find an artifact titled throttling strategies even if the content is semantically equivalent.

Proposed Solution

Add a pluggable vector search backend to KCPNode:

node = KCPNode(
    user_id="alice",
    search_backend="sqlite-vss",  # or "qdrant", "pgvector", "chroma"
    embedding_model="text-embedding-3-small"  # or local Ollama
)
results = node.search("rate limiting", mode="semantic")
results = node.search("rate limiting", mode="hybrid")  # FTS5 + vector

Candidate Backends

Backend	Mode	Notes
sqlite-vss	Local	Zero-infra, same SQLite file, natural fit for local mode
chromadb	Local/Server	Python-native, popular in AI ecosystem
qdrant	Server	Production-grade, open-source
pgvector	Server	PostgreSQL extension, natural fit for Hub mode

Design Principles

• FTS5 remains the default — zero additional dependencies
• Vector search is opt-in via search_backend param
• Embedding generation should support: OpenAI, HuggingFace local, Ollama
• Local mode default: sqlite-vss (keeps zero-infra philosophy)

Acceptance Criteria

• KCPNode accepts optional search_backend and embedding_model params
• At minimum: sqlite-vss local backend working end-to-end
• node.search(query, mode='semantic'|'keyword'|'hybrid')
• Tests for Python SDK (sdk/python/)
• SPEC.md §4.3 updated to reflect semantic discovery

Related

• RFC KCP-001 §4.3 (Discovery)
• Suggested during LLM eval: Claude 3.7 Sonnet, Grok 2