docs(pm): two rendered manifests nothing applies — the keycloak one is a trap

Co-Authored-By: Claude Opus 5 <[email protected]>

DECISIONS-LOG.md

@@ -3298,3 +3298,37 @@ should say how to expose the spec repo to a clone without writing into it.
 - **R-TLS-02 still needs the owner** (revocation is not implementable with cert-manager).
 - **`path_requirements()` leaves 159 of 613 tracked paths (26%) unmapped** — 56 prose, 103 non-prose.
   Measured today; smaller than the 255/476 an older branch claimed, still the larger fail-open.
+
+---
+
+## 2026-09-13 — two rendered manifests that NOTHING applies, and one is a trap
+
+`apps/wave-1/keycloak.yaml` and `apps/wave-0/vm-demo.yaml` are produced by `catalog/render.py`,
+committed, and kept honest by the `render-golden` gate stage — but **no kustomization references
+either**, so Flux never applies them. Verified: `grep -rl <basename> --include=kustomization.yaml`
+returns nothing for both.
+
+**Why the keycloak one is worse than dead weight.** The real Keycloak is operator-managed through
+`platform-config/kustomization.yaml` → `platform/keycloak/keycloak-instance.yaml`, with its own
+ServiceMonitor and the live `KeycloakDown` rule. The rendered ServiceDefinition version is a FULL
+second Deployment of the same service. Someone tidying up "an unreferenced file" by wiring it into
+`apps/wave-1/kustomization.yaml` would stand up a conflicting second Keycloak against the same
+database — and it would look like the obvious fix, because every other rendered app IS wired in.
+It also carried a duplicate ServiceMonitor pointing at the wrong port (found 2026-09-13 during the
+SLI audit), which is how its unreferenced state came to light at all.
+
+**No harm today**: nothing applies them, and Keycloak's liveness is genuinely covered by the
+operator-side ServiceMonitor plus `KeycloakDown`. This is latent risk plus a gate stage spending
+effort on output that reaches no cluster.
+
+**NOT ACTED ON — needs the owner's intent**, because the catalog is the declaration of record and
+there may be a reason both entries exist. The three options, in the order I would pick them:
+1. Keep the catalog entries as the service DECLARATION (ingress, auth, observability contract) but
+   teach the renderer not to emit a workload for a service whose workload is operator-managed —
+   a flag such as `source: operator-managed`. Keeps the contract, removes the trap.
+2. Remove `catalog/keycloak.yaml`, moving its ingress/auth declaration to `platform/keycloak/`
+   alongside the instance it describes. Loses the uniform catalog view of the service.
+3. Wire nothing, delete nothing, and add a prominent DO-NOT-WIRE header to both rendered files.
+   Cheapest, and relies on a comment — which is the mechanism this repo has already watched fail
+   (the bulk StorageClass sat as a REPLACE-ME stub behind four hand-written comments).
+`vm-demo` is likely just an undeployed demo and may only need option 3.