82 lines
2.2 KiB
Markdown
82 lines
2.2 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,
|
|
- use the right-side panel for structured activity and progress,
|
|
- reserve the bottom region for logs and detailed textual output,
|
|
- support a tabbed right-side panel so activity can coexist with other contextual surfaces such as diagnostics or inspector views.
|
|
|
|
## Distinction Between Activity and Logs
|
|
|
|
Baseline distinction:
|
|
|
|
- `activity` is the structured operational timeline of the Studio;
|
|
- `logs` are detailed textual outputs from compiler, packer, and other services.
|
|
|
|
Examples of `activity`:
|
|
|
|
- project opened;
|
|
- asset scan started;
|
|
- diagnostics updated;
|
|
- build started or finished;
|
|
- preview ready;
|
|
- action applied or failed.
|
|
|
|
Examples of `logs`:
|
|
|
|
- compiler output;
|
|
- packer trace output;
|
|
- stack traces;
|
|
- detailed technical diagnostics and execution text.
|
|
|
|
## Expected Follow-up
|
|
|
|
- a decision on activity feed and progress UX,
|
|
- a shell or integration spec,
|
|
- a plan for event rendering and background updates.
|