As a developer running validation, I want the CLI to tell me which checks actually ran and reject selections it cannot execute, so that a green result cannot mean nothing was checked.
Problem
Hands-on testing found explicit selections that silently became a different check or no check at all:
extension validate --only phpstan without --full ran sw-cli instead of failing, because --full was missing; 16 metadata findings, not PHPStan's. The type error in TypeTrouble.php goes uncaught.project validate --only sw-cli returned 0 problems although sw-cli does no project checkextension fix --only phpstan exited successfully without doing anything; no fix ran and no files changed- In a disposable copy of
FroshTools, ESLint reported one no-unused-expressions error. Running extension fix --only eslint --allow-non-git printed the same finding but produced no file changes, showing that validation can report an error without the selected fixer resolving it.
This makes a green result ambiguous. It also prevents project upgrade from honestly reporting compatibility coverage: if the CLI cannot say what executed, it cannot distinguish "verified" from "not checked."
Expected
An explicit selection either runs or fails clearly. For example:
$ shopware-cli extension validate --only phpstan
Error: phpstan requires --full
$ shopware-cli project validate --only sw-cli
Error: sw-cli does not support project validation
$ shopware-cli extension fix --only phpstan
Error: phpstan does not provide a fix operation
Successful validation reports its coverage:
Checks: phpstan ✓
0 problems
Acceptance criteria
- An explicitly selected tool runs or fails clearly; it is never silently replaced or ignored.
- Validation reports checks that ran and checks skipped/unsupported.
0 problems cannot result from a no-op selection.- The same coverage information is available to machine-readable output and
project upgrade.
Readiness checklist
As a developer running validation, I want the CLI to tell me which checks actually ran and reject selections it cannot execute, so that a green result cannot mean nothing was checked.
Problem
Hands-on testing found explicit selections that silently became a different check or no check at all:
extension validate --only phpstanwithout--fullransw-cliinstead of failing, because--fullwas missing; 16 metadata findings, not PHPStan's. The type error inTypeTrouble.phpgoes uncaught.project validate --only sw-clireturned 0 problems althoughsw-clidoes no project checkextension fix --only phpstanexited successfully without doing anything; no fix ran and no files changedFroshTools, ESLint reported oneno-unused-expressionserror. Runningextension fix --only eslint --allow-non-gitprinted the same finding but produced no file changes, showing that validation can report an error without the selected fixer resolving it.This makes a green result ambiguous. It also prevents
project upgradefrom honestly reporting compatibility coverage: if the CLI cannot say what executed, it cannot distinguish "verified" from "not checked."Expected
An explicit selection either runs or fails clearly. For example:
Successful validation reports its coverage:
Acceptance criteria
0 problemscannot result from a no-op selection.project upgrade.Readiness checklist