diff --git a/AGENTS.md b/AGENTS.md
index 7fe9763..0475538 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -75,7 +75,9 @@ When adding values, keep defaults identical to `config-default.yaml` so a defaul
 
 ## developer-portal-fe chart: config is a pass-through
 
-`config.yaml` is rendered from `developerPortal.config`, which carries the application's whole config schema. **Do not add per-field `.Values` keys for it** — the schema lives in `api7/api7ee-developer-portal` (`apps/site/src/lib/config/schema.ts`) and mirroring it drifts on every application release. Only the connection settings the chart itself owns are templated, and they are merged over the block so a user cannot move the Secret-backed `${PORTAL_TOKEN}` / `${DB_URL}` / `${AUTH_SECRET}` placeholders into the ConfigMap.
+`config.yaml` is rendered from `developerPortal.config`, which carries the application's whole config schema (owned by `api7/api7ee-developer-portal`, `apps/site/src/lib/config/schema.ts`). **Do not hoist schema fields into their own `.Values` keys** — a dedicated key plus template plumbing per field mirrors that schema, drifts on every application release, and leaves two ways to set one field. Only the connection settings the chart itself owns are templated, and they are merged over the block, so a user cannot replace the `${PORTAL_TOKEN}` / `${DB_URL}` / `${AUTH_SECRET}` placeholders with literal credentials — those placeholders stay in the ConfigMap and resolve from Secret-backed env vars at startup.
+
+That is not a licence to skip chart releases: pass-through only means a user is never *blocked* on one, while `values.yaml` is still how they find out an option exists. When the application adds config worth surfacing, add it under `developerPortal.config` and cut a chart release. Write it as a commented example rather than a live default — a live default pins the application's default of that day into the chart and keeps overriding it after the application moves on.
 
 To verify a rendered config, run it through the image's own loader: `docker run --rm -v $PWD/config.yaml:/app/apps/site/config.yaml -e PORTAL_TOKEN=x -e DB_URL=x -e AUTH_SECRET=$(head -c 32 /dev/zero | tr '\0' a) --entrypoint sh api7/api7-ee-developer-portal-fe:<ver> -c 'node preflight.js'` — reaching the `Portal URL:` line means the config validated (the portal/database checks after it need a live backend). That mount path is fixed: the standalone server chdirs into `apps/site`, and preflight looks there.