@awesomate/hosting-mcp 0.11.0 → 0.12.0

package/dist/index.js

@@ -40114,9 +40114,9 @@ readTool(
 var PLAN_LADDER_FALLBACK = {
   note: "Live per-account limits come from awesomate_get_limits \u2014 this is the plan ladder reference (static fallback).",
   plans: [
-    { name: "Essentials", purchasable: false, monthlyPriceUsd: 75, maxSites: 1, maxCustomDomains: 0, maxApps: 0, cpanelAccess: true, shellAccess: false, appBuilder: false },
-    { name: "Support Plus", purchasable: true, monthlyPriceUsd: 175, maxSites: 2, maxCustomDomains: 3, maxApps: 5, cpanelAccess: true, shellAccess: true, appBuilder: true },
-    { name: "Pro", purchasable: true, monthlyPriceUsd: 375, maxSites: 10, maxCustomDomains: 10, maxApps: 20, cpanelAccess: true, shellAccess: true, appBuilder: true },
+    { name: "Essentials", purchasable: false, monthlyPriceUsd: 75, maxSites: 1, maxCustomDomains: 1, maxApps: 0, cpanelAccess: true, shellAccess: false, appBuilder: false },
+    { name: "Support Plus", purchasable: true, monthlyPriceUsd: 175, maxSites: 2, maxCustomDomains: 5, maxApps: 5, cpanelAccess: true, shellAccess: true, appBuilder: true },
+    { name: "Pro", purchasable: true, monthlyPriceUsd: 375, maxSites: 10, maxCustomDomains: 20, maxApps: 20, cpanelAccess: true, shellAccess: true, appBuilder: true },
     { name: "Embedded", purchasable: false, monthlyPriceUsd: null, maxSites: 100, maxCustomDomains: 100, maxApps: 100, cpanelAccess: true, shellAccess: true, appBuilder: true, note: "Not generally available yet" }
   ],
   upgradePath: "Essentials \u2192 Support Plus \u2192 Pro \u2192 Embedded; upgrades at hub.awesomate.ai/billing (only Support Plus and Pro are purchasable)"
@@ -40147,7 +40147,7 @@ server.registerTool(
   {
     description: "Snapshot a WordPress site (files + database) BEFORE any risky change \u2014 an AI edit, a deploy, a plugin/theme/core update. Returns a snapshotId you can roll back to. ALWAYS snapshot before mutating a live site. Requires shell access (Support Plus+).",
     inputSchema: {
-      domain: external_exports.string().describe("The site domain (as shown by awesomate_list_sites), e.g. mysite.awesomate.io"),
+      domain: external_exports.string().describe("The site domain (as shown by awesomate_list_sites), e.g. mysite.awesomate.site"),
       reason: external_exports.string().optional().describe('Why (stored in the snapshot list), e.g. "before deploy"')
     }
   },
@@ -40194,6 +40194,60 @@ server.registerTool(
     }
   }
 );
+server.registerTool(
+  "awesomate_site_staging_create",
+  {
+    description: "Create a staging copy of a WordPress site on the client's private awesomate.dev address (files + database cloned, URLs rewritten). Use this BEFORE making user-facing changes so the user can review at the staging URL first \u2014 post to dev, review, then awesomate_site_staging_promote. The staging site is hidden from search engines and AI crawlers by policy; anyone with the link can view it. One staging copy per site \u2014 a 409 with code 'staging_exists' means promote or discard the existing one first. Cloning can take a few minutes on large sites. Requires shell access (Support Plus+).",
+    inputSchema: {
+      domain: external_exports.string().describe("The LIVE site domain (as shown by awesomate_list_sites), e.g. mysite.awesomate.site")
+    }
+  },
+  async ({ domain }) => {
+    try {
+      return textResult(
+        await hubPost(requireConfig(), `/api/hosting-access/sites/${encodeURIComponent(domain)}/staging`, {})
+      );
+    } catch (err) {
+      return errorResult(err);
+    }
+  }
+);
+server.registerTool(
+  "awesomate_site_staging_promote",
+  {
+    description: "Publish the staging copy to the LIVE site (overwrites live files + database with staging). The live site is auto-snapshotted first \u2014 the result includes preSnapshotId, which awesomate_rollback_site can restore if anything looks wrong. **Confirm with the user before promoting \u2014 it replaces the live site.** Requires shell access (Support Plus+).",
+    inputSchema: {
+      domain: external_exports.string().describe("The LIVE site domain whose staging copy should go live")
+    }
+  },
+  async ({ domain }) => {
+    try {
+      return textResult(
+        await hubPost(requireConfig(), `/api/hosting-access/sites/${encodeURIComponent(domain)}/staging/promote`, {})
+      );
+    } catch (err) {
+      return errorResult(err);
+    }
+  }
+);
+server.registerTool(
+  "awesomate_site_staging_discard",
+  {
+    description: "Delete the staging copy of a site (staging WP install + its awesomate.dev address; the live site is untouched). **Confirm with the user before discarding \u2014 unpromoted staging changes are lost.** Requires shell access (Support Plus+).",
+    inputSchema: {
+      domain: external_exports.string().describe("The LIVE site domain whose staging copy should be discarded")
+    }
+  },
+  async ({ domain }) => {
+    try {
+      return textResult(
+        await hubDelete(requireConfig(), `/api/hosting-access/sites/${encodeURIComponent(domain)}/staging`)
+      );
+    } catch (err) {
+      return errorResult(err);
+    }
+  }
+);
 readTool(
   "awesomate_app_context",
   "Call FIRST before any app-builder work. Returns the connected account's plan, whether the app builder is unlocked (capability.appBuilder \u2014 Support Plus+), whether they have a cPanel hosting account yet, their existing apps, firstRun, and capability-aware next-step suggestions to offer the user. If appBuilder is false, relay the upgrade suggestion rather than attempting to build.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awesomate/hosting-mcp",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "description": "Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases",
   "license": "UNLICENSED",
   "type": "module",

package/skill/awesomate-app-builder/SKILL.md

@@ -87,12 +87,22 @@ target; never touch prod without an explicit ask.**
    [references/node-recipes.md](references/node-recipes.md) has the recipes
    (add a table/endpoint, env vars, connection strings, promote/rollback).
    Handle **secrets** only via the **awesomate-credentials** skill
-   (encrypted + injected, never committed/echoed). Wire **version control**
-   from the first commit via **awesomate-github**. If it needs email/lookup/AI,
-   attach n8n (§"when to use n8n").
-6. **Testing** — deploy to **dev** (`git push` to `dev`), then
-   `awesomate_app_health` to confirm it came up (Node: `/api/ready`). Show the
-   user the live dev URL and let them try it. Iterate on dev until they're happy.
+   (encrypted + injected, never committed/echoed). **Version control is not
+   optional**: as soon as the scaffold exists, run the awesomate-github setup
+   (repo + first commit + push-to-deploy) — ask only the project name and
+   private-y/n, in plain words ("I'll back your work up as we go"). From then
+   on, **auto-checkpoint**: commit after every working change with a message
+   you write, and run the github skill's `vc-healthcheck.mjs` at session start
+   and before every deploy. If it needs email/lookup/AI, attach n8n (§"when to
+   use n8n").
+6. **Testing — always ask "live or dev?" before posting anything.** When the
+   user asks to publish/change something user-facing, ask: *"Want this on your
+   live site, or on your dev site (awesomate.dev) to review and test first?"*
+   Recommend dev. Deploy to **dev** (`git push` to `dev` — the dev site lives
+   at `{app}.{slug}.awesomate.dev`, hidden from search engines and AI crawlers
+   by policy), then `awesomate_app_health` to confirm it came up (Node:
+   `/api/ready`). Show the user the live dev URL and let them try it. Iterate
+   on dev until they're happy.
 7. **Wrap-up / promote** — only when the user approves, promote **dev → staging
    → main** (merge + push per branch). `awesomate_app_deploy` reports the
    branch→env map + last-deploy state. Prod is `main`. **Before merging to
@@ -113,7 +123,11 @@ files directly (no build step).
 - Non-technical user: explain in plain words, one or two short questions at a
   time, no unexplained jargon. Recommend; don't quiz them on architecture.
 - Confirm the stack + name before `awesomate_app_create`. Default the target
-  to **dev**; never push to prod without an explicit ask.
+  to **dev**; never push to prod without an explicit ask — and when they ask
+  to "post"/"publish" something, ask **"live or dev?"** first.
+- You are the user's version-control expert (they don't know what a repo is):
+  set up GitHub right after the first build, auto-commit as you go, and run
+  the github skill's vc-healthcheck at session start + before deploys.
 - A `403` on a write = plan gate (Support Plus+). Offer an upgrade, don't retry.
 - A `409` with code `app_limit` = the plan's app allowance is full (Support
   Plus 5, Pro 20 — `awesomate_app_context.limits` has the live numbers).

package/skill/awesomate-github/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: awesomate-github
-description: Set up GitHub version control for the user's app with zero Git knowledge required — connect their GitHub once, then create the repo, .gitignore, first commit and push-to-deploy for them. Use when the user says "connect GitHub", "back up my app", "save my work", "set up version control", "put this on GitHub", or after building an app when it should be version-controlled. Companion to awesomate-app-builder.
+description: Set up GitHub version control for the user's app with zero Git knowledge required — connect their GitHub once, then create the repo, .gitignore, first commit and push-to-deploy for them. Use when the user says "connect GitHub", "back up my app", "save my work", "set up version control", "put this on GitHub", or after building an app when it should be version-controlled — and proactively: run its vc-healthcheck at session start and before deploys to keep commits/pushes/deploys healthy for users who do not know Git. Companion to awesomate-app-builder.
 ---
 
 # Awesomate GitHub — version control for people who don't know Git
@@ -62,6 +62,32 @@ Explain it as *"save your work = it goes live"* — don't lecture on branches.
 - "Put it live" → push to the right branch (dev/staging/main) and tell them the URL.
 - Always write clear commit messages **for** them; don't ask them to.
 
+## 4. Be the version-control guardian (proactive, not reactive)
+
+The user is ~99% likely to have no idea what a repo is. YOU own their version
+control — they should never have to think about it:
+
+- **Health check at session start.** Before touching an app folder, run:
+  ```
+  node ~/.claude/skills/awesomate-github/scripts/vc-healthcheck.mjs <project-dir>
+  ```
+  It prints JSON (`problems[]`: `no_repo`, `no_remote`, `uncommitted_changes`,
+  `unpushed_commits`, `env_file_tracked`, `last_deploy_failed`, …). Fix what
+  you can silently (commit + push loose work with a message you write); for
+  `no_repo`/`no_remote`, offer setup (§1) in plain words: *"your last changes
+  aren't backed up anywhere — want me to set that up? Takes a minute."*
+  `env_file_tracked` is urgent: untrack it, .gitignore it, and route the
+  secrets through awesomate-credentials.
+- **Auto-checkpoint.** After every meaningful working change (feature works,
+  bug fixed, content updated), commit with a plain-English message — don't
+  wait for "save my work", and never ask them to write a message. Push at
+  natural pauses so their backup is never behind.
+- **Health check before every deploy/publish.** Re-run the script; never push
+  to a deploy branch with a failing prior run you haven't explained.
+- **Report in their language.** "Your work is backed up" / "your last 3
+  changes were never saved — I've saved them now" — never "you're 2 commits
+  ahead of origin/main".
+
 ## Hard rules
 - Never commit a secret or a `.env`. The script's secret guard is a backstop,
   not a licence to skip checking. If you spot a secret, route it through the

package/skill/awesomate-github/scripts/vc-healthcheck.mjs

@@ -0,0 +1,102 @@
+#!/usr/bin/env node
+/**
+ * Version-control health check for an Awesomate app folder.
+ *
+ * Run from (or pass) the project directory. Prints a JSON report Claude uses
+ * to keep the user's version control healthy WITHOUT them knowing Git:
+ *   - repo/remote wiring, uncommitted + unpushed work
+ *   - branch → deploy-env mapping (dev → awesomate.dev, main → live)
+ *   - last GitHub Actions deploy run (when `gh` is authed)
+ *
+ * Exit code 0 always (reporting tool, not a gate) — Claude decides what to
+ * fix based on the JSON.
+ */
+import { execSync } from 'node:child_process';
+import { existsSync } from 'node:fs';
+import { resolve } from 'node:path';
+
+const dir = resolve(process.argv[2] ?? '.');
+const report = {
+  dir,
+  gitInstalled: false,
+  repoInitialized: false,
+  remote: null,
+  branch: null,
+  uncommittedFiles: 0,
+  unpushedCommits: null, // null = unknown (no upstream)
+  hasUpstream: false,
+  envTracked: false,
+  ghAuthed: false,
+  lastDeployRun: null,
+  problems: [],
+};
+
+function sh(cmd) {
+  return execSync(cmd, { cwd: dir, stdio: ['ignore', 'pipe', 'pipe'], timeout: 15_000 })
+    .toString()
+    .trim();
+}
+function trySh(cmd) {
+  try {
+    return sh(cmd);
+  } catch {
+    return null;
+  }
+}
+
+if (trySh('git --version') === null) {
+  report.problems.push('git_not_installed');
+} else {
+  report.gitInstalled = true;
+  report.repoInitialized = trySh('git rev-parse --is-inside-work-tree') === 'true';
+  if (!report.repoInitialized) {
+    report.problems.push('no_repo');
+  } else {
+    report.branch = trySh('git branch --show-current') || '(detached)';
+    report.remote = trySh('git remote get-url origin');
+    if (!report.remote) report.problems.push('no_remote');
+
+    const status = trySh('git status --porcelain') ?? '';
+    report.uncommittedFiles = status ? status.split('\n').length : 0;
+    if (report.uncommittedFiles > 0) report.problems.push('uncommitted_changes');
+
+    // .env must never be tracked — the single most dangerous drift.
+    const tracked = trySh('git ls-files .env */.env') ?? '';
+    report.envTracked = tracked.length > 0;
+    if (report.envTracked) report.problems.push('env_file_tracked');
+
+    const upstream = trySh('git rev-parse --abbrev-ref @{upstream}');
+    report.hasUpstream = !!upstream;
+    if (upstream) {
+      const ahead = trySh('git rev-list --count @{upstream}..HEAD');
+      report.unpushedCommits = ahead === null ? null : Number(ahead);
+      if (report.unpushedCommits > 0) report.problems.push('unpushed_commits');
+    } else if (report.remote) {
+      report.problems.push('branch_not_pushed');
+    }
+
+    if (report.remote && trySh('gh auth status') !== null) {
+      report.ghAuthed = true;
+      const runs = trySh(
+        'gh run list --limit 1 --json displayTitle,conclusion,headBranch,updatedAt',
+      );
+      try {
+        const parsed = JSON.parse(runs ?? '[]');
+        if (parsed[0]) {
+          report.lastDeployRun = parsed[0];
+          if (parsed[0].conclusion && parsed[0].conclusion !== 'success') {
+            report.problems.push('last_deploy_failed');
+          }
+        }
+      } catch {
+        /* no runs / not parseable — fine */
+      }
+    }
+  }
+}
+
+if (!existsSync(resolve(dir, '.gitignore')) && report.repoInitialized) {
+  report.problems.push('no_gitignore');
+}
+
+console.log(JSON.stringify(report, null, 2));

package/skill/awesomate-hosting/SKILL.md

@@ -3,7 +3,7 @@ name: awesomate-hosting
 description: >
   Manage, build, and grow your Awesomate WordPress hosting from Claude. Use when
   the user mentions their Awesomate site or hosting, cPanel, a site on
-  *.awesomate.io or a custom domain hosted with Awesomate, WordPress admin,
+  *.awesomate.site (or legacy *.site.awesomate.io) or a custom domain hosted with Awesomate, WordPress admin,
   installing a plugin/theme, running WP-CLI, "my site is slow / out of space /
   broke", snapshotting or rolling back a site, deploying from a local WordPress
   Studio site to live, checking hosting stats or how close they are to a plan
@@ -11,7 +11,9 @@ description: >
   plan. Trigger phrases: "my awesomate site", "connect my hosting", "spin up a
   wordpress site", "install wordpress", "add my domain", "why is my site slow",
   "am I near my limit", "snapshot my site", "roll back my site", "deploy to
-  live", "run wp-cli", "upgrade my plan", "how many sites can I have".
+  live", "run wp-cli", "upgrade my plan", "how many sites can I have",
+  "create a staging site", "test changes before going live", "publish staging",
+  "post this to my dev site".
 ---
 
 # Awesomate Hosting
@@ -170,25 +172,34 @@ Allowed: `awesomate_get_context`, `_get_hosting_status`, `_get_hosting_account`,
 `_get_hosting_stats`, `_get_grafana_url`, `_get_credit_balance`, the billing
 preview/deep-link tools, and 1-click WP-admin / cPanel SSO links.
 
-Never attempt SSH, WP-CLI, snapshot/rollback, deploy, multi-site, or custom
-domains — those tools will 403. Instead, surface the specific limit and what
+Never attempt SSH, WP-CLI, snapshot/rollback, staging, deploy, multi-site —
+those tools will 403. Instead, surface the specific limit and what
 Support Plus/Pro unlocks (see §4), and offer to preview the upgrade.
 
 ### Support Plus and above (shell) — full workflow
 
 You additionally have: jailed SSH to the client's own cPanel account, WP-CLI
 (`awesomate_run_wp_cli` or raw SSH via `scripts/ssh-connect.sh`),
-snapshot/rollback, and the local-first deploy flow (§5). Golden rule, always:
+snapshot/rollback, **WP staging on awesomate.dev** (§5a), and the local-first
+deploy flow (§5). Golden rule, always:
 
 > **Local first, live never — and snapshot before you touch live.**
 
+**Ask "live or dev?" before posting anything user-facing.** When the user asks
+you to change/publish something on their WordPress site, ask: *"Want me to put
+this on your live site, or on your private dev copy (awesomate.dev) so you can
+review it first?"* Default suggestion: dev first, publish after they've looked
+at it. Their dev copy is invisible to Google and AI crawlers by policy.
+
 ## 3. Safety rules (non-negotiable)
 
 - **Before ANY change to a live site** — plugin/theme/core update, `search-replace`,
   bulk edit, deploy — call **`awesomate_snapshot_site`** first and tell the user the
   `snapshotId`. If it goes wrong, `awesomate_rollback_site` restores files + DB.
 - **Confirm before destructive actions**: `awesomate_uninstall_site`,
-  `awesomate_rollback_site`, dropping tables, `wp db reset`, deleting content.
+  `awesomate_rollback_site`, `awesomate_site_staging_promote` (replaces live),
+  `awesomate_site_staging_discard` (loses unpublished staging work), dropping
+  tables, `wp db reset`, deleting content.
   State exactly what will be lost and wait for an explicit "yes".
 - Prefer building/testing in **WordPress Studio locally**, then deploy (§5).
 - Dry-run risky WP-CLI where the command supports it before the real run.
@@ -214,8 +225,8 @@ one command — `scripts/deploy.sh`, which **snapshots live first** (so a bad
 deploy is one rollback away), pushes files, then optionally the DB:
 
 ```
-scripts/deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.io          # files only
-scripts/deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.io --with-db # + database
+scripts/deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.site          # files only
+scripts/deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.site --with-db # + database
 ```
 
 - **Always files-first is the safe default.** `--with-db` also exports the
@@ -230,6 +241,26 @@ scripts/deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.io --with-db
 Never deploy without confirming with the user first, and always report the
 snapshot id and the verified live status.
 
+## 5a. Staging on awesomate.dev (Support Plus+)
+
+The middle tier between "edit live" and "local Studio": a private full copy of
+the site at `{name}.{slug}.awesomate.dev`, noindexed at the edge (no Google, no
+AI crawlers — anyone with the link can view, perfect for client review).
+
+- `awesomate_site_staging_create <live domain>` — clones files + DB, rewrites
+  URLs. One staging copy per site (409 `staging_exists` → promote or discard
+  first). Takes a few minutes on large sites.
+- Make the changes ON the staging domain (WP-CLI / wp-admin / deploy.sh with
+  `--domain <staging domain>`), send the user the staging URL to review.
+- `awesomate_site_staging_promote <live domain>` — publishes staging over live.
+  Live is auto-snapshotted first; report the returned `preSnapshotId` as the
+  undo handle (`awesomate_rollback_site`). **Confirm before promoting.**
+- `awesomate_site_staging_discard <live domain>` — deletes the staging copy;
+  live untouched. **Confirm — unpublished staging changes are lost.**
+
+Prefer this flow over editing live whenever the change is user-visible
+(theme/layout/content restructures, plugin experiments, redesigns).
+
 ## 6. Version control with GitHub (optional)
 
 Awesomate's snapshots are your safety net, so Git isn't required — but for real

package/skill/awesomate-hosting/scripts/deploy.sh

@@ -4,7 +4,7 @@
 # Awesomate site. SNAPSHOTS LIVE FIRST via the hub (so a bad deploy is one
 # rollback away), then pushes files, then optionally the database.
 #
-#   deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.io [options]
+#   deploy.sh --from ~/Studio/mysite --domain mysite.awesomate.site [options]
 #
 # Options:
 #   --docroot PATH     Live docroot (default: /home/<cpanel-user>/public_html)

package/skill/awesomate-hosting/scripts/pull-live.sh

@@ -4,7 +4,7 @@
 # from an existing live site). Read-only against live — it never changes the
 # live site. Copies files + exports the live DB.
 #
-#   pull-live.sh --domain mysite.awesomate.io --to ~/Studio/mysite [--docroot PATH]
+#   pull-live.sh --domain mysite.awesomate.site --to ~/Studio/mysite [--docroot PATH]
 #
 # Then import the files into a new WordPress Studio site and load db.sql.
 # Client-side deps: bash, ssh, rsync, scp.