50 lines
1.2 KiB
Markdown
50 lines
1.2 KiB
Markdown
# Studio Decisions
|
|
|
|
This directory contains Studio decision records that still need propagation.
|
|
|
|
Current retained set:
|
|
|
|
- none
|
|
|
|
The current Studio decision wave has already been consolidated into:
|
|
|
|
- normative specifications under [`../specs/`](../specs/)
|
|
- didactic material under [`../learn/`](../learn/)
|
|
|
|
## Purpose
|
|
|
|
A Studio decision record bridges UI discussion and implementation.
|
|
|
|
Use this directory to capture:
|
|
|
|
- what Studio behavior was chosen,
|
|
- why that interaction model was preferred,
|
|
- what constraints now apply to the shell and workspaces,
|
|
- what specs, plans, and code paths must be updated.
|
|
|
|
## Expected Format
|
|
|
|
A Studio decision should usually include:
|
|
|
|
1. Title
|
|
2. Status
|
|
3. Date or Cycle
|
|
4. Context
|
|
5. Decision
|
|
6. Invariants and Constraints
|
|
7. Explicit Non-Decisions
|
|
8. Propagation Targets
|
|
9. Validation Notes or Examples
|
|
|
|
## Writing Rules
|
|
|
|
- State the adopted Studio behavior early and clearly.
|
|
- Keep the tone stable and implementation-oriented.
|
|
- Record interaction constraints explicitly.
|
|
- Point to exact specs, plans, or UI surfaces that need propagation.
|
|
|
|
## Implementation Rule
|
|
|
|
If Studio code work reveals a missing decision, do not guess the UX contract.
|
|
Return the issue to agenda or decision review.
|