docs(alerting): Plan 01 — outbound HTTP infra + admin-managed outbound connections

First of three sequenced plans for the alerting feature. Covers:
- Cross-cutting http/ module (OutboundHttpClientFactory, SslContextBuilder,
  TLS trust composition, startup validation)
- Admin-managed OutboundConnection with PG persistence, AES-GCM-encrypted
  HMAC secret (resolves spec §20 item 2)
- Admin CRUD REST + test endpoint + RBAC + audit
- Admin UI page with TLS config, allowed-envs multi-select, test action
- OIDC retrofit deliberately deferred (documented in Task 4 audit)

Plan 02 (alerting backend) and Plan 03 (alerting UI) written after Plan 01
executes — lets reality inform their details, especially the secret-cipher
interface and the rules-referencing integration point.

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

docs/superpowers/backlog.md

@@ -0,0 +1,74 @@
+# Backlog
+
+Deferred items surfaced during design / planning / execution that we've decided *not* to build right now but want to keep visible. Append-only — close items by marking them and moving to the "Closed" section with a link to the delivering commit/spec.
+
+---
+
+## Open
+
+### BL-001 — Managed CA bundles for outbound HTTPS
+
+**Opened:** 2026-04-19
+**Surfaced by:** [Alerting design](specs/2026-04-19-alerting-design.md) — TLS trust section
+**Tracking:** [gitea#137](https://gitea.siegeln.net/cameleer/cameleer-server/issues/137)
+**Status:** Open
+
+**Context.** The alerting feature introduces server → external HTTPS webhooks, which makes outbound TLS trust a cross-cutting concern (joining the existing OIDC token-exchange / JWKS fetch paths). Alerting v1 handles this with a shared `OutboundHttpClientFactory` + system config (`cameleer.server.outbound-http.trusted-ca-pem-paths`) + a per-webhook `TrustMode` override (`SYSTEM_DEFAULT` / `TRUST_ALL` / `TRUST_PATHS`). CA files in v1 are filesystem-resident, managed via deployment config — there is no in-app upload surface.
+
+**What's deferred.**
+
+1. **In-app CA bundle management.** Admin UI to upload, list, and delete trusted CA PEMs. Storage in PG (`trusted_ca_certs` table) so all replicas see a consistent set without a filesystem sync step. Likely lives under `/admin/outbound-http` (new admin surface) or as a tab on the existing admin navigation.
+
+2. **SaaS-layer CA reuse — design investigation (do first).** The SaaS layer already manages CA material for the server (for its reverse-proxy → OIDC path and related). Before building in-app CA management in the OSS server, investigate whether the SaaS CA mechanism can be extended/exposed so the server can consume trust material from the SaaS layer directly. Goal: KISS + DRY — don't duplicate a CA store in the server if the SaaS side already owns one. If reuse is viable, in-app CA upload in the server may never be needed — the SaaS layer becomes the authoritative admin surface and the server just reads.
+
+**Acceptance criteria.**
+- Investigation concludes with a one-page decision: reuse SaaS / build in-server / hybrid, with rationale and an implementation sketch.
+- If "build in-server" is chosen: spec + plan + implementation following the normal flow. Must include PG-backed storage, audit logging on CA change (category already introduced: `OUTBOUND_HTTP_TRUST_CHANGE`), and cluster-consistent propagation.
+- If "reuse SaaS" is chosen: spec for the extension on the SaaS side + a small server-side consumer; the server's current file-path-based trust config remains as the OSS fallback for non-SaaS deployments.
+
+**Why we're not doing it now.**
+- Alerting v1's file-based trust config is identical to how the server handles other trust material today (OIDC issuer URIs, Ed25519 keys), so it's no regression.
+- Building in-server CA management before the SaaS reuse investigation risks duplicating work we may throw away.
+- Most early alerting users will target public SaaS webhooks (Slack, PagerDuty, Teams) whose certs chain to public roots — no custom CA needed.
+
+**Links.**
+- `cameleer-server-app/src/main/java/com/cameleer/server/app/http/` (v1 outbound HTTP module — the investigation will extend this)
+- OIDC trust touch-points in `OidcProviderHelper`, `OidcTokenExchanger` (alignment reference)
+
+---
+
+### 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)_