@awesomate/hosting-mcp 0.19.1 → 0.19.2

package/dist/index.js

@@ -39897,7 +39897,7 @@ async function hubRequest(config3, method, path, jsonBody, opts = {}) {
     if (res.status === 401) {
       hint = " Your access token is invalid or expired \u2014 ask the user to open the hub Sites page (hub.awesomate.ai/sites), generate a fresh Connect prompt, and re-run the bootstrap.";
     } else if (res.status === 403 && code === "consent_required") {
-      const settingsUrl = body && typeof body === "object" && "settingsUrl" in body && typeof body.settingsUrl === "string" ? body.settingsUrl : "https://hub.awesomate.ai/settings?tab=privacy";
+      const settingsUrl = body && typeof body === "object" && "settingsUrl" in body && typeof body.settingsUrl === "string" ? body.settingsUrl : "https://hub.awesomate.ai/n8n/settings";
       hint = ` This needs a privacy toggle the user must flip themselves \u2014 send them to ${settingsUrl}, wait for them to confirm, then retry. Never suggest a plan upgrade for a consent denial.`;
     } else if (res.status === 403) {
       const missing = body && typeof body === "object" && "missingScopes" in body ? ` (missing: ${JSON.stringify(body.missingScopes)})` : "";
@@ -40574,6 +40574,36 @@ var SKILL_DRIFT = (() => {
   if (!info.updateAvailable) return null;
   return `${info.installedSkillVersion ?? "unversioned"} \u2192 ${SERVER_VERSION}`;
 })();
+function restartGuidance() {
+  const entry = (process.env.CLAUDE_CODE_ENTRYPOINT ?? "").toLowerCase();
+  const inVsCode = entry.includes("vscode") || Boolean(process.env.VSCODE_IPC_HOOK || process.env.VSCODE_PID);
+  if (inVsCode) {
+    return {
+      surface: "vscode",
+      instruction: 'Open the Command Palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows/Linux) and run "Developer: Reload Window".',
+      certain: true
+    };
+  }
+  if (entry.includes("desktop") || entry.includes("app")) {
+    return {
+      surface: "desktop-app",
+      instruction: "Quit the Claude app completely and open it again, then reopen this project.",
+      certain: true
+    };
+  }
+  if (entry === "cli" || entry.includes("cli")) {
+    return {
+      surface: "terminal",
+      instruction: "Type `exit` (or press Ctrl+C twice) to leave Claude Code, then run `claude` again.",
+      certain: true
+    };
+  }
+  return {
+    surface: entry || "unknown",
+    instruction: "Start a fresh Claude Code session \u2014 however you normally start one (close this session and open a new one). Ask the user how they run Claude Code rather than guessing.",
+    certain: false
+  };
+}
 var SERVER_INSTRUCTIONS = [
   "Awesomate connects this account's WordPress hosting, n8n automations, apps and Knowledge Base to Claude.",
   "Entry point: call awesomate_get_context once per session FIRST \u2014 it returns the account, plan, limits, an `attention` digest (unread notifications, erroring workflows, token expiry) and skill freshness. The domain contexts (awesomate_n8n_context, awesomate_app_context, awesomate_knowledge_status) come after it, only for their domain.",
@@ -40917,12 +40947,18 @@ server.registerTool(
         ...result,
         changed: changed.map((u) => `${u.name}: ${u.from ?? "unversioned"} \u2192 ${u.to}`),
         whatsNew: changelogSince(changed[0]?.from ?? null).flatMap((e) => e.highlights),
-        restart: {
-          note: "Updated skill files load in the next Claude Code session \u2014 one restart lands both the skills and the (self-updating) server.",
-          terminal: "Type exit (or press Ctrl+C twice), then run `claude` again.",
-          vscode: 'Command Palette (Cmd/Ctrl+Shift+P) \u2192 "Developer: Reload Window".',
-          verify: "After restarting, awesomate_get_context should report skill.updateAvailable: false."
-        }
+        restart: (() => {
+          const g = restartGuidance();
+          return {
+            note: "Updated skill files load in the next Claude Code session \u2014 one restart lands both the skills and the (self-updating) server.",
+            // Detected from this session's own environment. Give the user THIS
+            // instruction only — do not read out a list of surfaces.
+            detectedSurface: g.surface,
+            instruction: g.instruction,
+            ...g.certain ? {} : { note2: "Surface could not be detected \u2014 ask the user how they run Claude Code instead of guessing steps." },
+            verify: "After restarting, awesomate_get_context should report skill.updateAvailable: false."
+          };
+        })()
       });
     } catch (err) {
       return errorResult(err);
@@ -41015,7 +41051,7 @@ server.registerTool(
 server.registerTool(
   "awesomate_run_wp_cli",
   {
-    description: "Run an allowlisted WP-CLI command on one of the user's WordPress sites (plugin/theme list+activate+update, cache flush, option get/update, post/media/menu/comment/user list). Installs accept wp.org SLUGS only \u2014 never URLs. args is the command as an array, e.g. ['plugin','list'] or ['plugin','install','wordpress-seo','--activate']. A 400 wp_cli_not_allowed means that command isn't permitted; a 502 wp_cli_unavailable is a temporary server-side issue, not your command.",
+    description: "Run an allowlisted WP-CLI command on one of the user's WordPress sites (plugin/theme list+activate+update, cache flush, option get/update, post/media/menu/comment/user list). ARGUMENTS CANNOT CONTAIN SPACES (letters, digits and -_./=:@+, only) \u2014 so a site title, tagline or any multi-word value is impossible here: use awesomate_wp_settings for those, and awesomate_wp_post for post/page content. Installs accept wp.org SLUGS only \u2014 never URLs. args is the command as an array, e.g. ['plugin','list'] or ['plugin','install','wordpress-seo','--activate']. A 400 wp_cli_not_allowed means that command isn't permitted; a 502 wp_cli_unavailable is a temporary server-side issue, not your command.",
     inputSchema: {
       domain: external_exports.string().describe("The site domain"),
       args: external_exports.array(external_exports.string()).describe("WP-CLI args, e.g. ['plugin','list']")
@@ -41302,7 +41338,6 @@ server.registerTool(
 server.registerTool(
   "awesomate_app_deploy_info",
   {
-    annotations: READ_ONLY,
     description: "READ-ONLY deploy briefing \u2014 this never deploys anything (deploys happen via git push). Reports how to deploy an app, its per-env targets, last-deploy/health state, and how to promote (dev\u2192staging\u2192main) or roll back (git revert + push). Node apps deploy via git push (dev/staging/main \u2192 GitHub Actions \u2192 cPanel). Use the awesomate-github skill to wire push-to-deploy the first time.",
     inputSchema: { appId: external_exports.number().int().positive().describe("The app id") }
   },
@@ -41656,7 +41691,7 @@ server.registerTool(
   "awesomate_n8n_findings",
   {
     annotations: READ_ONLY,
-    description: "Findings from Awesomate's automated error analyzer for THIS account (Pro/Embedded + the 'AI error analysis' privacy toggle): severity, workflow, occurrences, a plain-language clientSummary, needsClientAction (something only the user can fix \u2014 expired logins, third-party quotas), and fixReady (a reviewed fix is prepared \u2014 raise it with awesomate_support to have it applied). Read-only. An empty list on a healthy instance is the good state, not an error.",
+    description: "Findings from Awesomate's automated error analyzer for THIS account (Pro/Embedded + the 'Enable AI Error Diagnosis' privacy toggle (n8n \u2192 Settings \u2192 Privacy)): severity, workflow, occurrences, a plain-language clientSummary, needsClientAction (something only the user can fix \u2014 expired logins, third-party quotas), and fixReady (a reviewed fix is prepared \u2014 raise it with awesomate_support to have it applied). Read-only. An empty list on a healthy instance is the good state, not an error.",
     inputSchema: { limit: external_exports.number().int().min(1).max(100).optional() }
   },
   async ({ limit }) => {
@@ -41690,7 +41725,7 @@ readTool(
 );
 readTool(
   "awesomate_privacy_settings",
-  "READ which privacy/consent toggles are on or off for this account \u2014 call it when a tool returns 403 consent_required so you can name the exact toggle instead of guessing. Toggles are changed ONLY by the user in the hub (Settings \u2192 Privacy, hub.awesomate.ai/settings?tab=privacy); there is deliberately no write here.",
+  "READ which privacy/consent toggles are on or off for this account \u2014 call it when a tool returns 403 consent_required so you can name the exact toggle instead of guessing. Toggles are changed ONLY by the user in the hub (n8n \u2192 Settings \u2192 Privacy, hub.awesomate.ai/n8n/settings); there is deliberately no write here.",
   "/api/client-settings/privacy"
 );
 server.registerTool(
@@ -41782,6 +41817,31 @@ server.registerTool(
     }
   }
 );
+server.registerTool(
+  "awesomate_wp_settings",
+  {
+    description: `Change a WordPress site's core settings \u2014 THE tool for "change my site title" / tagline. Use this, never awesomate_run_wp_cli, for any value containing spaces: that tool's argument gate rejects spaces outright, so \`option update blogname "My Business Name"\` cannot work there. Fields (send only what you're changing): title, tagline, timezone (IANA, e.g. Australia/Sydney), dateFormat, timeFormat, postsPerPage (1-100), searchEngineVisible (false hides the site from search engines \u2014 confirm before setting it). Support Plus+ and audited; flushes the object cache so the change shows. Snapshot first with awesomate_snapshot_site if this is the session's first change to a live site.`,
+    inputSchema: {
+      domain: external_exports.string().min(3).max(253).describe("The site domain, e.g. mybusiness.awesomate.site"),
+      title: external_exports.string().min(1).max(200).optional().describe("Site title (blogname)"),
+      tagline: external_exports.string().max(300).optional().describe("Tagline (blogdescription)"),
+      timezone: external_exports.string().max(64).optional(),
+      dateFormat: external_exports.string().max(40).optional(),
+      timeFormat: external_exports.string().max(40).optional(),
+      postsPerPage: external_exports.number().int().min(1).max(100).optional(),
+      searchEngineVisible: external_exports.boolean().optional()
+    }
+  },
+  async ({ domain, ...fields }) => {
+    try {
+      const dom = encodeURIComponent(domain.toLowerCase());
+      const payload = Object.fromEntries(Object.entries(fields).filter(([, v]) => v !== void 0));
+      return textResult(await hubPatch(requireConfig(), `/api/client-hosting/sites/${dom}/settings`, payload));
+    } catch (err) {
+      return errorResult(err);
+    }
+  }
+);
 server.registerPrompt(
   "awesomate-status",
   {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awesomate/hosting-mcp",
-  "version": "0.19.1",
+  "version": "0.19.2",
   "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/CHANGELOG.json

@@ -1,5 +1,12 @@
 {
   "versions": [
+    {
+      "version": "0.19.2",
+      "highlights": [
+        "Change your site title or tagline just by asking - multi-word names now work",
+        "Claude tells you how to restart in the way that matches how you actually run it, instead of listing every option"
+      ]
+    },
     {
       "version": "0.19.1",
       "highlights": [
@@ -20,13 +27,13 @@
       "highlights": [
         "Search your knowledge base with filters and ask questions within a slice of your content",
         "People & entities: your knowledge base now recognises who appears in your content, and you can name and merge them",
-        "Build AI agents from your own content \u2014 drafted, tested privately, and published only when you approve"
+        "Build AI agents from your own content — drafted, tested privately, and published only when you approve"
       ]
     },
     {
       "version": "0.14.0",
       "highlights": [
-        "Tools built for business owners, not developers \u2014 plain-language answers about your account, plan and limits",
+        "Tools built for business owners, not developers — plain-language answers about your account, plan and limits",
         "New support skill: get help, understand credits, or request a done-for-you build without leaving Claude",
         "New database skill: Claude picks the right place to keep your data and sets it up for you"
       ]

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

@@ -45,7 +45,24 @@ decision brain. The short version, matched to what they say:
 - **Landing page / capture leads / one-pager / "just needs to look good and
   be found"** → **static site** (`kind: 'static'`). Fastest possible load,
   no database. This is the right default for marketing pages — don't reach for
-  a full app.
+  a full app. Know what you give up, and check it against the job BEFORE
+  creating, because the stack can't be changed afterwards:
+  - **No server-side environment.** `awesomate_app_set_env` returns 400 for
+    a static app — there is nowhere to put a secret. Anything the page must
+    keep private (an API key, a webhook URL you don't want public) rules
+    static out.
+  - **`awesomate_n8n_attach_to_app` is Node-only.** So the "form posts to
+    their n8n" pattern needs a Node app, unless the webhook URL being public
+    is genuinely acceptable.
+  - **No separate dev site.** All three environment URLs point at the same
+    single subdomain — there's no dev copy to review on, so every change is
+    live the moment it's published.
+  - **No deploy workflow.** The static template is just the page files, so
+    pushing to GitHub does not publish it (see the awesomate-github skill's
+    §2 — deploy wiring needs Awesomate support).
+
+  If the page needs a webhook URL, a secret, or a place to test before it
+  goes live, it's a **Node app**. Say that in one line and move on.
 - **App with logins / custom logic / a dashboard / an API** → **Node app**
   (`kind: 'node'`). Pick **postgres** when the data is relational / needs
   concurrency / JSON / analytics; **mysql** for simple cases.
@@ -58,7 +75,14 @@ If the app needs to **send an email, look something up in their apps (Sheets,
 CRM, a database), or use AI** — their **own n8n** is often the fastest path,
 because their credentials are already connected there. Check the credential
 inventory (`awesomate_n8n_inspect {what:'credentials'}`) and say e.g. *"you already
-have Gmail connected in n8n — want the form to email you through that?"* Use
+have Gmail connected in n8n — want the form to email you through that?"*
+That read is **consent-gated**: it needs the **"Allow Claude Code to Build
+n8n Workflows"** toggle (n8n → Settings → Privacy,
+hub.awesomate.ai/n8n/settings; also on hub.awesomate.ai/n8n/settings),
+which is **off by default** — so on a fresh account it comes back 403
+`consent_required`. That's not a failure to work around: call
+`awesomate_privacy_settings` to name the exact toggle, ask the user to flip
+it, re-check, and meanwhile design as if you don't know what's connected. Use
 the **awesomate-n8n** skill to build the workflow, then store its webhook URL
 in the app (see the awesomate-credentials skill) and call it from the app.
 Don't reach for n8n for pure in-app logic with no external app/credential — a
@@ -108,6 +132,29 @@ target; never touch prod without an explicit ask.**
    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.
+   **That dev address is Node-only.** A static app has ONE address —
+   `{app}.{slug}.awesomate.app` — and `awesomate_app_get` reports it for dev,
+   staging and prod alike. There is no separate copy to review on, so with a
+   static site "post it to dev first" isn't an option you can honestly offer:
+   say the change goes live, and get the yes before publishing. Read the real
+   addresses from `awesomate_app_get` rather than constructing them — an
+   account without the branded domains falls back to subdomains of its own
+   primary domain (`dev-{app}.{domain}`).
+   **Publishing to their WordPress site** (as opposed to an app) has its own
+   tools, and `awesomate_run_wp_cli` is the wrong one for content: its
+   argument gate rejects spaces outright, so a title or tagline can't go
+   through it.
+   - `awesomate_wp_post` — create/update/read a post or page, with real
+     titles and HTML. It lands as a **DRAFT** unless you explicitly pass
+     `status:'publish'`; never publish something the user hasn't read.
+   - `awesomate_wp_media_import` — pull one image in by https URL (it cannot
+     read local files) and get back an `attachmentId` to reference.
+   - `awesomate_wp_settings` — site title, tagline, timezone, date/time
+     format, posts per page, search-engine visibility.
+
+   Snapshot the site (`awesomate_snapshot_site`) before the session's first
+   change to a live WordPress site.
+
 7. **Wrap-up / promote** — only when the user approves, promote **dev → staging
    → main** (merge + push per branch). `awesomate_app_deploy_info` reports the
    branch→env map + last-deploy state (it never deploys — `git push` does). Prod is `main`. **Before merging to
@@ -141,7 +188,10 @@ app with a UI, an n8n data table (awesomate-n8n skill) beats building an app
 - 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.
+  from the error. **There is no delete-app tool or route** — don't offer
+  "delete an old one to free a slot", because neither you nor the user can.
+  The honest options are an upgrade or asking support (awesomate-support
+  skill) to remove an app.
 - 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/stack-decision.md

@@ -10,7 +10,22 @@ confirm before building. **Never default to WordPress.**
 |---|---|---|
 | "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** | Provision via the awesomate-hosting skill, install WooCommerce over WP-CLI, then run **awesomate-seo** (product pages need `Product` JSON-LD + real product data). |
-| 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 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 — but see the three limits under the table before you commit to it. |
+
+**What a static site cannot do** (the stack can't be changed later, so check
+this against the job first):
+
+- **No server-side environment.** `awesomate_app_set_env` returns 400 for a
+  static app. Anything the page must keep secret has nowhere to live — it
+  would be in the page source, readable by anyone.
+- **`awesomate_n8n_attach_to_app` is Node-only.** A static lead form can only
+  POST to an n8n webhook URL that is **hardcoded in the page and therefore
+  public**. Sometimes that's acceptable (a plain lead capture behind n8n-side
+  validation); when it isn't, it's a Node app.
+- **No separate dev site.** All three environment URLs are the same single
+  subdomain, so there's nowhere to review a change before it's live.
+- **No deploy workflow.** The static template is just the page files —
+  pushing to GitHub does not publish it (awesomate-github §2).
 | A tool/app with **logins, custom logic, a dashboard, or an API** | **Node app** (`kind: 'node'`) | A real backend + database. |
 
 ### Within a Node app: which starter template?
@@ -47,18 +62,30 @@ If the ask includes **email someone, look something up in their apps, save a
 lead somewhere, or use AI**, that's usually a job for their **own n8n** — their
 credentials are already connected there, so there's nothing new to set up.
 
-- Check `GET /api/my-n8n/machine/credentials` (names/types only) and offer what
-  they already have: *"You've got Gmail + Google Sheets connected — want the
-  form to email you and add the lead to a sheet?"*
+- Check what's connected with `awesomate_n8n_inspect {what:'credentials'}`
+  (names/types only) and offer what they already have: *"You've got Gmail +
+  Google Sheets connected — want the form to email you and add the lead to a
+  sheet?"* That read needs the **"Allow Claude Code to Build n8n Workflows"**
+  privacy toggle, which is off by default — a 403 `consent_required` means
+  call `awesomate_privacy_settings`, name the toggle, and ask the user to flip
+  it at hub.awesomate.ai/n8n/settings.
 - Build the workflow with the **awesomate-n8n** skill (webhook trigger →
-  action), take its **webhook URL**, and store it in the app as
-  `N8N_WEBHOOK_URL` via the **awesomate-credentials** skill. The static
-  template's lead form and the Node template's `src/lib/n8n.ts` both POST there.
+  action), take its **webhook URL**, and wire it into the app.
+  - **Node app:** `awesomate_n8n_attach_to_app` — it stores
+    `N8N_WEBHOOK_URL` plus a generated `N8N_WEBHOOK_SECRET` (encrypted +
+    injected) and returns the secret so you can add the matching
+    `X-Awesomate-Webhook-Secret` check on the n8n side. `src/lib/n8n.ts`
+    POSTs there.
+  - **Static site:** there is no app environment, so the URL sits in the page
+    source, public. Tell the user that plainly, and defend the workflow on the
+    n8n side instead (validation, rate limiting) — or use a Node app.
 - Skip n8n for pure in-app logic with no external app/credential/AI — a webhook
   round-trip just adds latency and a failure point.
 
 ## Always, for any public site
 Offer **awesomate-seo** (meta/OG tags, `sitemap.xml`, `robots.txt`, JSON-LD, a
 general `llms.txt`) so it's findable by search engines *and* AI assistants — and
-**awesomate-github** so their work is version-controlled and deploys on push
-from day one.
+**awesomate-github** so their work is version-controlled from day one.
+Push-to-deploy is a second step and not one you can finish alone: the Actions
+workflow needs SSH repo secrets no client-side tool returns, so set up the repo
+and hand the deploy wiring to Awesomate support (awesomate-github §2).

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

@@ -26,8 +26,10 @@ until you're happy."*
    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.
+   robots, meta). A migrated site brings its old plugins with it and stale
+   plugins are the top WP risk, so check for outdated ones
+   (`awesomate_run_wp_cli ['plugin','list']`), update what's safe to update,
+   and flag anything abandoned to the user.
 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

package/skill/awesomate-credentials/SKILL.md

@@ -47,8 +47,13 @@ value goes browser → destination directly; you only ever see the key NAMES.
    node ~/.claude/skills/awesomate-credentials/scripts/secret-drop.mjs \
      --hub-app <appId> --env dev --keys STRIPE_SECRET_KEY --port <port> --token <hex>
    ```
-   Get `<appId>` from `awesomate_app_list`. Keys are UPPER_SNAKE (lowercase is
-   auto-uppercased). Node apps only — static sites have no server env. The
+   Get `<appId>` from `awesomate_app_list`. Keys must be UPPER_SNAKE: the
+   drop script uppercases what you pass it in hub mode, but the
+   `awesomate_app_set_env` TOOL does not — it hard-rejects anything that
+   isn't `^[A-Z][A-Z0-9_]{0,63}$`, so a lowercase name or a leading
+   underscore is a validation error there, not a tidy-up. Pick the final
+   uppercase name once and use it in both places. Node apps only — static
+   sites have no server env (`set_env` returns 400 for them). The
    script posts each value to the hub with the user's own PAT
    (`~/.awesomate/credentials.json`) — the same route `awesomate_app_set_env`
    uses, so encryption, `.env` injection and restart all behave identically.
@@ -71,6 +76,26 @@ value goes browser → destination directly; you only ever see the key NAMES.
 6. Confirm with key names only. No rotation warning needed — the value never
    entered the conversation.
 
+### What the drop link can't do
+
+- **The link is short-lived and single-use.** It expires after 15 minutes
+  (`--ttl <minutes>` to change it) and the server exits after the FIRST
+  successful save unless you passed `--stay`. If the user comes back later
+  and the page is dead, that's expected — start a fresh one on a new port
+  with a new token rather than telling them to retry the old link.
+- **It cannot carry a MULTI-LINE value.** The bulk box is parsed line by
+  line, splitting on the first `=`, so a PEM private key or a Google
+  service-account JSON loses everything after line 1 — silently, and those
+  are two of the commonest secrets people have. The named field is a
+  single-line input, so it can't hold one either. For a multi-line secret,
+  either:
+  - **base64 it into one line** — `base64 -i key.pem | tr -d '\n'` — drop
+    that through the link as e.g. `GOOGLE_SA_JSON_B64`, and decode it in the
+    app at startup; or
+  - have the user **save it to a file** on their machine and tell you the
+    path, then read and store it — being honest that reading it puts the
+    value in the conversation record, so the rotation nudge applies.
+
 ## Detect and offer
 
 If the user's message contains something shaped like a secret — `sk-…`,
@@ -94,14 +119,26 @@ full map. Short version:
   the file-mode link; add a rotation note if it came through the chat.
 - **Never** a tracked file, a commit, or the chat.
 
+A secret for an n8n workflow belongs on the n8n instance (awesomate-n8n
+skill), never in an app `.env`. Those tools are consent-gated: if one comes
+back 403 `consent_required`, call `awesomate_privacy_settings` — it names
+the exact toggle that's off, so you can send the user to the right switch at
+hub.awesomate.ai/n8n/settings instead of guessing. You can't flip it
+for them.
+
 ## Fallback: the file-drop flow
 
 Only when the link flow can't work (e.g. Claude is running on a remote machine
 the user's browser can't reach as 127.0.0.1):
 
 1. Tell them: *"Create a file `.awesomate/secret-inbox.txt` in your project and
-   paste the value there — I'll grab it and wipe the file."* (`.awesomate/` is
-   gitignored by the github skill.)
+   paste the value there — I'll grab it and wipe the file."*
+   **Verify `.gitignore` yourself before any commit.** Don't assume the
+   folder is ignored: the github skill's setup script adds `.awesomate/` only
+   when it has actually been run in this project, and older installed copies
+   of that script didn't list it at all. `grep -q '^\.awesomate/' .gitignore`
+   — add the line if it's missing, before the file exists, and never commit
+   while it does.
 2. Read the file, store via `awesomate_app_set_env`, then **scrub the file**:
    `node ~/.claude/skills/awesomate-credentials/scripts/capture-secret.mjs .awesomate/secret-inbox.txt`
 3. Be honest with the user: reading the file put the value in the conversation

package/skill/awesomate-database/SKILL.md

@@ -26,6 +26,14 @@ co-located with the workflow that uses it. No hosting slot consumed, and
 workflows query it directly — this is the default answer for anything
 automation-shaped. Inspect what exists with
 `awesomate_n8n_inspect {what:'datatables'}`.
+**Both the write AND that read are gated:** Support Plus or above, plus the
+privacy toggle **"Allow Claude Code to Build n8n Workflows"** — n8n →
+Settings → Privacy (hub.awesomate.ai/n8n/settings, or the same toggles at
+hub.awesomate.ai/n8n/settings, which is what the 403's
+`settingsUrl` points at). It is **off by default**, so on a fresh account
+both the read and the write come back 403 `consent_required`. Call
+`awesomate_privacy_settings` to name the exact toggle that's off, send the
+user to flip it, then re-check. You cannot flip it for them.
 
 **(b) Real APP data** — logins, dashboards, anything relational that an
 app serves to people. → the app's own Postgres.
@@ -38,7 +46,23 @@ app serves to people. → the app's own Postgres.
 **(c) A WORKFLOW that needs raw SQL against its own Postgres** — real
 joins, aggregates, or volumes a data table shouldn't carry. →
 `awesomate_n8n_provision_pg`. One step creates the database AND the n8n
-credential, so the workflow can query it immediately.
+credential, so the workflow can query it immediately. It has the most gates
+of anything here — check them BEFORE offering it, so the user doesn't hit a
+wall halfway:
+- Support Plus or above.
+- The **"Allow Claude Code to Build n8n Workflows"** toggle (off by
+  default) — same one as branch (a).
+- The **direct database writes** consent (`allow_pg_writes`). It's on by
+  default, so this is rare — but it has **no client-facing toggle in the
+  hub**, so if it's off, don't send the user hunting for a switch that
+  doesn't exist: route it to support via the awesomate-support skill.
+- An Awesomate cPanel hosting account. Without one it returns 409
+  `hosting_required`; hosting comes first (awesomate-hosting skill).
+- Capped at **2 a day**.
+
+On any 403 here, call `awesomate_privacy_settings` first — it names the
+exact toggle that's blocking, which decides whether this is a "flip this
+switch" or a "raise it with support" answer.
 
 **(d) Analytics/BI or data shared with other systems** — reporting
 warehouses, a spreadsheet the whole team lives in, a CRM. → recommend
@@ -69,12 +93,19 @@ reach), ask "live or dev?" before provisioning against it.
 
 ## 2. Safety rules
 
-- **Passwords are shown ONCE by provisioning and land where they
-  belong** — the app's environment for `awesomate_app_provision_db`,
-  the n8n credential for `awesomate_n8n_provision_pg`. Never echo a
-  password into chat, and never put a `DATABASE_URL` in a message. Tell
-  the user where it lives instead: "the app already has its connection —
-  nothing for you to copy."
+- **Passwords land where they belong, and the two branches differ.**
+  `awesomate_app_provision_db` NEVER returns a password: it's set
+  server-side, stored encrypted, and injected as the app's `DATABASE_URL`
+  — there is nothing to show, so don't promise the user a password.
+  `awesomate_n8n_provision_pg` is the one that DOES return a password, once,
+  because it lives in the n8n credential and Awesomate never stores it. The
+  workflow doesn't need you to repeat it — the credential already holds it —
+  so say that, and only offer the value if the user actually needs it
+  elsewhere, warning that it has now passed through the transcript and
+  should be rotated. Never put a `DATABASE_URL` in a message. Tell the user where
+  it lives instead: "the app already has its connection — nothing for you
+  to copy." (After an app database is provisioned, the app needs a restart
+  or redeploy to pick it up.)
 - Secrets the user's own app code needs (API keys, tokens) go through
   the awesomate-credentials skill, never pasted into files or chat.
 - **Deleting data requires an explicit filter and an explicit yes.**
@@ -84,14 +115,28 @@ reach), ask "live or dev?" before provisioning against it.
 
 ## 3. Limits, honestly
 
-Provisioning quotas are per-day and plan-gated. App databases
-(`awesomate_app_provision_db`) and workflow Postgres
-(`awesomate_n8n_provision_pg`) need Support Plus or above; data tables
-work on any plan with n8n access. If the user's plan doesn't cover what
-branch (b) or (c) needs, say it once — "app databases are on Support
-Plus" — point them at hub.awesomate.ai/billing to upgrade, then help
-fully within what their plan allows. Usually that means branch (a): a
-data table covers more "keep track of X" asks than people expect. If a
+Everything that provisions here needs **Support Plus or above** — app
+databases (`awesomate_app_provision_db`), workflow Postgres
+(`awesomate_n8n_provision_pg`) and data tables alike. Data tables are NOT
+"any plan with n8n access": Essentials gets 0 creations a day, and both the
+table read and the write also need the "Allow Claude Code to Build n8n
+Workflows" toggle (§0(a)).
+
+Only some of it is capped per day:
+- `awesomate_n8n_provision_pg` — **2 a day**, flat; no plan raises it, so
+  don't pitch an upgrade for it.
+- Data table creations — **10 a day** on Support Plus and Pro (20 on
+  Embedded), 0 on Essentials. An instance also tops out at 50 data tables.
+- `awesomate_app_provision_db` — **no daily cap**. It's one database per
+  environment and refuses (409 `already_has_db`) if the app has one, so
+  there's nothing to ration.
+
+If the user's plan doesn't cover what branch (b) or (c) needs, say it once
+— "app databases are on Support Plus" — point them at
+hub.awesomate.ai/billing to upgrade, then help fully within what their plan
+allows. On Essentials that means none of (a), (b) or (c) is available —
+don't dangle a data table as the consolation prize; say so once and look at
+(d), keeping the data where it already lives and connecting to it. If a
 daily quota is hit, say when it resets and what can proceed meanwhile.
 
 Report every result as a business outcome: "your workflow now remembers

package/skill/awesomate-github/SKILL.md

@@ -47,19 +47,48 @@ Ask only: **"What should we call this project?"** (repo name) and, if relevant,
 **"Keep it private?"** (default yes). Derive a sensible kebab-case repo name
 from what they tell you.
 
+**The script's first push goes to `main`.** It runs `git init -b main` and
+pushes the current branch, so on a fresh repo `main` — the PRODUCTION branch
+for Node apps — is what gets created. That's fine for a repo that's just a
+backup, but if the code isn't ready to be live, say so before running it, or
+create and check out `dev` first. There is **no `dev` branch until you make
+one**: `git push origin dev` on a fresh repo fails. Create it, then push:
+
+```
+git checkout -b dev
+git push -u origin dev
+```
+
 ## 2. Push-to-deploy (for apps built with awesomate-app-builder)
 
-If this is a Node app from the app builder, wire the deploy secrets so a push
-ships it (GitHub Actions → cPanel). The app builder / hub provides the SSH
-deploy values; set them as repo secrets with `gh secret set` (the script does
-this when run with `--deploy-secrets` and the values are available in the
-environment). Then: **push to `dev` → deploys dev; `main` → deploys prod.**
-Explain it as *"save your work = it goes live"* — don't lecture on branches.
+Node apps from the app builder ship with a GitHub Actions workflow that
+deploys on a push to `dev` / `staging` / `main` (dev → dev, main → prod).
+Once the branches exist, explain it as *"save your work = it goes live"* —
+don't lecture on branches.
+
+**But you cannot finish the wiring yourself, and you should say so.** That
+workflow needs `SSH_HOST`, `SSH_USER` and `SSH_PRIVATE_KEY` as repo secrets,
+and **no client-reachable tool or route returns those values** — they're
+admin-only. `github-setup.mjs --deploy-secrets` only copies them from your
+environment, so with nothing there it prints `skip deploy secret …` and the
+first deploy run goes red. So:
+
+1. Set up the repo, the branches and the commits (§1) — all of that works.
+2. Tell the user plainly: *"your code is backed up on GitHub; the automatic
+   deploy still needs Awesomate to connect it — I'll raise that for you."*
+   Raise it via the **awesomate-support** skill.
+3. **Do not loop on the failing pipeline.** Re-running it, rewriting the
+   workflow, or pushing again won't produce the missing secrets.
+
+Static sites have no deploy workflow at all — the template is just the page
+files — so pushing does not publish them either; same handoff.
 
 ## 3. Everyday use (plain language)
 
 - "Save my work" → stage, commit with a short message you write for them, push.
-- "Put it live" → push to the right branch (dev/staging/main) and tell them the URL.
+- "Put it live" → push to the right branch (dev/staging/main) and tell them the
+  URL. If the branch doesn't exist yet, create it (`git checkout -b <name>`)
+  before pushing — only `main` exists after first-time setup.
 - Always write clear commit messages **for** them; don't ask them to.
 
 ## 4. Be the version-control guardian (proactive, not reactive)
@@ -78,6 +107,13 @@ control — they should never have to think about it:
   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.
+  **`last_deploy_failed` that never clears is usually the unwired deploy
+  secrets (§2), not a bug you can fix.** Check whether `SSH_HOST` /
+  `SSH_USER` / `SSH_PRIVATE_KEY` are set on the repo (`gh secret list`)
+  before touching anything: if they're missing, stop, tell the user the
+  deploy connection is pending with Awesomate, and raise it via the
+  awesomate-support skill. Don't retry the run, and don't start editing the
+  workflow file.
 - **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
@@ -90,7 +126,12 @@ control — they should never have to think about it:
 
 ## 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
+  not a licence to skip checking. The script's `.gitignore` list — `.env`,
+  `.env.local`, `.awesomate/`, `*.log`, `.DS_Store`, `node_modules/` — is only
+  applied when the script has been run in that project, so on a repo somebody
+  else set up, read `.gitignore` before committing rather than assuming.
+  `.awesomate/` matters especially: the credentials skill's file-drop fallback
+  puts a live secret there. If you spot a secret, route it through the
   awesomate-credentials skill instead.
 - Never ask the user for a GitHub token or password; the device-flow is the
   only auth path.

package/skill/awesomate-github/scripts/github-setup.mjs

@@ -50,7 +50,10 @@ if (run('gh', ['auth', 'status']).status !== 0) {
 
 // --- 1. .gitignore excludes .env ------------------------------------------
 const giPath = join(cwd, '.gitignore');
-const needed = ['.env', '.env.local', '*.log', '.DS_Store', 'node_modules/'];
+// .awesomate/ is the secret-drop inbox — the credentials skill tells users it is
+// ignored, and the SECRET_RE guard only catches known key SHAPES, so a database
+// URL or bare token in there would otherwise be committable.
+const needed = ['.env', '.env.local', '.awesomate/', '*.log', '.DS_Store', 'node_modules/'];
 let gi = existsSync(giPath) ? readFileSync(giPath, 'utf8') : '';
 const have = new Set(gi.split(/\r?\n/).map((l) => l.trim()));
 const toAdd = needed.filter((n) => !have.has(n));