prometeu-studio/docs/studio/agendas/Agenda-05-Asset-Bank-Composition-WorkspaceBus-Interaction.md

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.