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:
- Title
- Status
- Scope or Applies To
- Purpose
- Authority and Precedence
- Normative Inputs
- Core Rules
- Non-Goals
- 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:
- agendas that frame the open Studio topic,
- decisions that close the product or interaction choice,
- plans that define propagation,
- 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. Studio Shell and Workspace Layout Specification.md2. Studio UI Foundations Specification.md3. Studio Components Module Specification.md4. Assets Workspace Specification.md8. Project-Local Studio State Specification.md
Reading Order
Recommended order:
- shell and workspace layout;
- shared UI foundations;
- components module policy;
- assets workspace behavior;
- project-local Studio state behavior.
Current Wave Notes
The embedded Studio code-editor stack was removed by DEC-0031.
Normative reminders:
- the active Studio workspace corpus is
Assets,Debug, andShipper; - project-local Studio session state remains normative and is owned by
StudioProjectSession; - any future external-editor backend or replacement language-service architecture requires a new accepted decision before new Studio specs are introduced.