# Asset Bank Composition Middleware and Staged Editing Agenda

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

## Problem

`StudioDualListView<T>` and `StudioAssetCapacityMeter` are intentionally dumb.
That means `Bank Composition` needs a middleware/controller layer that owns:

- family-specific capacity rules;
- staged draft state;
- `change` / `apply` / `reset` / `cancel` orchestration;
- hard-limit decisions about whether a candidate file can enter the selected list.

Without that layer, component responsibilities will blur quickly.

## Context

The current direction already rejects two extremes:

- no component should hide bank-family rules internally;
- the first wave should not overgeneralize into a universal bank manager abstraction.

The middleware/controller therefore needs to be explicit, scoped to `Asset Details`, and designed to evolve incrementally.

## Options

1. Put orchestration inside the section control itself.
2. Create a dedicated bank-composition middleware/controller for the section.
3. Push family-specific logic down into the transfer list and meter components.

## Tradeoffs

1. Section-local orchestration reduces file count initially, but risks turning `AssetDetails` into a heavy behavior host.
2. A dedicated middleware/controller keeps the section and components simpler while preserving room for bank-family policies.
3. Embedding rules into components breaks the current design goal of keeping them dumb and composable.

## Recommendation

Create a dedicated bank-composition middleware/controller for the section.

Baseline expectations:

- own the draft state while editing is active;
- translate persisted state into editable state on `change`;
- support `reset` back to the persisted state;
- support `cancel` by discarding draft changes;
- keep `apply` stubbed or disabled until persistence is wired;
- delegate family-specific capacity logic through narrowly scoped policies instead of premature platform-wide abstractions.

### First-Wave Middleware Baseline

The first wave should not introduce a second session model parallel to the one already used by Studio.

The middleware/controller should be built around `StudioFormSession<BankCompositionDraft>` as the common staged-edit core.

Family-specific variation should not come from subclassing `StudioFormSession`.
It should come from family-specific draft factories and policies that operate on a shared session model.

Baseline direction:

- `StudioFormSession<BankCompositionDraft>` owns `source`, `draft`, `mode`, `isDirty`, `beginEdit`, `reset`, `cancel`, and `apply`;
- the bank-composition middleware/controller coordinates that form session for the section;
- each asset family can offer its own draft-construction and bank-composition policy implementation;
- those policies should decide transfer eligibility, reorder effects, capacity usage, and hard-limit blockers;
- `apply` may remain stubbed or disabled until persistence is wired, but the session contract should already be complete.

The minimal state published by the middleware/controller should be one section-facing view model carrying:

- shell state such as `isEditing`, `isDirty`, and action availability;
- left and right list state;
- capacity-meter state;
- active blockers and hint messages when relevant.

## Open Questions

No open questions remain in this agenda wave.

### Resolved In This Agenda Wave

The following points are now closed:

1. The middleware/controller should be built around `StudioFormSession<BankCompositionDraft>`, not a parallel staged-edit model.
2. Family-specific behavior should come from draft factories and policies, not from subclassing `StudioFormSession`.
3. Family-specific rules should be represented first as small policies offered per asset family.
4. The middleware/controller should publish one section-facing view model with shell state, list state, meter state, blockers, and hints.

## Next Suggested Step

Turn this into a `decision` that fixes the middleware/controller contract and staged-edit lifecycle for the first wave.
