Context
Issue #553 made a concrete --db/KHIVE_DB path override fail loud when [[backends]] are declared in khive.toml (khive-mcp/src/serve.rs:824-833), because applying one caller path across multiple declared backends is ambiguous. That rejection is correct in the general case.
Problem
The rejection also fires when the override names the same file as the declared main backend. KHIVE_DB=/abs/path/khive.db kkernel exec '...' was a documented one-shot pattern; once a user-global config gained a second [[backends]] entry (e.g. sessions), every such invocation now aborts with:
--db "..." (or KHIVE_DB) cannot be combined with [[backends]]: 2 backend(s) are already declared in khive.toml...
This bit a live pipeline on 2026-07-08 (scripts had to drop KHIVE_DB and rely on khive.toml resolution). The workaround is fine, but the trap remains for any operator following older docs.
Proposed fix (either, maintainer's call)
- Accept the no-op case: when the override canonicalizes to the same path as the declared
main backend, proceed (nothing collapses; the override is redundant, optionally log INFO). Keep rejecting genuinely divergent paths.
- Docs-only: declare
KHIVE_DB incompatible with multi-backend configs everywhere it is documented, and state the khive.toml-resolution path as the only sanctioned form.
Option 1 preserves the ergonomic contract scripts already rely on and stays within #553's anti-ambiguity rationale (an identical path is not ambiguous).
Evidence
crates/khive-mcp/src/serve.rs:815-835 (build_registry_for_multi_backend):memory: special case already carved out at serve.rs:816-823, so a second narrow carve-out has precedent.
Context
Issue #553 made a concrete
--db/KHIVE_DBpath override fail loud when[[backends]]are declared in khive.toml (khive-mcp/src/serve.rs:824-833), because applying one caller path across multiple declared backends is ambiguous. That rejection is correct in the general case.Problem
The rejection also fires when the override names the same file as the declared
mainbackend.KHIVE_DB=/abs/path/khive.db kkernel exec '...'was a documented one-shot pattern; once a user-global config gained a second[[backends]]entry (e.g.sessions), every such invocation now aborts with:This bit a live pipeline on 2026-07-08 (scripts had to drop KHIVE_DB and rely on khive.toml resolution). The workaround is fine, but the trap remains for any operator following older docs.
Proposed fix (either, maintainer's call)
mainbackend, proceed (nothing collapses; the override is redundant, optionally log INFO). Keep rejecting genuinely divergent paths.KHIVE_DBincompatible with multi-backend configs everywhere it is documented, and state the khive.toml-resolution path as the only sanctioned form.Option 1 preserves the ergonomic contract scripts already rely on and stays within #553's anti-ambiguity rationale (an identical path is not ambiguous).
Evidence
crates/khive-mcp/src/serve.rs:815-835(build_registry_for_multi_backend):memory:special case already carved out at serve.rs:816-823, so a second narrow carve-out has precedent.