New rule: procedure should not call a procedure decorated with [EventSubscriber]

[Arthurvdv]

Event subscriber procedures exist to react to events raised by the platform or other apps. Calling them directly from regular code is a design smell:

• It couples business logic to a method whose signature is dictated by the publisher, not by the caller's needs. When the publisher changes (parameters added/removed), every direct call site breaks alongside the subscription.
• It bypasses the event semantics: manual calls don't respect SkipOnMissingLicense/SkipOnMissingPermission or manual binding (EventSubscriberInstance = Manual) the way the event dispatcher does.
• It hides a second entry point in what readers assume is event-driven-only code.

The correct refactoring is to extract the shared logic into a regular procedure that both the subscriber and the other caller invoke.

Proposal: a new LinterCop rule that reports a diagnostic when an invocation target is a procedure decorated with [EventSubscriber].

• Category: Design, Severity: Warning (open for discussion)
• No CodeFix in v1 (an "extract shared method" fix could be a phase 2)

Thoughts? Anything legitimate we'd break by discouraging this pattern?

Generated with Claude Fable 5