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
**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)
**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)
