prometeu-studio/docs/specs/studio

Studio Specs

This directory contains the normative Studio specification set.

Purpose

Specs define the official Studio contract.

They exist to stabilize:

• the application shell,
• workspace responsibilities,
• interaction flows,
• service and event integration expectations,
• UX behavior that implementation should preserve.

Expected Format

The exact structure may vary by document, but a Studio spec should usually contain:

1. Title
2. Status
3. Scope or Applies To
4. Purpose
5. Authority and Precedence
6. Normative Inputs
7. Core Rules
8. Non-Goals
9. Exit Criteria

Writing Rules

• Write in normative language.
• Integrate only decisions that have already been closed.
• Keep design exploration and option analysis out of the spec body.
• Preserve clear boundaries between shell, workspace, and integration specs.

Upstream Rule

Specs should normally be fed by:

1. agendas that frame the open Studio topic,
2. decisions that close the product or interaction choice,
3. plans that define propagation,
4. then spec integration.

If a spec edit would require guessing unresolved UI behavior, stop and surface the missing decision first.

Current Corpus

The current Studio core corpus is:

1. 1. Studio Shell and Workspace Layout Specification.md
2. 2. Studio UI Foundations Specification.md
3. 3. Studio Components Module Specification.md
4. 4. Assets Workspace Specification.md
5. 5. Code Editor Workspace Specification.md
6. 6. Project Document VFS Specification.md

Reading Order

Recommended order:

1. shell and workspace layout;
2. shared UI foundations;
3. components module policy;
4. assets workspace behavior;
5. project document VFS boundary;
6. code editor workspace behavior.

Current Wave Notes

The current Code Editor wave is not globally read-only anymore.

Normative reminders:

• editable scope is limited to supported non-frontend textual documents classified by prometeu-vfs;
• frontend-scoped supported documents remain hard read-only;
• the editor-local Save and Save All surfaces belong to the Code Editor workspace rather than the shell;
• editorial in-memory snapshots remain outside build-facing state.