nx doctor: 998 unstamped index-run fences on knowledge-store documents, suggested fix (nx index --force) cannot apply

[hhildebrand-conductor]

Summary

nx doctor reports 998 documents with index_state set but no index-run stamp. All of them are knowledge-store entries under the curator owner (tumbler prefix 1.1), not repo files. The suggested fix, nx index <path> --force, cannot apply to them: they have no file path. The warning persists after a full nx index repo of every registered repo owner.

Observed (macOS arm64, local mode, bge-base-en-v15-768, conexus 7.33.0, engine v0.1.105)

⚠ stale index-run fences: 998 document(s) report index_state but carry no stamp, despite being
  indexed after this install's fence baseline (2026-08-29T01:54:16.990986+00:00 ...):
  1.1.103 (2026-08-29T15:15:27.422591+00:00); 1.1.104 (2026-08-29T15:15:27.189417+00:00); ...
  +988 more (plus 2874 candidate(s) beyond the 1000-document tracking cap, not individually attributed).
  A producer wrote these without calling index-run begin/complete
  Fix: nx index <path> --force

Sample of the named documents:

Tumbler	Collection	Title	Indexed
1.1.103	knowledge__knowledge__bge-base-en-v15-768__v1	audit-cross-system-integration-conductor-orchestrate-2026-04-29	2026-08-29T15:15:27Z
1.1.104	knowledge__knowledge__bge-base-en-v15-768__v1	analysis-codebase-contentking-architecture-part1-2026-04-29	2026-08-29T15:15:27Z
1.1.122	knowledge__knowledge__bge-base-en-v15-768__v1	cross-ref-hal-meeting-prep-api-mcp-exposure-2026-04-30	2026-08-29T15:15:27Z

All ten named documents carry an indexed_at inside the same second, 2026-08-29T15:15:27Z. That is a bulk write, not interactive store_put calls. It falls inside the 6.11 -> 7.22 migration window described in #1489 (opened 2026-08-29T16:00Z on the same machine). The likely producer is a migration or backfill step that rewrote knowledge__knowledge rows without opening an index run. I could not confirm this from the logs: storage_service.log.1 has no events at that second, and there is no upgrade log covering it.

Problems

1. The check attributes non-file documents to the file indexer and suggests a fix that cannot run on them.
2. There is no supported way to stamp or clear these rows once they exist. The warning is permanent on this install.
3. The "2874 candidates beyond the 1000-document tracking cap" line means the real population is larger than the number in the headline.

Suggestion

• Split the check by owner kind. For curator-owned (store_put) documents, point at the store write path rather than nx index --force, or exclude them if the fence contract does not cover that path.
• Find which migration or backfill step in the 6.x -> 7.x path writes index_state on knowledge rows without an index run, and either wrap it in begin/complete or leave index_state NULL.
• Offer a one-shot reconcile (for example nx catalog reconcile-stale or a doctor --fix arm) that stamps or clears rows whose owner is not a repo, so an upgraded install can reach a clean doctor.

Environment

conexus 7.33.0 (generation layout), engine-service v0.1.105 local mode, bundled PostgreSQL, macOS 25.6 arm64. Database migrated through the path in #1486, #1488, #1489; restored to a new machine on 2026-09-06.