>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618632. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !25 >>> <p>drupal.org's CI template fetches its own <code>assets/phpstan.neon</code> only when a project ships none, and that asset is <code>level: 0</code> plus one <code>new static()</code> ignore. audit_trail ships no PHPStan configuration, so its static-analysis gate has been barely stronger than a parse check, and it runs under an <code>allow_failure</code> job where a red result hides beneath a green pipeline badge.</p> <h3>Proposed resolution</h3> <p>Ship a <code>phpstan.neon</code> in the module root at <code>level: 3</code>. The job picks a project's own configuration up automatically, so no CI variable changes. Keeping the level in the file rather than in <code>_PHPSTAN_LEVEL</code> means one source of truth: a contributor running <code>phpstan analyze .</code> in the module directory gets the answer the pipeline gets, on the current lane and on the next-major one. No baseline, and no <code>ignoreErrors</code> beyond the <code>new static()</code> line the template's own asset already carries. The <code>fileExtensions</code> list is carried over from that asset so shipping the file does not silently drop <code>audit_trail.install</code> and <code>audit_trail.post_update.php</code> out of the scan.</p> <p>A <code>drupal.entityMapping</code> block names the class each of the three config entity types' storage hands back. Without it every <code>loadMultiple()</code> is a list of <code>EntityInterface</code>, so a helper that promises the entity's own interface reads as returning the wrong type even though the storage can only ever return that class. None of the three is swapped by a <code>setClass()</code> call in <code>hook_entity_type_alter()</code>, so the attribute's class is also the class a site has.</p> <h3>Findings</h3> <p>Level 3 reports 17 errors against 1.x. The entity mapping clears two of them (the duplicated <code>loadEntities()</code> / <code>loadSecrets()</code> helpers in <code>KeyBackedSecretRepository</code> and <code>KeyMapDetector</code>). The remaining 15:</p> <ul> <li><code>EntityAuditHook::ruleFor()</code>'s <code>@return</code> array shape omits <code>skip_no_op_updates</code>, which <code>dispatch()</code> reads off the returned rule. The default is applied in the body, so this is the docblock being wrong, not the code.</li> <li><code>AuditTrailVerifier::listAcknowledgments()</code>'s shape omits four keys it returns: <code>anchor_before</code>, <code>anchor_after</code>, <code>valid_signature</code> and <code>anchors_match</code>. The acknowledgments controller reads the last two to build its status badge. <code>loadAcknowledgment()</code> has the same gap for the two anchors, which <code>updateAcknowledgment()</code> re-signs from.</li> <li>Three headless form-test helpers declare a <code>FormState</code> return type but hand back whatever <code>FormBuilder::buildForm()</code> passed out by reference, which is only known to satisfy <code>FormStateInterface</code>. Every caller reads <code>getErrors()</code> and nothing else, so the interface is the honest type.</li> <li><code>ChainArchiverTest</code> reads properties off <code>fetchObject()</code>'s <code>object|false</code> in four places. Those four blocks now go through the class's existing <code>loadArchive()</code> helper, which asserts the segment row exists before returning it.</li> <li>The <code>_audit_trail_skip</code> fixture assigns the flag as a magic property, which phpstan-drupal types as a <code>FieldItemListInterface</code> because it cannot know which names are fields. The flag now travels through <code>create()</code> instead. Both routes end in the same <code>ContentEntityBase::$values</code> slot: a key matching no field definition is handed to <code>ContentEntityStorageBase::initFieldValues()</code>, which performs that very assignment.</li> <li>A canonicalization data provider declares its fixture inputs as string-keyed arrays, but the fixture set deliberately includes numeric-looking keys, which PHP casts to int on the way into the array literal. The declared key type is widened to <code>array-key</code>.</li> </ul> <p>Nothing here changes runtime behavior. <code>docs/roadmap.md</code> carried a "PHPStan baseline-free check on a fresh checkout" item, which this delivers, so it is removed.</p> <h3>Why level 3</h3> <p>Level 3 is where <code>return.type</code> and <code>offsetAccess.notFound</code> arrive, which is the band that holds real findings: a docblock promising what the code cannot return, or naming a shape the code does not have. Level 4 reports 55 and level 5 reports 67, which is a separate change rather than something to fold in here.</p> <h3>Verification</h3> <p>phpcs (Drupal + DrupalPractice, 195 files) clean, phpstan level 3 clean, cspell over the changed files adds no dictionary words. The six touched test classes pass: <code>ChainArchiverTest</code> (68), <code>AuditTrailSecretCreateTest</code> (9), <code>AuditTrailArchiveRestoreFormTest</code> (3), <code>EntityAuditHookTest</code> (22), <code>EntityAuditSettingsFormTest</code> (1) and <code>CanonicalizeBytesTest</code> (9). One <code>ChainArchiverTest</code> assertion pins the MySQL name of the <code>chain_range</code> unique constraint and so only passes on MySQL, which is what the Kernel job runs; it is unrelated to this change.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and test changes on the merge request. I reviewed and ran the work myself before posting it.)</p>