clean up
This commit is contained in:
parent
6f105b11ab
commit
cf030cb5f5
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -1,93 +0,0 @@
|
|||||||
# 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.
|
|
||||||
|
|
||||||
The implementation should be based conceptually on the C# event system located at:
|
|
||||||
|
|
||||||
`/Users/niltonconstantino/personal/workspace.personal/unity/My-Local-Packages/Packages/intrepid-general-utilities/Runtime/SimpleEvents`
|
|
||||||
|
|
||||||
The generic bus machinery should live in shared infrastructure, not in the Studio components module.
|
|
||||||
|
|
||||||
The bus must be thread-safe because background work such as asset recognition, tree refresh triggers, diagnostics updates, and other asynchronous Studio tasks may publish events from outside the UI thread.
|
|
||||||
|
|
||||||
## Objective
|
|
||||||
|
|
||||||
Implement the typed Studio event infrastructure so future Studio work can publish and observe events without string routing or ad hoc direct coupling.
|
|
||||||
|
|
||||||
The generic event bus core should be introduced in `prometeu-infra`, while Studio-specific bus composition remains in Studio code.
|
|
||||||
|
|
||||||
## 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 event bus foundation in `prometeu-infra`
|
|
||||||
- introduce Studio-specific global and workspace bus composition on top of that foundation
|
|
||||||
- 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`
|
|
||||||
- placing the generic bus core inside `prometeu-studio-components`
|
|
||||||
|
|
||||||
## Execution Method
|
|
||||||
|
|
||||||
1. Use `/Users/niltonconstantino/personal/workspace.personal/unity/My-Local-Packages/Packages/intrepid-general-utilities/Runtime/SimpleEvents` as the architectural reference point.
|
|
||||||
2. Port the useful baseline ideas into Java rather than copying Unity-specific structure literally.
|
|
||||||
3. Introduce the generic event bus machinery in `prometeu-infra`.
|
|
||||||
4. Keep the generic layer unaware of Studio shell semantics.
|
|
||||||
5. Introduce the Studio-specific event contract and bus composition above that generic layer.
|
|
||||||
6. Use typed DTO events, preferably immutable.
|
|
||||||
7. Make subscription and unsubscription explicit and safe.
|
|
||||||
8. Implement one global bus and one workspace bus type for Studio.
|
|
||||||
9. Ensure every workspace event is automatically republished to the global bus.
|
|
||||||
10. Keep propagation one-way: workspace to global.
|
|
||||||
11. Make publication and subscription management thread-safe.
|
|
||||||
12. Add tests for:
|
|
||||||
- typed subscription
|
|
||||||
- unsubscription
|
|
||||||
- workspace-to-global propagation
|
|
||||||
- no accidental global-to-workspace rebroadcast
|
|
||||||
- concurrent publication and subscription safety
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- `prometeu-infra` has a generic typed event bus foundation
|
|
||||||
- Studio code has a global and workspace bus composition built on top of that foundation
|
|
||||||
- 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
|
|
||||||
- publication and subscription handling are safe under concurrent access
|
|
||||||
- automated tests cover the propagation baseline
|
|
||||||
|
|
||||||
## Validation
|
|
||||||
|
|
||||||
- unit tests for bus behavior
|
|
||||||
- basic smoke coverage for publish/subscribe and nested propagation
|
|
||||||
- concurrent test coverage for thread-safe event publication
|
|
||||||
|
|
||||||
## Affected Artifacts
|
|
||||||
|
|
||||||
- `prometeu-infra`
|
|
||||||
- `prometeu-studio` application infrastructure
|
|
||||||
- future shell integration points
|
|
||||||
- tests for Studio UI foundation code
|
|
||||||
@ -1,69 +0,0 @@
|
|||||||
# 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. Establish explicit `subscribe()` and `unsubscribe()` lifecycle hooks in the control layer so event-driven controls can override them when needed.
|
|
||||||
6. Establish `onAttached()` and `onDetached()` hooks that call `subscribe()` and `unsubscribe()` respectively.
|
|
||||||
7. Refactor the shell layer in `prometeu-studio` to consume these controls instead of raw JavaFX where the controls are now available.
|
|
||||||
8. 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
|
|
||||||
- event-driven controls have explicit subscribe and unsubscribe lifecycle hooks
|
|
||||||
- attach and detach lifecycle hooks drive subscription setup and teardown
|
|
||||||
- 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
|
|
||||||
@ -1,70 +0,0 @@
|
|||||||
# 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
|
|
||||||
@ -1,60 +0,0 @@
|
|||||||
# PR-04a - Project Launcher Window Lifecycle
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
The current project launcher already exists as a view before the main shell.
|
|
||||||
|
|
||||||
This PR evolves that flow into a separate launcher window so project selection and project editing no longer compete for the same application stage.
|
|
||||||
|
|
||||||
## Objective
|
|
||||||
|
|
||||||
Move the project launcher into its own window lifecycle and define how it coordinates with the main Studio project window.
|
|
||||||
|
|
||||||
## 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)
|
|
||||||
- `PR-03 - Project Launcher and Project Entry Shell`
|
|
||||||
|
|
||||||
## Scope
|
|
||||||
|
|
||||||
- introduce a dedicated launcher `Stage`
|
|
||||||
- open the main Studio shell in a separate project window
|
|
||||||
- define launcher visibility behavior when a project window opens
|
|
||||||
- define launcher restoration behavior when a project window closes
|
|
||||||
- keep event publication aligned with the Studio event model
|
|
||||||
|
|
||||||
## Non-Goals
|
|
||||||
|
|
||||||
- redesigning the launcher content model
|
|
||||||
- implementing the new project wizard itself
|
|
||||||
- supporting multiple simultaneous project windows unless needed by the chosen lifecycle
|
|
||||||
|
|
||||||
## Execution Method
|
|
||||||
|
|
||||||
1. Extract launcher-stage creation from the current single-window flow.
|
|
||||||
2. Open the main Studio shell in its own project window after project selection or creation.
|
|
||||||
3. Hide the launcher window when a project window opens.
|
|
||||||
4. Restore or reshow the launcher window when the project window closes.
|
|
||||||
5. Keep the transition between launcher and project window intentional and easy to follow.
|
|
||||||
6. Preserve theme and i18n behavior in both windows.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- the launcher runs in its own window
|
|
||||||
- the Studio shell runs in a separate project window
|
|
||||||
- opening or creating a project transitions from launcher to project window cleanly
|
|
||||||
- closing the project window returns the user to the launcher window
|
|
||||||
- the flow remains aligned with current project-open and project-created events
|
|
||||||
|
|
||||||
## Validation
|
|
||||||
|
|
||||||
- compile validation of `prometeu-studio`
|
|
||||||
- smoke validation of launcher window opening
|
|
||||||
- smoke validation of launcher hide/show behavior when a project window opens or closes
|
|
||||||
|
|
||||||
## Affected Artifacts
|
|
||||||
|
|
||||||
- `prometeu-studio` application entry and stage lifecycle
|
|
||||||
- launcher and shell composition
|
|
||||||
- project-open window behavior
|
|
||||||
@ -1,64 +0,0 @@
|
|||||||
# PR-04b - New Project Wizard
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
The current project launcher can create a project directly from an inline text field.
|
|
||||||
|
|
||||||
This PR replaces that minimal path with a dedicated wizard so project creation becomes a guided flow rather than a single-form action.
|
|
||||||
|
|
||||||
## Objective
|
|
||||||
|
|
||||||
Introduce a new project wizard that guides project creation before opening the Studio shell.
|
|
||||||
|
|
||||||
## 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)
|
|
||||||
- `PR-03 - Project Launcher and Project Entry Shell`
|
|
||||||
- `PR-04a - Project Launcher Window Lifecycle`
|
|
||||||
|
|
||||||
## Scope
|
|
||||||
|
|
||||||
- replace inline project creation with a wizard flow
|
|
||||||
- support at least:
|
|
||||||
- project name
|
|
||||||
- project location
|
|
||||||
- final confirmation
|
|
||||||
- create the project through the existing project service layer
|
|
||||||
- open the project after successful creation
|
|
||||||
|
|
||||||
## Non-Goals
|
|
||||||
|
|
||||||
- full template marketplace or template system
|
|
||||||
- advanced preset configuration
|
|
||||||
- remote project provisioning
|
|
||||||
|
|
||||||
## Execution Method
|
|
||||||
|
|
||||||
1. Introduce a `New Project Wizard` surface from the launcher.
|
|
||||||
2. Split project creation into explicit steps.
|
|
||||||
3. Validate project name and location before final confirmation.
|
|
||||||
4. Reuse the existing project creation service instead of duplicating creation logic in the UI.
|
|
||||||
5. Open the created project after the wizard completes successfully.
|
|
||||||
6. Keep the wizard aligned with Studio theming and i18n rules.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- `Create New Project` opens a wizard instead of creating inline immediately
|
|
||||||
- the wizard supports name, location, and confirmation steps
|
|
||||||
- invalid project data is blocked before creation
|
|
||||||
- successful completion creates the project and opens it
|
|
||||||
- the flow remains consistent with the launcher/project-entry model
|
|
||||||
|
|
||||||
## Validation
|
|
||||||
|
|
||||||
- compile validation of `prometeu-studio`
|
|
||||||
- smoke validation of wizard opening and step progression
|
|
||||||
- test or smoke coverage for successful project creation
|
|
||||||
|
|
||||||
## Affected Artifacts
|
|
||||||
|
|
||||||
- launcher UI
|
|
||||||
- project creation flow
|
|
||||||
- project service integration
|
|
||||||
- entry transition from launcher to shell
|
|
||||||
Loading…
x
Reference in New Issue
Block a user