Round-2 fixes to http-delivery §8.1-§8.4, in the text, wai-rs, http_receipts.py and
the corpus together.
1. Claims run jwp-receipts §3.1 step 6 against what the passed delivery items
deliver: energy against their object receipts (a named OER receipt is
context_not_held); measurement/operating-point against the moq-jwp:object figure
of an item delivered under the claimed group (energy_figure::HeldObject), else
figure_not_held / context_not_held; delivery-gap against an item at its
coordinates; decisions and recovery records against the declaration fetched by
link; reconstruct-session context_not_held. Never acceptance without context.
2. A claim about a receipt attaches only through the group of an item whose
delivery check passed.
3. A soft binding of another object is reported as attesting the ancestor only
after §3.2 steps 2-5 pass (held object, a publisher key from a verified
delivery, a matcher); otherwise receipt_not_about_object.
4. Bounds: receipt files 1 MiB (receipt_too_large), indexes 4 MiB with 256 items
and 256 claims (receipt_index_too_large), each name fetched once per index
(memo), 1024 fetches per index (receipt_fetch_budget_exhausted); the CLI fetches
under a deadline (--deadline-ms) and these caps, never following a redirect.
5. A legacy (unlabelled) group file is refused (receipt_legacy_group): its name
does not fix its parent.
6. The parent walk is clamped to 64 whatever bound is asked.
7. wai http receipts --key-origin retrieves the key log itself from --connect,
sending anchoring_request_headers, following no redirect, and builds the
Retrieval from the response.
Corpus: measurement/energy/gap claims and O5's index, legacy group, a 66-deep
chain, padded files and indexes, 256/257 items and claims, a fifty-fold item list;
1015 cases, Rust and Python agree.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
d29cd0731d