prometeu-studio/docs/studio/agendas/Agenda-01-Asset-Bank-Composition-Snapshot-Transfer-to-Details-DTOs.md

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.