ci: pin symfony/console to ^7 — Infection mutation gate broken by Symfony Console 8

[Goosterhof]

What

Pins symfony/console to ^7.2 in require-dev.

Why — repo-wide CI breakage, no source change

symfony/console v8.1.0 (released 2026-05-29) crashes Infection 0.33.x's mutation runner:

In Container.php line 194:
  Unknown service "Symfony\Component\Console\Helper\QuestionHelper"

Infection's DI container references QuestionHelper as a service Symfony Console 8 no longer registers that way, so composer mutation:ci aborts and exits 1 — failing the check job.

The package's composer.lock is gitignored, so CI resolves dependencies fresh on every run. illuminate/* v13 permits Symfony 8, so the resolver started pulling v8.1.0. Result: every fresh CI run went red on the mutation step fleet-wide — PRs green on 2026-05-28 turned red on 2026-05-29 with zero source change (this branch, main, and the three open rule PRs #26/#27/#28 all affected).

Fix + verification

Pinning symfony/console: ^7.2 resolves the dev toolchain down to v7.4.13 (illuminate v13 accepts it). Verified locally:

• composer mutation:ci → 419 mutants, 340 killed, Covered Code MSI 81% ≥ 75, exit 0.
• composer phpstan / composer test (90) / composer format:check / composer coverage:check (87.56%) all green.

Lifespan

Temporary. Remove or widen the constraint once Infection ships Symfony Console 8 support.

🤖 Generated with Claude Code

[Goosterhof]

No blockers, no concerns, one nit. This is a correctly-diagnosed, minimal dependency pin and the diagnosis checks out against the repo.

Verified the claims directly against origin/main:

• composer.lock is gitignored (/.gitignore carries /composer.lock), so CI does resolve fresh on every run — the "green yesterday, red today with no source change" failure mode is real, not hypothetical.
• The require block permits illuminate/* ^13, and Laravel 13 permits Symfony 8, so the fresh-resolve path to symfony/console v8.1.0 is the documented one.
• symfony/console is the only Symfony component pinned, which is the right call: the break is specifically Infection's DI container resolving Symfony\Component\Console\Helper\QuestionHelper as a service, and that's a symfony/console 8 change. Pinning the whole Symfony surface would be over-broad blast radius for a single-component break.

Praise

The CHANGELOG entry is load-bearing, not ceremonial — it captures the gitignored-lock mechanism, the illuminate v13 → Symfony 8 resolution path, the exact Unknown service failure signature, and an explicit removal trigger (Infection ships Symfony Console 8 support). Anyone hitting a confusing transitive-dep CI failure on a sibling Infection-gated repo can grep this and self-serve. That's the right place for incident provenance.

Nit

The pin's only removal reminder lives in the CHANGELOG. A pin keyed to an upstream fix tends to outlive its cause silently — the gate goes green and nobody revisits. Consider a short inline tracking marker (a one-line // symfony/console ^7: Infection 0.33 QuestionHelper break — widen when Infection supports Symfony Console 8 comment isn't possible in JSON, so a tracked issue or a deferred.md Resolve By is the practical equivalent). Not blocking — the CHANGELOG is honest about the temporary nature.

Verdict: approve-worthy. The fix is one line, the diagnosis is verified, and the constraint widening (^7.2 rather than =7.4.13) leaves room for 7.x patch uptake. Merge once CI confirms the mutation gate is green on this head.

[jasperboerhof]

Approved — reviewed, no blockers.