I read this as a security investigation - I will inspect the sealed candidate's receipt and acknowledgement paths without modifying it.


I read this as a security investigation - I am reporting the verified verdict.

PASS - no blockers.

- Candidate source hashes match sealed `102c...4635`; installed ack/recovery modules are byte-identical.
- Receipt loader enforces sealed candidate and exact owner route, credential-root containment, private regular receipt ownership/mode, and rejects leaf symlinks.
- Acknowledgements are HMAC-protected and bind actor, authority route, message, callback, publication generation/identity, and receipt integrity. Tamper probe was rejected.
- Callback path rejects stale/foreign cards before the hold-ack branch. The hold-ack branch only persists acknowledgement, retires the owner keyboard, and returns; it cannot approve, finalize/activate, clear `safety_hold`, invoke model-provider work, or send customer messages.
- Replay is idempotent and duplicate-safe.

Verified: `20 passed` across the focused recovery/publication tests.


I read this as a final security re-review - I will inspect the new candidate's dedupe delta and run its focused test without edits.


I read this as a final security re-review - I found a regression in the new dedupe helper.

FAIL - blocker: `_send_publication()` now returns when an existing normal owner-attention payload differs only by `operator_recovery_request`. A `/status` recovery payload is exactly that case, so an existing original card suppresses the requested fresh recovery card. This reintroduces committed-but-unseen notification suppression.

The new test only covers restart after a prior `/status` publication; it misses normal-card -> `/status` recovery. Focused suite passed (21), but does not cover this blocker.


I read this as a final security re-review - I will verify the narrowed `/status` dedupe fix and its sealed candidate evidence.


PASS - no new security regression.

The early dedupe now applies only when the desired payload lacks `operator_recovery_request`, so normal -> `/status` publishes a fresh card while `/status` -> same-candidate restart remains deduplicated. Focused suite: 21 passed. Candidate binding matches `e06a...2fc6` and wheel `ea618...1db9`.