[josbeir]

Enforce CakePHP's instance assertion convention ($this->assert…) as an error and exempt conventional framework classes from native size limits. Method-count exemptions cover application and plugin controllers, tables, and helpers; declared-property exemptions cover entities. Both checks remain active for services and other classes.

The exemptions are path-based rather than inheritance-aware. Document that PHPDoc fields do not count toward property limits, keep application-specific strictness choices local, and explain local boolean-flag suppressions for required framework signatures. Precise shared boolean exemptions need native signature-aware support; this change keeps the rule enabled.

Focused consumer checks verify root and plugin path exemptions, continued service diagnostics, and assertion error severity. Native assertion fixer behavior is left to Mago’s own tests. Assertion conversions require Mago's potentially unsafe fixer opt-in. Update the package's own tests to use instance assertions and explicitly check new fixture formatting.

[ADmad]

There's also excessive-parameter-list rule which I had to disable in the core repo. Do we want to address that?

[ADmad]

These too can be included:

no-ini-set = { enabled = false }
function-name = { enabled = false } # This rule expects function names in snake_case while we use camelBacked
assert-description = { enabled = false }
no-negated-ternary = { enabled = true }
no-parameter-shadowing = { enabled = true }

[josbeir]

no-ini-set and assert-description make sense to disable.

For function-name, we could use camel = true, but it still complains about translation functions like __n() and __d(), so disabling it is probably the simplest option.

I’m happy with no-parameter-shadowing. Less sure about no-negated-ternary, since something like $value !== null ? ... : ... can read fine. Do we want that preference enforced across CakePHP projects?

I’d keep excessive-parameter-list disabled in core’s config for now, rather than relaxing it for all apps.

[ADmad]

no-ini-set and assert-description make sense to disable.

👍

For function-name, we could use camel = true, but it still complains about translation functions like __n() and __d(), so disabling it is probably the simplest option.

Oh, I didn't check for the camel = true option. So we can turn that on instead. Reports for functions like __n() could be added to the baseline.

I’m happy with no-parameter-shadowing.

👍

Less sure about no-negated-ternary, since something like $value !== null ? ... : ... can read fine. Do we want that preference enforced across CakePHP projects?

The negation can be avoid by simply swapping the values of the 2 branches. Unnecessary negation is a pet peeve of mine :)

I’d keep excessive-parameter-list disabled in core’s config for now, rather than relaxing it for all apps.

👍

Couple of other rules I had to disable in core today are:

• no-literal-password: This complains even when you mask a password value like 'password' => '********' in __debugInfo()
• prefer-early-continue This rule at times requires adding negated conditions and continue statements, which can make code less readable. If forces you to use continue if the if block has 1-2 statements where early return doesn't make much sense.