🤖 Generated by the Agentic Engineer
What happens
The manifest validation suite has a helper written specifically to check that the published-plugin
rename rule rejects a bad manifest. That helper is defined and never called, so the rule is only
ever exercised on input it should accept.
Found while ablating assertions in this suite: removing the rename check changed nothing, which
looked at first like the assertion being pointless. It was not — the code proving it works is simply
never run.
Why it matters
The rename rule exists to stop a published plugin being renamed out from under the people who
installed it. A rule that is only tested on good input cannot tell you it still bites; it would keep
passing after it silently stopped rejecting anything. This repo's own convention is that a check
whose job is to fail bad input carries both a passes-on-good and a blocks-on-bad test.
Acceptance criteria
- The rename rule is exercised against a manifest that violates it, and the check fails.
- The unused helper is either wired in or removed, so nothing looks covered when it is not.
Small.
What happens
The manifest validation suite has a helper written specifically to check that the published-plugin
rename rule rejects a bad manifest. That helper is defined and never called, so the rule is only
ever exercised on input it should accept.
Found while ablating assertions in this suite: removing the rename check changed nothing, which
looked at first like the assertion being pointless. It was not — the code proving it works is simply
never run.
Why it matters
The rename rule exists to stop a published plugin being renamed out from under the people who
installed it. A rule that is only tested on good input cannot tell you it still bites; it would keep
passing after it silently stopped rejecting anything. This repo's own convention is that a check
whose job is to fail bad input carries both a passes-on-good and a blocks-on-bad test.
Acceptance criteria
Small.