47 lines
1.2 KiB
Markdown
47 lines
1.2 KiB
Markdown
# Studio Pull Requests
|
|
|
|
This directory contains executable plans for Studio work.
|
|
|
|
Current retained set:
|
|
|
|
- none
|
|
|
|
The previous Studio execution wave has already been consolidated into [`../learn/`](../learn/) and propagated into [`../specs/`](../specs/).
|
|
|
|
## Purpose
|
|
|
|
A Studio pull-request or plan artifact packages a decision into an implementable sequence.
|
|
|
|
Use it to:
|
|
|
|
- separate shell work from workspace work,
|
|
- describe service and event-lane integration steps,
|
|
- define acceptance criteria for UI behavior,
|
|
- make validation and regression risks explicit before code changes.
|
|
|
|
## Expected Format
|
|
|
|
A Studio plan should usually include:
|
|
|
|
1. Briefing
|
|
2. Objective
|
|
3. Dependencies
|
|
4. Scope
|
|
5. Non-Goals
|
|
6. Execution Method
|
|
7. Acceptance Criteria
|
|
8. Validation
|
|
9. Affected Artifacts
|
|
|
|
## Writing Rules
|
|
|
|
- Organize by execution sequence, not by brainstorming.
|
|
- Keep visual design, interaction behavior, and service integration clearly separated.
|
|
- State what the user should be able to do after the change lands.
|
|
- Tie the plan back to Studio specs and decisions explicitly.
|
|
|
|
## Current Queue
|
|
|
|
When a new Studio execution wave starts, add only the plans that still represent pending work.
|
|
Do not repopulate this directory with already-absorbed historical implementation slices.
|