20 lines
1.5 KiB
Markdown
20 lines
1.5 KiB
Markdown
# 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:** ready-for-agent
|
|
|
|
- [ ] 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.
|