A dry-run evaluates a saved chain against stored historical evidence and reports what would have matched. It never sends a notification, requests a reviewer, adds a label, comments, or changes a check.
When it is required
Draft chains with a GitHub-writing step must have a reviewed dry-run for the current definition before they can be enabled. GitHub-writing steps include review requests, rerouting, labels, comments, and checks.
Notify-only chains can be enabled without that gate, although a supported dry-run can still show matching events.
Supported historical evidence
Dry-run supports bounded pull-request, review, and rule-event replay. It can recover changed-file evidence for path-aware conditions when that evidence is available.
There is no historical dry-run for:
- Deployment triggers.
- Workflow triggers.
- Issue triggers.
- Repository ownership checks.
- Schedules such as
scheduled_report.
Those chains do not require a dry-run gate and can be enabled from the Chains list after configuration is reviewed.
Evidence can be unavailable
Warestack refuses to fabricate a historical count when required facts are incomplete — for example, when a past event cannot prove whether an actor was human or cannot recover a complete changed-file set. Narrow the scope/window or fix the evidence rather than treating unknown as zero.
Definition version matters
Acknowledgment belongs to the exact saved definition. Changing its event, condition, scope, wait, action, or destination makes the old dry-run stale and requires a new replay where the gate applies.
Enabling is not a backfill
Dry-run deliberately replays history without side effects. Enabling a chain starts it for new matching events; it does not blast historical PRs into Slack. These are separate safety properties.
See Automation activity for real executions after enablement.