catalog-agent was one rename too aggressive: 'catalogue' is accepted, and the
Keycloak client, its audience scope and the Vault key that names it were never
renamed to match — leaving an inconsistency between what Kubernetes and
Keycloak call the same agent. Keycloak carries more weight to move, so this
side moves back.
k8s/namespace.yaml is out of this Kustomization's inventory. It was in
2026-08-31 when renaming the Kustomization pruned the old one — which owned
the namespace three agents share — and took all three down. A namespace shared
across repos should not be owned by any one of them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
catalogue-agent and approvisionnement-agent named a Deployment, a Service, an
Ingress and a Certificate in French, in an estate where nothing else is.
The peer URLs move with them, set through the existing per-environment override
so the rename takes effect without rebuilding an image; the defaults in the code
carry the same values for the next build.
The Keycloak client ids, the image names and the repository names are still
French. They are a separate, heavier move.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
assistant-agent.sttlab.local and its two siblings were long, and two of them
were French where nothing else in the estate is.
The Kubernetes object names are unchanged — they name a Deployment and a
Service, and nobody types them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nothing outside the cluster could talk to it: every conversation went through
kubectl run curl, which makes an agent that works and nobody can use.
The same authentication subrequest that guards the n8n endpoints guards this
one. The agent forwards and exchanges the caller's token, so a forged one
fails at the realm — but failing downstream is not refusing, and an
unauthenticated caller could still make it do inference.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>