# 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

- [x] Interactive application construction exposes Target identity and descriptions before availability and inspection complete.
- [x] Startup renders every known Target in a structured Checking state without waiting for aggregate detection.
- [x] Availability and inspection results stream to the TUI one Target at a time.
- [x] Refresh uses the same progressive behavior rather than a separate aggregate-only path.
- [x] Checking rows display a non-color-only progress cue and update independently on success or failure.
- [x] Independent completion order does not reorder Targets or move selection to a different identity.
- [x] A Target detection failure is represented truthfully without preventing unrelated Target results from appearing.
- [x] The progressive Application Interface contains presentation-independent phases and results rather than Bubble Tea types or strings that callers must parse.
- [x] Existing non-interactive maintenance behavior remains compatible.
- [x] Application tests cover independent completion order, mixed success/failure, and final snapshots.
- [x] 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.