56 lines
1.5 KiB
Markdown
56 lines
1.5 KiB
Markdown
# Background Events, Progress, and Activity Feed Agenda
|
|
|
|
## Status
|
|
|
|
Open
|
|
|
|
## Purpose
|
|
|
|
Define how Studio surfaces background asset activity, progress, and logs coming from the packer event lane.
|
|
|
|
## Domain Owner
|
|
|
|
`docs/studio`
|
|
|
|
## Current Code Context
|
|
|
|
The packer already defines a Studio-facing asset event lane with events such as:
|
|
|
|
- `asset_discovered`
|
|
- `asset_changed`
|
|
- `diagnostics_updated`
|
|
- `build_started`
|
|
- `build_finished`
|
|
- `cache_hit`
|
|
- `cache_miss`
|
|
- `preview_ready`
|
|
- `action_applied`
|
|
- `action_failed`
|
|
- `progress_updated`
|
|
|
|
Current `BuilderWorkspace` already contains a logs area, which is a useful signal but not yet a coherent Studio-wide activity model.
|
|
|
|
## Core Questions
|
|
|
|
1. Should activity be global to the Studio shell or local to the Assets workspace?
|
|
2. How should progress, logs, and state changes be distinguished?
|
|
3. What should persist in history versus only appear transiently?
|
|
4. How noisy should automatic background reporting be?
|
|
5. How should action failures and blockers surface?
|
|
|
|
## Recommendation
|
|
|
|
Baseline direction:
|
|
|
|
- global activity region in the Studio shell,
|
|
- structured event rendering rather than raw log dumping,
|
|
- progress visible both inline and in the activity surface,
|
|
- recent actionable failures retained until acknowledged,
|
|
- normal background noise summarized rather than streamed endlessly.
|
|
|
|
## Expected Follow-up
|
|
|
|
- a decision on activity feed and progress UX,
|
|
- a shell or integration spec,
|
|
- a plan for event rendering and background updates.
|