0.22.0 — a store that builds itself, and a message that stops denying the document

A store arrived on a machine with its documents and no index — a fresh clone, a new git worktree, every CI checkout — and every read answered nothing while every write said the document did not exist. Both halves are fixed here: the message stops asserting a deletion that never happened, and the state stops occurring, because opening a store is now what builds it.

Upgrade notes¶

• A fresh clone or git worktree no longer needs docir reindex before it can be read or written. Opening the store rebuilds an index it finds empty — about a second on a 190-document corpus — and leaves the vectors to the background queue. The explicit docir reindex is still what computes those vectors, so it stays first in the CI order.
• docir doctor's no-index finding is now a warning, not an error. A docir doctor --strict that failed on a fresh checkout will start passing: the run reporting the finding is one of the things that repairs it. empty-index keeps the error severity, for the stores that rebuild does not reach.
• Nothing else changes without you asking. A store with a built index reads exactly as it did.

🎯 Opening a store with no index builds one¶

.docir/docs/ is committed and index.db is gitignored, so a store arrives with its files and no projection of them. Nothing rebuilt it: the daemon's watcher rebuilds what changes, and an untouched checkout changes nothing. It stayed unusable until somebody remembered docir reindex — which docir's actual user, an agent, has to be told twice: once that the command exists, once to run it and retry.

It was a manual step because of a cost estimate, and the estimate was wrong. docir reindex on this repository's 191 documents takes ~70s, but ~69s of that is the embedding drain, loading the ONNX model to write 1,454 vectors. The rebuild itself — files to rows, full text, the relation and mention graphs, the id counters, both stamps — is ~0.9s against a 0.98s baseline docir get.

So the bootstrap does the rebuild and defers the vectors. Every document comes out dirty in the queue a write already uses, the daemon's scheduler drains it in the background, and docir doctor reports what is still queued as embeddings-pending. Until it drains, docir context ranks on full text and the graph alone — a worse answer than a warm store, and an answer, where the state it replaces returned nothing at all.

Only the empty case, decided by the same comparison behind docir check's and docir doctor's empty-index. A store merely behind is untouched and stays index-behind-files, or one unparseable file would make opening a store a corpus-sized write on every checkout. Peers are never bootstrapped: a federated read that rebuilt another repository's index would make a read a write in a repository nobody asked us to touch.

🐛 no document with id stops denying a document that is on disk¶

no document with id '<id>' was the answer to every failed lookup, including the one where the document is sitting in docs/ and the index that answers for it was never built. The message stated something false about the corpus and sent everyone to the wrong place: a human looks for a deletion that never happened, and an agent — which cannot glance at the directory and see the file — concludes the document is gone. The reporter of the issue lost a document amendment to exactly that.

docir check and docir doctor had named this condition since 0.20.0, and neither runs on the path that hits it. The message now names it, through the same comparison, and points at docir reindex. Same error, same exit code 4, same prefix — only where it sends you changes. With the bootstrap above it is the backstop rather than the common case: an index emptied under a running daemon, or a store opened by an older build.

🔗 Full Changelog¶

See CHANGELOG.md