95 lines
3.4 KiB
Markdown
95 lines
3.4 KiB
Markdown
# 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`.
|