DB-first unified KB lifecycle management. All surfaces (CLI, REST API, MCP, Web UI) delegate KB CRUD here. Config.yaml KBs are seeded as `source="config"`; user-added KBs are `source="user"`.
Methods
| Method | Description | |--------|-------------| | `seed_from_config()` | Upsert config.yaml KBs into DB with source='config'. Idempotent | | `list_kbs(type_filter)` | List all KBs from DB, enriched with config metadata (read_only, shortname) | | `get_kb(name)` | Get a single KB from DB with config enrichment | | `add_kb(name, path, kb_type, description)` | Register a new user KB in DB. Raises ValueError if exists | | `remove_kb(name)` | Remove a user-added KB. Raises `KBProtectedError` for config KBs | | `update_kb(name, **updates)` | Update KB metadata (description, kb_type, default_role) | | `reindex_kb(name)` | Reindex a specific KB via IndexManager | | `health_kb(name)` | Check KB health: path exists, file count vs index count, staleness | | `get_kb_config(name)` | Build a `KBConfig` from a DB row (for DB-only KBs) |
Architecture
Constructor takes `PyriteConfig`, `PyriteDB`, and `IndexManager`. Config KBs cannot be removed via the registry (raises `KBProtectedError`). User-added KBs can be fully managed.
The `list_kbs()` method enriches DB rows with config metadata (`read_only`, `shortname`) by looking up the `KBConfig` for each KB. This merges the two sources (config + DB) into a unified view.