feat(local): one-shot deploy — local deploy alias + database by default when the push creates the site

[vikasiwp]

Problem

We already supported deploying a locally-built site to the cloud in one shot — but nobody could find it, and it shipped a half-empty site.

• instawp local push <name> with no cloud-site argument already provisions a cloud site (POST /sites, is_reserved: true) and pushes into it. Nothing in the command name or its description ("Push local wp-content to an InstaWP cloud site") said so.
• Worse, that auto-created site got files only. wp-content went up; the pages, posts and settings — which live in the database — did not. You landed on a live site that looked empty, and only then saw a hint suggesting --with-db.
• Meanwhile the command that sounds like the deploy path — migrate push [path], the "mirror" — cannot work on a local create site: it parses wp-config.php for DB_NAME/DB_USER/DB_HOST and exports via wp db export/mysqldump, but a Playground instance is SQLite (wp-content/database/.ht.sqlite) with no MySQL credentials. Users reaching for it hit a wall.

Change

• local deploy — a commander alias of local push. The discoverable verb for "make my local site live".
• A site-creating push now includes the database by default. Decided by a new pure helper shouldPushDb() (lib/local-instance.ts, unit-tested). Pushing into an existing site is unchanged — the DB stays opt-in behind --with-db, because it overwrites live data. New --no-db opts out of either.
• No overwrite prompt and no safety backup on a site we just created. The DB being replaced is the untouched WordPress default from seconds ago, so confirming the "overwrite" and wp db export-ing it are pure cost (the prompt also forced --json deploys to pass --force). Both guards stay fully in force for an existing site — threaded through as freshSite.
• Robustness: a missing local .ht.sqlite used to exit(1). Now that the DB push is the default, that would abandon a half-finished deploy — site created, files pushed, then a hard exit. An auto-included DB now degrades to files-only with a warning; an explicit --with-db still fails loud.
• Help text now states that local push creates the cloud site when no target is given, and points local create users at local deploy rather than migrate push.

Verification

• npm test — 492 passed (50 files), including 3 new shouldPushDb cases: the create-path default, the existing-site opt-in, and --no-db winning over both.
• Drove the changed dry-run branch end-to-end against an isolated config (fake token, scratch XDG_CONFIG_HOME, no network):
  • local deploy blog --dry-run → "The local database would be pushed to the new site and its URLs rewritten."
  • local push blog --dry-run --no-db → "Files only (--no-db) — the new site would keep its empty WordPress database."
  • --json → {"success":true,"dry_run":true,"would_create_site":"blog","would_push_db":true,...}
• Cross-model review (GLM-4.6) over the diff: no real defects; it prompted the .ht.sqlite half-deploy hardening above.
• Not yet exercised against a real cloud site. A live local deploy (create → rsync → SQLite→MySQL import → search-replace) is going to the QA agent.

Docs

The public docs at https://docs.instawp.com/cli/ describe the current behaviour and will need a matching revision (cli-local-development.md "Move work between local and cloud" + the typical-loop example; cli-command-reference.md). Tracked for docs-bot, held until this merges and v0.0.1-beta.33 is tagged.

Release

Version bumped to 0.0.1-beta.33 with a matching CHANGELOG heading, per this repo's tag-triggered release flow. Merging this publishes nothing — a human still pushes the v0.0.1-beta.33 tag.

Run /code-review ultra <PR#> before merge.

— Engineer (agent-os)

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.