awb-config-guardlisted

# Config guard — two contexts, two levels > **Announce on activation:** "Using awb-config-guard — checking access context and key level." Config bugs are quiet. The code runs, returns `None` or reads a stale value, and the failure surfaces somewhere far away — an `AttributeError` on `None`, a per-request file read that drags latency, a setting that silently never takes effect. The cheapest place to stop that is before you write the access. ## HARD GATE — verify BOTH before writing config-access code 1. **Context** — *where* does this code run? Many apps expose config through two doors: an in-request accessor (cached, valid only inside a framework request) and an out-of-band loader (`load_config(path)` for scripts, jobs, init). Use the wrong one and you get a runtime error ("working outside of application context") or a file read on every request. 2. **Level** — is the key **top-level** or **nested** under a container? A nested key read one level deep returns `None` *silently* — no exception, just wrong behavior downstream. If either is unclear, stop and read the two sections below before writing code. ## Two contexts — don't cross them | Accessor | Use when | |---|---| | the in-request accessor (e.g. `get_cfg()`) | inside a framework request (routes, request-scoped services) | | the out-of-band loader (e.g. `load_config(path)`) | outside the framework (scripts, batch jobs, init) | ## Two levels — the silent-None trap A key under a container must be read *