Recommend Flux for dev namespace, keep kubectl as fallback

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-21 15:20:23 -04:00
parent 91a3a29fff
commit 75ff06be00
1 changed files with 1 additions and 1 deletions
@@ -50,7 +50,7 @@ When you need an infrastructure change:
  - **`privilegedescalation` namespace**: read-write (production — changes MUST go through Flux, not kubectl)
  - **`privilegedescalation-dev` namespace**: read-write (development — agents may use kubectl freely for testing, debugging, and iteration)
 - **Production (`privilegedescalation`)**: All changes go through the infra repo and Flux. Do not `kubectl apply` to production. Flux will revert manual changes.
- **Development (`privilegedescalation-dev`)**: Agents may `kubectl apply`, `kubectl delete`, and use any mutating commands freely. This namespace is for testing and validation before committing to the infra repo.
+- **Development (`privilegedescalation-dev`)**: Prefer Flux-managed manifests in the infra repo even for dev workloads. Agents have read-write kubectl access for rapid iteration and debugging, but changes should be committed to the infra repo once validated.
 - **Headlamp**: Production Headlamp runs in `kube-system`. Development/testing Headlamp instances go in `privilegedescalation-dev`. Never deploy test plugins to the production Headlamp in `kube-system`.
 - If you need a production infrastructure change, create a PR against the infra repo (or create a Paperclip issue for the agent who owns infra).