55 lines
1.5 KiB
Markdown
55 lines
1.5 KiB
Markdown
# Data Model
|
|
|
|
## Canonical Input
|
|
|
|
The canonical input is one Reanimator hardware JSON snapshot.
|
|
|
|
The viewer does not own the schema. The Reanimator JSON contract remains external to this repository.
|
|
|
|
## Viewer Data Model
|
|
|
|
The viewer uses a presentation model derived directly from the input JSON:
|
|
|
|
- top-level snapshot metadata
|
|
- ordered top-level sections
|
|
- table definitions per section
|
|
- raw field values
|
|
|
|
## Rendering Rule
|
|
|
|
The viewer is schema-preserving, not schema-owning.
|
|
|
|
- Known sections have a preferred order.
|
|
- Known important fields may have a preferred column order.
|
|
- Every field present in the input must remain visible.
|
|
- Unknown fields must not be dropped.
|
|
|
|
## Section Model
|
|
|
|
Section types expected initially:
|
|
|
|
- singleton object section, for example `board`
|
|
- array-of-object section, for example `cpus`
|
|
- nested grouped section, for example `sensors.{fans,power,temperatures,other}`
|
|
|
|
## Column Rules
|
|
|
|
For array sections:
|
|
|
|
1. collect the union of keys present across all rows
|
|
2. place known fields first
|
|
3. append unknown fields after known fields
|
|
4. render absent values as empty cells
|
|
|
|
## Special Field Handling
|
|
|
|
- `status` is rendered as a colored badge
|
|
- arrays such as `mac_addresses` may be rendered as line-separated values or badges inside one cell
|
|
- nested values such as `status_history` may be rendered in expandable detail blocks inside one cell
|
|
|
|
## Persistence
|
|
|
|
There is no database and no canonical stored state in v1.
|
|
|
|
The viewer operates on the in-memory snapshot provided by the embedding application or local file input.
|