PSShouldProcess Rule and module specific adaption

[FriedrichWeinmann]

Scenario

One of the default rules checks, whether a command that supports should process, actually uses ...

$PSCmdlet.ShouldProcess( ... )

Now, this is a great rule in principle, but in the framework module I maintain (https://psframework.org) I've got a cmdlet that replaces that method call (for readability and mocking reasons).

My current solution is to disable the specific script analyzer rule (PSShouldProcess) in my automatic tests. Which works well enough for my purposes.
But it would be more awesome if it were to detect the command and equate it with the method call (cause I'd actually appreciate having that check enabled, if it were practical).

Creating my own rule wouldn't be a problem, so my own projects would be covered. But since I'm trying to distribute this to others - with increasing success - distributing the custom rule to their tests would be ... inconvenient outside of PSScriptAnalyzer.

Questions

What's the policy on changes to rules that are module specific?

If I write that update, would it even be considered?

[bergmeister]

One can suppress a violation on a per cmdlet basis, see docs and example here, I am not sure if you did not know about this feature or if I misunderstood the problem, can you please elaborate? Please note also related issue #945
There is no policy on rule changes that are module specific, there are issues open e.g. what to do about Pester's Gherkin aliases, at the end everything is up for discussion and thus change for the better

[FriedrichWeinmann]

Heya, alas it appears to be misunderstood or ill explained :)
I'm fully aware of the ability to work around this limitations. For my own modules, I'm totally cool with the current status quo.
My desire however is to optimize to user experience of developers that build their tools on the PSFramework. At the moment they are forced to do either blanket or targeted exclusions, which I first have to explain to them (And I really want them to be able to just go and have fun with the framework without bothering them with those kinds of details). The cmdlet in question is not equivalent to the scenario discussed in #945 , where they rely on preference variable inheritance.
The only way I can see to make this work as desired would be to adjust the original rule to correctly identify the command and accept it as fulfilling its examples.

[SeeminglyScience]

@FriedrichWeinmann does the proxy function support ShouldProcess?

If I remember correctly all that the rule checks is that either

1. $PSCmdlet.ShouldProcess is called

2. Any command that also supports ShouldProcess is called

So as long as your proxy command supports ShouldProcess and is resolvable, that should be enough to "fix" the warning.

[FriedrichWeinmann]

hm, the cmdlet does not do so yet.
But if I understand #945 correctly that may not be a behavior I want to rely on remaining unchanged