81 lines
3.5 KiB
Markdown
81 lines
3.5 KiB
Markdown
# 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.
|