114 lines
3.6 KiB
Markdown
114 lines
3.6 KiB
Markdown
# Studio Documentation
|
|
|
|
This directory contains the working, planning, normative, and didactic documentation for the `studio` domain.
|
|
|
|
`studio` is a standalone domain focused on the UI shell, workspace model, interaction design, and service integration of `prometeu-studio`.
|
|
|
|
It follows the same documentary cycle used elsewhere in the repository:
|
|
|
|
`agendas -> decisions -> pull-requests -> specs -> learn`
|
|
|
|
## Tree
|
|
|
|
```text
|
|
docs/studio/
|
|
├── agendas/
|
|
├── decisions/
|
|
├── learn/
|
|
├── pull-requests/
|
|
├── specs/
|
|
└── README.md
|
|
```
|
|
|
|
## Current Code Context
|
|
|
|
The current `prometeu-studio` application already has a lightweight shell:
|
|
|
|
- `MainView` composes the application frame;
|
|
- `WorkspaceBar` switches between workspaces;
|
|
- `EditorWorkspace` is the most concrete workspace today;
|
|
- `Assets` is still a placeholder workspace;
|
|
- `BuilderWorkspace` exists as an implementation artifact, but Studio UI planning should treat shipping and asset tooling as distinct concerns going forward.
|
|
|
|
The first Studio documentation wave should therefore focus on turning the current shell into an intentional UI model instead of adding more placeholders.
|
|
|
|
## Responsibilities
|
|
|
|
### `agendas/`
|
|
|
|
`agendas/` is the staging area for open Studio product and interaction questions.
|
|
|
|
Use it to:
|
|
|
|
- shape workspace and panel structure,
|
|
- compare UI interaction models,
|
|
- decide how Studio consumes services and events,
|
|
- define what must be visible, staged, or confirmed in the UI.
|
|
|
|
When a topic is fully propagated into specs and learn, the corresponding agenda should leave the retained set.
|
|
|
|
### `decisions/`
|
|
|
|
`decisions/` records closed Studio product and UX decisions before they are fully propagated.
|
|
|
|
Use it to:
|
|
|
|
- close interaction and architecture choices,
|
|
- define invariants for UI behavior,
|
|
- capture what must be implemented in Studio code and service contracts.
|
|
|
|
Once their content is fully absorbed into specs and learn, they should not be retained just as historical residue.
|
|
|
|
### `pull-requests/`
|
|
|
|
`pull-requests/` contains execution plans for Studio changes.
|
|
|
|
Use it to:
|
|
|
|
- break a UI decision into implementation slices,
|
|
- separate shell work, workspace work, and service integration work,
|
|
- define acceptance criteria and validation paths.
|
|
|
|
### `specs/`
|
|
|
|
`specs/` contains the normative Studio contract.
|
|
|
|
Use it to:
|
|
|
|
- define shell structure,
|
|
- document workspace responsibilities,
|
|
- specify interaction flows,
|
|
- stabilize event and service integration expectations.
|
|
|
|
### `learn/`
|
|
|
|
`learn/` contains didactic Studio material.
|
|
|
|
Use it to:
|
|
|
|
- explain the mental model of the Studio,
|
|
- document why the UI is structured the way it is,
|
|
- help future contributors navigate shell, workspaces, and integration boundaries.
|
|
|
|
## Recommended Flow
|
|
|
|
The preferred Studio documentation flow is:
|
|
|
|
1. `agendas/`: open and shape the unresolved UI topic.
|
|
2. `decisions/`: close the product or interaction choice.
|
|
3. `pull-requests/`: plan propagation into code and specs.
|
|
4. `specs/`: integrate the normative Studio contract.
|
|
5. `learn/`: consolidate the final model in a didactic form.
|
|
|
|
## Practical Rule
|
|
|
|
- `agendas/` stores currently open Studio questions.
|
|
- `decisions/` stores only decisions that still need propagation.
|
|
- `pull-requests/` stores execution plans.
|
|
- `specs/` stores the normative Studio contract.
|
|
- `learn/` stores teaching-oriented Studio knowledge.
|
|
|
|
The current Studio core and first `Assets` workspace wave have already been consolidated into [`specs/`](./specs/) and [`learn/`](./learn/). The `agendas/` and `decisions/` directories remain available for future cycles.
|
|
|
|
If implementation exposes a missing UI or interaction decision, stop and return to `agendas/` or `decisions/`.
|