@awesomate/hosting-mcp
Version:
Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases
36 lines (30 loc) • 1.68 kB
Markdown
# 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.