# Studio Shell and Workspace Layout Specification

Status: Draft
Scope: Studio shell, project entry, and workspace frame
Purpose: Define the normative shell structure of the Studio UI.

## Authority and Precedence

This specification consolidates the accepted Studio shell decision into normative form.

## Normative Inputs

- the Studio application shell
- project entry or launcher flow
- shell-level workspace navigation
- shell-level utility and run surfaces

## Core Rules

1. The Studio must open through a project launcher or home surface before entering the main workspace shell.
2. The main shell must expose a top global menu region.
3. The main shell must expose a left fixed workspace selector.
4. The main shell must expose a center workspace host.
5. The main shell must expose a right global utility panel.
6. The main shell must expose an always-visible run surface in the top-right area.

## Project Entry

The Studio must not land directly into a workspace as its primary entry behavior.

Baseline project entry behavior is:

- show a lightweight launcher or home surface first;
- show existing or recent projects;
- expose `Open Project` and `Create Project` as first-class actions;
- enter the main workspace shell only after a concrete project is selected or created.

## Workspace Model

The left workspace selector remains fixed in the baseline Studio shell.

The baseline workspace set includes:

- Code Editor;
- Asset Management;
- Debugger/Profiler;
- Shipper, temporarily represented by the current `BuilderWorkspace`.

`BuilderWorkspace` is transitional and must not be treated as a long-term architectural reference for the final shipping surface.

## Right Utility Panel

The right-side global utility surface is tab-based.

Baseline rules:

- the initial tab set contains only `Activity`;
- the panel must be extendable with additional tabs later;
- `Run` is not a tab.

The right utility panel exists for shell-level visibility and utility, not for general per-workspace log dumping.

## Logs and Operational Detail

Detailed execution output belongs to the active workspace that owns the operation.

Rules:

- the shell must not define a single mandatory global console as the baseline logging model;
- each workspace may expose its own logs, console, or detailed operational output;
- shell-level utility surfaces may summarize shared activity, but they do not replace workspace-owned detail.

## UI Remodeling Scope

The Studio UI may be remodeled substantially during this wave.

That flexibility is constrained by:

- theme support must remain preserved;
- i18n support must remain preserved;
- the resulting shell must keep a clear path for reusable Studio controls.

## Deferred Docking

A fully docked IDE shell is not baseline behavior.

Rules:

- docking is explicitly deferred;
- shell topology and workspace responsibilities must be proven first;
- future dockability may be revisited only after the baseline shell is stable in actual use.

## Non-Goals

- defining the full internal layout of every workspace
- defining the final future tab set of the right utility panel
- defining the detailed activity rendering model

## Exit Criteria

This specification is complete enough when:

- project entry and shell regions are unambiguous;
- workspace and shell responsibilities are clearly separated;
- the baseline Studio frame is stable enough for implementation planning.