- loadConfig: pure over env object, accumulates all problems, names var names only - DATABASE_URL now required at startup; PORT/HOST/LOG_LEVEL/NODE_ENV/REDIS_URL defaulted - flags module behind FeatureFlagProvider; unknown flags OFF; runtime setEnabled (no redeploy) - buildApp decorates app.flags; server.ts fail-fast before app boot - tests caught and fixed flag-store case-normalization bug before gates - zero new dependencies; all gates approved; verify.sh green
1.1 KiB
1.1 KiB
Documenter — F-004 Typed config and feature flags
done -> work/artifacts/F-004/documenter.md
Why documentation applies
F-004 changes the startup contract (DATABASE_URL now required, fail-fast behavior) and introduces the flag mechanism every future risky feature will use.
Documents reviewed/produced
project/README.md: "Configuration" section added at build stage — required/optional vars, fail-fast behavior, FLAG_* semantics, fail-safe defaults, activation ≠ deployment..env.example: REDIS_URL + FLAG_EXAMPLE_FEATURE added with explanatory comments.spec/tech.md: no new dependency rows needed — ticket added zero dependencies by design (noted for audit trail).specs/F-004-config-flags/SPEC/DESIGN/TASKS/TESTS consistent with implementation.
Verification
- README Configuration section cross-checked against config.ts behavior (required DATABASE_URL; PORT/HOST/LOG_LEVEL/NODE_ENV/REDIS_URL defaults; FLAG_* parsing).
- Startup contract change (DATABASE_URL required) is called out explicitly so operators are not surprised.
Pending docs (not this ticket)
- Flag admin transport documented when first consumer lands.