You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add notification system for scheduled triggers
Replace the single-tracking-issue approach with a provider-based notification
layer. Scheduled findings now route through configurable providers (GitHub Issues,
Slack) with suppression rules for false positive management.
- Add GitHub Issues provider with two-tier dedup (hash + semantic via Haiku)
- Add Slack provider with Block Kit webhook posting
- Add YAML-based suppression system (skill + glob paths + title matching)
- Add notification dispatcher to orchestrate suppression and provider execution
- Remove createOrUpdateIssue and issue-renderer (replaced by providers)
- Remove issueTitle from schedule config schema
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Warden's scheduled triggers analyze the full codebase on a cron. Today, findings go to a single tracking issue per skill that gets overwritten each run. There's no way to:
6
+
- Get notified in Slack when new findings appear
7
+
- Mark findings as false positives so they don't recur
8
+
- Track individual findings across runs
9
+
10
+
## Goals
11
+
12
+
1. Per-finding GitHub issues with semantic dedup across runs
13
+
2. Slack webhook notifications for new findings
14
+
3. Suppression file for false positives (rule-based pre-filtering)
15
+
4. Replace the single-tracking-issue approach with a provider-based notification layer
16
+
17
+
## Configuration
18
+
19
+
### `warden.toml`
20
+
21
+
```toml
22
+
[[notifications]]
23
+
type = "github-issues"
24
+
labels = ["warden"]
25
+
26
+
[[notifications]]
27
+
type = "slack"
28
+
webhookUrl = "$SLACK_WEBHOOK_URL"
29
+
```
30
+
31
+
Top-level `[[notifications]]` array. Each provider receives all non-suppressed findings independently. Environment variables expanded at runtime via `$VAR` syntax.
32
+
33
+
### Migration
34
+
35
+
The `[[notifications]]` section replaces the existing `schedule.issueTitle` tracking-issue approach. The `createOrUpdateIssue` code path and `schedule.issueTitle` config are removed. `schedule.createFixPR` and `schedule.fixBranchPrefix` remain (fix PRs are orthogonal to notifications).
0 commit comments