2.0 KiB
2.0 KiB
Studio Components Module and Admission Policy Agenda
Status
Open
Purpose
Define the role of prometeu-studio-components and the rules for what should enter that module.
The module now exists as a base project, but it should not become a dumping ground for wrappers around JavaFX controls or speculative framework work.
Domain Owner
docs/studio
Context
The Studio UI is about to be remodeled.
We want:
- a consistent Studio UI dialect;
- reusable JavaFX-based Studio components;
- easier customization and stronger engineering around shared controls;
- continued compatibility with i18n and themes.
At the same time, we explicitly do not want to populate the module prematurely.
Current Direction
prometeu-studio-components should remain empty until concrete Studio UI work requires shared controls.
The baseline policy is:
- the module exists now so Studio UI work has a clear home for shared components;
- components are admitted only when they are needed by the current Studio UI wave;
- the module should stay focused on real Studio shell and workspace needs, not general JavaFX abstraction for its own sake.
Core Questions
- Which kinds of components belong in
prometeu-studio-componentsfrom day 1? - Which controls should remain local to
prometeu-studiountil a second use appears? - What theme and i18n requirements must every admitted component satisfy?
- How much infrastructure should live in this module versus in Studio application code?
- How do we prevent the module from turning into a speculative component catalog?
Recommendation
Keep the module intentionally sparse.
Recommended admission rule:
- add a component when it is part of the shell or has immediate reuse in the current Studio UI work;
- otherwise keep it local until the need is proven.
Expected Follow-up
- a decision on the admission policy for
prometeu-studio-components; - a future spec or learn artifact once the first component wave actually exists.