generated from coulomb/repo-seed
45 lines
1.4 KiB
Markdown
45 lines
1.4 KiB
Markdown
# Configuration Boundaries
|
|
|
|
## Standalone Mode
|
|
|
|
Standalone mode is for local development, tests, prototypes, and small
|
|
single-service deployments.
|
|
|
|
Expected characteristics:
|
|
|
|
- local configuration file or environment variables;
|
|
- local database or file-backed persistence during early development;
|
|
- fixture or local identity claims adapter;
|
|
- deterministic authorization test adapter;
|
|
- no password, MFA, or token issuance responsibility inside user-engine.
|
|
|
|
## Platform Mode
|
|
|
|
Platform mode is for a NetKingdom-aligned shared service deployment.
|
|
|
|
Expected characteristics:
|
|
|
|
- verified IAM Profile claims arrive from an identity layer;
|
|
- authorization decisions are requested through the authorization check port;
|
|
- runtime secrets are delivered through a scoped secret provider;
|
|
- audit records and outbox events are correlated with platform sinks;
|
|
- tenant and application bindings are explicit.
|
|
|
|
## Secret Names
|
|
|
|
The code should refer to logical secret names, not platform paths. Concrete
|
|
secret lookup is owned by the active `SecretProvider` adapter.
|
|
|
|
Initial logical names:
|
|
|
|
- `database.url`
|
|
- `event.signing_key`
|
|
- `webhook.shared_secret`
|
|
|
|
## Production Guardrails
|
|
|
|
- Local issuers must be rejected by production adapters.
|
|
- Sensitive writes must fail closed when authorization is unavailable.
|
|
- Claims enrichment must be optional and must not make user-engine a token
|
|
issuer.
|