Verified Incident Response (demo)

The primary demo bundled workflow (wf-cascades-incident-response) is the canonical example in tests and docs. It exercises webhook → api → agent → condition branching with payload paths from enrichment.

Use it to validate your worker, Redis queue, and proof pipeline end-to-end. See Immutable snapshots and DAG execution.

Trigger shape (sample payload)

Run with sample inputs POSTs context roughly like:

{ "sampleAlert": { "id": "DEMO-001", "severity": "high", "source": "pager" } }

That merges into workflow_run.context under the dashboard baseline (source: "dashboard-run").

Node-by-node

1. Webhook trigger — ingress (HTTP executor path).
2. Enrich Context — internalEcho: GET /api/workflow-echo on this deployment (set CASCADES_INTERNAL_ORIGIN if the worker is off-origin). Output is stored as enrich_output.
3. Agent triage — stub agent; policy-bound model yields high severity so the policy gate tends toward the notify branch.
4. Policy gate — severity condition; TRUE → GitHub integration gate.
5. GitHub integration? — hasIntegration:github. TRUE → live GitHub notify; FALSE → internal stub transform (no external call).
6. Execute remediation — tool stub on the non-escalation branch.

Run with sample inputs

Use the builder button or:

POST /api/workflows/run
{ "workflow_id": "wf-cascades-incident-response", "context": { "sampleAlert": { "id": "DEMO-001", "severity": "high", "source": "pager" } } }

Expected logs

• workflow_started, task_started / task_completed per node.
• No integration_missing on the GitHub node when integration is absent — the guard routes to the stub instead.
• If you force the live GitHub node without config (custom graph), you would see integration_missing (warn) then task_failed.

Proof summary

After completion, proof_records.metadata includes compact fields such as successfulTaskCount, failedTaskCount, and integrationFailures (count of integration_missing log rows — usually 0 on bundled presets).