liminis-context-graph v0.13.3 — the upgrade path, and one rule for groups

[verveguy]

v0.13.3 repairs the upgrade path from pre-0.13.0 workspaces, finishes scoping every group-aware operation to the group it names, and adds per-group ontologies.

Upgrading from a pre-0.13.0 workspace works again

0.13.2 introduced a regression on the oldest upgrade path. The migration that moves a flat pre-0.13.0 WAL into the per-group layout never wrote a generation identity for the stream it created — and 0.13.2's new guard refuses to replay a stream whose generation it can't verify. The result: knowledge_rebuild_from_wal was unavailable on every upgraded workspace, which is exactly when you need it — after a lost database, during degraded-mode recovery, or when rolling back.

Migration now stamps the generation it should always have written (#431).

Two related fixes on the same path: the .graphiti → .lcg migration now honours LCG_WAL_DIR / GRAPHITI_WAL_DIR instead of moving content to a hardcoded location the service would never read (#442), including when the configured root is on a different filesystem. And the docs now state plainly that connecting to the socket is not a readiness signal — the socket binds before the database opens, deliberately, so recovery stays reachable; readiness is a health_check round-trip (#436).

Every group operation now names its group

knowledge_canonicalize_relations and knowledge_backfill_relation_types selected candidates database-wide, with no group filter, and wrote their mutations to the default group's stream. On a multi-group workspace, canonicalizing your own group rewrote every co-resident group's edges as a side effect — and recorded those changes in the wrong stream.

Both now require an explicit group_id (#447). This is breaking: a caller that omitted it previously got a database-wide rewrite and now gets an error. There is no default, because a silent default is the defect. No deployment invokes these yet, which is why the parameter is required outright rather than introduced permissively and tightened later.

That completes the boundary work 0.13.0 began. Reads, writes, deletes and maintenance now share one rule: an operation names the group it acts on, and touches nothing else.

Per-group ontologies

A group_id can have its own extraction vocabulary, independent of every other group in the same workspace (#446). Place one at .lcg/ontology/<group_id>.yaml; a group without one falls back to the workspace ontology.yaml exactly as before, so nothing changes for a workspace that doesn't adopt them.

The resolved ontology governs extraction, mode: strict validation, canonicalization and reprocessing for that group only. When a group's stream is published, the ontology that guided its extraction travels alongside it as .wal-ontology.json — informational provenance a consumer can inspect, never applied to the consumer's own extraction or validation.

Telling "empty" from "not yet hydrated"

knowledge_status gains hydration_status per group — hydrated, wal_ahead, or not_applicable (#456). A fresh or wiped database beside a populated WAL previously reported as a healthy empty graph, indistinguishable from a genuinely empty one, which let a downstream mirror propagate the emptiness. healthy is unchanged — it answers "can this process serve requests", and a restart wouldn't hydrate anything.

Upgrading

One breaking change, above. Pass group_id explicitly to the two maintenance tools. Everything else is additive.