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,
- pull-request 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.md
Reading Order
Recommended order:
- shell and workspace layout;
- shared UI foundations;
- components module policy;
- assets workspace behavior.