48 lines
1.9 KiB
Markdown
48 lines
1.9 KiB
Markdown
# Runtime Flows
|
|
|
|
## Render Snapshot Flow
|
|
|
|
1. receive one Reanimator JSON snapshot from the caller
|
|
2. decode the payload into generic/object structures without dropping unknown fields
|
|
3. identify known top-level sections
|
|
4. build presentation sections in preferred order
|
|
5. for each array section, build the union of keys across rows
|
|
6. order columns with known fields first and unknown fields after
|
|
7. render the page
|
|
|
|
## Status Presentation Flow
|
|
|
|
1. read the raw `status` value from the payload
|
|
2. normalize only for presentation matching (`OK`, `Warning`, `Critical`, `Unknown`, `Empty`)
|
|
3. apply status badge class
|
|
4. in dense table layouts, render `status` as an icon-only column with an empty header when it improves scanning
|
|
5. preserve the raw status value in accessible labeling even when the visible cell shows only a pictogram
|
|
|
|
## Severity Presentation Flow
|
|
|
|
1. read the raw `severity` value from the payload
|
|
2. map the raw value only to a presentation glyph/color class
|
|
3. when a table includes `severity`, add a leftmost icon-only column for it
|
|
4. keep the original textual `severity` column visible in the table
|
|
5. preserve the raw severity value in accessible labeling for the pictogram cell
|
|
|
|
## Unknown Field Invariant
|
|
|
|
1. if a field exists in the input, it must remain visible somewhere in the output
|
|
2. unknown fields may appear after known fields in a section table
|
|
3. unknown top-level sections may be rendered after known sections
|
|
4. the viewer must never silently discard fields because they are new or unexpected
|
|
|
|
## Non-Augmentation Invariant
|
|
|
|
1. do not compute aggregate health summaries unless they already exist in the JSON
|
|
2. do not derive warnings/failures counters
|
|
3. do not infer statuses for missing fields
|
|
4. do not merge or rewrite source values
|
|
|
|
## Simplicity Rule
|
|
|
|
1. prefer server-rendered HTML
|
|
2. keep JavaScript optional and presentation-only
|
|
3. do not introduce a frontend framework without a concrete present need
|