# 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. pull-request 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`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
2. [`2. Studio UI Foundations Specification.md`](2.%20Studio%20UI%20Foundations%20Specification.md)
3. [`3. Studio Components Module Specification.md`](3.%20Studio%20Components%20Module%20Specification.md)
4. [`4. Assets Workspace Specification.md`](4.%20Assets%20Workspace%20Specification.md)
5. [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md)

## Reading Order

Recommended order:

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