LPX-606: yolo deploy always builds; --app-version names the build

[stevethomas]

Hey, I made a thing! 🥳

LPX-606

What problems are you solving?

yolo deploy <env> now always builds, pushes, and deploys as one motion. The v1 rewrite in PR #26 had inadvertently dropped build-in-deploy, leaving the README's one-liner broken and forcing users to remember a separate yolo build step.

--app-version is now reframed as an input to the build — the tag to stamp on the fresh image:

• yolo deploy production — auto-generates a timestamp tag (26.21.2.1500), builds, pushes, deploys.
• yolo deploy production --app-version=v1.2.3 — uses v1.2.3 (e.g. a GitHub release name) as the build's tag, builds, pushes, deploys.

The alpha-era "skip build when --app-version is supplied" branch is gone. Deploying a pre-existing ECR tag is rollback's job, tracked separately as LPX-608. Folding rollback into deploy --app-version=<old-tag> muddied the mental model.

BuildCommand writes --app-version back onto the shared InputInterface before returning, so deploy's downstream steps pick up the tag via $this->option('app-version').

Also drops the Manifest::has('tasks.web') guard. The ExecutesWebStep interface + Manifest::isHeadless() already gates DNS steps for headless apps (the right axis). The dropped guard was catching a different scenario — "yolo.yml has no Fargate spec at all" — which is best left to surface as ServiceNotFoundException via the natural AWS error path. Consistent with the "let AWS errors bubble" stance.

Plus: closes a coverage gap in ExecutesWebStep. LPX-604 (#29) added headless-mode gating for solo DNS (SyncSoloRecordSetStep) but missed the multitenancy mirror. SyncMultitenancyRecordSetStep dereferences $this->config['apex'] and ['domain'] unconditionally, so a headless multitenant deploy would undefined-key-crash before reaching ECS. Adding implements ExecutesWebStep to the tenant step lets shouldBeRunning() skip it via the existing trait.

README's yolo init && yolo build && yolo sync production && yolo deploy production was nonsensical (yolo build errored on the missing env arg; explicit build was redundant). Updated to:

yolo init && yolo sync production && yolo deploy production

Is there anything the reviewer needs to know to deploy this?

• Every yolo deploy now triggers the full build pipeline (rsync → composer/npm → docker build → ECR push) before the deploy steps. ~2-5 min added depending on cache hits.
• CI workflows that previously ran yolo build and yolo deploy --app-version=<tag> as separate stages can now collapse to a single yolo deploy production --app-version=<release-tag> call. If the split is still wanted for any reason (e.g. preview before promotion), yolo build alone still works.
• Unit tests not added for the build-invocation path — goes through Command::execute() which runs registerAwsServices() and shouldBeRunning checks, hard to mock cleanly. Smoke-tested locally via the CL Fargate canary path.
• 119 pest, 0 phpstan, pint clean.

🤖 Generated with Claude Code