The lab hands generation of the critical loader to the AI ("load the .env file with a few lines of plain Python"). Part D's headline demo (APP_ENV=staging python sync.py overriding .env's dev) only works if the loader uses os.environ.setdefault so real/CLI env wins. A very common AI-generated minimal loader uses plain assignment os.environ[key]=value, in which case .env overwrites the command-line override, the URL doesn't change, the "same code, different environment" point silently fails, and nothing tells the learner why. This precedence is load-bearing yet unexplained.
Evidence
modules/17-secrets-config-and-environments/README.md Part C prompt (~line 335): "load the .env file with a few lines of plain Python." Model answer (~line 352) uses os.environ.setdefault(...). Part D (~lines 388-389, 397): "Watch the backend URL change with APP_ENV while the source never does."
Reproduced: plain-assignment loader → APP_ENV=staging resolves to dev.
Why it matters
The module's payoff silently fails for a plausible AI output, and the Check-for-understanding test fails, with no diagnostic — against the explain-the-why voice and honesty promise.
Proposed change
State that the loader must NOT overwrite already-set variables — use os.environ.setdefault(...) so real/CLI env wins over the file (matches the real-world dotenv default override=False).
Explain that this precedence is exactly what makes Part D work.
Add a verification line: "if the URL didn't change, your loader is clobbering existing vars."
Acceptance criteria
Part C's prompt/requirements specify that the loader must not overwrite already-set vars.
The README explains why setdefault precedence makes Part D's override work.
A diagnostic hint is given for the clobbering failure mode.
Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.
## Problem
The lab hands generation of the critical loader to the AI ("load the .env file with a few lines of plain Python"). Part D's headline demo (`APP_ENV=staging python sync.py` overriding .env's `dev`) only works if the loader uses `os.environ.setdefault` so real/CLI env wins. A very common AI-generated minimal loader uses plain assignment `os.environ[key]=value`, in which case .env overwrites the command-line override, the URL doesn't change, the "same code, different environment" point silently fails, and nothing tells the learner why. This precedence is load-bearing yet unexplained.
## Evidence
`modules/17-secrets-config-and-environments/README.md` Part C prompt (~line 335): "load the .env file with a few lines of plain Python." Model answer (~line 352) uses `os.environ.setdefault(...)`. Part D (~lines 388-389, 397): "Watch the backend URL change with APP_ENV while the source never does."
Reproduced: plain-assignment loader → `APP_ENV=staging` resolves to `dev`.
## Why it matters
The module's payoff silently fails for a plausible AI output, and the Check-for-understanding test fails, with no diagnostic — against the explain-the-why voice and honesty promise.
## Proposed change
1. State that the loader must NOT overwrite already-set variables — use `os.environ.setdefault(...)` so real/CLI env wins over the file (matches the real-world dotenv default `override=False`).
2. Explain that this precedence is exactly what makes Part D work.
3. Add a verification line: "if the URL didn't change, your loader is clobbering existing vars."
## Acceptance criteria
- [ ] Part C's prompt/requirements specify that the loader must not overwrite already-set vars.
- [ ] The README explains why `setdefault` precedence makes Part D's override work.
- [ ] A diagnostic hint is given for the clobbering failure mode.
## Affected files
- `modules/17-secrets-config-and-environments/README.md`
## References
Source finding F44 (realVotes 3/3).
---
*Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The lab hands generation of the critical loader to the AI ("load the .env file with a few lines of plain Python"). Part D's headline demo (
APP_ENV=staging python sync.pyoverriding .env'sdev) only works if the loader usesos.environ.setdefaultso real/CLI env wins. A very common AI-generated minimal loader uses plain assignmentos.environ[key]=value, in which case .env overwrites the command-line override, the URL doesn't change, the "same code, different environment" point silently fails, and nothing tells the learner why. This precedence is load-bearing yet unexplained.Evidence
modules/17-secrets-config-and-environments/README.mdPart C prompt (~line 335): "load the .env file with a few lines of plain Python." Model answer (~line 352) usesos.environ.setdefault(...). Part D (~lines 388-389, 397): "Watch the backend URL change with APP_ENV while the source never does."Reproduced: plain-assignment loader →
APP_ENV=stagingresolves todev.Why it matters
The module's payoff silently fails for a plausible AI output, and the Check-for-understanding test fails, with no diagnostic — against the explain-the-why voice and honesty promise.
Proposed change
os.environ.setdefault(...)so real/CLI env wins over the file (matches the real-world dotenv defaultoverride=False).Acceptance criteria
setdefaultprecedence makes Part D's override work.Affected files
modules/17-secrets-config-and-environments/README.mdReferences
Source finding F44 (realVotes 3/3).
Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.