## Problem The mechanical passes over this tree came back clean: clone detection at three window sizes, an identical-body detector, a lockstep-docblock grep, a dead-code sweep, query-shape grouping, and a renamed-override index all reported nothing. Everything in this issue was therefore found by reading, which is the point worth recording: a clean detector report is a floor, not a verdict. The clearest case is the one duplication a detector would have caught if the copies had stayed identical. The effective-delays retention preview is written twice, and the two copies have already diverged. That is precisely the failure mode duplication exists to predict, caught after it happened rather than before. ## What happens Nothing here misreports state to an operator or destroys anything, which is why it is filed at normal priority. What it costs is the next change: a second reader of the retention preview has to work out which of the two copies is authoritative, three list builders each carry their own time formatter, and three methods exist that nothing calls. The naming items are the same kind of cost. `getStatus()` sitting beside `status()` in four places means the call site cannot tell you which one it wants, and several `render*` methods return arrays rather than rendered output, so the name disagrees with the return type. ## Findings in this issue - **M1** `src/Form`: the effective-delays preview is written twice and the two copies have already diverged. - **M2** `src/Writer/PendingWriteBufferInterface.php:88`: `countStaged()` has no caller anywhere. - **M3** `src/SegmentLifecycleAction.php:113`: `isKnown()` is a third, uncalled spelling of the verifier's inline rule. - finding `src/`: `formatTime()` and the render helpers are written across three list builders; three separate message renderers; `applyFilters()` twice. - finding `modules/audit_trail_entity/src`: the contributor EMPTY idiom is documented backwards from what the code does. - finding `src/`: `getStatus()` sits beside `status()` in four places, and several `render*` methods return arrays, so the name does not match the return type. `listSegments()` was listed here as a third uncalled method and that was wrong: it has fourteen call sites across `ChainArchiverTest` and `AuditTrailCronArchiveHooksTest`. It stays, and the count in the title is two. ## Proposed fix Pre-1.0 there are no update hooks to write and renames are free, so this is the cheapest moment to do it: 1. Extract the effective-delays preview once, reconciling the two divergent copies deliberately rather than picking one. 2. Extract the shared list-builder time formatting and the three message renderers. Judge each seam by whether the result reads better at the call site; if it reads worse, the seam is wrong. 3. Delete `countStaged()` and `isKnown()`, or give them callers. 4. Settle `getStatus()` versus `status()` on one name per concept, and rename the `render*` methods that return arrays to say so (`build*`, following core). 5. Correct the contributor EMPTY docblock to describe what the code does. Only a refactor that improves or equals the current query count should land. Nothing here is worth a regression. --- 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. I reviewed it before posting; there is no merge request on this issue yet.)