38 lines
1.6 KiB
Markdown
38 lines
1.6 KiB
Markdown
# ADR 0002: Daily Fortune Contract Ownership
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The device needs to receive a user birth profile over its LAN configuration
|
|
page, persist it, fetch a daily fortune after wall-clock
|
|
synchronization, and apply the returned wealth direction. This workflow crosses
|
|
transport, storage, domain data, and orchestration boundaries.
|
|
|
|
## Decision
|
|
|
|
- `platform` owns opaque persistent blob storage, SNTP time synchronization,
|
|
and bounded raw LAN HTTP transport primitives.
|
|
- `domain` owns the typed birth-profile and daily-fortune result contracts,
|
|
persistence adapters, direction-name aliases, and user configuration routes.
|
|
- `control_plane` owns HTTP fetch, retry, local-midnight scheduling, result
|
|
refresh policy, configuration-server connectivity lifecycle, and the
|
|
wealth-direction apply sequence.
|
|
- `app_composition` continues to start the existing control-plane runtime worker
|
|
set and does not gain fortune policy logic.
|
|
- The favorable-color element is persisted and logged. LCD color presentation
|
|
is deferred because it requires a separate semantic expression contract and
|
|
assets.
|
|
|
|
## Consequences
|
|
|
|
- The stateless server can be called every day because the device retains the
|
|
birth profile in NVS through an opaque platform storage API.
|
|
- Upper layers do not include platform types or call platform LCD primitives.
|
|
- Cardinal server values such as `正北` are normalized by the domain direction
|
|
catalog rather than by orchestration code.
|
|
- Any future favorable-color animation requires a new ADR or an explicit update
|
|
to the existing LCD expression ownership decision.
|