## Problem A segment moves through six states (bare, archived, transient-purged, live-purged, file-purged, compacted), driven by seven cron stages and five thresholds. Each stage destroys more than the last, and each destructive stage skips a check that a sibling stage in the same class already performs. `purgeSegmentLiveRows()` is the clearest case. Its only guards are `assertToCreatedStamped()` and an already-purged short-circuit (`if ((int) $row['live_purged_at'] !== 0) return 0;`). There is **no `archived_at` check** before the `DELETE`, and no check that the archive file still exists or still matches its recorded SHA-256. Both of those are secret-free checks the file-purge stage already does. ## What happens Five independent routes to permanent, unrecoverable loss of audit rows, each one documented or one click deep: - `drush audit_trail:purge --id=<bare segment>` destroys the rows with no archive behind them, while the message the operator read first says "The archive's NDJSON file on disk is your only remaining copy", of a file that never existed. - Cron's live-purge deletes the last copy without re-checking the archive. - `docs/configuration.md`'s own `cron_archive` example pairs `archive_after: P7D` with `transient_purge_after: P30D`. Both forms reject that ordering; applied as YAML (`drush config:set`, a config import) it saves, and `resolveThresholds()` performs no ordering check, despite a comment promising it is "re-checked at cron time". Raw PII is then frozen into signed archives with no remediation path. - `file_purge_after: PT0S`, the exact pattern the transient field's own description teaches, renders as "disabled" in both retention previews, while the cron worker applies the zero sentinel to only two of four thresholds and computes `cutoff = now`. Live-purge and file-purge run in the **same tick**, live-purge first, so a chain's rows and its only archive are destroyed together. - "Auto-archive" in the chains dropbutton is a GET route with no confirm form and no preview, running seven lifecycle stages including both purges, then reporting unconditional success even if every stage threw. ## Findings in this issue - **H4** `src/Archive/ChainArchiver.php:518-566`: live-purge has no `archived_at` guard, so it destroys the rows of a bare segment. Verified by reading the guard set. - **H18** `src/Archive/ChainArchiver.php`: cron live-purge deletes the last copy of the rows without checking the archive file still exists or still matches its recorded SHA-256. - **H19** `src/Archive/ChainArchiver.php`: the archive stage is not gated on transient-purge having succeeded, so raw PII is frozen into a signed archive. - **H20** `src/Archive/ChainArchiver.php`: `PT0S` means "disabled" in both retention previews and "purge now" to the cron worker; the sentinel is applied to two of four thresholds. - finding `src/Controller`: Auto-archive is an unconfirmed GET route running seven lifecycle stages, reporting unconditional success even if every stage threw. - finding `src/Archive/ChainArchiver.php`: overlapping segments are never refused, so two segments can claim the same range with different anchors. - finding `src/Archive/ChainArchiver.php`: a timed-out archive strands `.tmp-*.ndjson` files holding raw payloads. Not a `.gitignore` matter: the archive directory is always outside the repository. ## Proposed fix Two rules. **Verify before destroying**, and **a refusal must not be terminal.** 1. Live-purge requires `archived_at <> 0`, the archive file present, and its SHA-256 matching the recorded digest. Any of those failing is a refusal, not a warning. 2. The archive stage requires transient-purge to have succeeded when a transient threshold is configured, and refuses a range whose transient bytes are empty with nothing accounting for it. 3. `PT0S` gets **one** meaning across the previews, the forms and the worker. 4. `resolveThresholds()` enforces the ordering the comment already promises, so a config import cannot save what the forms reject. 5. Auto-archive becomes a POST behind a confirm form with the same preview the individual stages have, and reports per-stage outcomes. 6. Stranded `.tmp-*` files are swept. Every archive in progress writes into one temp directory, so the sweep is a single directory read and reaches what a crash left in any year of any chain. Each guard above is a refusal, and a refusal nothing can clear is its own defect: 7. A refused segment must not stop a stage reaching the ones behind it. Each capped stage keeps a per-chain resume point, so refusals are examined once per sweep instead of filling every batch. Without it, enough missing archives stop a chain's retention entirely: rows past their window are never dropped and the only sign is the same refusals logged each tick. 8. A segment whose archive file is missing can have it rebuilt from its still-live rows with `audit_trail:rewrite-archive`, verified both against the recorded SHA-256 and against the archive signature over that digest. Live-purge then proceeds on schedule, so the lifecycle never has to choose between destroying the last copy and holding rows past their retention window. 9. Orphan auto-heal reconciles a segment whose rows a sibling's purge already removed, and does not require that segment's own archive: it destroys nothing, and the rows it accounts for are covered by the sibling's archive as well. **Not doing:** refusing overlapping segments, proposed as item 6 in the original summary. Non-overlap is already structural on every automatic route, and the one remaining route, `createBareSegment()` with an operator-supplied range, allows overlap deliberately; the `(chain, from_id, to_id)` unique key already refuses exact duplicates. --- Found by a full-tree audit of `1.x` pinned at `7bae553` (tag `1.0.0-alpha9`), reading all 271 tracked files. Every claim above was checked against the source, and where a claim could only be settled by running something, the issue says so. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on merge request !47. I reviewed and ran the work myself before posting it.)