Five states the module documents as supported, or reaches through an ordinary concurrency window, leave the chain unverifiable, laundered, broken or silently unpurged. Found by a whole-module read of `1.x` at `00ae092`; none of them is reachable by phpcs, PHPStan, cspell or the current suite. ## 1. Verification crashes after the emergency retire `SecretRepositoryInterface::retire()` exists so an operator can disable a compromised secret before a replacement is ready, and its contract says *"Existing rows continue to verify under the retired secret as long as its bytes / Key entity remain resolvable."* They do not. A clean `verifyChainIncremental()` walk ends in `mintCheckpoint()`, which calls `getSigningSecretId()` — and after a retire without replacement nothing is active, so it throws `SecretNotAvailableException`. Nothing on the way out catches it: - `/admin/reports/audit-trail/{chain}/verify` and `verify-all` return a 500; `AuditTrailChainOperationsController` does not catch. - On cron, `verifyAll()` aborts at the first chain, so every chain behind it goes unverified and `AuditTrailCronVerifyHooks` never reaches its `state->set()`, leaving the status report on the previous tick's verdict. Minting a checkpoint is an optimisation. It should report and return `FALSE`, which is exactly what the same method's lock-contention branch already does. `SecretRetireTest` stops at `getSigningSecretId()` throwing; nothing walks a chain afterwards. ## 2. Restore re-signs lifecycle stamps nothing validated Every forward transition loads its row through `SegmentReader::loadSegmentRowForTransition()`. That method exists to stop a transition sealing a forged lifecycle envelope under the live secret — its own docblock calls the alternative "a laundering step" — and archive, live-purge, transient-purge and file-purge each call it a second time *inside* the chain lock. `SegmentRestorer::finalizeRestoredSegmentRow()` uses plain `loadSegmentRow()` and signs what it finds. Two ways in: - `--allow-missing-secret` waives the up-front lifecycle check in `restoreSegment()`, and step 3 then seals the found `transient_purged_at` / `archived_at` / `file_purged_at` under a resolvable secret. The waiver's remaining guard is the file SHA-256, which says nothing about the segment row. - The up-front check runs outside the lock step 3 holds, so the archiver's read-again-under-the-lock pattern is missing on both counts. ## 3. Deleting a bare segment checks outside the lock it deletes inside `ChainArchiver::deleteSegment()` reads the four lifecycle flags, acquires the chain-write lock, then issues a DELETE with no predicate. Its siblings all re-read under the lock, and `archiveSegment()` additionally carries `->condition('archived_at', 0)` on its UPDATE and refuses when zero rows are affected. A cron archive stamping `archived_at` in that window removes a load-bearing row. The `segment_archived` event it has just written now names a segment that does not exist, so `verifySegmentEventCrossReference()` reports the chain broken, and the NDJSON is orphaned with no segment row left for any purge stage to reach. ## 4. `deleteChain()` takes no chain-write lock and no transaction It is the module's largest destructive operation — rows, segments, acknowledgments, checkpoints and files — and the only one that does not serialise against concurrent writers. A writer that read the head hash just before the DELETE inserts its row just after. The surviving chain then begins with a row whose `previous_hash` names a row that is gone: broken from its first entry, on an operation whose own confirm text promises *"New entries written to %chain afterwards continue to follow the same policy."* Holding the lock closes the window exactly: the writer either lands before the DELETE and is removed with everything else, or after it and starts a genesis row. ## 5. A reinstall inherits the previous install's operational State There is no `hook_uninstall()`. `README.md` says *"there are no update hooks before 1.0.0, so reinstalling is the supported way to move between them"*, and `docs/roadmap.md` still lists "hook_uninstall() cleanup verification" as open. Nine State keys outlive an uninstall, and the ones that bite are the ones the status report reads. `auto_verify.results` and `auto_verify.last_run_at` make `AuditTrailRequirementsHooks::runtime()` skip its "Never run" branch and report chains verified that this install has never seen, some of them chains that no longer exist, on the one page where the module answers for itself. `dropped_under_contention` and `inline_in_transaction` resurrect a previous install's warnings the same way. Three per-chain cron cursors also survive, each holding an `audit_trail_segment` id from an install whose segment table is gone: - `audit_trail.cron_archive.live_purge_cursor.<chain>` - `audit_trail.cron_archive.file_purge_cursor.<chain>` - `audit_trail.cron_archive.orphan_heal_cursor.<chain>` Those self-heal. `advanceStageCursor()` writes `max($examined)` only when a tick filled its batch and `0` otherwise, so the first tick that finds nothing puts the cursor back to the start. They are deleted because they belong to an install that is gone, not because they strand retention. **One key must be kept.** `docs/security.md` relies on `audit_trail.highest_assigned_secret_id` outliving the uninstall, so that a reissued secret id can never point at bytes that did not sign a row an archive file still names. The uninstall hook has to say so. ## Proposed resolution - `mintCheckpoint()` catches `SecretNotAvailableException`, reports on the `audit_trail` channel and returns `FALSE`, matching its lock-contention branch. - `finalizeRestoredSegmentRow()` reloads through `loadSegmentRowForTransition()`. - `deleteSegment()` re-reads under the lock and puts the four flags on the DELETE. - `deleteChain()` runs under `ChainWriteLock`. - `audit_trail_uninstall()` deletes the operational State keys and keeps the secret-id floor, with the reason in a comment. Each gets a test that pins the defect rather than the helper. --- AI-Generated: Yes (Claude Code was used to read the module and to draft this issue and the merge request against it. I reviewed both, and each finding has a test that fails without the change.)