docs(alerting): add BL-002 for native provider integrations + Mustache auto-complete

BL-002 / gitea#138 tracks deferred native provider types (Slack Block Kit,
PagerDuty Events v2, Teams connector) with shipped templates as a post-v1
fast-follow once usage data informs which providers matter.

Spec §13 folds in context-aware variable auto-complete for the shared
<MustacheEditor /> component used in rule editor, webhook overrides, and
outbound-connection admin. Available variables filter by condition kind.
Completion engine choice added to §20 as a planning-phase decision.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/superpowers/backlog.md

@@ -37,6 +37,38 @@ Deferred items surfaced during design / planning / execution that we've decided
 
 ---
 
+### BL-002 — Native provider integrations for alerting (Slack, Teams, PagerDuty with shipped templates)
+
+**Opened:** 2026-04-19
+**Surfaced by:** [Alerting design](specs/2026-04-19-alerting-design.md) — §2 Out of scope
+**Tracking:** [gitea#138](https://gitea.siegeln.net/cameleer/cameleer-server/issues/138)
+**Status:** Open
+
+**Context.** Alerting v1 ships with generic outbound webhooks + JMustache templates — users paste their Slack incoming webhook URL (or PagerDuty Events API key, or Teams connector URL) and write the body from scratch. A natural fast-follow is to elevate the most common providers to first-class connection types with tuned default templates, provider-specific config hints, and test actions that speak each provider's native format.
+
+**What's deferred.**
+- `SLACK_INCOMING_WEBHOOK` connection type with Block Kit default body template and URL-shape validation.
+- `PAGERDUTY_EVENTS_V2` with routing-key input (not URL) and default body tuned to the Events API v2 — including `dedup_key` tied to alert-instance id, severity mapping, and auto-resolve via `event_action: resolve` on alert RESOLVED.
+- `MS_TEAMS_CONNECTOR` with adaptive-card/MessageCard default.
+- Optional follow-ons: Discord, OpsGenie.
+
+**Acceptance criteria.**
+- Decide on the first 2 providers based on usage data from alerting v1 (likely Slack + PagerDuty).
+- Ship templates as versioned resources (`outbound-templates/slack-v1.mustache`) so they can iterate without breaking existing connections.
+- Golden-file tests per provider type — payload matches current documented format.
+- Provider-integration guide in docs.
+
+**Why we're not doing it now.**
+- Generic webhook + Mustache covers every target today; not a blocker.
+- Provider schemas drift (Slack deprecated old JSON once; Teams connectors are on a deprecation path as of late 2025); shipping baked-in templates is a maintenance commitment.
+- Usage data will tell us which providers actually matter — shipping three speculatively is wasted work.
+
+**Links.**
+- `cameleer-server-core/src/main/java/com/cameleer/server/core/outbound/` (v1 connection model — extend with `OutboundConnectionType` sealed hierarchy)
+- Related (different concern): BL-001 / [gitea#137](https://gitea.siegeln.net/cameleer/cameleer-server/issues/137)
+
+---
+
 ## Closed
 
 _(nothing yet)_