2.7 KiB
2.7 KiB
Studio Pull Requests
This directory contains executable plans for Studio work.
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:
- Briefing
- Objective
- Dependencies
- Scope
- Non-Goals
- Execution Method
- Acceptance Criteria
- Validation
- 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
The current Studio execution queue is:
PR-05a-assets-workspace-foundation-and-service-state.mdPR-05b-asset-navigator-search-filters-and-selection.mdPR-05c-selected-asset-details-contract-and-preview.mdPR-05d-assets-activity-progress-and-logs-integration.mdPR-05e-assets-staged-mutations-preview-and-apply.mdPR-07a-assets-event-topology-and-lifecycle-foundation.mdPR-07b-asset-navigator-and-row-subscriptions.mdPR-07c-asset-details-and-form-lifecycle.mdPR-07d-asset-mutation-and-structural-sync-orchestration.mdPR-07e-assets-refactor-cleanup-and-regression-coverage.mdPR-06-project-scoped-studio-state-and-activity-persistence.md
The PR-07 family is a corrective refactor pass for the current Assets implementation.
It exists to replace the refresh-heavy direction with lifecycle-managed, event-driven ownership.
It also establishes the intended Studio-wide workspace framework, with Assets as the first consumer and proof point.
Recommended execution order:
PR-05a -> PR-05b -> PR-05c -> PR-05d -> PR-05e -> PR-07a -> PR-07b -> PR-07c -> PR-07d -> PR-07e -> PR-06