docs(alerting): spec for alerting feature + backlog entry BL-001

Comprehensive design spec for a confined, env-scoped alerting feature:
6 signal sources, shared env-scoped rules with RBAC-targeted notifications,
in-app inbox + webhook delivery via admin-managed outbound connections,
claim-based polling for horizontal scalability, 4 CH projections for hot-path
reads. Backlog entry BL-001 / gitea#137 tracks deferred managed-CA investigation
(reuse SaaS-layer CA handling first before building in-server storage).

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

docs/superpowers/backlog.md

@@ -0,0 +1,42 @@
+# 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)
+
+---
+
+## Closed
+
+_(nothing yet)_