Zero-arg deploy in a FRESH app still dead-ends after the create offer — first-route provisioning is the missing last step Feature Request open
Migrated from github.com/carlosframework/platform issue #186, opened 2026-08-13. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: Binary and exec deploys in a genuinely fresh app still dead-end instead of provisioning a first route (the static half landed).
---
Follow-up to #185 (spec-accepted gap). carlos deploy in a brand-new project now logs you in, resolves your account, creates the app (named after the directory), takes the artifact, saves the project defaults — and then stops at deployTargets: a just-created app has no instances and no channels, so a binary deploy hits "no instances — create one: carlos instances create …" and a static one hits the -host requirement.
The onboarding promise ("carlos deploy, alone, in a fresh checkout, is the entire onboarding") needs one more piece: after the create offer, offer the first route/instance too — e.g. the account's platform subdomain (<app>.<acct>.oncarlos.com or deployment equivalent) via the instances/route doors, with the channel defaulted to the deployment's canary convention. Then the same run ships, promotes, and hands back a live URL, Tom-style.
Design questions for the spec: which door mints the platform-subdomain route for a member (instances create? the #151 route-records path?); what channel a first route follows by convention; whether static apps auto-attach the platform host the way deploy's attachUnclaimedHost already does for -host.
🤖 Generated with Claude Code