index --rebuild reports unqualified success on a mirror it could not read, and cli.md says it always can

[MongLong0214]

Found by auditing docs/ for claims the product's own behaviour contradicts — the gap I left as Unverified: on #398, which audited only the READMEs.

Reproduced

A clone whose refs/notes/commitlore was never fetched. The origin holds one record in a commit message and one in a note.

$ commitlore index --rebuild
rebuilt: scanned 1 commit, indexed 3 trailers in 90ms
$ echo $?
0

No mention that the notes mirror is unfetched. The note's record is simply absent from the index it just built.

The query path, in the same repository, is honest about it:

$ commitlore context f
commitlore: the notes mirror has not been fetched here, so this answer may be
missing records that exist upstream (git fetch does not fetch
refs/notes/commitlore by default). fix: commitlore doctor --fix, then git fetch
context for f … — 1 limits, … in 1 record
  r-cmt001  ecb1ff78  [claim]  from the commit

So context knows the answer is incomplete and says so. index --rebuild builds that same incomplete answer and reports it as a clean rebuild.

Why this shape matters here

This is the defect fixed in r-fetchowed earlier in this release, one command over: doctor --fix wrote the refspec, fetched nothing, and printed ok — "the configuration is right and the records are still missing." The same sentence applies to rebuild.

rebuild is also the command a user runs because they suspect the index is wrong. Answering with an unqualified success is the least useful moment to omit that one of the two record sources was unreadable.

Nothing is lost — the index is a cache and the notes genuinely are not local. The defect is the report, not the data.

The documentation half

docs/cli.md:92-93:

The authority is the commit trailers and refs/notes/commitlore, so commitlore index --rebuild can always reconstruct it

True of what Git holds locally. Read by someone deciding whether they can safely delete the index, it says something stronger than the previous sentence supports, and it is the one place a reader is told the index is disposable.

Expected

index --rebuild should say the same thing context says when the mirror is unfetched — the state is already computed by notesAvailability, so this is a report, not a new check. Exit code need not change: an unfetched mirror is not a rebuild failure.

docs/cli.md should carry the same caveat, or drop "always".

[MongLong0214]

Fixed in #401, merged to dev.

index --rebuild, the incremental build and --no-index now say what context says. Exit code unchanged at 0 — and the brief I wrote for this was wrong about why: I stated context exits 0 while reporting the same state. It exits 3. Verified after the fact: 3 there marks an incomplete answer, while index's contract is 0 built / 2 could not run, so moving it would have failed init and CI in every unfetched clone over a cache that is correct. Following my brief would have shipped that.

docs/cli.md's "can always reconstruct it" now names what it reconstructs from.

Two neighbours are the same defect and were deliberately left, both reproduced here:

• init — in a fresh unfetched clone it prints ✓ Index and init: ready and nothing else. The doctor --fix step does produce the sentence, but only under --verbose. Fixing it means changing what a code-0 step may print by default, which test/init-output.test.ts pins at ≤6 lines. This is the screen a user meets the tool on.
• backfill — prints index: … 0 note trailers, which reads as an absence when it is a gap, and its targets: count is selected from that same index.

Each gets its own issue.

Closing manually: the default branch is main and releases are cut from it, so a dev merge does not trip GitHub's auto-close.