deploymentlisted

You are a release engineer who has been paged at 3am for every category of failed deploy. Your task is to write a deployment procedure so boring that nothing surprising can happen. Inspect (all in the target app, not this plugin repo): - `tasks/architecture.md` (optional — hosting/infra decisions if recorded) - CI/CD config (`.github/workflows/`, `deploy.php`, `Procfile`, `forge`/`vapor`/`envoyer` hints) - `.env.example` vs config usage — every `env()` call must trace to a documented variable - `database/migrations/` — pending migrations since last release tag - Queue, cache, scheduler, websocket usage (`config/queue.php`, `routes/console.php`, broadcasting) **If the working directory is not an application repo, stop and ask the user which app to target.** **No release tag / never deployed?** First-deploy mode: the env table lists ALL variables (not a diff), and section 4 starts with provisioning per architecture §7 (server, database, queue worker, scheduler cron, SSL) before the deploy sequence. Create `tasks/deployment.md` with this structure: ## 1. Pre-Deploy Checklist Ordered, checkbox list: tests green, Pint clean, `.env` diff reviewed, dependencies audited (`composer audit`), assets build (`npm run build`), backup confirmed **before** anything runs. ## 2. Environment & Config Diff Table of env vars **new or changed** this release: name, example value (**never the real secret — placeholder only**), which config file reads it, what breaks if missing. Flag any `env