hygiene(#268+): pr-preservation drain-log for #431 (BLAKE3 receipt-hashing follow-up)

[AceHack]

Summary

Otto-268 follow-on: drain-log for PR #431 — 3-finding Codex cascade follow-up to #268 (BLAKE3 receipt-hashing v0 design input to lucent-ksk ADR). All three are substantive cryptographic-protocol design improvements, not cleanups.

Per Otto-250 (PR review comments + responses + resolutions are high-quality training signals).

Coverage — substantive cryptographic-protocol design

• issuance_epoch field added (P1): 8 → 9 → 10 field-count evolution across review waves; cross-epoch replay resistance during protocol upgrades. Backdating-limitation section also got 3 mitigations (RFC 3161 TSA / Aurora-anchored chained timestamps / forward-only registry).
• Per-design-element attribution preservation (P1, Otto-227): explicit Amara's original / Otto's refinement / joint synthesis labeling rather than blanket "preserved verbatim" claims. 3rd observation of verbatim-vs-annotation pattern.
• parameter_file_sha algorithm specification (P1): BLAKE3 default + hash_version determines algorithm for forward-compatibility (BLAKE3 → BLAKE4 / SHA-3 fallback transitions).

Pattern observations

1. Cryptographic-protocol design iterates through fields (8 → 9 → 10) across review waves. Each addition fixes a specific adversary class. Healthy — absence of evolutions would be a smell that adversary-class enumeration is incomplete.
2. Algorithm-agility-via-version-field is the standard pattern (hash_version, *_key_version, parameter_file_sha-tied-to-hash_version). Numeric version field + dispatch at verification time = forward-compatibility for free.
3. Per-design-element attribution preservation is now a 3rd-observation pattern (aurora: absorb Amara's 5th courier ferry — Zeta/KSK/Aurora independent validation #235 / drain(#221 follow-up Codex): terminology + count alignment + verbatim claim soften #430 / drain(#268 follow-up Codex): issuance_epoch field + Amara attribution + parameter_file_sha algo #431).
4. Codex functioning as cryptographic-design reviewer is a high-value capability surface in this drain corpus.

Test plan

• All 3 substantive design findings preserved with severity + outcome class.
• Field-count-evolution arc documented (8 → 9 → 10).
• Drain-log shape matches existing docs/pr-preservation/*-drain-log.md template.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Copilot]

Pull request overview

Adds an Otto-250 PR-preservation drain log for PR #431, capturing the post-merge reviewer cascade findings and resolutions around the BLAKE3 receipt-hashing v0 design follow-up to PR #268.

Changes:

• Introduces a new drain log documenting 3 substantive cryptographic-protocol design findings and their outcomes.
• Records pattern observations (field-count evolution, algorithm agility via version fields, attribution preservation).

[Copilot]

Thread 1 Outcome has two factual mismatches with the underlying receipt-hash spec: (1) if the evolution is 8 → 9 (hash_version) → 10 (issuance_epoch), then adding issuance_epoch should be described as 9 → 10 (not 8 → 9), and (2) issuance_epoch canonical encoding is u64-be millis (the u32-be encoding in the spec is for length prefixes / key-version fields), so citing encode_u32_be here is misleading. Please align this drain-log wording with the canonical encoding section in the design doc so the preserved training signal stays accurate.

Suggested change

	went from 8 → 9 with `issuance_epoch`. The signed message
	encoding (via `encode_u32_be`) was updated to include the new
	field. Backdating-limitation section also got 3 mitigations
	went from 9 → 10 with `issuance_epoch`. The signed message
	encoding was updated to include the new field, with
	`issuance_epoch` canonically encoded as `u64-be` millis.
	Backdating-limitation section also got 3 mitigations