## Problem A chain whose retention lifecycle has archived and live-purged a range in the middle walks clean. The verifier bridges the gap on the segment's signed anchors and reports: ``` Chain "webdav" verified: 6 entries intact. Bridged purged ranges via 1 WORM archive covering rows 2-4. ``` The entry detail page contradicted that walk, twice, on the same chain: - The integrity panel on the first row after the gap rendered a red error: `Row #5 does NOT verify: previous_hash does not link to the predecessor (expected 6d0aace7…, found bb681e44…).` `AuditTrailEntriesController::loadPreviousRow()` takes the highest live id below the row, which after a purge is the row before the gap rather than the predecessor the row actually links to, and handed that hash to `AuditTrailVerifier::checkRow()` as the expected value. - The Chain context panel on the last row before the gap labelled its successor BROKEN, comparing the same two rows. Retention is the module's ordinary operation, so on a long-lived install both fired at every purged boundary, and what they showed an operator is the tamper verdict the chain exists to make meaningful. `testPurgedChainStartIsNotBrokenLink` covered the case where the whole start of a chain is gone: no live predecessor is found at all, so the link check reads as undetermined. The middle-gap case, where a live predecessor exists but is not the one the row links to, is the common one and was not covered. ## What changed Crossing a gap is now one reader. `AuditTrailVerifier::bridgeGapStep()` takes a single step across it, trying the signed segment first and the attested acknowledgment second, and `walkGap()` loops that until nothing accounts for what is left. The chain walk and the new `findExpectedPreviousHash()` both go through it, so the loop that existed twice exists once and the two answers cannot drift. The entry detail page has one adapter that both its panels call, for the same reason. A gap nothing accounts for still falls back to the previous live row's hash, so a row deleted out of the middle of a chain is reported exactly as before. Nor is the check short-circuited on a row that already matches the previous surviving row: that is precisely the shape a row re-pointed past an archived range takes, and the segment's sealed `anchor_after` is the only thing that says it should not verify. The Chain-context label now reads `next.previous_hash does not follow from this row` rather than naming this row's hash, which is not what the successor should carry across a purged range. One change outside the page, needed so this does not cost one: `AcknowledgmentRepository::findAcknowledgmentBridging()` replayed every `acknowledgment_*` event on the chain before looking at whether the chain had an acknowledgment at all, which is a scan of the chain. It now reads the index first and returns on an empty one. Measured on an interleaved two-chain fixture, a cold entry-detail render costs 3 queries before this issue and 5 after it, both additions indexed and bounded by the chain's segment and acknowledgment counts. ## Test coverage `AuditTrailEntriesControllerTest` gains four cases, each confirmed to fail against unpatched 1.x and to pass with the change: - a bridged middle gap, asserted on both panels, with the walk's own verdict asserted first; - an unbridged gap as the control, which passes against 1.x as well; - a row re-pointed past an archived range with its hash and HMAC both re-signed, which must still read as broken; - a query-cost case asserting which statements the page ran, with the index read asserted present so it cannot pass by measuring a page that never reached the bridge. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its test cases. I reviewed both, and the new tests were confirmed to fail against unpatched 1.x and to pass with the change.)