phase-1: scaffold platform foundation structure and architecture governance
This commit is contained in:
@@ -0,0 +1,36 @@
|
||||
# ADR-004: Configuration Bootstrap and Provider Abstraction
|
||||
|
||||
Status: Accepted
|
||||
Date: 2026-07-03
|
||||
|
||||
## Context
|
||||
|
||||
Configuration must initially come from mock JSON and later from backend API without changing consumers.
|
||||
|
||||
## Decision
|
||||
|
||||
Introduce configuration provider abstraction behind ConfigService.
|
||||
|
||||
- ConfigService is the only configuration entrypoint.
|
||||
- Consumers depend on typed ConfigService selectors only.
|
||||
- Provider implementation is swappable:
|
||||
- MockBootstrapProvider
|
||||
- ApiBootstrapProvider
|
||||
- Frontend calls GET /bootstrap when API provider is enabled.
|
||||
- Frontend does not pass tenant id.
|
||||
|
||||
## Consequences
|
||||
|
||||
Positive:
|
||||
|
||||
- Source-agnostic configuration usage.
|
||||
- Mock-to-backend transition with minimal change surface.
|
||||
|
||||
Negative:
|
||||
|
||||
- Requires strict prohibition of direct JSON imports in components/services.
|
||||
|
||||
## Compliance Requirements
|
||||
|
||||
- No code outside ConfigService may load bootstrap JSON.
|
||||
- No page/widget/component may access configuration files directly.
|
||||
Reference in New Issue
Block a user