asset walker (WIP)
This commit is contained in:
parent
c4b7acab6f
commit
1c17562cc9
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -35,7 +35,7 @@ The first-wave projection rules are:
|
||||
|
||||
The first DTO revision starts with these fields:
|
||||
|
||||
- `fileId/path`
|
||||
- `path`
|
||||
- `displayName`
|
||||
- `size`
|
||||
- `lastModified`
|
||||
|
||||
@ -7,7 +7,7 @@ Cross-Domain Impact: `docs/packer`
|
||||
|
||||
## Context
|
||||
|
||||
`Bank Composition` needs a control layer above the new UI components because:
|
||||
`Bank Composition` needs a section-scoped coordinator above the new UI components because:
|
||||
|
||||
- `StudioDualListView<T>` is intentionally dumb;
|
||||
- `StudioAssetCapacityMeter` is intentionally dumb;
|
||||
@ -33,7 +33,7 @@ This decision closes the middleware direction discussed in:
|
||||
|
||||
## Decision
|
||||
|
||||
Adopt a dedicated bank-composition middleware/controller built around `StudioFormSession<BankCompositionDraft>`.
|
||||
Adopt a dedicated bank-composition section-scoped coordinator built around `StudioFormSession<BankCompositionDraft>`.
|
||||
|
||||
The first-wave rules are:
|
||||
|
||||
@ -43,7 +43,7 @@ The first-wave rules are:
|
||||
4. family-specific variation must come from draft factories and bank-composition policies offered per asset family;
|
||||
5. `apply` may remain stubbed or disabled until persistence is wired, but the session contract should already exist.
|
||||
|
||||
The middleware/controller owns orchestration around the form session, including:
|
||||
The section-scoped coordinator owns orchestration around the form session, including:
|
||||
|
||||
- translating persisted section state into session source/draft state;
|
||||
- beginning edit mode;
|
||||
@ -55,7 +55,7 @@ The middleware/controller owns orchestration around the form session, including:
|
||||
- calculating capacity state;
|
||||
- calculating hard-limit blockers and hints.
|
||||
|
||||
The middleware/controller should publish one section-facing view model that includes:
|
||||
The section-scoped coordinator should publish one section-facing view model that includes:
|
||||
|
||||
- shell state such as editing mode, dirty state, and action availability;
|
||||
- left and right list state;
|
||||
@ -67,7 +67,7 @@ The middleware/controller should publish one section-facing view model that incl
|
||||
This is the simplest design that matches the actual codebase.
|
||||
|
||||
`StudioFormSession` already provides the staged-edit lifecycle the section needs.
|
||||
Creating a second middleware-specific session model would duplicate behavior for no gain.
|
||||
Creating a second coordinator-specific session model would duplicate behavior for no gain.
|
||||
|
||||
At the same time, subclassing `StudioFormSession` is the wrong variation point.
|
||||
The current class is final, and more importantly the lifecycle does not change by asset family.
|
||||
@ -81,7 +81,7 @@ The following constraints now apply:
|
||||
|
||||
1. `StudioFormSession<BankCompositionDraft>` is the only staged-edit core for the section in the first wave;
|
||||
2. asset-family differences must be modeled outside `StudioFormSession`;
|
||||
3. the middleware/controller remains section-specific and should not become a platform-wide bank manager abstraction;
|
||||
3. the section-scoped coordinator remains section-specific and should not become a platform-wide bank manager abstraction;
|
||||
4. dumb UI components consume derived state and do not own bank rules;
|
||||
5. the section-facing output must be consolidated into one view model rather than scattered state channels.
|
||||
|
||||
@ -89,7 +89,7 @@ The following constraints now apply:
|
||||
|
||||
This decision does not yet define:
|
||||
|
||||
- the exact Java class names or package layout for the middleware/controller, policies, or draft factories;
|
||||
- the exact Java class names or package layout for the section-scoped coordinator, policies, or draft factories;
|
||||
- the exact shape of `BankCompositionDraft`;
|
||||
- the `workspaceBus` event contract;
|
||||
- persistence/apply integration with packer;
|
||||
@ -103,12 +103,12 @@ This decision does not yet define:
|
||||
- Studio specs:
|
||||
[`4. Assets Workspace Specification.md`](../specs/4.%20Assets%20Workspace%20Specification.md)
|
||||
- Studio code:
|
||||
`StudioFormSession` integration, `Bank Composition` section controller/middleware, family-specific draft factories, and family-specific bank-composition policies
|
||||
`StudioFormSession` integration, `Bank Composition` section-scoped coordinator, family-specific draft factories, and family-specific bank-composition policies
|
||||
|
||||
## Validation Notes
|
||||
|
||||
Examples implied by this decision:
|
||||
|
||||
- a tile family and a sound family can share the same `StudioFormSession` lifecycle while using different capacity/blocker policies;
|
||||
- the dual list and meter can stay dumb because the middleware/controller supplies already-derived state;
|
||||
- the dual list and meter can stay dumb because the section-scoped coordinator supplies already-derived state;
|
||||
- when persistence is not wired yet, `beginEdit`, `reset`, and `cancel` still work through the shared form-session model.
|
||||
|
||||
@ -39,14 +39,14 @@ Route `Bank Composition` apply through packer and persist selection under `asset
|
||||
The first-wave rules are:
|
||||
|
||||
1. Studio must not write `asset.json` directly;
|
||||
2. packer owns persistence of selected bank-composition files;
|
||||
2. the packer service owns validation, persistence, and minimal snapshot refresh for selected bank-composition files;
|
||||
3. `artifacts` replaces the older `inputsByRole` representation for this flow;
|
||||
4. selected file order must remain explicit in persisted data rather than relying on array position alone;
|
||||
5. after a successful apply, Studio must refresh from persisted state rather than trusting stale draft state.
|
||||
|
||||
The minimal successful apply flow is:
|
||||
|
||||
1. Studio submits the selected ordered files to packer;
|
||||
1. Studio submits the selected ordered files to the packer service;
|
||||
2. packer updates `asset.json` under the `artifacts` representation;
|
||||
3. packer refreshes the minimal runtime snapshot state required by `Asset Details`;
|
||||
4. Studio rebinds the section from that refreshed persisted state;
|
||||
@ -74,6 +74,9 @@ This keeps write ownership in the correct domain boundary.
|
||||
Packer already owns asset mutation and runtime refresh logic.
|
||||
Letting Studio write manifests directly would duplicate rules and create drift between UI and runtime behavior.
|
||||
|
||||
The Studio should only submit the apply request and react to the result.
|
||||
The packer service is the owner of validation, persistence, and state propagation.
|
||||
|
||||
Refreshing from persisted state after success is also necessary.
|
||||
Otherwise the section would keep trusting stale draft state and could diverge from what packer actually accepted and wrote.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ Adopt a minimal, notification-oriented first-wave `workspaceBus` contract for `B
|
||||
|
||||
The first-wave rules are:
|
||||
|
||||
1. user actions should stay local to the bank-composition middleware/controller whenever possible;
|
||||
1. user actions should stay local to the bank-composition section-scoped coordinator whenever possible;
|
||||
2. the first public `workspaceBus` surface should publish only state transitions or lifecycle notifications that matter outside the section;
|
||||
3. the event contract must not encode bank-family product rules directly into event types;
|
||||
4. capacity notifications should use absolute progress in the `0..1` range, not deltas.
|
||||
@ -43,7 +43,7 @@ The first-wave public notification set is:
|
||||
- `BankCompositionApplied`
|
||||
- `BankCompositionApplyFailed`
|
||||
|
||||
The first-wave local-only action set remains inside the middleware/controller:
|
||||
The first-wave local-only action set remains inside the section-scoped coordinator:
|
||||
|
||||
- `beginEdit`
|
||||
- `moveToSelected`
|
||||
@ -54,6 +54,9 @@ The first-wave local-only action set remains inside the middleware/controller:
|
||||
- `cancel`
|
||||
- `apply`
|
||||
|
||||
`apply` should remain a local section action that calls the packer service.
|
||||
It is not a public bus command in the first wave.
|
||||
|
||||
The first-wave capacity notification should expose at least:
|
||||
|
||||
- `progress`
|
||||
@ -65,7 +68,7 @@ The first-wave capacity notification should expose at least:
|
||||
This preserves the workspace event architecture without inflating the bus contract too early.
|
||||
|
||||
If every section interaction became a public event, the bus would turn into a noisy command surface with little external value.
|
||||
The middleware/controller is already the right local place for section commands and recalculation.
|
||||
The section-scoped coordinator is already the right local place for section commands and recalculation.
|
||||
|
||||
Absolute capacity state is also the right public shape.
|
||||
It is easier to consume, easier to reason about, and safer for late subscribers than delta-based updates.
|
||||
@ -95,7 +98,7 @@ This decision does not yet define:
|
||||
- Studio specs:
|
||||
[`4. Assets Workspace Specification.md`](../specs/4.%20Assets%20Workspace%20Specification.md)
|
||||
- Studio code:
|
||||
bank-composition middleware/controller, event definitions, and event subscribers in `Asset Details`
|
||||
bank-composition section-scoped coordinator, event definitions, and event subscribers in `Asset Details`
|
||||
|
||||
## Validation Notes
|
||||
|
||||
@ -103,4 +106,5 @@ Examples implied by this decision:
|
||||
|
||||
- dragging or reordering inside the dual list does not require a public bus command in the first wave;
|
||||
- the capacity meter can react to a published absolute progress state such as `0.72` with `orange` severity and `blocked=false`;
|
||||
- apply success or failure can be observed outside the section without exposing every internal section action as a bus event.
|
||||
- apply success or failure can be observed outside the section without exposing every internal section action as a bus event;
|
||||
- clicking `apply` should call the packer service locally and only publish lifecycle notifications around that operation.
|
||||
|
||||
@ -0,0 +1,81 @@
|
||||
# PR-10a Bank Composition Details DTO Projection
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
Cross-domain impact: `docs/packer`
|
||||
|
||||
## Briefing
|
||||
|
||||
Introduce the Studio-owned DTO projection boundary for `Bank Composition` inside `Asset Details`.
|
||||
|
||||
This slice converts runtime/details source data into section-facing DTOs before any new section UI or middleware is added.
|
||||
|
||||
The goal is to land the data boundary first, so the UI work that follows does not bind directly to snapshot rows or raw `asset.json` shapes.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- `Asset Details` has a Studio-owned DTO family for `Bank Composition`;
|
||||
- snapshot-derived data feeds `available` rows;
|
||||
- persisted selection data feeds `selected` rows;
|
||||
- only non-blocking files reach the `available` DTO list;
|
||||
- selected ordering is represented in a way that can later map to explicit persisted indexes.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition Details DTO Projection Decision.md`](../decisions/Bank%20Composition%20Details%20DTO%20Projection%20Decision.md)
|
||||
- [`./PR-07c-asset-details-and-form-lifecycle.md`](./PR-07c-asset-details-and-form-lifecycle.md)
|
||||
- [`../specs/4. Assets Workspace Specification.md`](../specs/4.%20Assets%20Workspace%20Specification.md)
|
||||
|
||||
## Scope
|
||||
|
||||
- add the Studio DTO family for bank-composition rows and section data
|
||||
- map details/snapshot source data into:
|
||||
- `available`
|
||||
- `selected`
|
||||
- start the DTO field set with:
|
||||
- `path`
|
||||
- `displayName`
|
||||
- `size`
|
||||
- `lastModified`
|
||||
- `fingerprint`
|
||||
- `metadata`
|
||||
- filter blocking files out of the `available` projection
|
||||
- ensure selected ordering is available to the UI as ordered row state
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no new section UI yet
|
||||
- no dual-list component yet
|
||||
- no capacity meter yet
|
||||
- no staged-edit coordinator yet
|
||||
- no persistence/apply integration yet
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Introduce the DTO types for bank-composition details data.
|
||||
2. Extend the details projection path to populate `available` and `selected`.
|
||||
3. Filter blocking files before DTO emission.
|
||||
4. Preserve selected ordering in the section-facing projection.
|
||||
5. Add regression tests around DTO mapping and filtering.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- `Asset Details` can provide Studio-owned `Bank Composition` DTOs without exposing raw packer internals to the section
|
||||
- `available` rows come from current runtime/details data
|
||||
- blocking files do not appear in `available`
|
||||
- `selected` rows are available as ordered data
|
||||
- the new DTO projection is ready for subsequent section and component slices
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for DTO mapping from details/snapshot source data
|
||||
- unit tests for blocking-file exclusion
|
||||
- unit tests for selected-row ordering preservation
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/messages/...`
|
||||
- tests for details projection and DTO mapping
|
||||
- cross-domain touchpoint: packer-facing details DTO shaping if source data is still missing
|
||||
@ -0,0 +1,75 @@
|
||||
# PR-10b Bank Composition Base Components
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
|
||||
## Briefing
|
||||
|
||||
Introduce the base UI building blocks for `Bank Composition`:
|
||||
|
||||
- `StudioDualListView<T>`
|
||||
- `StudioAssetCapacityMeter`
|
||||
|
||||
This slice lands the named components with intentionally narrow first-wave APIs, before section-shell wiring or behavior orchestration.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- `StudioDualListView<T>` exists as an abstract Studio component;
|
||||
- the first asset-details concrete dual-list implementation exists;
|
||||
- `StudioAssetCapacityMeter` exists as a dumb vertical meter component;
|
||||
- right-list ordering support includes `moveUp`, `moveDown`, and visible indices.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition Base Components Decision.md`](../decisions/Bank%20Composition%20Base%20Components%20Decision.md)
|
||||
- [`../decisions/Bank Composition Details DTO Projection Decision.md`](../decisions/Bank%20Composition%20Details%20DTO%20Projection%20Decision.md)
|
||||
- [`./PR-10a-bank-composition-details-dto-projection.md`](./PR-10a-bank-composition-details-dto-projection.md)
|
||||
|
||||
## Scope
|
||||
|
||||
- add abstract `StudioDualListView<T>`
|
||||
- add the first asset-details-specific concrete dual-list implementation
|
||||
- add dumb `StudioAssetCapacityMeter`
|
||||
- support row rendering directly in the concrete dual-list implementation
|
||||
- support right-list index display
|
||||
- support `moveUp` and `moveDown` affordances in the component contract
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no section shell yet
|
||||
- no `FormSession` integration yet
|
||||
- no family-specific capacity rules inside components
|
||||
- no workspace-bus contract yet
|
||||
- no apply persistence
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Add the abstract dual-list base component.
|
||||
2. Add the first concrete asset-details implementation against the new DTOs.
|
||||
3. Add the capacity meter component with:
|
||||
- `progress`
|
||||
- label
|
||||
- severity band
|
||||
- optional hint text
|
||||
4. Add component tests for rendering, ordering affordances, and meter state display.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the codebase contains the new named base components for `Bank Composition`
|
||||
- the first concrete dual-list implementation works against Studio DTOs
|
||||
- the right/build list can show visible indices
|
||||
- the component contract exposes `moveUp` and `moveDown`
|
||||
- the capacity meter can render absolute progress and severity state without owning bank rules
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for dual-list rendering and ordering controls
|
||||
- unit tests for visible index updates
|
||||
- unit tests for capacity-meter state rendering
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/controls/...`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- tests for dual-list and capacity meter components
|
||||
@ -0,0 +1,70 @@
|
||||
# PR-10c Bank Composition Section Shell and Form Session Integration
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
|
||||
## Briefing
|
||||
|
||||
Add the `Bank Composition` section shell into `Asset Details`, aligned with `Runtime Contract` and the existing `StudioFormSession` section rhythm.
|
||||
|
||||
This slice lands the visible section and its staged-edit shell contract before full family-specific behavior is wired.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- `Asset Details` contains a real `Bank Composition` section;
|
||||
- the section is a `VBox` section aligned with the existing details composition;
|
||||
- the section mirrors the `Runtime Contract` shell as closely as practical;
|
||||
- the section exposes `change`, `apply`, `reset`, and `cancel`;
|
||||
- outside editing it renders persisted state in read-only mode;
|
||||
- before behavior wiring is complete it can still render disabled/read-only internals instead of looking absent.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition Section Shell Decision.md`](../decisions/Bank%20Composition%20Section%20Shell%20Decision.md)
|
||||
- [`./PR-10a-bank-composition-details-dto-projection.md`](./PR-10a-bank-composition-details-dto-projection.md)
|
||||
- [`./PR-10b-bank-composition-base-components.md`](./PR-10b-bank-composition-base-components.md)
|
||||
- [`./PR-07c-asset-details-and-form-lifecycle.md`](./PR-07c-asset-details-and-form-lifecycle.md)
|
||||
|
||||
## Scope
|
||||
|
||||
- add the `Bank Composition` section to `Asset Details`
|
||||
- align the shell with `Runtime Contract`
|
||||
- integrate `StudioFormSession` staged-edit lifecycle at the section boundary
|
||||
- render read-only or disabled internals when behavior is incomplete
|
||||
- show persisted state outside edit mode
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no family-specific bank rules yet
|
||||
- no final section-scoped coordinator yet
|
||||
- no workspace-bus events yet
|
||||
- no packer apply write path yet
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Introduce the section host into `Asset Details`.
|
||||
2. Reuse the existing section/action-bar rhythm from `Runtime Contract`.
|
||||
3. Bind the section shell to a `StudioFormSession` lifecycle.
|
||||
4. Render read-only state outside edit mode.
|
||||
5. Render disabled/read-only internals where behavior is still pending.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the `Bank Composition` section is visible in `Asset Details`
|
||||
- the section shell matches the existing details-section rhythm
|
||||
- `change`, `apply`, `reset`, and `cancel` are part of the shell contract
|
||||
- outside edit mode the section shows persisted state in read-only form
|
||||
- the section does not appear blank or absent while later slices are still pending
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for section visibility and shell state
|
||||
- unit tests for `StudioFormSession`-driven shell transitions
|
||||
- UI smoke validation for read-only and editing shell modes
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/AssetDetailsControl.java`
|
||||
- new bank-composition section controls under `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- tests for details section-shell lifecycle
|
||||
@ -0,0 +1,77 @@
|
||||
# PR-10d Bank Composition Family Policies and Section Coordinator
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
Cross-domain impact: `docs/packer`
|
||||
|
||||
## Briefing
|
||||
|
||||
Introduce the section-scoped coordinator for `Bank Composition`, built around `StudioFormSession<BankCompositionDraft>`, plus the first family-specific draft factories and policies.
|
||||
|
||||
This is the slice where the section starts behaving like an actual editor instead of just a shell.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- `Bank Composition` has a section-scoped coordinator built around `StudioFormSession<BankCompositionDraft>`;
|
||||
- the section can enter edit mode and maintain draft state;
|
||||
- draft state can transfer rows between `available` and `selected`;
|
||||
- right-list ordering can update draft state;
|
||||
- family-specific rules are applied through draft factories and policies, not component-local logic.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition Middleware and Staged Editing Decision.md`](../decisions/Bank%20Composition%20Middleware%20and%20Staged%20Editing%20Decision.md)
|
||||
- [`./PR-10a-bank-composition-details-dto-projection.md`](./PR-10a-bank-composition-details-dto-projection.md)
|
||||
- [`./PR-10b-bank-composition-base-components.md`](./PR-10b-bank-composition-base-components.md)
|
||||
- [`./PR-10c-bank-composition-section-shell-and-form-session-integration.md`](./PR-10c-bank-composition-section-shell-and-form-session-integration.md)
|
||||
|
||||
## Scope
|
||||
|
||||
- add `BankCompositionDraft`
|
||||
- add the section-scoped coordinator around `StudioFormSession<BankCompositionDraft>`
|
||||
- add family-specific draft factories
|
||||
- add family-specific policies for:
|
||||
- transfer eligibility
|
||||
- reorder effects
|
||||
- capacity usage
|
||||
- hard-limit blockers
|
||||
- publish one section-facing view model for shell, lists, meter, blockers, and hints
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no public `workspaceBus` contract yet
|
||||
- no packer apply persistence yet
|
||||
- no final cross-domain mutation messages yet
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Add the draft model for bank composition.
|
||||
2. Add the section-scoped coordinator around `StudioFormSession`.
|
||||
3. Add the first family-specific policy/factory implementations.
|
||||
4. Route dual-list and meter inputs through the coordinator view model.
|
||||
5. Support edit, reset, and cancel with real draft recomputation.
|
||||
6. Keep apply stubbed or disabled until the write path lands.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the section can enter editing mode and maintain draft state
|
||||
- dual-list moves update draft state through the coordinator
|
||||
- right-list ordering updates draft state through the coordinator
|
||||
- meter state reflects policy-driven capacity calculations
|
||||
- tile and sound family differences are modeled through policies, not through component branches
|
||||
- `reset` and `cancel` work through `StudioFormSession`
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for `BankCompositionDraft`
|
||||
- unit tests for tile and sound policy behavior
|
||||
- unit tests for transfer blocking and reorder effects
|
||||
- unit tests for `StudioFormSession` integration and draft lifecycle
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- family-specific policy and draft-factory classes under `prometeu-studio/src/main/java/p/studio/workspaces/assets/...`
|
||||
- tests for coordinator and policy behavior
|
||||
- cross-domain touchpoint: any details data gaps exposed by the new policy logic
|
||||
@ -0,0 +1,70 @@
|
||||
# PR-10e Bank Composition WorkspaceBus Events and Local Orchestration
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
|
||||
## Briefing
|
||||
|
||||
Connect the `Bank Composition` section-scoped coordinator to the Studio workspace event model using the minimal notification-oriented contract already decided.
|
||||
|
||||
This slice keeps user actions local while making draft, capacity, and apply lifecycle visible to the rest of the workspace when needed.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- the section keeps user commands local to the section-scoped coordinator;
|
||||
- the minimal `workspaceBus` notifications exist for bank-composition state changes;
|
||||
- external observers can react to draft, capacity, and apply lifecycle without owning section-local commands.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition WorkspaceBus Interaction Decision.md`](../decisions/Bank%20Composition%20WorkspaceBus%20Interaction%20Decision.md)
|
||||
- [`./PR-10d-bank-composition-family-policies-and-section-coordinator.md`](./PR-10d-bank-composition-family-policies-and-section-coordinator.md)
|
||||
|
||||
## Scope
|
||||
|
||||
- add the first public bank-composition events:
|
||||
- `BankCompositionDraftChanged`
|
||||
- `BankCompositionCapacityChanged`
|
||||
- `BankCompositionApplyRequested`
|
||||
- `BankCompositionApplied`
|
||||
- `BankCompositionApplyFailed`
|
||||
- keep section-local actions local to the coordinator
|
||||
- publish capacity notifications with:
|
||||
- `progress`
|
||||
- `severity`
|
||||
- `blocked`
|
||||
- wire section subscribers/publishers as needed inside `Asset Details`
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no conversion of all section actions into public bus commands
|
||||
- no cross-workspace event taxonomy expansion beyond the minimal first-wave set
|
||||
- no packer write-path implementation in this slice
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Add the event classes and payloads.
|
||||
2. Publish draft and capacity notifications from the coordinator.
|
||||
3. Publish apply-requested/applied/apply-failed lifecycle notifications at the right boundaries.
|
||||
4. Keep move/reorder/edit/reset/cancel orchestration local.
|
||||
5. Add tests for event publication and subscription behavior.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the minimal first-wave bank-composition events exist on `workspaceBus`
|
||||
- user actions such as move and reorder are not exposed as public bus commands
|
||||
- capacity events publish absolute `0..1` progress plus severity and blocked state
|
||||
- apply lifecycle notifications are observable outside the section
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for event publication
|
||||
- unit tests for event payload correctness
|
||||
- unit tests confirming section-local actions remain local
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/events/...`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- tests for bank-composition event flow
|
||||
@ -0,0 +1,76 @@
|
||||
# PR-10f Bank Composition Apply Through Packer and Snapshot Refresh
|
||||
|
||||
Domain owner: `docs/studio`
|
||||
Cross-domain impact: `docs/packer`
|
||||
|
||||
## Briefing
|
||||
|
||||
Close the write path for `Bank Composition` by routing `apply` through the packer service and rebinding the section from refreshed persisted state.
|
||||
|
||||
This is the slice where the section stops being draft-only and becomes a real persisted editor.
|
||||
|
||||
## Objective
|
||||
|
||||
After this PR:
|
||||
|
||||
- clicking `apply` sends the selected ordered files to packer;
|
||||
- packer owns validation, manifest persistence, and minimal runtime snapshot refresh;
|
||||
- `asset.json` persistence flows through `artifacts`, not `inputsByRole`;
|
||||
- successful apply rebinds the section from refreshed persisted state;
|
||||
- failed apply preserves the draft and keeps the section in editing mode.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../decisions/Bank Composition Persistence and Snapshot Propagation Decision.md`](../decisions/Bank%20Composition%20Persistence%20and%20Snapshot%20Propagation%20Decision.md)
|
||||
- [`./PR-10d-bank-composition-family-policies-and-section-coordinator.md`](./PR-10d-bank-composition-family-policies-and-section-coordinator.md)
|
||||
- [`./PR-10e-bank-composition-workspacebus-events-and-local-orchestration.md`](./PR-10e-bank-composition-workspacebus-events-and-local-orchestration.md)
|
||||
- cross-domain dependency: packer-side message, persistence, and snapshot-refresh support for bank-composition apply
|
||||
|
||||
## Scope
|
||||
|
||||
- route section `apply` through the packer service boundary
|
||||
- send selected ordered files from Studio to packer
|
||||
- persist selection through `asset.json` `artifacts`
|
||||
- refresh minimal runtime/details state after successful apply
|
||||
- rebind the section from refreshed persisted state
|
||||
- preserve draft state on apply failure
|
||||
- surface local failure state plus `BankCompositionApplyFailed`
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- no direct `asset.json` writes from Studio
|
||||
- no fallback write path through legacy `inputsByRole`
|
||||
- no broader manifest migration outside this flow
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Define the Studio-to-packer apply request path for bank composition.
|
||||
2. Integrate section `apply` with the packer service.
|
||||
3. Update the Studio side to await success/failure and rebind accordingly.
|
||||
4. Land the paired packer-side persistence and minimal snapshot refresh support.
|
||||
5. Add regression tests for success and failure behavior.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Studio does not write `asset.json` directly for bank composition
|
||||
- `apply` is executed by packer
|
||||
- selected ordered files are persisted through `artifacts`
|
||||
- after success, the section leaves edit mode and reloads from refreshed persisted state
|
||||
- after failure, the section stays in edit mode and the draft is preserved
|
||||
- apply lifecycle notifications reflect the actual result of the packer call
|
||||
|
||||
## Validation
|
||||
|
||||
- Studio unit tests for apply success rebinding
|
||||
- Studio unit tests for apply failure preserving draft state
|
||||
- packer tests for `artifacts` persistence and minimal snapshot refresh
|
||||
- UI smoke validation for apply, success, and failure flows
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/...`
|
||||
- `prometeu-studio/src/main/java/p/studio/projects/...`
|
||||
- `prometeu-studio/src/main/java/p/studio/events/...`
|
||||
- `prometeu-packer/src/main/java/p/packer/...`
|
||||
- `asset.json` persistence handling under the packer write path
|
||||
- Studio and packer tests for bank-composition apply
|
||||
@ -61,3 +61,12 @@ It enforces list/details package boundaries and requires every panel to consume
|
||||
Recommended execution order:
|
||||
|
||||
`PR-05a -> PR-05b -> PR-05c -> PR-05d -> PR-05e -> PR-07a -> PR-07b -> PR-07c -> PR-07d -> PR-07e -> PR-08 -> PR-06`
|
||||
|
||||
Next planned family for `Bank Composition`:
|
||||
|
||||
13. [`PR-10a-bank-composition-details-dto-projection.md`](./PR-10a-bank-composition-details-dto-projection.md)
|
||||
14. [`PR-10b-bank-composition-base-components.md`](./PR-10b-bank-composition-base-components.md)
|
||||
15. [`PR-10c-bank-composition-section-shell-and-form-session-integration.md`](./PR-10c-bank-composition-section-shell-and-form-session-integration.md)
|
||||
16. [`PR-10d-bank-composition-family-policies-and-section-coordinator.md`](./PR-10d-bank-composition-family-policies-and-section-coordinator.md)
|
||||
17. [`PR-10e-bank-composition-workspacebus-events-and-local-orchestration.md`](./PR-10e-bank-composition-workspacebus-events-and-local-orchestration.md)
|
||||
18. [`PR-10f-bank-composition-apply-through-packer-and-snapshot-refresh.md`](./PR-10f-bank-composition-apply-through-packer-and-snapshot-refresh.md)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user