refactor(runtime): prefer env-backed secrets at runtime

This commit is contained in:
2026-03-30 19:17:32 +02:00
parent 4f5d410b94
commit fed7aa5b61
13 changed files with 532 additions and 71 deletions
@@ -50,6 +50,7 @@ The previously critical SSE and browser parser coverage issues were addressed du
2. Secret handling is still application-database centric.
Evidence: system settings mutate and persist API keys and SMTP credentials in [settings.ts](/home/hartmut/Documents/Copilot/capakraken/packages/api/src/router/settings.ts).
Risk: operational secrets remain too coupled to the main app data plane for a gold-standard project.
Update: runtime resolution is now env-first for the active secret consumers, but persistence is still transitional and should be reduced further.
3. Least-privilege is materially better documented now, but it still needs long-lived enforcement rather than relying mainly on one hardening batch.
Evidence: the route audience model is now explicit in [route-access-matrix.md](/home/hartmut/Documents/Copilot/capakraken/docs/route-access-matrix.md) and backed by multiple focused auth tests, but the remaining guarantee still depends on continuing test coverage and architecture guardrails as new routes evolve.
@@ -124,6 +125,7 @@ Goals:
- Keep hardened spreadsheet parser boundaries under regression coverage.
- Treat the route access matrix and narrowed auth slices as maintained architecture contracts.
- Move production secrets out of regular application settings, or add an interim encrypted-secrets layer with clear migration path.
Status: in progress. Runtime consumers now prefer environment overrides; the remaining gap is eliminating or encrypting compatibility persistence in the admin settings path.
Definition of done: