refactor(runtime): prefer env-backed secrets at runtime
This commit is contained in:
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user