liminis-context-graph v0.16.1 — per-group ontology reload, a health check that says 'busy', and scored search

[verveguy]

v0.16.1 brings three operational improvements for hosts that run lcg as a long-lived, multi-tenant daemon. All three were requested by the community. Everything is additive: there is no migration, no schema change, and nothing to do when upgrading from 0.16.0. If you're coming from 0.15.x or earlier, read the 0.16.0 notes first, because that release migrates entities and doesn't support downgrade.

Reload one group's ontology without restarting (#611)

knowledge_reload_ontology { group_id } is a new admin tool. It makes one group adopt its edited ontology while every other group keeps serving.

Afterwards, knowledge_canonicalize_relations and knowledge_reprocess_entity_types work against the new vocabulary. Before, they failed with -32000 or silently used the old ontology. So "edit the ontology, then reprocess" now works on a live daemon.

It respects the identity guard from 0.16.0. A reload that would reinterpret existing entities (adding or removing identity: true on a type the group already holds) is refused, just as a restart would refuse it. The refusal is reported in the response, and restoring the old file and reloading again clears it. Reloading an unchanged file does nothing.

The health check answers "busy" instead of hanging (#612)

Previously, knowledge_health_check waited until any in-progress write finished, including a WAL rebuild that can take minutes. Supervisors with short timeouts saw that silence as a dead daemon and restarted it mid-rebuild, sometimes repeatedly.

It now answers immediately with state: "busy" and an activity: either rebuilding, with the rebuild job's id and progress, or writing. It doesn't touch the database to do so.

• ok: true means the process is alive.
• healthy means it is ready, so it is false while busy.
• If your supervisor treats any ok: true as "ready", gate on healthy instead.

Search results say how relevant they are (#613)

knowledge_find_entities and knowledge_find_relationships used to return a full page of results with no scores, so a nonsense query still filled every slot.

• Relevance evidence: each result now carries a search object with rrf_score, text_match, bm25_score, and the cosine similarity for each vector path. A path that didn't find the item reports null.
• min_similarity floor: this optional parameter (0–1) removes distant vector matches before ranking. Full-text hits always stay eligible, and it works with the kind filter from 0.16.0.
• Nothing changes by default: leave min_similarity unset and results and ordering are exactly as before.

Also

• If an episode was being extracted when its group's ontology was reloaded, it no longer overwrites the reloaded group's drift record.
• The docs site now republishes automatically on each release. It had only been updated by hand since 0.14.0.

What was verified

• CI: the full Rust suite and real-corpus end-to-end jobs on Linux, the Windows named-pipe end-to-end job (which creates and queries real vector and full-text indexes), and release builds for all four targets with the pinned-extension check.
• Per-change tests: each change's acceptance criteria have dedicated tests. That's 12 reload scenarios, every health-check path, and 10 search-evidence tests, including unchanged ordering with no floor.
• macOS: the sidecar-gated replay battery ran with no skips, with timings in line with 0.16.0.
• Published artifacts: all four archives pass their checksums, every bundled extension matches its pinned hash, and the published macOS binary reports 0.16.1 and exposes knowledge_reload_ontology and min_similarity over MCP.

Full detail: docs/releases/0.16.1.md · CHANGELOG