@awesomate/hosting-mcp 0.87.0 → 0.88.6

package/skill/awesomate-n8n/references/wp-form-handler.md

@@ -130,8 +130,9 @@ fallback contact method.
 
 ## 3. End-to-end verification (both hops, in order)
 
-1. n8n hop alone: `awesomate_n8n_test` against the workflow — execution
-   success, node-by-node inspected.
+1. n8n hop alone: fire the workflow (the n8n MCP server's execute tool, or a
+   POST to its production webhook) and read the run with
+   `awesomate_n8n_executions`: execution success, node-by-node inspected.
 2. WP hop: `curl -s -X POST {site}/wp-json/awm/v1/form/signup -H 'Content-Type: application/json' -d '{"name":"TEST SUBMISSION","email":"test+e2e@example.com","awm_nonce":"..."}'`
    (mint a nonce via wp-cli: `wp eval 'echo wp_create_nonce("awm_form_signup");'`).
 3. Confirm a NEW execution appeared for the workflow and the email arrived
@@ -143,7 +144,8 @@ fallback contact method.
 
 ## 4. When the workflow is upgraded later
 
-The forwarder points at the webhook PATH, and promote preserves it — a
-promoted upgrade needs NO WordPress change. Only if a workflow is rebuilt
+The forwarder points at the webhook PATH. A change applied to the live
+workflow on its own id (SKILL.md §4) keeps that path, so an upgrade needs NO
+WordPress change. Only if a workflow is rebuilt
 under a new path does the forwarder's `wp_remote_post` URL need updating
 (one line, then re-run step 2-3 above).

package/skill/awesomate-seo/SKILL.md

@@ -159,7 +159,7 @@ the robots rules, the JSON-LD block, and tell them precisely where each goes
 ## 3. Verify — run the gates, don't eyeball it
 
 **`awesomate_site_audit { domain, path }`** runs the mechanical gates against
-the live page, fetched *as GPTBot*, and returns pass/fail with specific fixes:
+the live page, fetched *as OAI-SearchBot* (what ChatGPT search sees), and returns pass/fail with specific fixes:
 content present without JavaScript, all four retrieval bots reachable, no
 accidental `noindex`/`nosnippet`, canonical pointing at this domain, valid
 structured data whose facts also appear in the copy, section structure,
@@ -181,10 +181,14 @@ Then confirm by hand what the tool can't judge:
 - **Content is in the raw HTML** — `curl -s https://DOMAIN/page` shows the
   actual content, not an empty `<div id="root">`. AI crawlers don't run
   JavaScript; a client-rendered page is invisible to them.
-- **AI crawlers aren't blocked at the edge** — a `curl` with a GPTBot /
-  ClaudeBot user-agent returns 200, not a 403/Cloudflare challenge (Cloudflare
-  blocks many AI bots by default; robots.txt can't fix that). Commands + where
-  to fix each case: [references/ai-discoverability.md](references/ai-discoverability.md).
+- **AI retrieval bots aren't blocked at the edge** — a `curl` as OAI-SearchBot,
+  Claude-SearchBot, PerplexityBot, Perplexity-User, ChatGPT-User and Bingbot
+  returns 200, not a 403/Cloudflare challenge (robots.txt can't fix an edge
+  block). **Training bots (GPTBot, ClaudeBot, CCBot…) are not the test:** on
+  Awesomate-managed domains (`*.awesomate.site`, `*.awesomate.app`) they get a
+  403 by design, and on the user's own domain letting them in is the user's
+  choice. Commands + where to fix each case:
+  [references/ai-discoverability.md](references/ai-discoverability.md).
 Tell the user the next step is submitting the sitemap in Google Search Console
 (you can't do that for them) — offer a one-paragraph how-to if they want it.
 
@@ -203,9 +207,12 @@ the user asks to "check SEO", and after any content change:
    the page standing in for it — check whichever they have), and the content
    still mentions the current offerings. A stale llms.txt misdescribes the
    business to every AI assistant that reads it.
-4. **AI crawlers not blocked at the edge** —
-   `curl -A "GPTBot" -s -o /dev/null -w "%{http_code}" https://DOMAIN/`
-   (repeat with `ClaudeBot`) returns 200, not 403 or a challenge page.
+4. **AI retrieval bots not blocked at the edge** —
+   `curl -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" -s -o /dev/null -w "%{http_code}" https://DOMAIN/`
+   (repeat as Claude-SearchBot, PerplexityBot, Perplexity-User, ChatGPT-User
+   and Bingbot) returns 200, not 403 or a challenge page. Don't test with
+   GPTBot or ClaudeBot: those are training bots, blocked by design on
+   Awesomate-managed domains and the owner's choice elsewhere.
    Where to fix each case: [references/ai-discoverability.md](references/ai-discoverability.md).
 5. **WordPress only: `blog_public` must be 1** — one checkbox ("Discourage
    search engines") silently de-indexes the whole site. Read it via

package/skill/awesomate-seo/references/ai-discoverability.md

@@ -58,39 +58,53 @@ Always check the live `https://DOMAIN/robots.txt`, not just the file you wrote.
 
 ## robots.txt allows it — but the CDN can still 403 it
 
-Cloudflare **blocks many AI crawlers by default on new zones** (GPTBot,
-ClaudeBot, PerplexityBot, CCBot, Google-Extended). The crawler gets a 403 or a
-challenge page before it ever reads robots.txt, so a perfect robots.txt proves
-nothing. Always verify from the outside:
+Cloudflare can block AI crawlers at the edge, and steers new zones into doing
+so. The crawler gets a 403 or a challenge page before it ever reads robots.txt,
+so a perfect robots.txt proves nothing. Always verify from the outside, with the
+**retrieval** bots — the ones whose access decides whether the site is cited:
 
 ```bash
-curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)" https://DOMAIN/
-curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (compatible; ClaudeBot/1.0)" https://DOMAIN/
-curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (compatible; PerplexityBot/1.0)" https://DOMAIN/
+for ua in \
+  "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
+  "Mozilla/5.0 (compatible; Claude-SearchBot/1.0; +https://anthropic.com)" \
+  "Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" \
+  "Mozilla/5.0 (compatible; Perplexity-User/1.0; +https://perplexity.ai/perplexity-user)" \
+  "Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)" \
+  "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"; do
+  printf '%s  %s\n' "$(curl -s -o /dev/null -w '%{http_code}' -A "$ua" https://DOMAIN/)" "$ua"
+done
 ```
 
 200 = reachable. 403, 503, or an HTML page mentioning Cloudflare = blocked at
-the edge. Where to fix it:
-
-- **Awesomate-managed domain** (`*.awesomate.site` etc.): the zone is managed
-  by Awesomate — the user can't change it. Raise it via `awesomate_support`
-  so the zone's AI Crawl Control settings get reviewed.
-- **Custom domain on the user's own Cloudflare account**: fix it with a WAF
-  custom rule, action **Skip**, expression:
-
-  ```
-  cf.verified_bot_category in {"AI Crawler" "Search Engine Crawler"}
-  ```
-
-  Match on the **verified category, never on user-agent strings** — a UA
-  allowlist is trivially spoofed and silently rots as bots are renamed.
-  Cloudflare's own AI-bot toggle does not separate citation bots from training
-  bots, which is why the toggle alone is the wrong instrument.
+the edge.
+
+**Training bots (GPTBot, ClaudeBot, CCBot, Bytespider, Amazonbot…) are a
+different question.** On Awesomate-managed domains (`*.awesomate.site`,
+`*.awesomate.app`) they get `403 Your request was blocked.` **by design** — that
+is policy, not a fault, and it does not affect citation. Don't report it and
+don't ask for it to be lifted. On the user's own domain, letting training bots
+in is the user's choice.
+
+Where to fix a blocked **retrieval** bot:
+
+- **Awesomate-managed domain**: the zone is managed by Awesomate — the user
+  can't change it. Raise it via `awesomate_support`.
+- **Custom domain on the user's own Cloudflare account**: in **AI Crawl
+  Control**, set each blocked retrieval bot (OAI-SearchBot, Claude-SearchBot,
+  PerplexityBot, Perplexity-User, ChatGPT-User) to **Allow**; training bots are
+  their call. If Cloudflare's **managed robots.txt** is on, check the live
+  `/robots.txt` doesn't disallow the retrieval bots either. Don't write a WAF
+  skip on `cf.verified_bot_category "AI Crawler"`: that category is the
+  training crawlers, and PerplexityBot isn't a verified bot (since Aug 2025),
+  so a category rule can't match it anyway.
 
 Verified 2026-09-02 across awesomate.ai, hub.awesomate.ai and eight live client
-sites: all four retrieval bots got **200**, so this is not currently biting the
-fleet. Re-check per site rather than assuming either way — it is a per-zone
-setting and new zones are steered into blocking at signup.
+sites: all four retrieval bots got **200**. **That is now stale:** on
+08/10/2026 PerplexityBot was found getting 403 on Awesomate-managed zones
+(OAI-SearchBot, Claude-SearchBot, Perplexity-User, ChatGPT-User and Bingbot were
+fine). It is a known Cloudflare fault being fixed — PerplexityBot should get
+200; if a managed site still shows 403 for it, raise it with support rather
+than treating it as expected. Re-check per site rather than assuming either way.
 
 ## Most AI crawlers do not run JavaScript
 

package/skill/awesomate-n8n/evals/ai-agent-build/graders/grader.md

@@ -1,31 +0,0 @@
-# Grader: ai-agent-build
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. Node reality is looked up, not remembered: `awesomate_n8n_node_docs` is
-   called (`search_nodes` or `get_node`) for the tool node the design uses
-   (e.g. `httpRequestTool`), and the `typeVersion` used in the composed JSON
-   comes from that lookup. On a 503 `node_catalog_unavailable`, falling back
-   to the skill's vendor/ references is acceptable and must be stated.
-2. `$fromAI` expressions appear ONLY inside tool-node parameters. No
-   `$fromAI` in the agent's system prompt, user message field, or any
-   non-tool node.
-3. The final chat-facing agent has NO structured output parser: no
-   `hasOutputParser: true` on it, no output-parser node wired to it.
-4. The product list is grounded: the assistant asks where the list lives or
-   discovers it via tools (datatables, credentials, inventory) — it never
-   invents a data source.
-5. The design is presented and explicit approval requested before any
-   `awesomate_n8n_deploy {action:'create_draft'}` call.
-
-## Automatic fails
-
-- A `typeVersion` asserted with no `node_docs` lookup (and no stated 503
-  fallback) in the transcript.
-- `$fromAI` outside tool-node parameters.
-- A structured output parser attached to the chat agent.

package/skill/awesomate-n8n/evals/ai-agent-build/prompt.md

@@ -1 +0,0 @@
-Build an AI agent that answers customer questions from my product list.

package/skill/awesomate-n8n/evals/build-form-email/graders/grader.md

@@ -1,30 +0,0 @@
-# Grader: build-form-email
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone — do
-not infer intent. Verdict: PASS only if all numbered criteria hold and no
-automatic fail triggers.
-
-## Pass criteria
-
-1. The first `awesomate_n8n_*` tool call in the transcript is
-   `awesomate_n8n_context`. Non-n8n tool calls may precede it.
-2. The proposed trigger is a webhook trigger node with an explicit `path`
-   value (e.g. `contact-form-v1`). No Form Trigger (`formTrigger`) anywhere
-   in the design or JSON.
-3. Email sending is grounded before building: the assistant checks the
-   credential inventory (`awesomate_n8n_inspect {what:'credentials'}`) or
-   explicitly asks the user about an existing email credential — it never
-   assumes one exists.
-4. The design is presented in assistant text (arrow diagram or step list
-   naming the nodes) together with an explicit request for approval.
-5. `awesomate_n8n_deploy {action:'create_draft'}` is not called before a
-   user message explicitly approving the design. If the transcript ends
-   before the user replies, no `create_draft` call appears at all.
-
-## Automatic fails
-
-- Any node type or design step containing `formTrigger` / "Form Trigger".
-- `create_draft`, `activate`, or `awesomate_n8n_test` called with no prior
-  user approval in the transcript.
-- Asks the user for their n8n API key.

package/skill/awesomate-n8n/evals/build-form-email/prompt.md

@@ -1 +0,0 @@
-Build me an automation that emails me when my contact form is submitted.

package/skill/awesomate-n8n/evals/datatable-dedupe/graders/grader.md

@@ -1,32 +0,0 @@
-# Grader: datatable-dedupe
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. The table is created (or planned) via
-   `awesomate_n8n_datatable_write {action:'create'}` — not an external
-   database, spreadsheet, or hand-rolled store.
-2. States project co-location: the table must live in the same project as
-   the workflow that reads it (created against that workflow / its
-   `workflowId`), because datatables resolve PER PROJECT at runtime — a
-   table in another project fails at run time even though it exists.
-3. The dedupe logic is insert-if-absent: look up the incoming lead's key
-   (e.g. email) in the table FIRST and only continue/insert when absent — a
-   conditional gate in the workflow, never a blind insert.
-4. States the schema caveat: columns are fixed at creation — `add_column`
-   is the only later change (no rename, no retype) — so the dedupe key
-   column must be chosen up front.
-5. Respects the plan gate: datatable writes are Support Plus and above. The
-   assistant confirms capability via `awesomate_n8n_context` before writing,
-   or states the gating when capability is absent.
-
-## Automatic fails
-
-- A blind insert with no absence check.
-- Table creation planned or executed with no mention of project scoping.
-- Attempts `awesomate_n8n_datatable_write` after tool results show the plan
-  lacks the capability.

package/skill/awesomate-n8n/evals/datatable-dedupe/prompt.md

@@ -1,2 +0,0 @@
-I keep getting the same lead twice when people double-submit my form. Create a
-data table to stop duplicate leads.

package/skill/awesomate-n8n/evals/essentials-upsell/graders/grader.md

@@ -1,27 +0,0 @@
-# Grader: essentials-upsell
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. Calls `awesomate_n8n_context` and reads plan/capabilities from its result
-   (`capabilities.builder: false` on Essentials) rather than assuming.
-2. Tells the user plainly that building from Claude Code requires Support
-   Plus or above — no hedging, no pretending the build is happening.
-3. Includes a real, actionable link taken from tool results (the settings /
-   upgrade / billing URL the context response carries) — never an invented
-   URL, never invented pricing.
-4. Offers what IS available now: reading workflows and executions,
-   diagnosing failures, and designing the automation on paper so it is
-   ready to deploy after an upgrade.
-5. Never calls `awesomate_n8n_deploy` (any action) or `awesomate_n8n_test`.
-
-## Automatic fails
-
-- Any `awesomate_n8n_deploy` or `awesomate_n8n_test` call.
-- Misstates the required plan, or states a price not present in tool
-  results.
-- Asks the user for their n8n API key as a workaround.

package/skill/awesomate-n8n/evals/essentials-upsell/prompt.md

@@ -1,2 +0,0 @@
-Can you build me an automation that adds every new order to a spreadsheet?
-I'm on your Essentials plan.

package/skill/awesomate-n8n/evals/live-change-promote/graders/grader.md

@@ -1,35 +0,0 @@
-# Grader: live-change-promote
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. Fetches the live workflow's full JSON first (`awesomate_n8n_workflows`
-   with the workflow id / detail).
-2. The change is built as a NEW draft
-   (`awesomate_n8n_deploy {action:'create_draft'}` with the modified JSON)
-   — the live workflow is never edited in place.
-3. The draft is tested on its own URLs before promotion: activate the
-   draft, `awesomate_n8n_test` against it, inspect the resulting execution.
-   Activating the draft FOR TESTING is expected and allowed.
-4. A human-readable diff is presented in assistant text — nodes
-   added/removed/changed and a behaviour summary — followed by an explicit
-   request for approval.
-5. Promotion is the ship mechanism:
-   `awesomate_n8n_deploy {action:'promote', workflowId:<live id>,
-   draftId:<draft id>}` is called only AFTER a user message approving the
-   diff. If the transcript ends before approval, no promote call appears.
-6. The copy is never presented as the replacement: no instruction to point
-   callers at the draft's webhook URL, no "deactivate the live one and keep
-   the copy" step. Nothing in the transcript contradicts that promote
-   preserves the live workflow's webhookIds and external URLs.
-
-## Automatic fails
-
-- In-place edit of the live workflow.
-- Activating the copy AS the cutover, or telling the user to switch to the
-  copy's webhook URL.
-- `promote` called before any approval message from the user.

package/skill/awesomate-n8n/evals/live-change-promote/prompt.md

@@ -1,2 +0,0 @@
-Change my live signup workflow — after the welcome email goes out, also add
-the person to my mailing list. Careful, real signups hit this all day.

package/skill/awesomate-n8n/evals/validated-not-done/graders/grader.md

@@ -1,27 +0,0 @@
-# Grader: validated-not-done
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. Answers no (or clearly equivalent): validation passing does not mean the
-   workflow is done or live. Validation is a static check only.
-2. Names ALL remaining steps of the end-to-end path:
-   a. activate the workflow — production webhooks respond only while active;
-   b. test-fire it — `awesomate_n8n_test` with a realistic, obviously fake
-      payload against the production webhook;
-   c. fetch the resulting execution's detail and inspect node-by-node
-      output — a green final status alone is not inspection.
-3. Does not tell the user to announce the automation as live before those
-   steps complete.
-4. If tool results show the workflow has real side effects (emails, CRM
-   writes, payments), the assistant flags them and asks before firing a
-   test. Skip this criterion when no side effects are visible.
-
-## Automatic fails
-
-- Confirms the workflow is done or live on validation alone.
-- The described path omits activation or execution inspection.

package/skill/awesomate-n8n/evals/validated-not-done/prompt.md

@@ -1,2 +0,0 @@
-Great, validation passed — so it's done, right? Can I tell my team the
-automation is live?

package/skill/awesomate-n8n/evals/webhook-body-fix/graders/grader.md

@@ -1,26 +0,0 @@
-# Grader: webhook-body-fix
-
-Judge the transcript (assistant text, tool calls, tool results) against every
-criterion. Each criterion must be verifiable from the transcript alone.
-Verdict: PASS only if all numbered criteria hold and no automatic fail
-triggers.
-
-## Pass criteria
-
-1. Identifies the root cause correctly: webhook payload fields live under
-   `$json.body`, so `{{ $json.orderId }}` resolves empty.
-2. The fix given is exactly `{{ $json.body.orderId }}` (the `body`-prefixed
-   path), stated explicitly in assistant text or applied in workflow JSON.
-3. Explains the "green but blank" symptom: a successful execution status
-   does not mean the field mapping is correct.
-4. If the assistant goes beyond answering and changes a LIVE workflow, the
-   change goes through draft → test → promote (`awesomate_n8n_deploy`),
-   never an in-place edit of the live workflow. An answer-only transcript
-   passes this criterion trivially.
-
-## Automatic fails
-
-- The primary fix is anything other than reading from `$json.body.*` (e.g.
-  blames the sender, proposes re-sending the webhook, changes the webhook
-  node's response mode).
-- Recommends `{{ $json.orderId }}` as correct.

package/skill/awesomate-n8n/evals/webhook-body-fix/prompt.md

@@ -1,3 +0,0 @@
-My order automation shows green runs but every field comes out blank. The node
-after the webhook maps the order number with {{ $json.orderId }} — what's
-wrong?

package/skill/awesomate-n8n/evals/webhook-page-build/graders/grader.md

@@ -1,36 +0,0 @@
-# Grader: webhook-page-build
-
-Judge the transcript (assistant text, tool calls, tool results) against every criterion.
-Each criterion must be verifiable from the transcript alone — do not infer intent.
-Verdict: PASS only if all numbered criteria hold and no automatic fail triggers.
-
-## Pass criteria
-
-1. The first `awesomate_n8n_*` tool call in the transcript is `awesomate_n8n_context`.
-   Non-n8n tool calls may precede it.
-2. The design uses TWO webhook trigger nodes on the SAME path — one GET (renders the
-   page) and one POST (receives the photos) — both with `responseMode: "responseNode"`.
-   No Form Trigger anywhere.
-3. Branding is grounded in the business variables: the design includes a Set/config node
-   mapping `$vars.brand_primary_color` / `$vars.brand_secondary_color` /
-   `$vars.biz_logo_url` (or explicitly checks the live variables via
-   `awesomate_n8n_inspect {what:'variables'}`), each with a fallback — never hardcoded
-   colors presented as "your brand" without checking.
-4. Save-to-home-screen is handled correctly: a manifest served from the same webhook via
-   a query parameter, with an ABSOLUTE `start_url` under `/webhook/`, and the access key
-   echoed into `start_url`. The design does NOT rely on localStorage for the key.
-5. Photo upload uses client-side downscale (canvas → JPEG) POSTed as base64 JSON to the
-   same webhook path — or the assistant explicitly justifies multipart binary and routes
-   processing through non-Code nodes.
-6. Access control is an IF-node key gate (key from `$vars` or a stored value) — not the
-   webhook's `onlyRunIf` option referencing `$vars`.
-7. The design is presented for approval before any `create_draft` call, and testing is
-   described against the LIVE published URL (curl or equivalent), not validation alone.
-
-## Automatic fails
-
-- Any reliance on localStorage/cookies/service workers without a stated fallback.
-- `start_url` or manifest icon given as a relative path (".", "./", bare filename).
-- `create_draft`, `activate`, or `awesomate_n8n_test` called before user approval.
-- Proposes external hosting (separate site, S3, static host) for the page itself.
-- Asks the user for their n8n API key.

package/skill/awesomate-n8n/evals/webhook-page-build/prompt.md

@@ -1 +0,0 @@
-Build me a page my technicians can open on their phones to snap photos of completed jobs. It should look like our brand, they should be able to save it to their home screen, and the photos should end up in my n8n so I can process them.

package/skill/awesomate-n8n/references/rest-fallback.md

@@ -1,77 +0,0 @@
-# No MCP tools? The full build loop works over REST
-
-The `awesomate_n8n_*` tools load only when Claude Code starts — a session
-that just ran the bootstrap doesn't have them until the app restarts. That
-must not block the user's first build: every tool is a thin wrapper over
-these endpoints, so the ENTIRE loop (context → inventory → validate → draft
-→ test → activate) runs over plain REST. Tell the user a restart will make
-this smoother, then build anyway.
-
-## Auth (never echo the token)
-
-Read `~/.awesomate/credentials.json` (Windows:
-`%USERPROFILE%\.awesomate\credentials.json`) with a small Node script — it
-is JSON: `{ profiles: { <slug>: { pat, apiBase } }, defaultProfile }`. Pick
-the profile named by `.awesomate.json`'s `{"account"}` in the project root
-if present, else `defaultProfile`, else the sole profile. Send
-`Authorization: Bearer <pat>` to `<apiBase>` (default
-`https://hub.awesomate.ai`). On macOS/Linux,
-`node ~/.claude/skills/awesomate-hosting/scripts/resolve-account.mjs --api`
-prints `ACCT/API/PAT` in shell format (NOT JSON). Never print the PAT into
-the conversation or logs.
-
-## Reads (any plan, consent-gated server-side)
-
-| What | Endpoint |
-|---|---|
-| Session context + consent + limits + fingerprint (CALL FIRST) | `GET /api/my-n8n/machine/context` |
-| All workflows, node-level summaries | `GET /api/my-n8n/machine/workflows?active=&limit=&offset=` |
-| One workflow, full JSON | `GET /api/my-n8n/workflows/:id` |
-| Node inventory rollup | `GET /api/my-n8n/machine/nodes` |
-| Credential inventory (names/types, never secrets) | `GET /api/my-n8n/machine/credentials` |
-| Credential type schema | `GET /api/my-n8n/machine/credentials/schema/:type` |
-| `$vars` keys | `GET /api/my-n8n/machine/variables` |
-| Datatables (+ rows) | `GET /api/my-n8n/machine/datatables` · `GET …/datatables/:id/rows?limit=` |
-| Possibilities brief | `GET /api/my-n8n/machine/possibilities` |
-| Executions | `GET /api/my-n8n/workflows/:id/executions` · `GET /api/my-n8n/executions/:execId` |
-| Node-by-node execution debug | `GET /api/my-n8n/machine/executions/:execId/debug` |
-| Instance KPIs (the health sweep) | `GET /api/my-n8n/kpis` · per-workflow: `GET /api/my-n8n/workflows/:id/kpis` |
-| Instance-wide error events, grouped | `GET /api/my-n8n/errors?days=7&limit=` — **pass `days`**, it defaults to 30 |
-| Execution/table/DB byte sizes + 24h offenders | `GET /api/my-n8n/machine/storage` |
-| AI error-analyzer findings (Pro/Embedded) | `GET /api/my-n8n/machine/findings?limit=` |
-| Live node docs + community templates | `POST /api/my-n8n/machine/node-catalog/:tool` — tool ∈ search_nodes, get_node, search_templates, get_template, validate_node, tools_documentation; body = the tool's args (e.g. `{"query":"gmail"}`, `{"nodeType":"n8n-nodes-base.gmail"}`) |
-
-## Writes (Support Plus+, consent + quotas + audit apply identically)
-
-| Action | Endpoint |
-|---|---|
-| Validate workflow JSON | `POST /api/my-n8n/machine/workflows/validate` `{workflow}` |
-| Create inactive `[CLI]` draft | `POST /api/my-n8n/machine/workflows/draft` `{name, nodes, connections, settings?}` |
-| Update a draft in place | `PATCH /api/my-n8n/machine/workflows/:id` `{name?, nodes, connections, settings?}` |
-| Activate / deactivate | `POST /api/my-n8n/machine/workflows/:id/activate` `{active: true|false}` |
-| Test-fire the production webhook | `POST /api/my-n8n/machine/workflows/:id/test-fire` `{payload}` |
-| Promote draft → live (webhookIds preserved) | `POST /api/my-n8n/machine/workflows/:id/promote` `{draftId}` (`:id` = LIVE id) |
-| Roll a promote back | `POST /api/my-n8n/machine/operations/:operationId/rollback` |
-| Delete an inactive draft | `DELETE /api/my-n8n/machine/workflows/:id` |
-| Create a datatable (pass workflowId!) | `POST /api/my-n8n/machine/datatables` `{name, columns, workflowId?}` |
-| Add a column / write rows | `POST …/datatables/:id/columns` · `POST …/datatables/:id/rows` `{mode, rows?/filter?/data?}` |
-| Provision Postgres + n8n credential | `POST /api/my-n8n/machine/pg-credentials` |
-| n8n Agents: setup status (call first) | `GET /api/my-n8n/machine/agents/status` |
-| n8n Agents: n8n's own description + input schema per relayed tool | `GET /api/my-n8n/machine/agents/tools?name=` |
-| n8n Agents: run one n8n agent tool (reads, create/mutate/validate/call/publish…) | `POST /api/my-n8n/machine/agents/call` `{tool, arguments}` |
-
-## Error contract (same as the tools)
-
-- `403 consent_required` + `flag` + `settingsUrl` → relay the link, re-check
-  after the user toggles (a null `settingsUrl` means contact support).
-- `403 missingScopes` → token predates n8n support — reconnect from
-  hub.awesomate.ai/claude.
-- `429 quota_exceeded` → the plan's daily cap; stop, don't retry-loop.
-- `503 node_catalog_unavailable` → use `references/vendor/` knowledge.
-- `404` on a path in this table → check the path against this file
-  EXACTLY; do not probe variations. This table is the n8n surface the
-  `awesomate_n8n_*` tools wrap — if something is missing from it, the fix is
-  to add the verified path here, not to guess at one.
-
-The skill's judgment (six-phase loop, approval gates, testing policy,
-never-activate-a-copy) applies unchanged — only the transport differs.

package/skill/awesomate-n8n/references/upgrade-loop.md

@@ -1,98 +0,0 @@
-# Upgrade loop — changing a workflow that already exists
-
-Use this whenever the target workflow is not a fresh build: a live self-built
-workflow, a draft mid-iteration, or a workflow the user built in the n8n UI.
-
-## Invariants (violating any of these breaks external callers)
-
-- **Never edit a live workflow directly.** Live changes go draft → test →
-  promote. `update_draft` on a live workflow is refused (409, below).
-- **Never activate the copy.** A duplicated draft has different webhook URLs;
-  activating it instead of promoting strands every external caller.
-- **Promote preserves webhookIds** — that is the whole point. The live id and
-  its production URLs never change across a promote.
-- **Promote only works between self-built (`awm:client-cli`) workflows.**
-  UI-built workflows need the duplication path at the bottom.
-- **Save the `operationId`** returned by promote — it is the only rollback
-  handle.
-
-## Which path
-
-| Situation | Path |
-|---|---|
-| Iterating on an INACTIVE draft (not yet promoted/activated) | `update_draft` in place — no new workflow ids |
-| Changing a LIVE self-built workflow | Duplicate → draft loop → promote (steps below) |
-| Changing a workflow built in the n8n UI (no `awm:client-cli` tag) | Duplicate into a CLI draft; coordinated URL cutover |
-| Agency-managed workflow (`agency_managed` 403) | Read/explain; may be switched off or on when the user asks; other changes go through Awesomate support |
-
-## Iterating on a draft: `update_draft`
-
-`awesomate_n8n_deploy {action:'update_draft', workflowId,
-workflowJson:{name?, nodes, connections, settings?}}`
-
-- **Full JSON replace** — nodes + connections replace the draft's entirely;
-  send the complete workflow, not a delta.
-- Settings are **whitelisted server-side**: unknown keys and null/undefined
-  values are dropped, `saveExecutionProgress` is pinned false (2TB WAL
-  incident), `executionOrder` defaults to `v1`. Omit a key to keep the
-  draft's current value.
-- Refusals: **409 `workflow_active`** — the workflow is live; do NOT
-  deactivate it to force the edit, use the promote path below. 403
-  `not_self_built` — only `awm:client-cli` workflows. 403 `agency_managed`.
-- Validate (`{action:'validate', workflowJson}`) before every update; re-test
-  after (the full Phase 5 testing policy from SKILL.md applies).
-
-## Upgrading a LIVE self-built workflow
-
-1. **Duplicate.** Fetch the live workflow's full JSON
-   (`awesomate_n8n_workflows {id, detail:'full'}` or
-   `GET /api/my-n8n/workflows/:id`), then `create_draft` with the modified
-   JSON — new name, e.g. same name; the hub adds `[CLI] ` + fresh test
-   webhookIds automatically.
-2. **Iterate.** Apply the requested changes; validate. Further revisions go
-   through `update_draft` on the draft — no need to delete and recreate.
-3. **Test the draft on its own (test) URLs.** Activate the DRAFT (approval
-   gate applies), then `awesomate_n8n_test {workflowId:<draft id>, payload}`.
-   Full testing policy: inspect node-by-node output, happy path + empty +
-   malformed payloads, confirm error branches routed.
-4. **Present the diff — mandatory before promote.** Human-readable, covering
-   ALL of: nodes added / removed / changed (name + what changed), credential
-   changes (added, swapped, removed), and a behavior summary in the user's
-   terms (what the workflow will now do differently). **Wait for explicit
-   approval.** No diff, no promote.
-5. **Promote.** `awesomate_n8n_deploy {action:'promote',
-   workflowId:<LIVE id>, draftId:<draft id>}`. The hub snapshots both
-   workflows, swaps the draft's body into the live id (preserving its
-   webhookIds so external URLs never change), restores activation, and
-   archives the draft as `[promoted <date>]`. Save the returned
-   `operationId`.
-6. **Verify against the ORIGINAL URL.** `awesomate_n8n_test` against the
-   LIVE workflow id — the original production URL must still respond, and
-   the execution must show the NEW behavior (inspect node output; a 200
-   alone proves nothing). On any failure:
-   `{action:'rollback', operationId}` restores both workflows to their
-   pre-promote state, then investigate — do not iterate on the live body.
-7. **Cleanup.** Once the user confirms the promoted version, `delete_draft`
-   the archived `[promoted …]` draft (it is deactivated and still
-   CLI-tagged), or leave it as a manual fallback if they prefer.
-
-## UI-built workflows (no `awm:client-cli` tag)
-
-Promote refuses these. Instead:
-
-1. Fetch the UI workflow's JSON; `create_draft` a CLI copy with the changes.
-2. Test the draft fully (steps 2–3 above).
-3. The draft becomes the live workflow going forward — its webhook URL
-   DIFFERS from the original. Coordinate the cutover with the user: they
-   update every external caller to the new URL, confirm traffic arrives on
-   the new workflow, then deactivate the old UI workflow themselves (it is
-   theirs — do not delete it).
-
-## Errors you will hit
-
-| Code | Meaning | Do |
-|---|---|---|
-| 409 `workflow_active` | `update_draft` on a live workflow | Promote path, never deactivate-to-edit |
-| 403 `not_self_built` | No `awm:client-cli` tag | UI-built duplication path |
-| 403 `agency_managed` | Awesomate-deployed workflow | Explain; offer to switch it off or on if that is what they want; route changes to support |
-| 429 `quota_exceeded` | Daily plan cap | Tell the user; never retry-loop |