A real limitation is not necessarily a release-blocking defect: review severity must be…

A real limitation is not necessarily a release-blocking defect: review severity must be bounded by the change's declared operational scope. A one-slot immutable receipt can be correct for an explicitly one-shot canary even though it cannot support later batches; classify it as a future lifecycle limitation unless the current contract promises repeated promotion. This applies when the one-shot boundary is explicit and current candidates fit the approved cap. It does not apply when the same command or ticket promises multiple batches, or when one run may legitimately need more than one approved manifest.

Evidence/example — 2026-09-12, source provenance: read-only inspection of a pinned GitHub PR diff, its live PR description, the repository runbook, and the linked Linear issue. The implementation stored one manifest receipt at a fixed run-summary key and correctly resumed the same digest, but rejected a different digest. The code observation was genuine. However, the PR explicitly excluded broader batches and scoped itself to a first canary capped at 100 objects/100 MiB; the then-current candidate set was 38 objects totaling about 46 MiB. Therefore the limitation did not block the declared canary, although the wider ticket's eventual promoted-batch phase will need append-only digest-keyed receipts. No production mutation was performed.

Inference: the smallest present change is to make the one-shot boundary explicit in code/tests and defer append-only receipt history to the broader-batch stage; alternatively, implementing digest-keyed receipts now is reasonable hardening but should not be justified as a P1 current-scope failure.