86 lines
2.9 KiB
Markdown
86 lines
2.9 KiB
Markdown
# 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. 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)
|
|
6. [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md)
|
|
7. [`7. Integrated LSP Semantic Read Phase Specification.md`](7.%20Integrated%20LSP%20Semantic%20Read%20Phase%20Specification.md)
|
|
8. [`8. Project-Local Studio State Specification.md`](8.%20Project-Local%20Studio%20State%20Specification.md)
|
|
|
|
## Reading Order
|
|
|
|
Recommended order:
|
|
|
|
1. shell and workspace layout;
|
|
2. shared UI foundations;
|
|
3. components module policy;
|
|
4. assets workspace behavior;
|
|
5. project document VFS boundary;
|
|
6. code editor workspace behavior;
|
|
7. integrated LSP semantic-read behavior;
|
|
8. project-local Studio state behavior.
|
|
|
|
## Current Wave Notes
|
|
|
|
The current `Code Editor` wave is not globally read-only anymore.
|
|
|
|
Normative reminders:
|
|
|
|
- editable scope is limited to supported non-frontend textual documents classified by `prometeu-vfs`;
|
|
- frontend-scoped supported documents remain hard `read-only`;
|
|
- the editor-local `Save` and `Save All` surfaces belong to the `Code Editor` workspace rather than the shell;
|
|
- editorial in-memory snapshots remain outside build-facing state;
|
|
- frontend semantic-read capability lands before any frontend editing release and is documented by the integrated LSP phase specification.
|