Ten places where the prose says something the code does not do. Two are surfaces an operator reads, not just a maintainer. ## Operator-facing **An error message names an internal merge request.** `ArchiveEnvelope::readArchiveRecordFooter()` throws *"Archive file %s has no archive_record footer: cannot be imported. **Pre-MR-2.5 archives** must be reconstructed by hand."* The only remaining internal name in a shipped string, on the disaster-recovery path, pointing at a merge request in a repository the reader has never seen. **Five button labels fall out of the translated sentence around them.** The segment confirm forms return a bare `'Delete'` / `'Archive'` / `'File-purge'` / `'Purge'` / `'Transient-purge'` from `getOperationLabel()`, which `SegmentOperationFormBase::submitForm()` substitutes into the translated `'@operation failed: @msg'`. The method's own docblock says subclasses *"return the same verb used in `getConfirmText()` so the error matches the confirm button"* — and `getConfirmText()` returns `$this->t()` of that same word, so on a translated site they are exactly what the docblock says they must not be: different. ## Prose that outlived its code - **`AuditTrailSecretInterface`** still resolves bytes *"via the entity's storage backend (state or drupal/key)"*. The state backend was deleted with `StateSecretRepository`; #3620328 swept every other contract and this one survived. `drupal/key` is the only backend, which is the whole reason it is a hard dependency. - **`SnapshotDelta`** lists `stateOnly($state)` as an entry point. The method is `buildStateOnlyFragment()`; the same class's other docblock names it correctly ten lines later. - **`AuditTrailSegmentDeleteForm`** says the submit *"calls `ChainArchiver::deleteSegment()` which emits a `segment_deleted` chain event then DELETEs the segment row"*. There is no such action constant, `deleteSegment()` says *"No chain event is emitted... by design"*, and the form's own `getDescription()` — the text the operator reads — says *"neither writes to the audit chain"*. - **`SegmentLifecycleAction::RESTORED`** says it is *"Emitted by `ChainArchiver::importFromFile()`"* (the method is on `SegmentRestorer` and does not emit it) and *"Recorded so the chain history captures who restored when and how many rows landed"*. Lifecycle events go through the writer and never get the forensic stamp, so there is no uid on the row; and `emitRestoredEvent()` records `row_count_expected`, saying in its own comment that the actual counts are deliberately not in the attestation. - **`AuditTrailChainDeleteForm::countTable()`** documents *"Returns 0 on unknown tables"* and has no try/catch. Its twin in `AuditTrailChainEntityDeleteForm` does, and the two are otherwise the same method over the same four tables: the docblock describes its twin's behaviour because there are two of them. The counting belongs in `ChainRepository`, once, with one answer to what a missing table means. - **`docs/roadmap.md`** still promises to lazy-load the segments listing because it *"recomputes SHA-256 on each visible NDJSON file at render time"*. `SegmentReader::listSegments()` says the opposite in its own docblock and `buildSegmentRow()` does no file I/O. ## Structure - **`AuditTrailCronArchiveHooks`** has two docblocks stacked, so the sixteen-line one describing `MAX_COVERAGE_PER_CRON_RUN` sits orphaned above `MAX_COVERAGE_ROWS_PER_CRON_RUN`'s own docblock, and the constant it describes is declared bare fourteen lines further down. - **`getCoverageBuckets()` names the wrong end.** The scan is `ORDER BY d.id ASC` with `range(0, cap + 1)`, so a truncated scan keeps the OLDEST rows and cuts the MOST RECENT bucket, which is the one `array_pop()` drops. The code is right. The docblock (*"the bucket at the OLD end is only as wide as the rows that fit under the scan cap"*) and the inline comment (*"Drop the oldest-end bucket of a truncated scan"*) both name the other end, on the one rule that stops a bucket being minted incomplete — which is how a future reader comes to "fix" it. ## Proposed resolution Correct each statement, and give the two behavioural ones a test: `getOperationLabel()` returns the same `TranslatableMarkup` as `getConfirmText()`, and the footer error drops the internal name for something an operator can act on. --- 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 the two behavioural corrections have tests that fail without the change.)