From cf030cb5f51938c77d7eb8e4c434ae0afee9b097 Mon Sep 17 00:00:00 2001 From: bQUARKz Date: Wed, 11 Mar 2026 15:55:36 +0000 Subject: [PATCH] clean up --- .../PR-01-studio-event-bus-foundation.md | 93 ------------------- .../PR-02-studio-shell-components-wave-1.md | 69 -------------- ...roject-launcher-and-project-entry-shell.md | 70 -------------- ...R-04a-project-launcher-window-lifecycle.md | 60 ------------ .../PR-04b-new-project-wizard.md | 64 ------------- 5 files changed, 356 deletions(-) delete mode 100644 docs/studio/pull-requests/PR-01-studio-event-bus-foundation.md delete mode 100644 docs/studio/pull-requests/PR-02-studio-shell-components-wave-1.md delete mode 100644 docs/studio/pull-requests/PR-03-project-launcher-and-project-entry-shell.md delete mode 100644 docs/studio/pull-requests/PR-04a-project-launcher-window-lifecycle.md delete mode 100644 docs/studio/pull-requests/PR-04b-new-project-wizard.md diff --git a/docs/studio/pull-requests/PR-01-studio-event-bus-foundation.md b/docs/studio/pull-requests/PR-01-studio-event-bus-foundation.md deleted file mode 100644 index bc6d1ca7..00000000 --- a/docs/studio/pull-requests/PR-01-studio-event-bus-foundation.md +++ /dev/null @@ -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 diff --git a/docs/studio/pull-requests/PR-02-studio-shell-components-wave-1.md b/docs/studio/pull-requests/PR-02-studio-shell-components-wave-1.md deleted file mode 100644 index b58b3ed5..00000000 --- a/docs/studio/pull-requests/PR-02-studio-shell-components-wave-1.md +++ /dev/null @@ -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 diff --git a/docs/studio/pull-requests/PR-03-project-launcher-and-project-entry-shell.md b/docs/studio/pull-requests/PR-03-project-launcher-and-project-entry-shell.md deleted file mode 100644 index 01c64330..00000000 --- a/docs/studio/pull-requests/PR-03-project-launcher-and-project-entry-shell.md +++ /dev/null @@ -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 diff --git a/docs/studio/pull-requests/PR-04a-project-launcher-window-lifecycle.md b/docs/studio/pull-requests/PR-04a-project-launcher-window-lifecycle.md deleted file mode 100644 index f4b8ab9b..00000000 --- a/docs/studio/pull-requests/PR-04a-project-launcher-window-lifecycle.md +++ /dev/null @@ -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 diff --git a/docs/studio/pull-requests/PR-04b-new-project-wizard.md b/docs/studio/pull-requests/PR-04b-new-project-wizard.md deleted file mode 100644 index b7838120..00000000 --- a/docs/studio/pull-requests/PR-04b-new-project-wizard.md +++ /dev/null @@ -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