From 532c56472fe34ed7779293c1e6c9c3fd493f37e4 Mon Sep 17 00:00:00 2001 From: Israel Weinberg <99821070+izzywdev@users.noreply.github.com> Date: Sun, 23 Aug 2026 09:47:51 +0300 Subject: [PATCH] docs(argocd): the app-of-apps header told maintainers to delete the AppProject this repo now owns MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit deploy/argocd/project.yaml has landed — the `fuzefront` AppProject is decentralised into this repo like the rest of the family. The app-of-apps header still said the opposite: # NOTE: the `fuzefront` AppProject is owned & provisioned by FuzeInfra # (FuzeInfra#99). # Do NOT apply a fuzefront AppProject from this repo — re-applying a stale # copy would re-widen prod cross-namespace access to fuzeinfra (issue #502). As written that instructs a maintainer to refuse to apply, or to delete, the very file that now carries the isolation boundary. FuzeInfra#99 established the RULE, not the file's location: `fuzeinfra` is never a destination for a consumer project. That rule travels with deploy/argocd/project.yaml and is restated at length in its header. Issue #502 was a stale, WIDER copy being re-applied; the in-repo copy is strictly NARROWER than FuzeInfra's (clusterResourceWhitelist is Namespace-only, not `*/*`), so applying it cannot re-widen anything. Also records why `project: fuzefront` matters at all: an Application left on `project: default` resolves against the permissive cluster-wide project and never consults the narrow one — the AppProject then exists as a file and enforces nothing. That is the fleet-wide defect this change is a companion to (FuzePlan#197, FuzeExecutive#41). Comment-only. No rendered Kubernetes object changes; verified the manifest still parses to exactly one Application (fuzefront-apps, project fuzefront, destination namespace argocd). Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GaPa3JgrVNtWrGvqQEAEqv --- deploy/argocd/app-of-apps.yaml | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/deploy/argocd/app-of-apps.yaml b/deploy/argocd/app-of-apps.yaml index 5b0ec2446..4211fd6ab 100644 --- a/deploy/argocd/app-of-apps.yaml +++ b/deploy/argocd/app-of-apps.yaml @@ -1,8 +1,26 @@ # Root "app of apps": apply this once after bootstrap and Argo manages the rest. # kubectl apply -f deploy/argocd/app-of-apps.yaml -# NOTE: the `fuzefront` AppProject is owned & provisioned by FuzeInfra (FuzeInfra#99). -# Do NOT apply a fuzefront AppProject from this repo — re-applying a stale copy would -# re-widen prod cross-namespace access to fuzeinfra (issue #502). +# NOTE: the `fuzefront` AppProject now lives in THIS repo, at +# deploy/argocd/project.yaml — decentralised from FuzeInfra along with the rest +# of the family. FuzeInfra's copy (argocd/projects/fuzefront.yaml) is pending +# deletion, tracked in FuzeInfra#625; until that lands both exist and +# registration is last-write-wins. +# +# This header previously said the opposite — "owned & provisioned by FuzeInfra +# (FuzeInfra#99). Do NOT apply a fuzefront AppProject from this repo" — which +# now reads as an instruction to refuse to apply, or to delete, the very file +# that carries the isolation boundary. What FuzeInfra#99 established is the +# RULE, not the file's location: `fuzeinfra` is never a destination for a +# consumer project. That rule travels with deploy/argocd/project.yaml and is +# restated at length in its header. Issue #502 was a stale, WIDER copy being +# re-applied; the in-repo copy is strictly narrower than FuzeInfra's +# (clusterResourceWhitelist is Namespace-only instead of `*/*`), so applying it +# cannot re-widen anything. +# +# `project: fuzefront` below — and on every Application under +# deploy/argocd/applications/ — is what makes that AppProject enforce anything +# at all. An Application left on `project: default` resolves against the +# permissive cluster-wide project and never consults the narrow one. apiVersion: argoproj.io/v1alpha1 kind: Application metadata: