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>
An agent talks to URLs that honour a contract: an MCP endpoint, an OIDC token
endpoint, an OpenAI-shaped LLM endpoint. Whatever serves those URLs is
replaceable, and naming it in an agent's code or docs implies a coupling that
does not exist.
Every product name is gone from prose, comments and identifiers, replaced by
what the agent actually depends on. Where a behaviour of the current middleware
leaks into the contract — the second audience scope, the tool ACL — the text
now says what the caller must do and why, not who imposes it.
One string survives and cannot be fixed here: the broker client an agent must
name in its audience scopes is itself named after the middleware. Closing that
means renaming it in Keycloak and following the rename through the gateway
configuration and LibreChat. Recorded as a blocker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two-stage Dockerfile: the runtime image carries neither uv nor a build
toolchain, runs as uid 10001, drops every capability and needs no writable
filesystem (verified with --read-only and no tmpfs).
k8s/ is what runs, dev/ is the Flux plumbing that applies it, self-managing
after three manual applies — the same shape every kong-* repo settled on.
Three choices worth naming:
- One namespace for the estate. What isolates an agent is its Keycloak client
and the audiences it may request, not a namespace boundary.
- The GitRepository uses anonymous HTTPS rather than SSH with a Vault-held
deploy key. The repo is already anonymously readable on gitea, so a key would
guard nothing while adding two objects to create by hand before anything
deploys. If the repos ever go private this becomes the kong-* SSH pattern.
- The lab CA certificate is committed. It is a certificate, never a key, and
checking it in means the deployment has no hidden prerequisite.
replicas: 1 is a constraint, not a default — conversation history lives in the
process, so a second replica would route a user's "yes" to a pod that never saw
the question.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stéphane Tailland