## Problem Segments partition a chain: a row belongs to at most one. Every producer already worked that way except the Declare form, which accepted any range an operator typed, so two segments could cover the same rows. That pairing strands data. A live-purge deletes rows by range, so purging either segment empties the other. What is left names rows that no longer exist, and it can never be archived: the file would start at the first survivor rather than at the range's signed `anchor_before`, and this module's own `importFromFile()` reads such a file as tampered. Because every later retention stage is reached through the archive, its remaining rows are then never live-purged. The operator's retention policy quietly stops applying to them, and each cron tick logs the same warning about it. Archiving it before the purge is not better. `archiveSegment()` streamed whatever rows were still in the range and refused only the empty case, so the record claimed a range it did not carry and the `archive_hmac` signed that claim. ## Steps to reproduce Confirmed with a kernel probe against `1.x`: 1. Write six rows on a chain. 2. Declare segment A over `[1, 3]` and segment B over `[3, 6]`. 3. Archive and live-purge A. Rows 1-3 are gone. 4. Run cron repeatedly, with `live_purge_after` already elapsed for rows 4-6. Rows 4-6 are still live on every tick. B carries `archived_at = 0` forever: the archive stage is the only door to `archived_at`, the live-purge stage only takes segments that carry it, and the orphan-heal stage only fired on segments that had already been archived. ## Proposed resolution Refuse the overlap at the declaration, which is the only way one can be created. `createBareSegment()` rejects any range an existing segment on the chain already covers, whether it overlaps partly, contains, or is contained. Nothing needs the exception it removes. `ensureSegmentCoverage()` slices requested ranges around the segments that exist and snaps each gap to rows inside it, so it cannot mint an overlap; `compactFilePurgedSegments()` folds a contiguous run into one row and deletes the originals; `SegmentRestorer::restoreSegment()` updates the segment it restores rather than adding a second; and `importFromFile()` already refuses a range that is not wholly absent, in its own words "to keep the operator's intent unambiguous". The only claim for allowing overlap was a test docblock asserting the lifecycle ops handle one, which is what this issue disproves. Making the pairing unreachable retires the machinery built to cope with it: - the orphan-heal cron stage, with its per-tick cap and state cursor; - `ChainArchiver::healOrphanSegment()`, and the `require_archive` branch it needed inside `applyLivePurge()`; - the tests covering both. The cron pipeline is six stages rather than seven. The partially-purged display on the segments page stays: an out-of-band `DELETE` still produces that state, and the orphan heal never covered it, refusing it explicitly for lack of a sibling cascade to attest. The `(chain, from_id, to_id)` UNIQUE key stays as the data-layer backstop. The application guard answers first, so the constraint is now exercised through a direct INSERT. No update hook: the alphas are pre-release and reinstalling is the supported way to move between them, so no install carries an overlap forward. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)