ADR 0007: Do not adopt Consolidation Robo on Symfony 8
- Status: accepted
- Date: 2026-08-21
Context
K0smos uses Composer scripts for package-level QA/install entry points, Symfony Console for application/operator commands, and small checked-in shell/Node/PHP scripts for container and frontend orchestration. P8 requested a Robo task-runner evaluation.
The repository currently has 24 Composer script entries, 34 attributed k0smos
Symfony commands, six bin/ entry files, and 11 script/tool files. The newly
shared local bootstrap is the representative multi-step workflow: Composer
install, runtime validation, guarded local migration, HTTP/queue smoke, and
optional isolated tests.
A clean temporary Composer dry-run required Robo 5.1.1 together with
Symfony Console/EventDispatcher/Filesystem/Process 8.0. Resolution failed
because Robo requires those Symfony components at ^6 || ^7.
Decision
Do not adopt Robo now.
The package cannot coexist with the root Symfony 8 constraints without downgrading the application or using unsupported aliases. Even if compatibility were forced, the representative bootstrap is already one idempotent script shared by Docker, DDEV, and Lando; wrapping it in a Robo task would add a second command vocabulary without removing shell logic or application commands.
Application/domain commands stay in Symfony Console. Package lifecycle and QA aliases stay in Composer. Bounded container/frontend orchestration stays in the appropriate checked-in script language.
Re-evaluation trigger
Re-open only when a stable Robo release explicitly supports every Symfony major used by the root package and at least one measured workflow needs dependency- aware parallel task composition, reusable remote execution, or another Robo capability that cannot be expressed cleanly by Composer plus Symfony Console. Any future pilot is tooling-only; it must replace an existing orchestration surface and must not move application/domain behavior out of Symfony commands.
Evidence
See doc/public/en/architecture/evaluations/robo.md.