@awesomate/hosting-mcp 0.9.0 → 0.11.0

package/dist/index.js

@@ -40108,25 +40108,39 @@ readTool(
 );
 readTool(
   "awesomate_get_limits",
-  "Usage vs plan limits across every dimension (sites, custom domains, workflow credits, AI-editor credits) plus a nudges[] array. Call BEFORE any create action; when a nudge has severity 'approaching' or 'exceeded', surface it to the user with the recommended plan \u2014 never execute an upgrade without preview + explicit confirmation (upgrade tools ship in a later release; for now deep-link to the hub billing page).",
+  "Usage vs plan limits across every dimension (sites, custom domains, apps, database provisions today, workflow credits, AI-editor credits) plus a nudges[] array. Call BEFORE any create action; when a nudge has severity 'approaching' or 'exceeded', surface it to the user with the recommended plan \u2014 never execute an upgrade without preview + explicit confirmation (upgrade tools ship in a later release; for now deep-link to the hub billing page). pgProvisionsToday is a flat daily cap that resets within 24h \u2014 no plan raises it, so don't pitch an upgrade for it.",
   "/api/client-hosting/limits"
 );
+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: "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)"
+};
 server.registerTool(
   "awesomate_get_plan_features",
   {
-    description: "Static reference: what each Awesomate plan includes for hosting (sites, custom domains, cPanel, shell/Claude Code access) and monthly pricing. Use to explain what an upgrade unlocks.",
+    description: "The Awesomate plan ladder: what each plan includes for hosting (WordPress sites, custom domains, hosted apps, cPanel, shell/Claude Code access) and which plans are purchasable. Fetched live from the hub (single source of truth) with a static fallback. Use to explain what an upgrade unlocks; live per-account usage comes from awesomate_get_limits.",
     inputSchema: {}
   },
-  async () => textResult({
-    note: "Live per-account limits come from awesomate_get_limits \u2014 this is the plan ladder reference.",
-    plans: [
-      { name: "Essentials", monthlyPriceUsd: 75, maxSites: 1, maxCustomDomains: 0, cpanelAccess: true, shellAccess: false },
-      { name: "Support Plus", monthlyPriceUsd: 175, maxSites: 1, maxCustomDomains: 1, cpanelAccess: true, shellAccess: true },
-      { name: "Pro", monthlyPriceUsd: 375, maxSites: 3, maxCustomDomains: 3, cpanelAccess: true, shellAccess: true },
-      { name: "Embedded", monthlyPriceUsd: null, maxSites: null, maxCustomDomains: null, cpanelAccess: true, shellAccess: true, note: "Unlimited sites/domains; not generally available yet" }
-    ],
-    upgradePath: "Essentials \u2192 Support Plus \u2192 Pro \u2192 Embedded; upgrades at hub.awesomate.ai/billing"
-  })
+  async () => {
+    try {
+      const live = await hubGet(requireConfig(), "/api/client-hosting/plan-ladder");
+      if (Array.isArray(live?.plans) && live.plans.length > 0) {
+        return textResult({
+          note: "Live plan ladder from the hub. Per-account usage comes from awesomate_get_limits.",
+          ...live,
+          upgradePath: PLAN_LADDER_FALLBACK.upgradePath
+        });
+      }
+    } catch {
+    }
+    return textResult(PLAN_LADDER_FALLBACK);
+  }
 );
 server.registerTool(
   "awesomate_snapshot_site",
@@ -40207,7 +40221,7 @@ server.registerTool(
 server.registerTool(
   "awesomate_app_create",
   {
-    description: "Provision a new app on the client's cPanel account. Choose the stack deliberately (see the awesomate-app-builder skill): kind 'static' = a single fast landing/lead page served straight from the docroot (no DB, no server process \u2014 pick this for brochure/landing/lead-capture); kind 'node' = a dynamic app with a backend + database (logins, custom logic, an API). Pick the template by job \u2014 'node-auth-sync' (user accounts/logins, MySQL), 'node-crud-postgres' (structured data without logins: trackers/dashboards \u2014 ready-made CRUD + UI, Postgres), 'node-api-only' (webhooks/integrations/glue, no DB wiring), 'static-landing' (marketing/lead page). If dbEngine is omitted the template's native engine is used (node-crud-postgres \u2192 postgres). Returns 202 immediately with an appId + subdomain(s); poll awesomate_app_get until status=active, then fetch the starter files with awesomate_app_scaffold. Requires apps:write (Support Plus+) \u2014 a 403 means offer an upgrade. Get the user's confirmation on the stack + name before calling.",
+    description: "Provision a new app on the client's cPanel account. Choose the stack deliberately (see the awesomate-app-builder skill): kind 'static' = a single fast landing/lead page served straight from the docroot (no DB, no server process \u2014 pick this for brochure/landing/lead-capture); kind 'node' = a dynamic app with a backend + database (logins, custom logic, an API). Pick the template by job \u2014 'node-auth-sync' (user accounts/logins, MySQL), 'node-crud-postgres' (structured data without logins: trackers/dashboards \u2014 ready-made CRUD + UI, Postgres), 'node-api-only' (webhooks/integrations/glue, no DB wiring), 'static-landing' (marketing/lead page). If dbEngine is omitted the template's native engine is used (node-crud-postgres \u2192 postgres). Returns 202 immediately with an appId + subdomain(s); poll awesomate_app_get until status=active, then fetch the starter files with awesomate_app_scaffold. Requires apps:write (Support Plus+) \u2014 a 403 means offer an upgrade. Plans also cap the NUMBER of apps (Support Plus 5, Pro 20 \u2014 check awesomate_get_limits.dimensions.apps first): a 409 with code 'app_limit' means the cap is reached \u2014 do NOT retry; tell the user their allowance is full and surface the recommendedPlan/deepLink from the error. Get the user's confirmation on the stack + name before calling.",
     inputSchema: {
       appSlug: external_exports.string().regex(/^[a-z][a-z0-9]{1,15}$/).describe("2-16 chars, starts with a letter, lowercase alphanumeric \u2014 used for subdomains + db names"),
       kind: external_exports.enum(["node", "static"]).default("node").describe("'static' for a landing/lead page (no DB); 'node' for a dynamic app"),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awesomate/hosting-mcp",
-  "version": "0.9.0",
+  "version": "0.11.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

@@ -95,7 +95,12 @@ target; never touch prod without an explicit ask.**
    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`.
+   branch→env map + last-deploy state. Prod is `main`. **Before merging to
+   main**, walk [references/security-checklist.md](references/security-checklist.md)
+   — the deploy workflow's automated gate blocks prod on high-severity
+   findings (secrets, injectable SQL, eval…), and the checklist covers what
+   a scanner can't (authorization, webhook secrets, data minimization).
+   Never remove the gate step to make a deploy pass — fix the finding.
 
 **Promote / rollback (git-based):** promoting is merging the tested branch
 forward (`dev`→`staging`→`main`); rolling back is `git revert` of the bad
@@ -110,6 +115,10 @@ files directly (no build step).
 - Confirm the stack + name before `awesomate_app_create`. Default the target
   to **dev**; never push to prod without an explicit ask.
 - 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).
+  Don't retry; tell the user and surface the `recommendedPlan`/`deepLink`
+  from the error. Deleting an unused app also frees a slot.
 - Never invent that a capability exists — read `awesomate_app_context` first.
 - Never print a secret or commit a `.env` (the credentials + github skills
   enforce this).

package/skill/awesomate-app-builder/references/security-checklist.md

@@ -0,0 +1,57 @@
+# Security checklist — walk this before promoting to prod
+
+Two layers guard prod. The **automated gate** runs in every app's deploy
+workflow (`scripts/security-check.mjs` — report-only on dev/staging,
+BLOCKING on `main`, plus `npm audit --audit-level=critical`). This checklist
+is the **human layer**: the things a scanner cannot see. Walk it with the
+user in plain language before merging staging → main.
+
+## What the automated gate already catches (don't re-litigate)
+
+Committed secrets / a tracked `.env` / private keys · SQL built by
+interpolation or concatenation · `eval` / `new Function` · shell exec with
+interpolated input · critical dependency advisories. If the prod deploy
+fails on the gate, read the Actions log — every finding prints its fix.
+**Never remove or bypass the gate step to make a deploy pass.**
+
+## The human checks (scanner-blind spots)
+
+1. **Authorization, not just authentication.** Logged-in is not allowed.
+   For every route that reads/writes data: could user A pass user B's id and
+   touch B's data? Filter by the session's user id server-side, never trust
+   an id from the request body.
+2. **Every input validated at the edge.** Each POST/PATCH handler starts
+   with a zod `safeParse`, with sane max lengths. No handler touches
+   `await c.req.json()` raw.
+3. **Secrets flow one way.** Values live in env vars (set via
+   `awesomate_app_set_env`), are never logged, never echoed in responses,
+   never sent to the browser.
+4. **Rendering is escape-safe.** Browser code uses `textContent` /
+   `createElement` for user data; server HTML never string-interpolates
+   user input without escaping.
+5. **The n8n webhook is not world-callable.** If n8n is attached, the
+   workflow checks the `X-Awesomate-Webhook-Secret` header (set during
+   attach). Test: call the webhook without the header — it must refuse.
+6. **Public API surface is intentional.** api-only starter: is `API_KEY`
+   set for prod, or is a public API genuinely intended? CORS open on
+   purpose?
+7. **Sensitive data is minimized.** Only collect what the app needs; if it
+   stores personal data, tell the user plainly: connections are TLS and
+   secrets are encrypted, but the DATABASE is not blanket-encrypted at
+   rest — sensitive fields deserve app-level encryption (ask before adding).
+8. **Errors don't leak.** 500 responses return a generic message, not stack
+   traces or SQL (the starters already do this — keep it).
+
+## Static sites
+
+No server code, so the gate doesn't run — the risks are the lead form's
+webhook (point 5) and third-party scripts (don't add any that aren't
+needed). Never put an API key in page JavaScript: anything in a static page
+is public.
+
+## How to talk about it
+
+Non-technical user — say what you checked, not the jargon: *"Before making
+it live I checked that people can only see their own data, that the contact
+form can't be abused, and that your API key never appears anywhere public.
+The deploy pipeline also scans every release automatically."*

package/skill/awesomate-app-builder/references/stack-decision.md

@@ -8,7 +8,7 @@ confirm before building. **Never default to WordPress.**
 
 | What the user is really trying to do | Stack | Why / how |
 |---|---|---|
-| "I already have a WordPress site" / a blog / publishes content regularly / **wants to rank on Google & AI** | **WordPress** | Best CMS for indexable content, sitemaps, schema. Hand to the awesomate-hosting skill to provision, then run **awesomate-seo**. |
+| "I already have a WordPress site" / a blog / publishes content regularly / **wants to rank on Google & AI** | **WordPress** | Best CMS for indexable content, sitemaps, schema. Hand to the awesomate-hosting skill to provision, then run **awesomate-seo**. Existing WP elsewhere → migrate it, don't rebuild: [wp-migrate.md](wp-migrate.md) (also covers WP ↔ app coexistence on subdomains). |
 | Sell products / online shop | **WordPress + WooCommerce** | Reuse the `woo-agent-storefront` (AI-shopping feeds + `llms.txt`) and `woo-catalog-perfection` skills. |
 | A landing page / capture leads / a one-pager / "just needs to look good and be found" | **static site** (`kind: 'static'`) | Served straight from the cPanel docroot — no database, no server process, fastest load. Add SEO + a lead form (below). The right default for marketing pages. |
 | A tool/app with **logins, custom logic, a dashboard, or an API** | **Node app** (`kind: 'node'`) | A real backend + database. |

package/skill/awesomate-app-builder/references/wp-migrate.md

@@ -0,0 +1,60 @@
+# Moving an existing WordPress site to Awesomate (and WP ↔ app coexistence)
+
+When the stack decision lands on WordPress **and the user already has a WP
+site elsewhere**, don't rebuild it — migrate it. Plain-language framing:
+*"We'll make an exact copy of your current site on your Awesomate hosting,
+check it works, then point your domain at it. Your old site stays untouched
+until you're happy."*
+
+## The migration path
+
+1. **Provision WP on Awesomate first** — the awesomate-hosting skill's
+   normal WP install (their plan's site limit applies; check
+   `awesomate_get_limits`). This gives a working target with SSL.
+2. **Export from the old host.** Preference order:
+   - **A full-copy plugin** (Duplicator / All-in-One WP Migration): the user
+     installs it on their OLD site and downloads the archive — the only step
+     that happens outside Awesomate, so give them click-by-click guidance.
+   - **Host export**: many hosts offer a backup download (files + a `.sql`).
+   - **WP admin export (XML)**: last resort — content only (posts/pages/
+     media), loses theme/plugins/settings; expect to reassemble the look.
+3. **Import on Awesomate.** With shell access (Support Plus+) prefer
+   `wp-cli` over the target install: unpack files into the docroot, import
+   the DB, then `wp search-replace 'https://old-domain.com'
+   'https://new-domain.com' --all-tables` (serialized-data-safe — never do
+   this with raw SQL). Plugin archives restore through the same plugin
+   installed on the new site.
+4. **Verify before DNS.** Browse the copy on its Awesomate URL: pages,
+   images, forms, admin login, HTTPS. Run **awesomate-seo** (sitemap,
+   robots, meta) and offer the **wp-security-review** skill — a migrated
+   site imports its old plugins, and stale plugins are the top WP risk.
+5. **Cut over DNS** — point the domain at Awesomate (add it as a custom
+   domain first; plan limits apply). Old site stays live as the fallback
+   until the user confirms; propagation can take up to a day and both
+   copies serve during it (avoid content edits that day).
+6. **After cutover:** confirm SSL issued for the domain, re-run the SEO
+   check on the final URL, and remind them to cancel the old hosting only
+   once everything's verified.
+
+## WP ↔ app coexistence (they want both)
+
+The platform already separates them cleanly — **WordPress owns the main
+domain; every app lives on its own subdomain** (`app.domain.com`,
+`dev-app.domain.com`, …). No conflict: Apache routes the main site to WP's
+docroot and each subdomain to its app.
+
+- Marketing/blog/shop stays in WP; the tool their customers log into is the
+  Node app on a subdomain. Link between them with plain links.
+- Don't try to serve an app *under a WP path* (`domain.com/app`) — that
+  fights WP's rewrites. A subdomain is the supported shape.
+- Shared look: reuse the WP site's colors/logo in the app's UI rather than
+  loading WP themes into the app.
+- Shared backend jobs (a form on either side emailing/CRM-ing): both can
+  call the same n8n webhook — one workflow, two callers.
+
+## When NOT to migrate
+
+If the old "WP site" is really one landing page and they don't blog or
+sell: recommend rebuilding it as a **static site** on Awesomate instead
+(faster, nothing to update) — see stack-decision.md. Migration is for sites
+with real content, plugins, or a shop.

package/skill/awesomate-hosting/SKILL.md

@@ -148,15 +148,18 @@ natural break so the richer MCP integration loads.
 
 ## 1. The plan model (so your nudges are accurate)
 
-| Plan | WP sites | Custom domains | Shell / Claude Code | Notes |
-|---|---|---|---|---|
-| **Essentials** | 1 | 0 | **No** | read/status + upgrade nudges only |
-| **Support Plus** | (per plan) | ≥1 | **Yes** | shell, WP-CLI, snapshot/rollback, deploy |
-| **Pro** | more | more | **Yes** | + higher limits |
-| **Embedded** | ∞ | ∞ | **Yes** | agency tier |
+| Plan | WP sites | Hosted apps | Custom domains | Shell / Claude Code | Notes |
+|---|---|---|---|---|---|
+| **Essentials** | 1 | 0 | 0 | **No** | read/status + upgrade nudges only |
+| **Support Plus** | 2 | 5 | 3 | **Yes** | shell, WP-CLI, snapshot/rollback, deploy, app builder |
+| **Pro** | 10 | 20 | 10 | **Yes** | + higher limits |
+| **Embedded** | 100 | 100 | 100 | **Yes** | agency tier, not generally available |
 
 Authoritative limits are always what `awesomate_get_limits` returns for THIS
-account — never quote the table above as fact; use it only to explain upgrades.
+account (and `awesomate_get_plan_features` fetches the live ladder from the
+hub) — never quote the table above as fact; use it only to explain upgrades.
+App creation past the cap returns a 409 with code `app_limit` — don't retry;
+surface the recommended plan instead.
 
 ## 2. Branch by capability