diff --git a/k8s/cluster-gke-peach/kustomization.yaml b/k8s/cluster-gke-peach/kustomization.yaml
index 518934b..30e0d80 100644
--- a/k8s/cluster-gke-peach/kustomization.yaml
+++ b/k8s/cluster-gke-peach/kustomization.yaml
@@ -84,6 +84,31 @@
 # reports a mode other than `standalone`. That guard existed BECAUSE of the
 # context-dropping bug; relax it in the same change that repoints the URL, not
 # before, so a stale image cannot be adopted silently.
+#
+# The consumer also needs the CA, because `:9500` serves TLS from the cluster's
+# OWN cert-manager root and no public root can verify it. Kubernetes Secrets do
+# not cross namespaces, so `ca.crt` from `tidaldb-cluster-ca` has to be copied
+# into the consumer's namespace (peach reads it via
+# `TidalClient::from_env_with_ca`).
+#
+# A copied certificate deserves suspicion — k3s-fleet's own history records an
+# incident where "the expired central SDLC wildcard had been copied manually
+# and never renewed into its consumer namespaces". This copy is materially
+# different and the numbers are why:
+#
+#   tidaldb-cluster-ca   duration 87600h (10y), renewBefore 8760h (1y)  isCA
+#   tidaldb-cluster-tls  duration  2160h (90d), renewBefore  720h (30d)
+#
+# The 90-day LEAF is what rotates, roughly every 60 days, and it rotates UNDER
+# this same root — so the copied CA keeps verifying it and needs no attention.
+# The fleet incident was an expiring leaf; this is a decade-lived root.
+#
+# The coupling that DOES bite is recreation, not expiry: `tidaldb-cluster-ca` is
+# self-signed and generated fresh on first apply, so destroying and re-applying
+# this namespace mints a NEW root and every copy goes stale at once — every
+# consumer request then fails TLS verification with nothing wrong on either
+# side. Treat "refresh the CA copy" as a mandatory step of any recreate, and
+# prefer `kubectl rollout restart` over deleting the namespace.
 apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization