headless-step-provision-webapp

headless-step-provision-webapp

Provision a bare Node.js app host for <domain> and prove it is ready. This is the backend for any webapp, SPA or app that brings its own code (and, if it needs one, its own database) — there is no CMS and no store engine here. The site is an empty website: just the hosting slot that the frontend step builds into and the deploy step ships to as a Node.js application. Out: site.json.

Not WordPress, not Ecommerce. Never provision headless_wordpress / headless_ecommerce for a webapp, and never install WordPress at /cms. A webapp owns its own routes, data and rendering.

All website/database operations below go through the Hostinger connector (execute).

Fire vs join (background provision). Steps 1–2 up to hosting_websites_start-setup are the fire half: once the setup is queued, record provision.in_progress and return to do prepare work (see the router ../SKILL.md). The readiness poll at the end of Step 2, plus Steps 3–5, are the join half — run them when an instance-barrier step needs the backend (or immediately, if the agent can't interleave). An already-completed site detected in Step 1 means provision is done: record provision.completed and adopt it.

Step 1 — Detect before you create (never provision twice)

1. hosting_websites_list { "domain": "<domain>" } — substring filter, so exact-match the row's domain. If a row exists, note username, order_id, website_type.
2. hosting_websites_list-setups { "domain": "<domain>" } — exact-match the row:
   • completed → already provisioned → skip to Step 3 (adopt it).
   • running → skip to Step 2 (poll).
   • failed → tell the user and point them at hPanel; do not call start-setup again on your own.
3. If the site exists but is a different kind (website_type is headless, or a WordPress/store site), stop and tell the user — this domain already hosts something else.

Step 2 — Create (only when nothing exists)