Continuity: three stacked defects prevent any capsule, and therefore any backup

[m10ust]

Summary

Continuity has never once succeeded on this instance. Every hourly run is accepted and then fails with:

Continuity operation failed without reporting repository credentials.

and the panel reports FAILED / No recovery copy has been recorded, with sia continuity freeze refusing:

SIA unavailable: source corpus receipt does not bind the live corpus root

Three separate defects stack up. Fixing each one only reveals the next, and none of the three error messages contains the value that caused it, which is why this stayed silent for days on a box that is watched constantly.

Context: 1,818-page corpus, ~3,600 events/day, repository on another machine over Tailscale, restic backing it. That transport is fine. I verified the repo opens, the key is correct, and the repository id matches the config exactly.

1. Shard numbering hole (siamind.py, _validate_event_replay_key)

r"(?:-part-[2-9][0-9]*)?"   # only the FIRST digit is inspected

That accepts part 2-9, and 20-99, and 200-999, but rejects part-10 through part-19 and 100-199. Verified by calling the function directly:

part-1  ACCEPTED   part-9   ACCEPTED   part-19  REJECTED
part-2  ACCEPTED   part-10  REJECTED   part-20  ACCEPTED
part-8  ACCEPTED   part-11  REJECTED   part-100 REJECTED

Consequence on a busy day: the journal fills nine shards of 400, the tenth shard cannot be written, so corpus_write raises on every pulse and, by design, replays the complete marker forever. My part-9 page is 4 distinct ids repeated 100 times each. The ledger never settles, so continuity can never verify it.

Suggest -part-(?:[2-9]|[1-9][0-9]+), or better, validate against MAX_EVENT_SHARDS rather than a digit class.

2. The corpus receipt binds st_dev (siacapsule.py, ~918-927)

The receipt is built from the corpus directory's dev:ino:mode:uid. On btrfs, a subvolume change alters st_dev, so the stored receipt can never match again no matter how long you wait. Mine:

expected  55:2146790:16832:1000
actual    29:2146790:16832:1000

Only the device differs. Inode, mode and uid are identical. This is not a hostile change, it is the filesystem moving under a correct installation, and there is no path to recovery short of rewriting the receipt by hand.

Suggest binding ino+mode+uid plus a content hash, or at minimum including the expected and actual values in the error message.

3. Capsule entry bound vs corpus growth (sialib.py)

MAX_SOURCE_TAIL_RECORDS = 1024
MAX_SOURCE_SCAN_ENTRIES = MAX_SOURCE_TAIL_RECORDS   # both capsule limits alias this

corpus/packages holds 1,553 entries and grows daily. The freeze then reports:

SIA unavailable: capsule source directory exceeds its entry bound

The net effect is that SIA cannot build a capsule of itself once the corpus passes roughly a thousand pages, which means continuity disables itself precisely when the memory becomes worth protecting. On this box that happened quietly, at around 1,024 pages, some time ago.

Suggest sharding packages/ the way events/ is already sharded, or raising the bound with a documented ceiling so the limit is visible before it is hit.

After fixing all three locally

Freeze succeeds, capsule classifies ready, upload completes and verifies:

capsule_id       7d52d88b98ea4bc38e89850f8090c645
snapshot_id      c4f15954ab38bc61e6b929b56fe322f13ec77c22cdbe8f951b6249f0690646cd
state            verified
"Verified recovery copy is available."

The pipeline is sound. It is these three gates. All three fixes are local patches with timestamped backups, and I would rather upstream them properly than carry them.

One general suggestion: every one of these messages would have been diagnosable in minutes if it had printed the offending value, the replay key, the two device numbers, the directory and its entry count. The refusal logic itself is good, it fails closed and leaves nothing half-written, but the reporting is what made this invisible.

[AnubisQuantumCipher]

Acknowledged, and the shard defect now has a published source fix: b129eef , retained on fix/omarchy-runtime-checkpoint.

The grammar is corrected at the event parser, replay-key validator, shard discovery/occurrence reader, and benchmark resolver. Recorded tests: new regressions 4 tests OK; reverting the old grammar makes those regressions fail (failures=6, errors=4); restored EpochMerge 31 tests OK; affected shard consumers 230 tests OK. The actual writer/discovery fixture reaches part-10. The benchmark resolver does not yet have its own multi-digit behavioral fixture.

This is NOT a complete continuity fix or release. The corpus-root identity change still needs a safe recovery path; simply dropping st_dev would weaken identity protection and is not the proposed repair. The package fan-out report overlaps #7 and is being reconciled against its already-published fix and candidate PR #15. The newer checkpoint is not release-ready: its whole-project gate exposed scanner-headroom failure. Keeping this issue open until all reported failure paths are verified.

[AnubisQuantumCipher]

The cumulative operational repair is now visible in draft PR #16 at published commit 466db32. Shard repair b129eef is included. Reconciliation confirms item 3 overlaps the already-published capsule fan-out fix 4ee1e41; it is not still unfixed merely because the separate source-tail bound remains unchanged.

Item 2, safe corpus-root re-admission after filesystem identity changes, remains unresolved. Device identity will not simply be dropped. The current full suite is running and has no final verdict yet. No release or complete issue resolution is claimed.

[AnubisQuantumCipher]

Released in v1.8.0 (main moved; tag v1.8.0). All three gates, and the general finding about messages:

1. Shard numbering. The grammar is -part-(?:[2-9]|[1-9][0-9]+) at every site (event parser, siamind._validate_event_replay_key, shard discovery and occurrence reader, benchmark resolver), with regressions through part-10, part-19 and part-100. The replay-key refusal now quotes the rejected slug and the expected shape.
2. Corpus receipt bound to st_dev. The identity is not dropped; the move is named and re-admitted by explicit consent. sia readmit prints corpus root expected 55:2146790:16832:1000, observed 29:2146790:16832:1000-style lines for both the corpus receipt and the delivery epoch's records directory; sia readmit --yes (daemon stopped) rewrites the receipt's root= line and publishes a sealed readmission.json beside the unchanged adoption, retaining the previous identity. SIA_READMIT_MOVED_STORAGE=1 ./install.sh performs the same two re-bindings under the installer's CAS journal. The continuity freeze refusal now reads source corpus receipt does not bind the live corpus root (receipt root=…, live root=…; after a filesystem move run: sia readmit), and the panel detail appends Reason: corpus-receipt-root-mismatch (…) instead of only "failed without reporting repository credentials". The maintainer machine hit exactly this class after a VM migration and was repaired through this path.
3. Capsule entry bound. The capsule's directory entry limit is decoupled from the source-tail sampling bound (65,536 entries, its own constant), with a regression freezing a directory beyond the old 1,024. The refusal now names the directory and the bound.

Thank you for the exact values in the report; they are what made each message fixable.