## Problem A tampered row that sits **below the chain's latest checkpoint** is reported for one cron tick and then cleared. `AuditTrailCronVerifyHooks::cron()` runs an incremental walk on every tick and a full walk from genesis once per `auto_verify_full_walk_every_days`. The full walk is the only one that re-reads rows behind the checkpoint. `docs/configuration.md` says so: "That is what catches a tampered row *behind* the checkpoint". Neither kind of walk remembers the other's answer, though: 1. The weekly full walk finds the tampered row and stores `ok: FALSE`. The status report turns red, and since #3620422 a `critical` goes out: `Chain "webdav" no longer verifies.` 2. On the next tick the walk is incremental again. It starts from the checkpoint, which is still valid because the row it names was not touched, and walks only the rows above it. They are fine, so it stores `ok: TRUE`. 3. The status report and the broken-chain banner go back to green, and cron logs `notice`: `Chain "webdav" verifies again.` 4. Seven days later the full walk finds the row again, and the cycle repeats. The row was never repaired and nobody acknowledged it. The module says the break went away because a walk that cannot see the row did not see it. The shipped defaults reach this: `checkpoint_min_rows: 100` mints a checkpoint on any chain with more than a hundred rows, and `auto_verify_full_walk_every_days: 7` is the only thing that walks below it. Observed on `1.x` with a probe that runs `cron()` five times on a three-row chain with `checkpoint_min_rows: 1`: | tick | walk | stored `ok` | log | | --- | --- | --- | --- | | 1 | full | `true` | | | 2 | incremental, mints checkpoint at row 3 | `true` | | | — | row 1 tampered, full walk made due | | | | 3 | full | `false` | critical: no longer verifies | | 4 | incremental from row 3 | **`true`** | **notice: verifies again** | | 5 | incremental | `true` | | The purge stage is not affected: it walks the range it is about to delete and does not read the stored verdict. ## Proposed resolution Incremental ticks stay incremental. A full walk records what it found broken beside its verdict. Each incremental tick after it reports its own result plus one more sentence: the last full walk found rows N-M broken, which an incremental walk does not read, and the next full walk says whether they are still broken. The chain stays reported broken with that range, so the status report goes on offering the acknowledgment. The break is cleared by a later full walk that finds the chain clean, or by an incremental walk that started below the broken rows (from genesis, on a chain with no checkpoint it can resume from) and found them clean. Only then does cron log that the chain verifies again. A full walk run by hand counts the same as cron's. `drush audit_trail:verify --full` and a full verify from the chains list store their verdict the way cron's full walk does, so they record, clear and log a break too. That also covers sites that set `auto_verify_full_walk_every_days: 0` and run their full walks from drush. Only a walk at `--depth=strict` counts. No extra walk is run. Also in this change: the `critical` line built its "First broken rows" sentence with `sprintf()` and passed it in as a placeholder value, so that part of the line could not be translated (the defect #3620416 fixed in the verdict). It is now two templates, one for each case. ## Remaining tasks None. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests on the merge request. I reviewed and ran the work myself before posting it.)