# Asset Workspace Information Architecture Agenda

## Status

Closed

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

1. Which panels are baseline for the Assets workspace?
2. What should the primary unit of navigation be: asset list, tree, or diagnostic inbox?
3. Which information should always be visible for the selected asset?
4. How should diagnostics, preload, and managed/orphan state surface in the workspace?
5. 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:

- a custom visual `Asset Tree` / `Asset Navigator` 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.

The Assets workspace must remain asset-first, but it must not hide physical organization.

Baseline path and structure rules:

- the primary navigation unit is the managed asset, not the raw file;
- the left navigation surface should not be a generic file tree; it should be an asset-aware tree that teaches the packer model;
- asset root path must remain visible for the selected asset;
- the asset list may be grouped by path or parent folder to preserve project structure awareness;
- the selected asset view should include a location section for asset root and relocational actions;
- the selected asset view should include an inputs/preview section that exposes internal files and folders as part of the asset;
- filesystem structure is supporting context, not the primary identity model.

Baseline visual navigation rules:

- the Assets workspace should use a custom `Asset Tree` / `Asset Navigator` component rather than a plain `TreeView` clone;
- asset nodes should carry strong visual semantics such as icons, badges, and state styling;
- the navigator should clearly surface managed/orphan state, preload intent, diagnostics presence, and broad asset family where available;
- grouping nodes may reflect path structure, but asset nodes remain the primary navigable unit;
- optional expansion of an asset into internal inputs is allowed as supporting inspection, not as a replacement for asset-first navigation.

This exists so the Assets workspace teaches the packer model while still letting users understand and organize the project's directory layout.

## Expected Follow-up

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

## Resolution

Closed by [`../decisions/004-asset-workspace-information-architecture-decision.md`](../decisions/004-asset-workspace-information-architecture-decision.md).