## Problem `docs/consumers.md` tells every bridge author to pass `'chain' => FALSE` on a diagnostic log call, and states: "The `audit_trail` module itself follows this convention for its internal diagnostics." Nine call sites do not: - `ChainArchiver`, the "could not unlink the on-disk archive" warning. Its sibling branch 30 lines below, for the same operation, does pass it. This one is emitted while file-purge still holds `audit_trail.write:<chain>`. - `AuditTrailCommands`, both `--allow-missing-secret` `critical()` lines. - `AuditTrailTsaCronHooks`, the per-chain failure warning and the per-tick summary, both on the `audit_trail` channel. - `AuditTrailArchiveImportForm` and `AuditTrailArchiveRestoreForm`, which log the same `--allow-missing-secret` critical the two Drush commands above log. The command and the form record one event and only one of them opted out. - `AuditTrailChainDeleteForm` and `AuditTrailChainEntityDeleteForm`, which log everything the operation destroyed: rows, segments, files, acknowledgments, checkpoints. Destroying one chain's data therefore appended a row to another chain, and which chain that was depended on nothing more than which one happened to list the `audit_trail` channel. On a site where a chain takes the `audit_trail` channel automatically, these become rows in the tamper-evident trail. Measured before the fix: one failing TSA cron tick wrote **2** extra rows into the chain it was reporting on. (`AuditTrail.php`'s fan-out to the other loggers is deliberate and correctly carries `ALREADY_CHAINED` instead, so it is not part of this.) ## Proposed resolution Pass `'chain' => FALSE` on all nine, and stop deciding this by reading: the first pass over these call sites read them by hand and missed four of them. (The count in this issue said eight until the diff was counted against it: the list below has five bullets, and four of them name two call sites each.) ## Tests - `ChainTimestamperTest::testCronDiagnosticsAreNotChained` — a chain taking the `audit_trail` channel in `mode: auto` receives no row from a failing cron tick. Fails without the fix (3 rows, expected 1). - `AuditTrailChainDeleteFormTest::testClearingTheDataIsNotItselfChained` — clearing `webdav` writes no row into `notarial`, which takes the `audit_trail` channel automatically and is untouched by the operation, so it can only have gained the row from the form's own log call. Two of the nine call sites, and both shapes: a chain that takes the channel automatically, and one operation writing into a different chain. The remaining seven are the same one-line change; enumerating them was how they were found, but the enumeration is an audit step rather than an assertion. ## Withdrawn from this issue This issue was filed also proposing that `ChainRegistry::hasAutoChannel()` should mirror `resolve()`'s `default` fallback, so that a `mode: auto` default chain auto-claims every unclaimed channel. **That was wrong and has been dropped.** `LoggerShortCircuitTest::testDefaultAutoOnlyClaimsListedChannels` pins the current behavior deliberately: auto-claiming the fallback is the leak that put every PHP deprecation and core notice into the audit chain, and narrowing it was the fix. `AuditTrail::event()` chaining the same call is not a disagreement between the two ingresses, because `event()` is an explicit audit request and a bare `\Drupal::logger()->notice()` is not. --- AI-Generated: Yes (Claude Code was used to audit the module, draft this issue summary, and write the code and tests on the merge request. Each new test was verified to fail without its fix and to pass with it, and phpcs, PHPStan, cspell and the impacted test classes were run before pushing.)