1.8 KiB

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
  2. 2. Studio UI Foundations Specification.md
  3. 3. Studio Components Module Specification.md
  4. 4. Assets Workspace Specification.md

Reading Order

Recommended order:

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