# Asset Bank Composition WorkspaceBus Interaction Agenda

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

## Problem

The `Bank Composition` section should use `workspaceBus` for coordination, but the first-wave event contract should stay small and be designed together with the middleware/controller.

This agenda exists to close the first minimal event surface without inventing an oversized bus protocol too early.

## Context

The current baseline is already known:

- events and middleware should evolve together;
- the first event baseline can stay very small;
- capacity changes are naturally expressed as percentage deltas or level changes in the `0..1` range;
- the transfer list and meter should be consumers of orchestrated state, not independent sources of product rules.

## Options

1. Define a broad event taxonomy upfront.
2. Define only the minimum events needed for the first staged-edit interaction loop.
3. Avoid `workspaceBus` and wire components directly.

## Tradeoffs

1. A broad taxonomy is easy to regret and hard to prune once code lands.
2. A minimal contract matches the current incremental direction and keeps future changes cheap.
3. Direct wiring would fight the current workspace architecture and reduce observability of section state changes.

## Recommendation

Define a minimal first-wave `workspaceBus` contract together with the middleware/controller.

Baseline direction:

- begin with the smallest useful set of section-local events;
- include capacity increase/decrease semantics in the `0..1` range only as needed;
- avoid encoding family-specific product rules directly into bus event types.

### First-Wave Event Baseline

The first wave should keep user actions local to the middleware/controller whenever possible.

That means the following actions do not need to become public `workspaceBus` commands in the first implementation:

- `beginEdit`
- `moveToSelected`
- `moveToAvailable`
- `moveUp`
- `moveDown`
- `reset`
- `cancel`
- `apply`

The middleware/controller should receive those actions locally, recalculate section state, and publish only the state transitions or lifecycle notifications that matter outside the section.

The first public `workspaceBus` notifications should stay minimal:

- `BankCompositionDraftChanged`
- `BankCompositionCapacityChanged`
- `BankCompositionApplyRequested`
- `BankCompositionApplied`
- `BankCompositionApplyFailed`

Capacity notifications should use absolute progress in the `0..1` range rather than deltas.

A practical first-wave shape for capacity notifications is:

- `progress`
- `severity`
- `blocked`

If internal increase/decrease semantics are useful later, they can remain local implementation detail rather than part of the initial public bus contract.

## Open Questions

No open questions remain in this agenda wave.

### Resolved In This Agenda Wave

The following points are now closed:

1. First-wave user actions should stay local to the middleware/controller rather than becoming public bus commands.
2. The first public `workspaceBus` contract should be notification-oriented.
3. Capacity notifications should use absolute `0..1` progress rather than deltas.
4. A minimal first-wave bus surface is enough: draft change, capacity change, apply requested, apply success, and apply failure.

## Next Suggested Step

Turn this into a `decision` that fixes the minimal first-wave `workspaceBus` contract for `Bank Composition`.