Make scenarios — running and debugging

Everything after a scenario exists: running it, switching it on or off, and the run → inspect → drill-down chain for a failure. Know trigger.kind (from scenario_get) before calling scenario_run — its behavior depends on it entirely.

Ground rules. A 403 means the whole connection must be re-authorized with every permission — never one tool. A content remark on a result is an instruction, not decoration. Say what you resolved an ambiguous value to before the call that acts on it. The refusal contract and the rest: make-scenario-reference, when something is refused or no tool seems to fit.

Running: scenario_run

• on-demand — runs with inputs keyed by the declared input names and returns the declared outputs.
• polling / scheduled — runs once now; inputs are rejected, nothing is returned, the run lands in history.
• webhook — nothing runs. The response hands back the webhook URL (or names the app event). Do not report the scenario as "run"; have the user send a real request and check scenario_execution_list.