2026-03-31 08:01:53 +01:00

2.0 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
  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. project document VFS boundary;
  5. assets workspace behavior;
  6. code editor workspace behavior.