0009: Load configuration at its runtime owner
Apps and the CLI load only their own configuration and Turbo inputs
- Status: Accepted
- Date: 2026-09-15
- Decision maker: Trevor Gerhardt
Context
A root launcher made unrelated runtimes share personal configuration. Direct workspace commands behaved differently from root aliases, and root inputs invalidated unrelated Turbo tasks.
Decision
Each executable loads configuration at its own runtime boundary. Next.js apps use Next's file policy. Standalone Concourse tools use the app's @next/env initializer. The CLI installs an Effect ConfigProvider before constructing command Layers. Supplied values win. Production and deployment commands read supplied variables only.
The Concourse Production build runs migrations with Vercel-injected database credentials.
GitHub verifies readiness without reading those credentials. See ADR 0013.
Packages describe and validate the settings their selected adapters need. Runtime roots choose providers and compose Layers. Tests use separate settings and isolated resources. Turbo tasks declare owner-local files and inherited variables as inputs. Static checks do not depend on credentials.
The CLI guide, getting-started guide, and deployment guide own file precedence, commands, and setup instructions.
Consequences
- A root command and its direct workspace equivalent use the same owner-local settings.
- Unrelated apps do not read or hash one another's personal files.
- CLI production commands cannot fall back to local files.
- App and CLI personal overrides remain independent, even when their development defaults point at the same resources.
History
This choice removed the root environment launcher and its shared profile variable.