What
composer check:strict fails on development at HEAD. Found while running the gate on feat/session-consolidation; every finding is in a file that branch never touched, so this is the repo baseline rather than new drift.
psalm (3):
lib/Service/Credential/CredentialScopeResolver.php:140 — UnusedClosureParam: param data is never referenced
lib/Service/Engine/RunTraceCollector.php:153 — InvalidPropertyAssignmentValue on $this->steps
lib/Service/ScheduleService.php:1592 — UnusedReturnValue: private method's return value never used
phpmd (8): BooleanArgumentFlag on $dryRun / $failQuietly in Engine::processMessage, FacadeToolInvoker::__construct, ResponseGenerationHandler::generateResponse, ToolLoop::buildFunctionInfos, ScheduleService::writeRunAudit, ScheduleService::runAgentViaEngine, GitHubTemplatePushService::brokerCall, WebResearchEgressGuard::assertSafe.
Why it matters
A red gate is a gate nobody can read. Once check:strict fails by default, a genuinely new finding is indistinguishable from the baseline noise, and the reflex becomes "it's always red" — which is how the next real defect ships.
The phpmd findings are a design opinion (boolean flag arguments) that the code has consciously adopted, so they are arguably a suppression decision rather than a fix. The psalm three look like real dead code.
Suggested resolution
Decide per class: fix the psalm three, and either refactor or explicitly suppress the BooleanArgumentFlag set with a reason. Either way the gate should end green so that red means something.
What
composer check:strictfails ondevelopmentat HEAD. Found while running the gate onfeat/session-consolidation; every finding is in a file that branch never touched, so this is the repo baseline rather than new drift.psalm (3):
lib/Service/Credential/CredentialScopeResolver.php:140—UnusedClosureParam: paramdatais never referencedlib/Service/Engine/RunTraceCollector.php:153—InvalidPropertyAssignmentValueon$this->stepslib/Service/ScheduleService.php:1592—UnusedReturnValue: private method's return value never usedphpmd (8):
BooleanArgumentFlagon$dryRun/$failQuietlyinEngine::processMessage,FacadeToolInvoker::__construct,ResponseGenerationHandler::generateResponse,ToolLoop::buildFunctionInfos,ScheduleService::writeRunAudit,ScheduleService::runAgentViaEngine,GitHubTemplatePushService::brokerCall,WebResearchEgressGuard::assertSafe.Why it matters
A red gate is a gate nobody can read. Once
check:strictfails by default, a genuinely new finding is indistinguishable from the baseline noise, and the reflex becomes "it's always red" — which is how the next real defect ships.The phpmd findings are a design opinion (boolean flag arguments) that the code has consciously adopted, so they are arguably a suppression decision rather than a fix. The psalm three look like real dead code.
Suggested resolution
Decide per class: fix the psalm three, and either refactor or explicitly suppress the
BooleanArgumentFlagset with a reason. Either way the gate should end green so that red means something.