# Studio Decisions

This directory contains Studio decision records.

Current decision records:

- [`Bank Composition Details DTO Projection Decision.md`](./Bank%20Composition%20Details%20DTO%20Projection%20Decision.md)
- [`Bank Composition Base Components Decision.md`](./Bank%20Composition%20Base%20Components%20Decision.md)
- [`Bank Composition Section Shell Decision.md`](./Bank%20Composition%20Section%20Shell%20Decision.md)
- [`Bank Composition Middleware and Staged Editing Decision.md`](./Bank%20Composition%20Middleware%20and%20Staged%20Editing%20Decision.md)
- [`Bank Composition WorkspaceBus Interaction Decision.md`](./Bank%20Composition%20WorkspaceBus%20Interaction%20Decision.md)
- [`Bank Composition Persistence and Snapshot Propagation Decision.md`](./Bank%20Composition%20Persistence%20and%20Snapshot%20Propagation%20Decision.md)

The first Studio decision wave and the first asset workspace wave were already 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.