@awesomate/hosting-mcp 0.87.0 → 0.88.2

package/skill/awesomate-n8n/references/error-handling.md

@@ -61,12 +61,12 @@ Two nodes:
    `[Automation failed] {{ $json.workflow.name }}`, body with the error
    message, the node that failed, and the execution URL so they can open it.
 
-Build it through the normal loop (validate → create_draft → approval →
-activate), then set `settings.errorWorkflow` on each production workflow via
-`update_draft`/promote. One error workflow can serve every workflow on the
-instance — build it once, point everything at it.
+Build it through the normal loop (SKILL.md §3, through the n8n MCP server),
+then set `settings.errorWorkflow` on each production workflow with the n8n
+server's update tool and republish each one. One error workflow can serve
+every workflow on the instance: build it once, point everything at it.
 
-Test it honestly: you can't fake a failure through `awesomate_n8n_test`
+Test it honestly: you can't fake a failure with a test fire
 without breaking something, so tell the user what will happen ("if any of
 these fail, you'll get an email like this") and verify the error workflow
 itself runs by executing it against a sample payload where possible.

package/skill/awesomate-n8n/references/n8n-agents.md

@@ -10,7 +10,7 @@ Four different things get called an agent. Pick before building:
 | The user wants… | Build | Tool |
 |---|---|---|
 | An assistant they set up once and talk to **in Slack, Telegram, Linear, Discord, Teams or n8n chat**, run **on a schedule**, or call from several workflows; it decides its own steps | **n8n Agent** (this file) | `awesomate_n8n_agents` |
-| A fixed trigger → steps → result, with an LLM as one step | Workflow with an AI Agent node | `awesomate_n8n_deploy` + [ai-agents.md](ai-agents.md) |
+| A fixed trigger → steps → result, with an LLM as one step | Workflow with an AI Agent node | The n8n MCP server (SKILL.md §3) + [ai-agents.md](ai-agents.md) |
 | A website chat that answers ONLY from their content, with citations | Knowledge agent | awesomate-knowledge skill |
 | One of Awesomate's ready-made chat agents | Template bundle | `awesomate_n8n_library` |
 
@@ -95,10 +95,10 @@ build → test → wrap-up.
    - Channels (Slack and so on) are NOT config. Use `update_agent_integration`.
 5. **Validate.** `validate_agent {agentId}` → fix every error.
    `incompatible_reference` with `no_supported_trigger` means that workflow
-   can't be a tool. `not_published` means it must be active first. On Support
-   Plus and above, activate it with `awesomate_n8n_deploy {action:"activate"}`
-   after the user's yes (the hub's agency-workflow guards apply there). On
-   Essentials the client switches it on in n8n themselves.
+   can't be a tool. `not_published` means it must be active first: publish it
+   through the n8n MCP server's publish tool after the user's yes (never a
+   workflow Awesomate manages for them), or the client switches it on in n8n
+   themselves.
 6. **Test.** `call_agent {agentId, request:{type:"message", message}}` with
    one representative message. To continue the same conversation, pass the
    `sessionId` it returned. Approval-gated tools come back as a pending
@@ -134,7 +134,7 @@ and the agent never holds any keys.
   description is the only thing the agent uses to choose the tool, so write
   it like an instruction.
 - Need a new tool workflow? Build it with the normal workflow loop
-  (`awesomate_n8n_deploy`) first, test it, then attach it.
+  (SKILL.md §3, through the n8n MCP server) first, test it, then attach it.
 - A data table is not usable just because it exists. Attach it as a node
   tool (`n8n-nodes-base.dataTable`, found via `search_nodes`).
 
@@ -158,9 +158,10 @@ It targets the **published** agent and returns `text`,
 
 ## Guard rails (enforced by the hub)
 
-- Only the agent tools and the read-only discovery tools are relayed. n8n's
-  workflow-writing MCP tools are NOT. Workflows still go through
-  `awesomate_n8n_deploy`, with its drafts, promote and rollback.
+- Only the agent tools and the read-only discovery tools are relayed through
+  `awesomate_n8n_agents`; n8n's workflow-writing MCP tools are NOT. Workflows
+  are written over the user's OWN connection to the same n8n MCP server
+  (SKILL.md §3), never through the hub.
 - An agent's config cannot attach a workflow Awesomate manages for the client,
   the n8n node, or any node using an n8n API credential (`403
   agent_tool_blocked`): calling the agent would run them. Use one of the

package/skill/awesomate-n8n/references/onebrain.md

@@ -28,8 +28,8 @@ answer), load the **awesomate-onebrain** skill too.
    (hub Settings, Integrations, 1Brain). For an agent, use the credential of
    the person the agent answers to (its supervisor): the agent can never see
    more than that person.
-4. **Validation false positive:** `awesomate_n8n_deploy {action:'validate'}`
-   and `awesomate_n8n_node_docs` do not know CUSTOM nodes and report the 1Brain
+4. **Validation false positive:** `awesomate_n8n_node_docs validate_node`
+   does not know CUSTOM nodes and reports the 1Brain
    node as unknown. Expected; do not "fix" it. The node catalog has no schema
    for it either: this page is the reference.
 
@@ -205,8 +205,8 @@ before. To bring one back to life:
 4. Any other old operation says "This 1Brain operation was retired": pick a new
    one in the node.
 
-Change a live workflow through the upgrade loop
-([upgrade-loop.md](upgrade-loop.md)), never in place.
+Change a live workflow on its own id through the n8n MCP server (SKILL.md
+§4), tested on a copy first, never by activating a copy in its place.
 
 ## 6. The no-code route: MCP Client Tool
 

package/skill/awesomate-n8n/references/platform-notes.md

@@ -99,23 +99,23 @@ trust this file.
     and its permissions are all perfectly intact. Every structural check
     passes; only the project link is wrong. **When the ID matches and
     permissions are fine, check scope, not existence.**
-21. **Create tables through the hub, threaded to the workflow.**
-    `awesomate_n8n_datatable_write {action: "create"}` co-locates the table
-    with the project that owns the client's drafts, and accepts `workflowId`
-    to target a specific workflow's owner project instead. Pass it whenever
-    the consuming workflow is known. Datatable writes are Support Plus+.
+21. **Create tables inside the workflow's project.** Tables are made in
+    n8n itself (Data tables in the left menu, while in the project that owns
+    the workflow), or through the n8n MCP server when it offers a data-table
+    tool. No Awesomate tool creates one. Read the result back with
+    `awesomate_n8n_inspect {what: "datatables"}` and reference it by name.
 22. List existing tables (ids, columns, rows) with
     `awesomate_n8n_inspect {what: "datatables"}` before creating duplicates.
 
-## Deploy & validation
+## Publishing & validation
 
-23. **Never activate a copy to replace a live workflow.**
-    `awesomate_n8n_deploy {action: "promote"}` preserves webhookIds;
-    activating a duplicate mints new ones and silently breaks every external
-    caller. E2E verification = activate, hit the production webhook, poll
-    `awesomate_n8n_executions`.
-24. **Known validation false positives** (via `awesomate_n8n_deploy
-    {action: "validate"}` or `awesomate_n8n_node_docs validate_node`):
+23. **Never activate a copy to replace a live workflow.** Change the live
+    one on its own id through the n8n MCP server and republish it (SKILL.md
+    §4); activating a duplicate mints new webhookIds and silently breaks
+    every external caller. E2E verification = publish, hit the production
+    webhook, poll `awesomate_n8n_executions`.
+24. **Known validation false positives** (via `awesomate_n8n_node_docs
+    validate_node`):
     community/CUSTOM nodes report "unknown" (expected — see variant gating,
     rule 3); graph cycles flag `valid: false`, but cycle-based polling loops
     are legitimate. Filter known false positives — don't "fix" a working

package/skill/awesomate-n8n/references/possibilities.md

@@ -89,8 +89,8 @@ and ground them in their numbers, never invent precision.
   nodes return `[{json:{...}}]`, `saveExecutionProgress` stays false,
   webhook trigger (explicit path) instead of formTrigger. Details:
   [platform-notes.md](platform-notes.md).
-- Datatable-backed ideas: only when `counts.datatables` is non-null;
-  writes need Support Plus+ (`awesomate_n8n_datatable_write`); tables
+- Datatable-backed ideas: only when `counts.datatables` is non-null; the
+  user creates tables in n8n's Data tables (no Awesomate tool does); tables
   resolve per project at runtime.
 
 ## Community templates — importable starting points
@@ -99,17 +99,18 @@ Search by the user's actually-connected services, not by the idea's topic:
 
 - `awesomate_n8n_node_docs {tool:'search_templates', args:{query: '<service>'}}`
   then `{tool:'get_template', args:{templateId}}` for the JSON.
-- A template is a starting point, not a deploy: strip nodes needing
-  credentials the user lacks, then run the full build loop (validate →
-  create_draft → test) from SKILL.md §2.
+- A template is a starting point, not a finished workflow: strip nodes
+  needing credentials the user lacks, then run the full build loop
+  (SKILL.md §3) through the n8n MCP server.
 - 503 `node_catalog_unavailable` → skip templates this session and fall
   back to the vendored references in `references/vendor/`.
 
 ## Essentials plan
 
-`capabilities.builder: false` → reads work, builds need Support Plus+.
-Say so ONCE, honestly — "I can explain, diagnose, and design these, but
-building on your instance needs Support Plus+ (upgrade at
-hub.awesomate.ai/billing)" — then keep helping within reads: present the
-tiers as a roadmap, sketch designs, diagnose existing workflows. Do not
-repeat the upsell on every idea.
+Reads, n8n Agents and building through the user's own n8n MCP server all
+work on Essentials. What it lacks is Awesomate's template library:
+`capabilities.templateInstall: false`. When an idea is best served by a
+curated bundle, say so ONCE, honestly ("that one is a ready-made template,
+which needs Support Plus+ (upgrade at hub.awesomate.ai/billing); I can build
+you a version of it on your n8n instead"), then keep going. Do not repeat
+the upsell on every idea.

package/skill/awesomate-n8n/references/testing-policy.md

@@ -1,54 +1,58 @@
 # Testing Policy (mandatory)
 
 A build or change is NOT done until the workflow has been EXECUTED on the
-user's instance and the execution INSPECTED node by node.
-`awesomate_n8n_deploy {action:'validate'}` checks structure, not behaviour —
-a passing validate plus a green final status is never "tested".
+user's instance and the execution INSPECTED node by node. Node validation
+(`awesomate_n8n_node_docs validate_node`) checks structure, not behaviour:
+a passing validation plus a green final status is never "tested".
 
-Applies to: new builds (SKILL.md Phase 5), the upgrade loop (test the draft
-AND re-verify after promote), and any fix to a failing workflow. Only
-exception: the user explicitly waives testing for that specific task.
+Applies to: new builds (SKILL.md Phase 5), changes to a live workflow (test
+the change AND re-verify the live one after it is applied), and any fix to a
+failing workflow. Only exception: the user explicitly waives testing for that
+specific task.
 
 ## How a test runs
 
-There is no manual or pin-data execution on this platform. E2E = activate +
+There is no manual or pin-data execution on this platform. E2E = publish +
 production webhook + poll executions:
 
-1. Get approval to go live, then
-   `awesomate_n8n_deploy {action:'activate', workflowId}` — production
-   webhooks only respond while the workflow is active.
-2. `awesomate_n8n_test {workflowId, payload}` — fires the PRODUCTION webhook
-   with the `X-Awesomate-Test` header; returns the webhook response plus the
-   `executionId` it caused. Real side effects DO run: emails actually send.
-   Address them to the user's own email, prefix subjects `[TEST]`, use
-   obviously fake data (`test+<runId>@…`, "TEST SUBMISSION"), and tell the
-   user before firing. Non-email side effects (CRM writes, payments, SMS):
-   STOP and ask first.
-3. Inspect: `awesomate_n8n_executions {executionId, debug: true}` — read the
+1. Get approval to go live, then publish the workflow through the n8n MCP
+   server's publish tool (or the user switches it on in n8n). Production
+   webhooks only respond while the workflow is published.
+2. Run it. Three ways, pick the one that fits: the n8n MCP server's execute
+   tool; a POST to the PRODUCTION webhook URL (`{instanceUrl}/webhook/<path>`)
+   with the fixture as the body; or ask the user to trigger it themselves
+   (submit the form, send the email). Real side effects DO run: emails
+   actually send. Address them to the user's own email, prefix subjects
+   `[TEST]`, use obviously fake data (`test+<runId>@…`, "TEST SUBMISSION"),
+   and tell the user before firing. Non-email side effects (CRM writes,
+   payments, SMS): STOP and ask first.
+3. Find the run: `awesomate_n8n_executions {workflowId}` lists the newest
+   executions; the one you just caused is at the top.
+4. Inspect: `awesomate_n8n_executions {executionId, debug: true}`. Read the
    node list, per-node output, and which branches ran. When consent is off,
    debug data is unavailable and the call falls back to the non-debug
-   detail (final status + failing node only) — state that in the report;
-   you inspected less than usual.
+   detail (final status + failing node only). State that in the report; you
+   inspected less than usual.
 
 A green final status is not inspection. Do not enable
-`saveExecutionProgress` to get richer data — the hub enforces it FALSE
-(write-amplification incident); `debug: true` is the inspection path.
+`saveExecutionProgress` to get richer data. Keep it FALSE on every workflow
+you write (write-amplification incident); `debug: true` is the inspection
+path.
 
 ## Fixtures (payload classes)
 
-The payload passed to `awesomate_n8n_test` is the POST body — the workflow
-sees it at `$json.body`. Run at minimum one of each class:
+The body you POST is what the workflow sees at `$json.body`. Run at minimum
+one of each class:
 
 | Class | Payload |
 |---|---|
 | happy-path | Realistic valid input, obviously fake values |
 | empty | `{}` / missing fields entirely |
 | malformed | Wrong types, missing required fields, junk strings |
-| error-`<api>` | Input that drives a named upstream API to a realistic error (nonexistent id → 404, bad enum → 400) — one per external dependency |
+| error-`<api>` | Input that drives a named upstream API to a realistic error (nonexistent id → 404, bad enum → 400): one per external dependency |
 
-Quota: `limits` from `awesomate_n8n_context` caps daily test fires. Plan
-the fixture set before burning tests; a 429 `quota_exceeded` means the
-day's cap — tell the user, never retry-loop.
+Awesomate sets no cap on test runs; the only cost is the side effects, so
+plan the fixture set before firing rather than spraying the user's inbox.
 
 ## Error-path testing (required, minimum 3)
 
@@ -58,20 +62,20 @@ day's cap — tell the user, never retry-loop.
 
 Verify `onError` branches ACTUALLY ROUTE: in the execution's node list,
 confirm the error path's nodes ran and the post-failure happy-path nodes
-did not. Final status alone proves nothing — an execution whose error
+did not. Final status alone proves nothing: an execution whose error
 branch routed can still finish green.
 
 ## Multi-trigger gotcha
 
-`awesomate_n8n_test` reaches the webhook trigger only. A schedule (or any
-non-webhook) branch NEVER runs from a test fire — it is untested unless
-exercised deliberately:
+A webhook fire reaches the webhook trigger only. A schedule (or any
+non-webhook) branch NEVER runs from it. It is untested unless exercised
+deliberately:
 
-- Draft phase: temporarily wire the branch behind a webhook trigger via
-  `awesomate_n8n_deploy {action:'update_draft'}`, test-fire it, then
-  REMOVE the temporary trigger before promote.
-- Never promote or leave live a workflow carrying a temporary test
-  trigger — it is a world-callable production URL.
+- Temporarily wire the branch behind a webhook trigger (update the workflow
+  through the n8n MCP server), fire it, then REMOVE the temporary trigger
+  before the workflow stays live.
+- Never leave live a workflow carrying a temporary test trigger: it is a
+  world-callable production URL.
 - If the branch cannot be exercised this way, list it under "needs human"
   in the report. Do not report it as tested.
 
@@ -91,7 +95,7 @@ their answer in the report.
 ## Test Report (required in every handoff)
 
 ```
-## Test Report — <workflow> @ <instance>
+## Test Report: <workflow> @ <instance>
 Executed: <executionIds + payload class for each>
 Inspection: debug / non-debug fallback (consent off)
 Passed: <node paths verified, outputs checked>
@@ -102,14 +106,14 @@ Post-test state: restored ✔ (checklist below)
 
 ## Post-test state restore
 
-- [ ] Temporary test triggers/nodes removed from drafts
-- [ ] Test drafts deactivated; deleted via
-      `awesomate_n8n_deploy {action:'delete_draft'}` unless the user wants
-      them kept
-- [ ] `[TEST]` rows written to datatables during tests cleaned up
-      (`awesomate_n8n_datatable_write {action:'delete_rows'}`)
-- [ ] Live workflow's activation state matches what the user expects
-- [ ] After a promote: the ORIGINAL production URL re-verified with a test
-      fire (promote preserves webhookIds — the old URL must still respond)
+- [ ] Temporary test triggers/nodes removed
+- [ ] Throwaway test workflows unpublished, then deleted through the n8n
+      MCP server (with the user's OK) unless they want them kept
+- [ ] `[TEST]` rows written to data tables during tests cleaned up (in
+      n8n's Data tables, or by the workflow's own delete step)
+- [ ] Live workflow's published state matches what the user expects
+- [ ] After a change to a live workflow: the ORIGINAL production URL
+      re-verified with a fire (the path is unchanged, so the old URL must
+      still respond)
 - [ ] User told which `[TEST]` artifacts (emails, records) to expect and
       discard

package/skill/awesomate-n8n/references/troubleshooting.md

@@ -4,13 +4,14 @@ Diagnosis playbook. Work the flow top-to-bottom; do not jump to fixes before
 you have the failing execution's detail.
 
 
-## "Could not create the draft" / writes fail while reads work
+## Template installs or activation fail while reads work
 
-If reads, `awesomate_n8n_context` and `validate` all succeed but every WRITE
-(create draft, activate, promote, test-fire) fails, the cause is almost always
-the account's stored n8n API key — not the hub, not Cloudflare, not the
-workflow JSON. Validation runs on Awesomate's side and never touches the
-instance, which is exactly why it keeps passing.
+If reads and `awesomate_n8n_context` succeed but every hub WRITE (a template
+`install`, `activate` or `test` through `awesomate_n8n_library`) fails, the
+cause is almost always the account's stored n8n API key: not the hub, not
+Cloudflare, not the template. Workflows you write through the n8n MCP server
+use its own MCP key, not this one, so a refusal there is the n8n server's own
+answer; read it as such.
 
 The server says so explicitly: HTTP **409** with `code: n8n_credential_invalid`.
 Older builds reported this as a 502, which reads like an outage — if you see a
@@ -65,22 +66,21 @@ rebuilt (a rebuilt instance shows 0 workflows and invalidates every old key).
 | Downstream fields empty/undefined on a webhook workflow | Webhook data lives at `$json.body`, not `$json` | Use `{{ $json.body.field }}`. #1 cause of "undefined" in webhook flows |
 | "access to environment variables is denied" | `$env` is blocked fleet-wide — in Code nodes AND regular field expressions | Use `{{ $vars.key \|\| 'fallback' }}` or a Config Set-node literal; never `$env` |
 | "$helpers is not defined" (works in editor preview, fails at run time) | Task runners strip `$helpers` from Code nodes | Move HTTP calls to HTTP Request nodes; process results in a downstream Code node |
-| "Could not find the data table: '<id>'" | PROJECT scope, not existence — datatables resolve within the workflow's own project at runtime | Check which project owns the table (`awesomate_n8n_inspect {what: "datatables"}`) vs the workflow. Recreate/move the table into the workflow's project (`awesomate_n8n_datatable_write`, Support Plus+). Reference tables by name, never by id |
+| "Could not find the data table: '<id>'" | PROJECT scope, not existence: datatables resolve within the workflow's own project at runtime | Check which project owns the table (`awesomate_n8n_inspect {what: "datatables"}`) vs the workflow. The user recreates the table inside the workflow's project (n8n's Data tables). Reference tables by name, never by id |
 | Credential "could not be found" | Sharing/RBAC — the credential exists but is not shared with the workflow's project/owner. Almost never deletion | Verify it exists via `awesomate_n8n_inspect {what: "credentials"}`; user shares it to the project in the n8n editor |
-| Webhook URL returns 404 | Workflow not active — production webhook paths register only while active. Test URLs work only while the editor is listening | Activate via `awesomate_n8n_deploy`. Never activate a copy — `promote` preserves webhookIds |
+| Webhook URL returns 404 | Workflow not active: production webhook paths register only while active. Test URLs work only while the editor is listening | Publish it through the n8n MCP server (or the user switches it on in n8n). Never activate a copy: change the live one on its own id (SKILL.md §4) |
 | Form URL 404s at its custom path | formTrigger ignores the custom `path`; forms serve only at `/form/<webhookId>` | Use a webhook trigger when a stable path matters |
 | "Unrecognized node type" / unknown node at activation | Community media node on an instance without the FFMPEG variant (Support Plus+ gate) | Check `awesomate_n8n_context` capabilities; upgrade variant or rebuild on core nodes. Note: static validation flagging `CUSTOM.*` nodes "unknown" is a false positive — trust activation, not the validator |
 | Output shows literal "[object Object]" | Expression resolves to an object where a string is expected | Drill to the scalar (`{{ $json.body.user.email }}`) or wrap in `JSON.stringify()` |
-| Workflow saved but never executes | Draft was never activated/published; saving is not publishing | `awesomate_n8n_deploy {action: "activate"}` (new) or `promote` (replacing a live one). E2E-verify: activate + hit the production webhook + poll executions |
+| Workflow saved but never executes | Draft was never activated/published; saving is not publishing | Publish it through the n8n MCP server (a new workflow), or republish the live one after updating it. E2E-verify: publish + hit the production webhook + poll executions |
 | Code node output vanishes or breaks downstream | Not returning `[{ json: {...} }]`, or leftover template boilerplate | Return an array of `{json}` objects; check whether the node is unedited boilerplate |
 | Node config valid yesterday, "Invalid value for 'operation'" today | Partial update stripped the `operation` discriminator | Set `resource` + `operation` together in the same update; re-validate |
-| `crashed` status, hours-long runtime, loop workflow | `saveExecutionProgress: true` (quadratic writes — 2TB WAL incident) and/or no `executionTimeout` on a `splitInBatches` loop | Keep `saveExecutionProgress` FALSE (the hub enforces it); add `executionTimeout` to every loop workflow; bound rows per run |
-| `429 quota_exceeded` | Plan daily cap reached | STOP immediately. Do not retry-loop — tell the user the cap is hit; it resets daily or they upgrade. Limits are in `awesomate_n8n_context` |
+| `crashed` status, hours-long runtime, loop workflow | `saveExecutionProgress: true` (quadratic writes, 2TB WAL incident) and/or no `executionTimeout` on a `splitInBatches` loop | Keep `saveExecutionProgress` FALSE (set it yourself; nothing enforces it for you); add `executionTimeout` to every loop workflow; bound rows per run |
 
 ## Verification after a fix
 
-- Re-run realistically: `awesomate_n8n_test {workflowId, payload}` for manual
-  runs; for live paths, activate + POST the production webhook + poll
+- Re-run realistically: the n8n MCP server's execute tool, a POST to the
+  production webhook, or the user's own trigger; then poll
   `awesomate_n8n_executions` until the new run appears.
 - Inspect the fixed run's data, not just its status — an `onError: continue`
   branch can turn a failure into a "successful" run carrying an `error` key.
@@ -91,11 +91,10 @@ rebuilt (a rebuilt instance shows 0 workflows and invalidates every old key).
   are fine: list it, read executions, run `debug`, and explain the failure to
   the user freely. Switching it off or on is allowed when the user asks (the
   reply carries `built_by_us`; tell them what stops while it's off). Do NOT
-  attempt any other change (`update_draft`, `promote`, `rollback`, `test`,
-  datatable writes): those go through Awesomate support.
+  attempt any other change (editing it through the n8n MCP server, test
+  fires, data table changes): those go through Awesomate support.
   Summarize your diagnosis so the user can paste it into their ticket.
 - `403 consent_required` the user declines to enable — diagnose from the
   execution summary only; say plainly what deeper access would show.
-- `429 quota_exceeded` — never burn remaining quota on retries.
 - Fix requires the FFMPEG variant or a higher plan — explain the gate; the
   upgrade happens in the hub, not here.

package/skill/awesomate-n8n/references/webhook-pages.md

@@ -5,11 +5,11 @@ mini-app the user saves to their home screen, an approval page that resumes a pa
 workflow, a live status page. No hosting, no CORS, no deploy pipeline: the page exists
 while the workflow is active.
 
-**Never hand-build the page's URL.** `awesomate_n8n_deploy` returns a `webhooks` array —
-`{ node, url, method }` per trigger — and that `url` is the live address. Most instances
-are `https://<slug>.awesomate.io`, but not all of them are, so a constructed hostname is
-a guess that fails silently for the clients on a different domain. `awesomate_n8n_context`
-carries the same truth as `instanceUrl`. Give the user the URL you were handed.
+**Never guess the page's hostname.** The live address is `{instanceUrl}/webhook/<path>`,
+with the path from the webhook trigger you wrote and `instanceUrl` from
+`awesomate_n8n_context`. Most instances are `https://<slug>.awesomate.io`, but not all of
+them are, so a hostname built from the slug is a guess that fails silently for the clients
+on a different domain. Give the user the URL built from `instanceUrl`.
 
 **The contract: GET renders, POST acts.** Two webhook trigger nodes on the SAME path —
 one `httpMethod: GET`, one `POST`, both `responseMode: "responseNode"`. Never let a GET

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-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.