DECISIONS: D10 #6 bluesky-pds (TLS-passthrough) swapped to n8n — caddy self-ACME conflicts with no-ACME design

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

DECISIONS.md

@@ -90,6 +90,21 @@ Architecture decisions and dead-ends. One line of rationale each. (§0, §8)
   - Optional `concurrency: {limit: 1}` in the recipe-CI `.drone.yml` is a redundant belt — primary
     mechanism is `DRONE_RUNNER_CAPACITY`. (Wired when the recipe-CI pipeline lands — see backlog.)
 
+- **D10 recipe #6: bluesky-pds (TLS-passthrough) SWAPPED → n8n — SETTLED (2026-05-27, plan §4.0
+  sanctions this swap-with-reason).** bluesky-pds routes via a Traefik **TCP router with
+  `tls.passthrough=true`** to an in-container **caddy** that terminates TLS itself and obtains its own
+  cert via **ACME**. cc-ci's design is the opposite: the operator gateway passes wildcard TLS through
+  to cc-ci's Traefik, which **terminates** it with the pre-issued static wildcard cert, and **ACME is
+  hard-forbidden** for commoninternet.net (no DNS token on the box — §4.0/§9). Serving bluesky-pds
+  would require either (a) ACME inside caddy (forbidden), or (b) injecting the wildcard cert into
+  caddy + a per-host TCP-passthrough router on cc-ci Traefik (recipe-internal surgery + a bespoke
+  proxy mode — not a clean shared-harness absorb). This is a genuine design conflict, not a harness
+  gap. Per the plan's explicit allowance, **bluesky-pds is a documented non-CI'd recipe** (reason
+  here), and **n8n** takes the 6th slot. The 5 required D10 categories are already covered by recipes
+  1–5 (simple=custom-html, single-DB+SSO=keycloak, stateful/no-DB=cryptpad, DB+media/large-volume=
+  matrix-synapse, multi-service+S3/object-storage=lasuite-docs); n8n adds a 6th real deployable app
+  (workflow automation) behind the normal terminate-at-Traefik path.
+
 ## Open (defaults from §8, to confirm as reality lands)
 
 - **Deploy mechanism — SETTLED (M0):** `nixos-rebuild switch --flake /root/cc-ci#cc-ci` run *on