48 lines
1.3 KiB
Markdown
48 lines
1.3 KiB
Markdown
# Preview, Confirm, and Apply Mutation Flows Agenda
|
|
|
|
## Status
|
|
|
|
Open
|
|
|
|
## Purpose
|
|
|
|
Define how Studio stages sensitive asset mutations before applying them.
|
|
|
|
## Domain Owner
|
|
|
|
`docs/studio`
|
|
|
|
## Current Code Context
|
|
|
|
The packer model already requires:
|
|
|
|
- preview/apply for sensitive mutations,
|
|
- explicit consent for destructive or relocational changes,
|
|
- structured responses with blockers, proposed actions, and applied actions.
|
|
|
|
The Studio must turn that into clear interaction flows instead of accidental one-click mutations.
|
|
|
|
## Core Questions
|
|
|
|
1. Which actions require preview by default?
|
|
2. What should a preview surface show before confirmation?
|
|
3. How should blockers, warnings, and safe fixes be separated?
|
|
4. When does the user see a modal confirmation versus an inline staged action panel?
|
|
5. How should batch operations differ from single-asset mutations?
|
|
|
|
## Recommendation
|
|
|
|
Baseline direction:
|
|
|
|
- use preview-first flows for sensitive mutations,
|
|
- show proposed actions and blockers explicitly,
|
|
- keep safe fixes distinct from destructive actions,
|
|
- favor inline staged review where possible,
|
|
- reserve modal confirmation for high-risk commits such as delete or relocation.
|
|
|
|
## Expected Follow-up
|
|
|
|
- a mutation-flow decision,
|
|
- a Studio interaction spec,
|
|
- a plan for preview/apply service integration.
|