# Asset Bank Composition Base Components Agenda

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

## Problem

The `Bank Composition` section depends on two new Studio components:

- `StudioDualListView<T>`
- `StudioAssetCapacityMeter`

Those components need a first-wave contract and scope before the section shell or middleware can be implemented safely.

## Context

The current direction is already partially fixed:

- `StudioDualListView<T>` should be abstract;
- the first concrete subclass should be asset-details-specific;
- right-list ordering must support `move up`, `move down`, and visible indices;
- `StudioAssetCapacityMeter` should be a vertical, game-like progress bar with color bands and percentage text;
- both components should stay intentionally dumb and leave family-specific rules to middleware/controller logic.

## Options

1. Build highly generic reusable components from the start.
2. Build bank-composition-scoped Studio components with narrow first-wave APIs.
3. Skip dedicated components and build the section directly inside `AssetDetails`.

## Tradeoffs

1. Highly generic components risk overengineering before the first section is proven.
2. Narrow first-wave components keep momentum and preserve room to generalize later from real usage.
3. Inline section code would move faster once, but it would bury behavior that already deserves named UI building blocks.

## Recommendation

Build dedicated first-wave components with narrow APIs:

- abstract `StudioDualListView<T>` as the transfer-list base;
- one asset-details concrete subclass first;
- `StudioAssetCapacityMeter` as a dumb vertical meter component with color thresholds and percentage display.

Do not force broad reuse rules yet.

### First-Wave Component Baseline

The first-wave component contract should stay intentionally small.

`StudioDualListView<T>` should expose only the hooks needed for the initial bank-composition section:

- row text and/or row graphic projection;
- current left and right collections;
- current selection state;
- move left-to-right;
- move right-to-left;
- `moveUp`;
- `moveDown`;
- visible index refresh for the right-side list.

The first concrete asset-details subclass should render rows directly.
Do not introduce a separate row renderer abstraction yet.

`StudioAssetCapacityMeter` should start as a dumb visual component with these baseline inputs:

- `progress` in the `0..1` range;
- a label, including percentage text when needed;
- a severity band state;
- optional hint text.

## Open Questions

No open questions remain in this agenda wave.

### Resolved In This Agenda Wave

The following points are now closed:

1. `StudioDualListView<T>` should expose only a narrow first-wave hook set for row projection, selection, transfers, reordering, and right-list index refresh.
2. The first concrete asset-details subclass should own row rendering directly.
3. `StudioAssetCapacityMeter` should start with `progress`, label, severity band state, and optional hint text.

## Next Suggested Step

Turn this into a `decision` that fixes the first-wave component contracts for `StudioDualListView<T>` and `StudioAssetCapacityMeter`.