Update to Mаke

{
  "name": "make-scenario-operations",
  "description": "Use when running a scenario, switching it on or off, reviewing or debugging executions, or investigating a webhook that receives nothing. Not for creating, editing or explaining a scenario.",
  "included_files": [],
  "skill_md_contents": "---\nname: make-scenario-operations\ndescription: Use when running a scenario, switching it on or off, reviewing or debugging executions, or investigating a webhook that receives nothing. Not for creating, editing or explaining a scenario.\nmetadata:\n  version: \"0.1.7\" # x-release-please-version\n---\n\n# Make scenarios — running and debugging\n\nEverything after a scenario exists: running it, switching it on or off, and the run → inspect → drill-down\nchain for a failure. Know `trigger.kind` (from `scenario_get`) before calling `scenario_run` — its behavior\ndepends on it entirely.\n\n**Ground rules.** A 403 means the whole connection must be re-authorized with every permission — never one\ntool. A `content` remark on a result is an instruction, not decoration. Say what you resolved an ambiguous\nvalue to before the call that acts on it. The refusal contract and the rest: `make-scenario-reference`, when\nsomething is refused or no tool seems to fit.\n\n## Running: `scenario_run`\n\n- **on-demand** — runs with `inputs` keyed by the declared input names and returns the declared outputs.\n- **polling / scheduled** — runs once now; `inputs` are rejected, nothing is returned, the run lands in\n  history.\n- **webhook** — **nothing runs**. The response hands back the webhook URL (or names the app event). Do not\n  report the scenario as \"run\"; have the user send a real request and check `scenario_execution_list`.\n\nAn inactive scenario refuses with a pointer to `scenario_activate` — new scenarios start inactive. A\n`\"pending\"` status means the run outlived the wait: check `scenario_execution_get` with the `executionId`, do\nnot assume failure. A rejected `inputs` key comes back naming the declared interface — read it rather than\nguessing again. Inputs passed to a scenario with no interface are silently unused; a remark says so — relay it.\n\n## Activating and deactivating\n\nTwo separate tools, and an already-satisfied request is success, not an error. An activation refusal almost\nalways means a module still has a configuration error — `scenario_get`'s per-module `issues` say which.\n\n## History: `scenario_execution_list` → `scenario_execution_get`\n\nThe list carries `errorMessage` inline for failed runs — often enough for \"did it work, why not\" without a\nsecond call. A run started moments ago can lag the list by a few seconds (a remark says so; not data loss).\n`scenario_execution_get` is for one run's outcome, outputs and consumption (credits and bytes — usage units,\nnot money); it has no per-module breakdown, so it answers \"did it finish\", not \"which module broke\". The\n`_show` twins only when the user wants a rendered timeline or card.\n\n## Debugging a failed run: `scenario_execution_inspect` → `scenario_execution_module_get`\n\n1. **`scenario_execution_inspect`** — overall status and error, plus every module that ran with invocation and\n   error counts. Make records **one** error per run (the one that ended it); other failures show only as\n   `errorCycles` counts. A **warning** run has no top-level `error` at all — `modules[].errors` is the only\n   signal, so never report \"no error found\" as \"nothing went wrong\".\n2. **`scenario_execution_module_get`** on the suspect module and the `cycle` `inspect` reported (usually 1) —\n   the real input and output that module saw. Never pick a cycle independently; a wrong cycle returns\n   unrelated data with no warning.\n3. Cross-check the current `config` with `scenario_module_get` — but first compare `scenario_get`'s `lastEdit`\n   to the run's `startedAt`. If the scenario was edited after the run, what you read is not necessarily what\n   ran; say so before attributing the bug.\n\n`…[truncated]` marks a cut payload — text, not JSON to parse. A module with no downstream consumer\n(`ReturnData`, `WebhookRespond`, a throw) always reports an empty output here even when correct; the scenario's\nown output lives in `scenario_execution_get`'s `outputs`.\n\n## A webhook that \"isn't receiving data\"\n\n- **`scenario_trigger_inspect`** first: it reports **`queued`** deliveries — requests stored and waiting because\n  the scenario is inactive, paused, or rate-limited. A non-zero `queued.count` is the answer to \"I sent data\n  and nothing happened\" far more often than a broken mapping. It also shows the detected structure and recent\n  deliveries, and with a `deliveryId` one raw request.\n- **`scenario_trigger_learn`** puts the webhook into learning mode: the next request is captured as the\n  structure without running the scenario (safe on an active scenario). Give the user the URL and have them\n  send one real request.\n\nWithheld payloads (confidential or shared webhooks, bodies over 1 MB, binary) are replaced by a placeholder\nand explained in a remark — not \"nothing arrived\".\n\n## Not covered here\n\n- Editing the scenario to fix what you found — `make-scenario-building`.\n- Explaining the scenario without running it — `make-scenario-explore`.\n"
}