# Asset Bank Composition Snapshot Transfer to Details DTOs Agenda

Status: Open
Domain Owner: `docs/studio`
Cross-Domain Impact: `docs/packer`

## Problem

The `Bank Composition` section needs a stable details-facing data shape before any component or middleware work can proceed.

Today the underlying information comes from two different sources:

- snapshot state derived from `walkResult`, which should feed `available` files;
- `asset.json`, which should feed the currently `selected` files for build composition.

This agenda exists to close how those sources should be transferred into Studio-facing DTOs for `Asset Details`.

## Context

Recent packer/runtime work already gives the Studio enough source information to populate a first-wave `Bank Composition` section:

- registered assets have stable identity;
- the snapshot already contains file inventory derived from `walkResult`;
- blocking diagnostics already exclude files from being generally available;
- selection state is persisted in `asset.json` and is expected to move through the newer `artifacts` shape.

The Studio should not bind raw UI code directly to packer internals.
The section needs a dedicated Studio DTO layer.

## Options

1. Bind the UI directly to snapshot and manifest shapes.
2. Build one dedicated Studio bank-file DTO for both `available` and `selected` rows.
3. Build separate DTOs for `available` rows and `selected` rows.

## Tradeoffs

1. Direct binding is fast initially but couples Studio too tightly to packer/runtime structures.
2. One shared DTO keeps the section simpler and is easier to use across transfer list, meter, and staged draft state.
3. Separate DTOs may model source differences more explicitly, but they add mapping and coordination overhead early.

## Recommendation

Adopt one dedicated Studio DTO family for bank composition rows and section state.

Baseline direction:

- `walkResult`-derived snapshot rows become `available`;
- `asset.json` composition state becomes `selected`;
- both are projected into Studio-owned DTOs before reaching the section UI;
- the DTO should be generic enough to work for any bank type, even if family-specific fields arrive later.
- the DTO field set should stay intentionally small and grow only when a concrete UI need appears.

### First-Wave DTO Baseline

The first-wave DTO direction is intentionally pragmatic:

- define one Studio-owned bank-file DTO family for both `available` and `selected` rows;
- add fields incrementally as real section behavior requires them;
- do not project blocking files into the UI DTO layer at all;
- keep selected-file order visual in the UI, but persist it in `asset.json` through an explicit index shape such as `{ file, index }`.
- start with this minimum first-wave field set:
  `fileId/path`, `displayName`, `size`, `lastModified`, `fingerprint`, and `metadata`.

## Open Questions

No open questions remain in this agenda wave.

### Resolved In This Agenda Wave

The following points are now closed:

1. The DTO field set should start small and grow only as concrete UI needs appear.
2. Only non-blocking files become `available` DTOs; blocking files should not be projected into the section DTO layer.
3. UI ordering is visual, while persisted ordering in `asset.json` should use an explicit index representation such as `{ file, index }`.
4. The first DTO revision should start with `fileId/path`, `displayName`, `size`, `lastModified`, `fingerprint`, and `metadata`.

## Next Suggested Step

Turn this into a `decision` that closes the first-wave Studio DTO shape for `Bank Composition` details data.
