prometeu-studio/docs/studio

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

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 only execution plans for pending work.
• 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/ and learn/. At this moment:

• agendas/ retains only topics that are still open;
• decisions/ is empty because the last accepted wave was fully propagated;
• pull-requests/ is empty because the historical execution wave was absorbed into learn/.

If implementation exposes a missing UI or interaction decision, stop and return to agendas/ or decisions/.