Skip to content

docs(deploy): correct the Argo ownership claim — FuzeAgent owns its manifests - #151

Draft
github-actions[bot] wants to merge 3 commits into
mainfrom
claude/correct-argocd-ownership-doc
Draft

docs(deploy): correct the Argo ownership claim — FuzeAgent owns its manifests#151
github-actions[bot] wants to merge 3 commits into
mainfrom
claude/correct-argocd-ownership-doc

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

deploy/argocd/README.md opened "a FuzeInfra delegation" and asserted "FuzeInfra
owns Argo Application and AppProject resources. A product repo does not
author them ... This file is the handoff spec, not a manifest."

That is false, and this directory already contradicted it: it carries four
Application manifests, and FuzeInfra's own argocd/applications/fuzeagent.yaml is
a ROOT app-of-apps pointing AT deploy/argocd/applications in this repo — it is
built on the assumption that this repo authors them.

FuzeInfra's docs/CONSUMER_ONBOARDING_SHARED_CLUSTER.md:

"Boundary: the consumer owns its deploy/** (Helm/kustomize + Argo Applications

  • sealed secrets). FuzeInfra owns the cluster, Argo, the tunnel, and the
    shared datastores."

FuzeInfra's .github/workflows/argocd-register.yml is built around it: a "Path in
the consumer repo holding the Argo Application/AppProject manifests", applied
ONCE, after which "ArgoCD polls and self-syncs the consumer's deploy/argocd
manifests".

The same claim was propagated across the fleet in one session and used to DELETE
Applications outright in FuzeService #32 and FuzeSales #44, leaving those repos
with no path to prod. Those are being reverted. FuzeAgent's manifests were not
deleted, so this is documentation-only: git status shows one changed file and
all four manifests are byte-identical to main.

WHAT THE FILE NOW SAYS INSTEAD. The real invariant is ONE Application per
workload. FuzeContact #33 and FuzeMarket #61 removed duplicates — two
Applications with prune+selfHeal on one namespace with disagreeing values.
FuzeAgent's are not that: the app-of-apps recurses into applications/ and each
child owns a DIFFERENT chart. The manifest table is kept, moved under that
explanation, and the "live wiring, do not delete" warning now also says "do not
add a second Application for any chart already listed".

Also recorded: all four use project: fuzeagent, the restricted AppProject
FuzeInfra owns at argocd/projects/fuzeagent.yaml. That project was verified to
exist — unlike several siblings, FuzeAgent has no missing-project blocker.

The A2A finding and everything downstream of it are untouched.

Verified: all four manifests still parse; deploy/helm/fuzeagent,
deploy/helm/a2a-shared and deploy/contabo/sealed all exist. No cluster operation
performed.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01GaPa3JgrVNtWrGvqQEAEqv

izzywdev and others added 3 commits August 10, 2026 17:36
…anifests

deploy/argocd/README.md opened "a FuzeInfra delegation" and asserted "FuzeInfra
owns Argo `Application` and `AppProject` resources. A product repo does not
author them ... This file is the handoff spec, not a manifest."

That is false, and this directory already contradicted it: it carries four
Application manifests, and FuzeInfra's own argocd/applications/fuzeagent.yaml is
a ROOT app-of-apps pointing AT deploy/argocd/applications in this repo — it is
built on the assumption that this repo authors them.

FuzeInfra's docs/CONSUMER_ONBOARDING_SHARED_CLUSTER.md:

  "Boundary: the consumer owns its deploy/** (Helm/kustomize + Argo Applications
   + sealed secrets). FuzeInfra owns the cluster, Argo, the tunnel, and the
   shared datastores."

FuzeInfra's .github/workflows/argocd-register.yml is built around it: a "Path in
the consumer repo holding the Argo Application/AppProject manifests", applied
ONCE, after which "ArgoCD polls and self-syncs the consumer's deploy/argocd
manifests".

The same claim was propagated across the fleet in one session and used to DELETE
Applications outright in FuzeService #32 and FuzeSales #44, leaving those repos
with no path to prod. Those are being reverted. FuzeAgent's manifests were not
deleted, so this is documentation-only: `git status` shows one changed file and
all four manifests are byte-identical to main.

WHAT THE FILE NOW SAYS INSTEAD. The real invariant is ONE Application per
workload. FuzeContact #33 and FuzeMarket #61 removed duplicates — two
Applications with prune+selfHeal on one namespace with disagreeing values.
FuzeAgent's are not that: the app-of-apps recurses into applications/ and each
child owns a DIFFERENT chart. The manifest table is kept, moved under that
explanation, and the "live wiring, do not delete" warning now also says "do not
add a second Application for any chart already listed".

Also recorded: all four use `project: fuzeagent`, the restricted AppProject
FuzeInfra owns at argocd/projects/fuzeagent.yaml. That project was verified to
exist — unlike several siblings, FuzeAgent has no missing-project blocker.

The A2A finding and everything downstream of it are untouched.

Verified: all four manifests still parse; deploy/helm/fuzeagent,
deploy/helm/a2a-shared and deploy/contabo/sealed all exist. No cluster operation
performed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaPa3JgrVNtWrGvqQEAEqv
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant