deploy-capabilitylisted

# Creating the deploy surface so a release has somewhere to land Every deployment-adjacent skill reads a deploy surface; none of them creates one. `/guardrails-install` records only what it can observe, and `/release-promotion` with no recorded rules settles `NEEDS_INPUT` naming the recorder - which, on a greenfield product, observes nothing and sends the question straight back. The circle breaks only when someone creates the surface: a platform project, the repo connected to it, a domain answering, the environment config uploaded. That is a capability gap, not a missing line of code, and it fills the way `/browser-capability` fills a missing browser: compose what the host already wires, walk the operator through what only they can create, source a tool for the rest. One distinction runs first. `deploy-surface: none` is the correct record for a library or a CLI - a deliberate no, settled once. This skill is for the other case: a product that should deploy and has no surface yet. Unsure which this repo is? That is the operator's question, asked before anything is created - creating a surface nobody wanted is as wrong as recording `none` on a product that ships. Read `.better-dev/overrides.md` first. A repo may already pin its platform, forbid new infrastructure, or name the team that owns provisioning - honor that before any rung below. ## 1. Name the gap as an observable check Write the missing surface as the probe it has to pass: "the app answers 200 at a public URL," "