config-and-secrets-hygienelisted

# Config and secrets hygiene Configuration bugs are rarely about the value being wrong. They're about the value landing in a layer nobody reads, a precedence rule nobody remembered, or a flag whose null/missing state does the opposite of what its name implies. This skill is a checklist for avoiding all three. ## Pick the right layer, on purpose Most non-trivial systems end up with several config layers (server-side environment variables, client-side/build-time variables, and a runtime database-backed settings table for things end users or admins can tune). Choose deliberately: - **Server-side env var**: per-deploy, infrastructure-shaped, or secret. - **Client-side/build-time var**: the client needs it and it is *not* a secret. Anything that ends up in a client bundle ships to every browser that loads the app, full stop. - **Runtime, tenant/admin-tunable setting**: an admin should be able to change it without a deploy. This is the highest-overhead option (needs validation, an admin surface, auditing); don't reach for it by default. ## Precedence traps that waste hours - **A misspelled env var may be silently ignored** rather than erroring, if your config loader is configured to ignore unknown keys. If a new variable "does nothing," check the spelling against the exact field name before assuming a deeper bug. - **Process-level environment variables usually beat a checked-in `.env` file**, which usually beats a local-only override file. Know your own stack's order, and che