claude-bot
b846faa8b3
A cold-rebuild test against an empty API server stopped here permanently: infrastructure False ExternalSecret/apps/external-dns-unifi-secret dry-run failed: no matches for kind "ExternalSecret" in version "external-secrets.io/v1" Flux server-side dry-runs the whole apply set, so a single unknown kind rejects all of it — including the ESO HelmRelease that installs the very CRD the dry-run is missing. The VM cluster confirmed it: zero HelmReleases, zero ESO CRDs. The deadlock cannot resolve itself, and no amount of waiting changes that. Eight ExternalSecrets and three Traefik Middlewares sat beside their consumers under infrastructure/, whose own HelmReleases install their CRDs. They move to post-crds/, which exists for exactly this and already held the OpenBao ClusterSecretStore and the Velero Schedules on the same grounds. Velero's ServiceMonitor and PodMonitor could never have applied there at all: monitoring.coreos.com CRDs come from kube-prometheus-stack under apps/, which reconciles after infrastructure. They move to apps/monitoring-rules/, whose Flux Kustomization already carries a comment describing this precise failure for PrometheusRule — the same diagnosis, made once and never carried across. None of this was reachable in production, where the CRDs have existed since the day each operator was introduced. Ordering only becomes load-bearing when something applies it against nothing, and until now nothing ever had. The ExternalSecret in openbao/rotation/flux-git.yaml is split out; the ServiceAccount and rotation CronJob stay where they are. Merging this transfers ownership between Kustomizations, so Flux prunes each object from infrastructure and recreates it under infrastructure-crds or monitoring-rules. The Secrets ESO owns vanish for that window — running pods keep their mounted copies, but a pod starting in the gap will not find them.