Asset Workspace Information Architecture Agenda

Status

Open

Purpose

Define the baseline information architecture of the Assets workspace.

The goal is to decide which panels and data views the user needs in order to manage assets through Studio services rather than through ad hoc file inspection.

Domain Owner

docs/studio

Current Code Context

WorkspaceId.ASSETS is still backed by a placeholder workspace.

Meanwhile, the packer domain already defines:

managed assets,
diagnostics,
preview/apply mutation flows,
an asset event lane,
structured service responses.

The Assets workspace must therefore be designed as a Studio view over those services, not as a file browser clone.

Core Questions

Which panels are baseline for the Assets workspace?
What should the primary unit of navigation be: asset list, tree, or diagnostic inbox?
Which information should always be visible for the selected asset?
How should diagnostics, preload, and managed/orphan state surface in the workspace?
What belongs in the workspace body versus a global Studio activity region?

Options

Option A

List-first asset workspace with details panel and diagnostics section.

Option B

File-tree-first asset workspace with asset details as a secondary mode.

Option C

Dashboard-first asset workspace focused on diagnostics and actions.

Tradeoffs

Option A aligns best with the managed asset model already defined by the packer.
Option B is familiar, but risks collapsing the Studio into a glorified file explorer.
Option C is useful for operations, but weak as a day-to-day authoring workspace.

Recommendation

Prefer Option A.

Recommended baseline:

asset list or registry-aware browser on the left,
asset details in the main panel,
diagnostics and action surfaces attached to the selected asset,
broader activity/progress outside the asset details body when possible.

Expected Follow-up

an information architecture decision,
a workspace spec,
a PR/plan for the first concrete AssetsWorkspace.

2.0 KiB Raw Blame History