# 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/`.