# 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.