@awesomate/hosting-mcp 0.87.0 → 0.88.6

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

@@ -127,14 +127,16 @@ n8n's chat widget can embed the agent on any site. chatTrigger config:
 - CORS `allowedOrigins`: no trailing slashes, no spaces after commas.
 - No structured output parser on the final agent (see above).
 
-## Test and deploy
-
-- E2E = activate + production webhook + poll executions: `awesomate_n8n_test`
-verify end-to-end: `awesomate_n8n_executions {workflowId}` to find the run,
-then `awesomate_n8n_executions {executionId, debug: true}` for node-by-node
-detail.
-  — `awesomate_n8n_deploy {action:"promote"}` preserves webhookIds.
-- `saveExecutionProgress` stays FALSE (hub enforces; quadratic-write
+## Test and publish
+
+- E2E = publish + production webhook + poll executions. Publish through the
+  n8n MCP server, fire the production webhook (or the n8n server's execute
+  tool), then `awesomate_n8n_executions {workflowId}` to find the run and
+  `awesomate_n8n_executions {executionId, debug: true}` for node-by-node
+  detail.
+- A change to a live agent workflow goes onto its own id (SKILL.md §4); a
+  copy mints new webhookIds.
+- `saveExecutionProgress` stays FALSE (set it yourself; quadratic-write
   incident). Agent/tool loops around `splitInBatches` need an
   `executionTimeout`.
 - Agent + chat workflows also run their published version — republish after

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

@@ -1,8 +1,11 @@
-# Datatables — client-side playbook
+# Datatables: client-side playbook
 
 n8n data tables: small operational stores a workflow reads/writes at runtime.
 Read with `awesomate_n8n_inspect {what: "datatables"}` (tables, columns, row
-counts). Write with `awesomate_n8n_datatable_write` (Support Plus+ plans only).
+counts, rows). Tables are created and edited in n8n itself: the user opens
+**Data tables** in their n8n's left menu, or Claude creates one through the
+n8n MCP server when that server offers a data-table tool. No Awesomate tool
+creates or writes a table.
 
 ## Right store or wrong store
 
@@ -12,94 +15,71 @@ counts). Write with `awesomate_n8n_datatable_write` (Support Plus+ plans only).
 | Task queue / retry list a workflow drains | Datatable |
 | Lookup map (SKU→label, email→owner) | Datatable |
 | Cursor/state between runs (last-synced timestamp) | Datatable |
-| Real app data (users, orders, content) | The app's own database — never a datatable |
+| Real app data (users, orders, content) | The app's own database, never a datatable |
 | Analytics, event history, anything unbounded | External store (app DB, sheet, warehouse) |
 
 Rule of thumb: bounded row count, flat rows, no joins, consumed by the
-automation itself. Instance cap is 50 tables (`datatable_cap_reached`), and
-creates have a daily plan quota (`quota_exceeded` — limits in
-`awesomate_n8n_context`).
+automation itself. n8n caps an instance at 50 tables.
 
-## Creating — pass workflowId
-
-```
-awesomate_n8n_datatable_write {action: "create", name, columns: [{name, type?}], workflowId}
-```
+## Creating: same project as the workflow
 
 - **Datatables resolve PER PROJECT at runtime.** A workflow in project A
   referencing a table in project B fails on every run with
-  `Could not find the data table: '<id>'` — while the table, its columns, and
+  `Could not find the data table: '<id>'` while the table, its columns, and
   permissions are all perfectly intact. When the id matches and structure
   looks fine, the project link is what's broken.
-- **Pass `workflowId` whenever the table serves a specific workflow** (nearly
-  always). The table is then moved into that workflow's owner project —
-  co-location is verified, never assumed.
-- Without `workflowId` the server co-locates only when exactly one project
-  owns your Claude Code drafts. Otherwise the response carries a
-  `projectWarning` ("CLI drafts span N projects — pass workflowId…" or
-  "workflowId … has no owner project — table left where n8n placed it").
-  **Treat `projectWarning` as a failed co-location**: recreate with the right
-  `workflowId` before inserting any rows.
-- Column `type`: `string` | `number` | `boolean` | `date` (default `string`).
-  Column names: letters/digits/underscores, starting with a letter, no
-  spaces — n8n's row API references columns bare, so a spaced name is
-  unwritable even though PG would accept it.
-- Design the full column set up front — schema is effectively frozen (next
-  section).
-
-## Schema is immutable over REST
-
-n8n's REST API cannot alter a table. `action: "add_column"` exists but runs a
-direct database write, so it additionally requires the account's
-`allow_pg_writes` consent — ON by default, and NOT client-toggleable: a
-`consent_required` here means Awesomate disabled it for this account, so the
-remediation is recreating the table with the full column set, or asking
-Awesomate support to re-enable direct database writes.
-There is no rename, drop, or retype at all. Wrong schema and no PG consent →
-create a new table, migrate rows, repoint the workflow.
-
-## Writes only touch self-created tables
-
-`insert` / `update` / `delete_rows` / `add_column` work only on tables created
-through Claude Code. Anything else → `403 not_self_created` — including tables
-provisioned by Awesomate template deploys. Those belong to managed
-automations; do not work around the refusal. Reads are unrestricted:
-`awesomate_n8n_inspect` lists every table.
-
-## Row operations
-
-| action | Requires | Notes |
-|---|---|---|
-| `insert` | `rows`: 1–100 objects | Chunk larger batches |
-| `update` | non-empty `filter` + `data` object | `data` is one object, not an array |
-| `delete_rows` | non-empty `filter` — REQUIRED | There is deliberately no delete-all. To empty a table, delete by filter or recreate it |
+- So the table is created **inside the project that owns the workflow**
+  (on a single-user instance that is the owner's personal project; check
+  `awesomate_n8n_workflows` for which project a workflow sits in). Tell the
+  user which project to be in when they create it, and read it back with
+  `awesomate_n8n_inspect` to confirm before the workflow references it.
+- Design the full column set up front: n8n's REST API cannot alter a table,
+  so a column added later means the user does it in n8n's Data tables UI or
+  the table is recreated. Column `type`: `string` | `number` | `boolean` |
+  `date` (default `string`). Column names: letters/digits/underscores,
+  starting with a letter, no spaces (n8n's row API references columns bare,
+  so a spaced name is unwritable even though PG would accept it).
+- Reference tables **by name** in the Data table node, never by id: a
+  rebuilt table keeps its name and gets a new id.
+- Walk the user through it in their words: "open Data tables, click Add,
+  name it `sent_invoices`, add these three columns, done". Then confirm with
+  `awesomate_n8n_inspect {what: "datatables"}`.
+
+## Rows
+
+Rows are written by the workflow itself (Data table node: insert, update,
+delete with a filter) and read back with `awesomate_n8n_inspect`. To put
+seed rows in by hand, the user pastes them in n8n's Data tables UI. There is
+no delete-all; to empty a table, delete by filter or recreate it.
+
+Tables that arrived with an Awesomate template belong to that managed
+automation: read them freely, never change their schema or rows.
 
 ## The dedupe gate pattern (rowNotExists)
 
-Insert-if-absent as a barrier before side effects — the main reason a
-datatable exists in a client workflow:
+Insert-if-absent as a barrier before side effects: the main reason a
+datatable exists in a client workflow.
 
 1. Table with one key column (e.g. `event_id` string) plus any audit columns.
 2. In the workflow, BEFORE the side effect (email, API call, charge): Data
-   table node with the **row-does-not-exist** operation matching the key —
-   only unseen items pass.
+   table node with the **row-does-not-exist** operation matching the key.
+   Only unseen items pass.
 3. Insert the key immediately after the gate, BEFORE the side effect.
    Insert-first gives at-most-once (right for emails and charges);
    insert-after gives at-least-once (duplicates on crash/retry).
-4. The gate and insert are separate node steps, not a transaction — a webhook
+4. The gate and insert are separate node steps, not a transaction: a webhook
    delivered twice in the same instant can pass both. Acceptable for dedupe;
    not a locking primitive.
 
 Queue-drain workflows (`splitInBatches` over a table) need `executionTimeout`
-set, and `saveExecutionProgress` stays FALSE — both fleet invariants.
+set, and `saveExecutionProgress` stays FALSE. Both are platform invariants
+you keep yourself.
 
 ## Failure decode
 
 | Symptom | Meaning | Fix |
 |---|---|---|
-| `Could not find the data table: '<id>'` at runtime | Project scope, not existence | Recreate/move the table with `workflowId`; check `awesomate_n8n_inspect {what: "datatables"}` vs the workflow's project |
-| `403 not_self_created` | Table wasn't created through Claude Code | Create your own table; never write agency tables |
-| `consent_required` on add_column | `allow_pg_writes` disabled for this account (not client-toggleable) | Recreate with the full schema, or ask Awesomate support |
-| `409 column_exists` | Column name collision | Pick another name; check current columns via inspect |
-| `429 datatable_cap_reached` / `quota_exceeded` | 50-table cap or daily create quota | Stop; reuse or delete tables, or wait for the daily reset |
-| `501 datatables_unsupported` | Instance's n8n version predates data tables | No datatable path — use an external store |
+| `Could not find the data table: '<id>'` at runtime | Project scope, not existence | Recreate the table inside the workflow's project; check `awesomate_n8n_inspect {what: "datatables"}` vs the workflow's project |
+| Data table node cannot see a column | Column name has a space or starts with a digit | Rename it in n8n's Data tables UI |
+| Table count stuck at 50 | n8n's per-instance cap | Reuse or delete tables |
+| Data tables missing from n8n's menu | Instance's n8n version predates data tables | No datatable path; use an external store |

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