added PRs
This commit is contained in:
parent
2ee37d7d13
commit
3afeaafc2a
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -0,0 +1,71 @@
|
||||
# PR-01 - StudioEventBus Foundation
|
||||
|
||||
## Briefing
|
||||
|
||||
The Studio now has a normative event model in spec, but `prometeu-studio` still relies on direct UI wiring.
|
||||
|
||||
This PR introduces the generic `StudioEventBus` foundation that later Studio code will use for:
|
||||
|
||||
- shell-level observation,
|
||||
- workspace-local activity,
|
||||
- workspace-to-global propagation,
|
||||
- project launcher and shell interactions.
|
||||
|
||||
## Objective
|
||||
|
||||
Implement the typed Studio event infrastructure in application code so future Studio work can publish and observe events without string routing or ad hoc direct coupling.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../specs/2. Studio UI Foundations Specification.md`](../specs/2.%20Studio%20UI%20Foundations%20Specification.md)
|
||||
- [`../specs/3. Studio Components Module Specification.md`](../specs/3.%20Studio%20Components%20Module%20Specification.md) for downstream UI implications
|
||||
|
||||
## Scope
|
||||
|
||||
- introduce a generic typed `StudioEventBus`
|
||||
- introduce a workspace-local bus model
|
||||
- support automatic workspace-to-global propagation
|
||||
- introduce DTO-style event payload contracts
|
||||
- add the minimum initial event set needed by the shell wave
|
||||
- add tests for propagation and subscription behavior
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- implementing every future Studio event now
|
||||
- integrating the full packer event lane now
|
||||
- redesigning the whole shell in this PR
|
||||
- moving visual controls into `prometeu-studio-components`
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Introduce a small event contract in `prometeu-studio`.
|
||||
2. Use typed DTO events, preferably immutable.
|
||||
3. Make subscription and unsubscription explicit and safe.
|
||||
4. Implement one global bus and one workspace bus type.
|
||||
5. Ensure every workspace event is automatically republished to the global bus.
|
||||
6. Keep propagation one-way: workspace to global.
|
||||
7. Add tests for:
|
||||
- typed subscription
|
||||
- unsubscription
|
||||
- workspace-to-global propagation
|
||||
- no accidental global-to-workspace rebroadcast
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- `prometeu-studio` has a generic typed `StudioEventBus`
|
||||
- workspace buses exist and can be attached to the global bus
|
||||
- every workspace-published event is observable on the global bus
|
||||
- callers do not need to publish the same event twice manually
|
||||
- event payloads are DTO-style and not string-based
|
||||
- automated tests cover the propagation baseline
|
||||
|
||||
## Validation
|
||||
|
||||
- unit tests for bus behavior
|
||||
- basic smoke coverage for publish/subscribe and nested propagation
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio` application infrastructure
|
||||
- future shell integration points
|
||||
- tests for Studio UI foundation code
|
||||
@ -0,0 +1,65 @@
|
||||
# PR-02 - Studio Shell Components Wave 1
|
||||
|
||||
## Briefing
|
||||
|
||||
The Studio has already decided that used visual controls should come through `prometeu-studio-components`.
|
||||
|
||||
Before implementing the new shell entry flow, the codebase needs the first component wave for the shell itself.
|
||||
|
||||
## Objective
|
||||
|
||||
Establish the first set of Studio shell controls in `prometeu-studio-components` so the launcher and shell work do not grow on top of raw JavaFX controls.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../specs/1. Studio Shell and Workspace Layout Specification.md`](../specs/1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
|
||||
- [`../specs/3. Studio Components Module Specification.md`](../specs/3.%20Studio%20Components%20Module%20Specification.md)
|
||||
- `PR-01 - StudioEventBus Foundation`
|
||||
|
||||
## Scope
|
||||
|
||||
- create the first shell-facing controls in `prometeu-studio-components`
|
||||
- establish theme and i18n-safe control patterns
|
||||
- wire the Studio shell to consume those controls
|
||||
|
||||
Initial candidate controls:
|
||||
|
||||
- shell menu surface
|
||||
- workspace rail or workspace selector control
|
||||
- right utility panel shell
|
||||
- run surface control
|
||||
- simple shell panel/header primitives as needed
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- implementing the full Assets workspace
|
||||
- introducing every future Studio control family
|
||||
- building a generic docking framework
|
||||
- solving project launcher behavior in full
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Define the first Studio shell controls in `prometeu-studio-components`.
|
||||
2. Keep each control API small and Studio-facing.
|
||||
3. Keep styling themeable through CSS.
|
||||
4. Keep user-facing text bindable and locale-safe.
|
||||
5. Refactor the shell layer in `prometeu-studio` to consume these controls instead of raw JavaFX where the controls are now available.
|
||||
6. Avoid adding speculative controls with no immediate shell use.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the first shell-facing controls exist in `prometeu-studio-components`
|
||||
- those controls are used by the Studio shell code
|
||||
- no new shell control work lands directly on raw JavaFX when a Studio control is now available
|
||||
- theme and i18n compatibility are preserved
|
||||
|
||||
## Validation
|
||||
|
||||
- compile validation of `prometeu-studio` and `prometeu-studio-components`
|
||||
- smoke validation that the Studio still launches and renders the shell
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio-components`
|
||||
- `prometeu-studio` shell code
|
||||
- shell styling and theme resources
|
||||
@ -0,0 +1,70 @@
|
||||
# PR-03 - Project Launcher and Project Entry Shell
|
||||
|
||||
## Briefing
|
||||
|
||||
The Studio shell spec requires a project launcher or home surface before the main workspace shell.
|
||||
|
||||
This PR introduces that first real user entry flow so the Studio can:
|
||||
|
||||
- show existing or recent projects,
|
||||
- open a project,
|
||||
- create a new project,
|
||||
- then enter the main shell intentionally.
|
||||
|
||||
## Objective
|
||||
|
||||
Implement the first project entry experience for the Studio and connect it to the shell and event model.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- [`../specs/1. Studio Shell and Workspace Layout Specification.md`](../specs/1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
|
||||
- [`../specs/2. Studio UI Foundations Specification.md`](../specs/2.%20Studio%20UI%20Foundations%20Specification.md)
|
||||
- [`../specs/3. Studio Components Module Specification.md`](../specs/3.%20Studio%20Components%20Module%20Specification.md)
|
||||
- `PR-01 - StudioEventBus Foundation`
|
||||
- `PR-02 - Studio Shell Components Wave 1`
|
||||
|
||||
## Scope
|
||||
|
||||
- add a launcher or home surface before the shell
|
||||
- show existing or recent projects
|
||||
- expose `Open Project` and `Create Project`
|
||||
- enter the main shell only after project selection or creation
|
||||
- publish the relevant Studio events for project entry
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- implementing the full asset-management workspace
|
||||
- implementing all future project metadata and history policy
|
||||
- finalizing shipper workflows
|
||||
- introducing remote project management behavior
|
||||
|
||||
## Execution Method
|
||||
|
||||
1. Introduce a project launcher or home view in the Studio entry flow.
|
||||
2. Add a minimal project list surface for existing or recent projects.
|
||||
3. Add actions for `Open Project` and `Create Project`.
|
||||
4. Route project entry through the Studio event model where appropriate.
|
||||
5. Enter the main shell only after a concrete project action completes.
|
||||
6. Keep the shell and launcher aligned with i18n, themes, and Studio controls.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- the Studio no longer lands directly in a workspace by default
|
||||
- the user can see existing or recent projects from the launcher
|
||||
- the user can trigger `Open Project`
|
||||
- the user can trigger `Create Project`
|
||||
- entering the main shell requires a concrete selected or created project
|
||||
- project entry behavior is aligned with the shell spec
|
||||
|
||||
## Validation
|
||||
|
||||
- compile validation of `prometeu-studio` and `prometeu-studio-components`
|
||||
- smoke validation that the launcher appears before the shell
|
||||
- smoke validation of open/create project entry paths
|
||||
|
||||
## Affected Artifacts
|
||||
|
||||
- `prometeu-studio` application entry flow
|
||||
- shell composition
|
||||
- `prometeu-studio-components` shell and launcher controls
|
||||
- Studio event publication for project entry
|
||||
@ -33,3 +33,11 @@ A Studio plan should usually include:
|
||||
- Keep visual design, interaction behavior, and service integration clearly separated.
|
||||
- State what the user should be able to do after the change lands.
|
||||
- Tie the plan back to Studio specs and decisions explicitly.
|
||||
|
||||
## Current Queue
|
||||
|
||||
The current Studio execution queue is:
|
||||
|
||||
1. [`PR-01-studio-event-bus-foundation.md`](./PR-01-studio-event-bus-foundation.md)
|
||||
2. [`PR-02-studio-shell-components-wave-1.md`](./PR-02-studio-shell-components-wave-1.md)
|
||||
3. [`PR-03-project-launcher-and-project-entry-shell.md`](./PR-03-project-launcher-and-project-entry-shell.md)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user