@awesomate/hosting-mcp 0.9.0 → 0.10.0

package/dist/index.js

@@ -40108,7 +40108,7 @@ 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"
 );
 server.registerTool(

package/package.json

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

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.