2.0 KiB
2.0 KiB
03 — Stream progressive startup and refresh
What to build: Show the dashboard immediately and update each Target independently as detection completes, both at startup and when the user refreshes.
Blocked by: 02 — Deliver the Operations Console dashboard.
Status: done
- Interactive application construction exposes Target identity and descriptions before availability and inspection complete.
- Startup renders every known Target in a structured Checking state without waiting for aggregate detection.
- Availability and inspection results stream to the TUI one Target at a time.
- Refresh uses the same progressive behavior rather than a separate aggregate-only path.
- Checking rows display a non-color-only progress cue and update independently on success or failure.
- Independent completion order does not reorder Targets or move selection to a different identity.
- A Target detection failure is represented truthfully without preventing unrelated Target results from appearing.
- The progressive Application Interface contains presentation-independent phases and results rather than Bubble Tea types or strings that callers must parse.
- Existing non-interactive maintenance behavior remains compatible.
- Application tests cover independent completion order, mixed success/failure, and final snapshots.
- Complete-Model tests prove the first useful frame precedes detection completion and each subsequent result updates only the relevant row.
Answer
Progressive startup and refresh now publish authoritative Application snapshots per Target while generation checks discard stale overlapping results. Application state and snapshots share one lock, dispatch invalidates in-flight detection before committing mutations, and the dashboard retains selected Target identity—including a newly unavailable selected Target. Adapter detection failures are classified truthfully without changing maintenance inspection semantics.