diff --git a/docs/studio/README.md b/docs/studio/README.md
new file mode 100644
index 00000000..10ebf0a7
--- /dev/null
+++ b/docs/studio/README.md
@@ -0,0 +1,107 @@
+# Studio Documentation
+
+This directory contains the working, planning, normative, and didactic documentation for the `studio` domain.
+
+`studio` is a standalone domain focused on the UI shell, workspace model, interaction design, and service integration of `prometeu-studio`.
+
+It follows the same documentary cycle used elsewhere in the repository:
+
+`agendas -> decisions -> pull-requests -> specs -> learn`
+
+## Tree
+
+```text
+docs/studio/
+├── agendas/
+├── decisions/
+├── learn/
+├── pull-requests/
+├── specs/
+└── README.md
+```
+
+## Current Code Context
+
+The current `prometeu-studio` application already has a lightweight shell:
+
+- `MainView` composes the application frame;
+- `WorkspaceBar` switches between workspaces;
+- `EditorWorkspace` is the most concrete workspace today;
+- `Assets` is still a placeholder workspace;
+- `BuilderWorkspace` exists as an implementation artifact, but Studio UI planning should treat shipping and asset tooling as distinct concerns going forward.
+
+The first Studio documentation wave should therefore focus on turning the current shell into an intentional UI model instead of adding more placeholders.
+
+## Responsibilities
+
+### `agendas/`
+
+`agendas/` is the staging area for open Studio product and interaction questions.
+
+Use it to:
+
+- shape workspace and panel structure,
+- compare UI interaction models,
+- decide how Studio consumes services and events,
+- define what must be visible, staged, or confirmed in the UI.
+
+### `decisions/`
+
+`decisions/` records closed Studio product and UX decisions before they are fully propagated.
+
+Use it to:
+
+- close interaction and architecture choices,
+- define invariants for UI behavior,
+- capture what must be implemented in Studio code and service contracts.
+
+### `pull-requests/`
+
+`pull-requests/` contains execution plans for Studio changes.
+
+Use it to:
+
+- break a UI decision into implementation slices,
+- separate shell work, workspace work, and service integration work,
+- define acceptance criteria and validation paths.
+
+### `specs/`
+
+`specs/` contains the normative Studio contract.
+
+Use it to:
+
+- define shell structure,
+- document workspace responsibilities,
+- specify interaction flows,
+- stabilize event and service integration expectations.
+
+### `learn/`
+
+`learn/` contains didactic Studio material.
+
+Use it to:
+
+- explain the mental model of the Studio,
+- document why the UI is structured the way it is,
+- help future contributors navigate shell, workspaces, and integration boundaries.
+
+## Recommended Flow
+
+The preferred Studio documentation flow is:
+
+1. `agendas/`: open and shape the unresolved UI topic.
+2. `decisions/`: close the product or interaction choice.
+3. `pull-requests/`: plan propagation into code and specs.
+4. `specs/`: integrate the normative Studio contract.
+5. `learn/`: consolidate the final model in a didactic form.
+
+## Practical Rule
+
+- `agendas/` stores currently open Studio questions.
+- `decisions/` stores decisions that still need propagation.
+- `pull-requests/` stores execution plans.
+- `specs/` stores the normative Studio contract.
+- `learn/` stores teaching-oriented Studio knowledge.
+
+If implementation exposes a missing UI or interaction decision, stop and return to `agendas/` or `decisions/`.
diff --git a/docs/studio/agendas/01.0. Studio Shell, Workspace Navigation, and Layout Agenda.md b/docs/studio/agendas/01.0. Studio Shell, Workspace Navigation, and Layout Agenda.md
new file mode 100644
index 00000000..365c366d
--- /dev/null
+++ b/docs/studio/agendas/01.0. Studio Shell, Workspace Navigation, and Layout Agenda.md	
@@ -0,0 +1,76 @@
+# Studio Shell, Workspace Navigation, and Layout Agenda
+
+## Status
+
+Open
+
+## Purpose
+
+Define the baseline Studio shell:
+
+- main window layout,
+- workspace navigation model,
+- shell regions and panel hierarchy,
+- default landing behavior,
+- how future workspaces should fit into the frame.
+
+## Domain Owner
+
+`docs/studio`
+
+## Current Code Context
+
+Current `prometeu-studio` already provides:
+
+- `MainView` as the root shell;
+- `WorkspaceBar` as left-side workspace navigation;
+- `EditorWorkspace` as the most concrete workspace;
+- placeholder workspaces for `Assets` and `Device`;
+- a `BuilderWorkspace` implementation artifact with logs and toolbar.
+
+The shell exists, but it is still closer to a scaffold than a documented Studio UX contract.
+
+## Core Questions
+
+1. What is the long-lived shell structure of the Studio?
+2. Is left-side workspace switching the correct baseline navigation model?
+3. Which shell regions are global and which belong to each workspace?
+4. How should the Assets workspace coexist with Editor, Device, and future shipping flows?
+5. What should the default landing workspace be?
+
+## Options
+
+### Option A
+
+Keep the current shell mostly intact and grow workspaces within it.
+
+### Option B
+
+Evolve toward a multi-panel shell with global activity and contextual side panels.
+
+### Option C
+
+Adopt a dock-heavy IDE-style shell from the start.
+
+## Tradeoffs
+
+- Option A is fast and consistent with current code, but may constrain richer workflows later.
+- Option B preserves the current shell while creating room for Studio-grade interaction design.
+- Option C is powerful, but likely too heavy for the current code and service maturity.
+
+## Recommendation
+
+Prefer Option B.
+
+Recommended direction:
+
+- keep workspace switching in the shell,
+- formalize a stable frame with navigation, workspace body, and activity/progress region,
+- let each workspace own its internal panels,
+- avoid a fully dockable IDE model for the first Studio UI wave.
+
+## Expected Follow-up
+
+- a shell decision,
+- a Studio shell spec,
+- a PR/plan for `MainView`, `WorkspaceBar`, and workspace composition.
diff --git a/docs/studio/agendas/01.1. Asset Workspace Information Architecture Agenda.md b/docs/studio/agendas/01.1. Asset Workspace Information Architecture Agenda.md
new file mode 100644
index 00000000..3dbd8264
--- /dev/null
+++ b/docs/studio/agendas/01.1. Asset Workspace Information Architecture Agenda.md	
@@ -0,0 +1,74 @@
+# Asset Workspace Information Architecture Agenda
+
+## Status
+
+Open
+
+## Purpose
+
+Define the baseline information architecture of the Assets workspace.
+
+The goal is to decide which panels and data views the user needs in order to manage assets through Studio services rather than through ad hoc file inspection.
+
+## Domain Owner
+
+`docs/studio`
+
+## Current Code Context
+
+`WorkspaceId.ASSETS` is still backed by a placeholder workspace.
+
+Meanwhile, the packer domain already defines:
+
+- managed assets,
+- diagnostics,
+- preview/apply mutation flows,
+- an asset event lane,
+- structured service responses.
+
+The Assets workspace must therefore be designed as a Studio view over those services, not as a file browser clone.
+
+## Core Questions
+
+1. Which panels are baseline for the Assets workspace?
+2. What should the primary unit of navigation be: asset list, tree, or diagnostic inbox?
+3. Which information should always be visible for the selected asset?
+4. How should diagnostics, preload, and managed/orphan state surface in the workspace?
+5. What belongs in the workspace body versus a global Studio activity region?
+
+## Options
+
+### Option A
+
+List-first asset workspace with details panel and diagnostics section.
+
+### Option B
+
+File-tree-first asset workspace with asset details as a secondary mode.
+
+### Option C
+
+Dashboard-first asset workspace focused on diagnostics and actions.
+
+## Tradeoffs
+
+- Option A aligns best with the managed asset model already defined by the packer.
+- Option B is familiar, but risks collapsing the Studio into a glorified file explorer.
+- Option C is useful for operations, but weak as a day-to-day authoring workspace.
+
+## Recommendation
+
+Prefer Option A.
+
+Recommended baseline:
+
+- asset list or registry-aware browser on the left,
+- asset details in the main panel,
+- diagnostics and action surfaces attached to the selected asset,
+- broader activity/progress outside the asset details body when possible.
+
+## Expected Follow-up
+
+- an information architecture decision,
+- a workspace spec,
+- a PR/plan for the first concrete `AssetsWorkspace`.
diff --git a/docs/studio/agendas/01.2. Asset List, Filters, and Selection Model Agenda.md b/docs/studio/agendas/01.2. Asset List, Filters, and Selection Model Agenda.md
new file mode 100644
index 00000000..cb1b94a6
--- /dev/null
+++ b/docs/studio/agendas/01.2. Asset List, Filters, and Selection Model Agenda.md	
@@ -0,0 +1,50 @@
+# Asset List, Filters, and Selection Model Agenda
+
+## Status
+
+Open
+
+## Purpose
+
+Define how users navigate and select assets inside the Assets workspace.
+
+## Domain Owner
+
+`docs/studio`
+
+## Current Code Context
+
+The Studio shell already has workspace switching, but no concrete Assets workspace.
+
+The packer model already distinguishes:
+
+- managed assets,
+- orphan declarations,
+- diagnostics,
+- preload intent,
+- stable `asset_id` and logical `asset_name`.
+
+The list model should make those distinctions visible without forcing users into raw registry inspection.
+
+## Core Questions
+
+1. Should the main asset view be flat, grouped, or tree-based?
+2. Which filters are baseline?
+3. How should the current selection be preserved across refreshes and background events?
+4. How should empty, loading, and error states appear?
+5. How much of the filesystem path should be exposed in the primary list?
+
+## Recommendation
+
+Baseline direction:
+
+- registry-aware flat or grouped asset list,
+- lightweight filters for `managed`, `orphan`, `diagnostics`, and `preload`,
+- selection preserved by stable identity when possible,
+- path treated as supporting information, not primary identity.
+
+## Expected Follow-up
+
+- a decision on the asset list model,
+- a UI state spec for selection and filtering,
+- a plan for list rendering and refresh behavior.
diff --git a/docs/studio/agendas/01.3. Asset Details, Diagnostics, and Action Surface Agenda.md b/docs/studio/agendas/01.3. Asset Details, Diagnostics, and Action Surface Agenda.md
new file mode 100644
index 00000000..0ed6438d
--- /dev/null
+++ b/docs/studio/agendas/01.3. Asset Details, Diagnostics, and Action Surface Agenda.md	
@@ -0,0 +1,47 @@
+# Asset Details, Diagnostics, and Action Surface Agenda
+
+## Status
+
+Open
+
+## Purpose
+
+Define what the selected asset view shows and which actions are directly available there.
+
+## Domain Owner
+
+`docs/studio`
+
+## Current Code Context
+
+The packer service model already expects:
+
+- structured diagnostics,
+- preview/apply mutation flows,
+- operations such as `register_asset`, `adopt_asset`, `forget_asset`, `remove_asset`, `doctor`, and `build`.
+
+The selected asset view should therefore be designed around explicit state and explicit actions.
+
+## Core Questions
+
+1. What summary information is always visible for the selected asset?
+2. Which diagnostics belong inline versus in a separate panel?
+3. Which actions should be primary, secondary, or hidden behind confirmation?
+4. How should managed and orphan assets differ visually?
+5. How should runtime-facing information such as preload and output format appear?
+
+## Recommendation
+
+Baseline direction:
+
+- a summary card for identity and state,
+- explicit diagnostics panel,
+- explicit action group,
+- clear differentiation between safe actions and sensitive mutations,
+- no hidden automatic repair behavior.
+
+## Expected Follow-up
+
+- a decision on asset details composition,
+- a spec for diagnostics and actions in the workspace,
+- a plan for Studio service integration in the asset details view.
diff --git a/docs/studio/agendas/01.4. Background Events, Progress, and Activity Feed Agenda.md b/docs/studio/agendas/01.4. Background Events, Progress, and Activity Feed Agenda.md
new file mode 100644
index 00000000..291c21d0
--- /dev/null
+++ b/docs/studio/agendas/01.4. Background Events, Progress, and Activity Feed Agenda.md	
@@ -0,0 +1,55 @@
+# Background Events, Progress, and Activity Feed Agenda
+
+## Status
+
+Open
+
+## Purpose
+
+Define how Studio surfaces background asset activity, progress, and logs coming from the packer event lane.
+
+## Domain Owner
+
+`docs/studio`
+
+## Current Code Context
+
+The packer already defines a Studio-facing asset event lane with events such as:
+
+- `asset_discovered`
+- `asset_changed`
+- `diagnostics_updated`
+- `build_started`
+- `build_finished`
+- `cache_hit`
+- `cache_miss`
+- `preview_ready`
+- `action_applied`
+- `action_failed`
+- `progress_updated`
+
+Current `BuilderWorkspace` already contains a logs area, which is a useful signal but not yet a coherent Studio-wide activity model.
+
+## Core Questions
+
+1. Should activity be global to the Studio shell or local to the Assets workspace?
+2. How should progress, logs, and state changes be distinguished?
+3. What should persist in history versus only appear transiently?
+4. How noisy should automatic background reporting be?
+5. How should action failures and blockers surface?
+
+## Recommendation
+
+Baseline direction:
+
+- global activity region in the Studio shell,
+- structured event rendering rather than raw log dumping,
+- progress visible both inline and in the activity surface,
+- recent actionable failures retained until acknowledged,
+- normal background noise summarized rather than streamed endlessly.
+
+## Expected Follow-up
+
+- a decision on activity feed and progress UX,
+- a shell or integration spec,
+- a plan for event rendering and background updates.
diff --git a/docs/studio/agendas/01.5. Preview, Confirm, and Apply Mutation Flows Agenda.md b/docs/studio/agendas/01.5. Preview, Confirm, and Apply Mutation Flows Agenda.md
new file mode 100644
index 00000000..9a4d215f
--- /dev/null
+++ b/docs/studio/agendas/01.5. Preview, Confirm, and Apply Mutation Flows Agenda.md	
@@ -0,0 +1,47 @@
+# 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.
diff --git a/docs/studio/agendas/README.md b/docs/studio/agendas/README.md
new file mode 100644
index 00000000..bae0c220
--- /dev/null
+++ b/docs/studio/agendas/README.md
@@ -0,0 +1,61 @@
+# Studio Agendas
+
+This directory contains active Studio discussion agendas.
+
+## Active Agendas
+
+The initial Studio UI planning wave is:
+
+1. [`01.0. Studio Shell, Workspace Navigation, and Layout Agenda.md`](./01.0.%20Studio%20Shell,%20Workspace%20Navigation,%20and%20Layout%20Agenda.md)
+2. [`01.1. Asset Workspace Information Architecture Agenda.md`](./01.1.%20Asset%20Workspace%20Information%20Architecture%20Agenda.md)
+3. [`01.2. Asset List, Filters, and Selection Model Agenda.md`](./01.2.%20Asset%20List,%20Filters,%20and%20Selection%20Model%20Agenda.md)
+4. [`01.3. Asset Details, Diagnostics, and Action Surface Agenda.md`](./01.3.%20Asset%20Details,%20Diagnostics,%20and%20Action%20Surface%20Agenda.md)
+5. [`01.4. Background Events, Progress, and Activity Feed Agenda.md`](./01.4.%20Background%20Events,%20Progress,%20and%20Activity%20Feed%20Agenda.md)
+6. [`01.5. Preview, Confirm, and Apply Mutation Flows Agenda.md`](./01.5.%20Preview,%20Confirm,%20and%20Apply%20Mutation%20Flows%20Agenda.md)
+
+Recommended discussion order:
+
+`01.0 -> 01.1 -> 01.2 -> 01.3 -> 01.4 -> 01.5`
+
+That order closes the Studio shell first, then the asset workspace structure, then interaction details and mutation flows.
+
+## Purpose
+
+An agenda exists to drive a decision.
+
+Use an agenda when:
+
+- the Studio UI topic is still open,
+- multiple interaction models are possible,
+- the team still needs tradeoffs and a recommendation,
+- implementation would otherwise guess shell or UX behavior.
+
+## Expected Format
+
+A Studio agenda should usually include:
+
+1. Title
+2. Status
+3. Purpose
+4. Domain Owner
+5. Current Code Context
+6. Options
+7. Tradeoffs
+8. Recommendation
+9. Open Questions
+10. Expected Follow-up
+
+## Writing Rules
+
+- Keep the document centered on unresolved Studio behavior.
+- Anchor the discussion in the actual `prometeu-studio` shell and workspaces.
+- Distinguish clearly between shell decisions, workspace decisions, and service-integration decisions.
+- Prefer concrete interaction tradeoffs over generic design commentary.
+
+## Exit Rule
+
+An agenda should leave the active set when:
+
+- the main UX tradeoffs are understood,
+- a recommendation is ready to adopt,
+- and the topic is ready to become a decision record.
diff --git a/docs/studio/decisions/README.md b/docs/studio/decisions/README.md
new file mode 100644
index 00000000..ef21c963
--- /dev/null
+++ b/docs/studio/decisions/README.md
@@ -0,0 +1,42 @@
+# Studio Decisions
+
+This directory contains Studio decision records.
+
+There are currently no retained Studio decision records.
+
+## 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.
diff --git a/docs/studio/learn/README.md b/docs/studio/learn/README.md
new file mode 100644
index 00000000..6d142c1b
--- /dev/null
+++ b/docs/studio/learn/README.md
@@ -0,0 +1,43 @@
+# Studio Learn
+
+This directory contains didactic Studio knowledge.
+
+## Purpose
+
+`learn/` exists to teach the Studio model, not merely to store old discussion output.
+
+Use it to:
+
+- explain why the Studio shell is structured the way it is,
+- connect UI decisions to practical implementation,
+- document common integration pitfalls,
+- help future contributors navigate the workspaces and background event model.
+
+## What Belongs Here
+
+A Studio `learn` artifact should usually include:
+
+1. the original UX or architecture problem,
+2. the decision that resolved it,
+3. the implemented or specified final model,
+4. practical examples or flows,
+5. common mistakes and warnings,
+6. links to relevant specs and plans.
+
+## Writing Rules
+
+- Prefer didactic structure over historical accumulation.
+- Explain why the Studio model exists, not only what it is.
+- Keep terminology aligned with Studio specs.
+- Refactor older material when the directory stops feeling like a clear learning path.
+
+## Refactor Rule
+
+This directory should be periodically reorganized for better presentation.
+
+If content grows, prefer:
+
+- thematic grouping,
+- overview documents,
+- explicit learning paths,
+- consolidation of duplicated explanations.
diff --git a/docs/studio/pull-requests/README.md b/docs/studio/pull-requests/README.md
new file mode 100644
index 00000000..cf898b65
--- /dev/null
+++ b/docs/studio/pull-requests/README.md
@@ -0,0 +1,35 @@
+# 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:
+
+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.
diff --git a/docs/studio/specs/README.md b/docs/studio/specs/README.md
new file mode 100644
index 00000000..be441007
--- /dev/null
+++ b/docs/studio/specs/README.md
@@ -0,0 +1,47 @@
+# Studio Specs
+
+This directory contains the normative Studio specification set.
+
+## Purpose
+
+Specs define the official Studio contract.
+
+They exist to stabilize:
+
+- the application shell,
+- workspace responsibilities,
+- interaction flows,
+- service and event integration expectations,
+- UX behavior that implementation should preserve.
+
+## Expected Format
+
+The exact structure may vary by document, but a Studio spec should usually contain:
+
+1. Title
+2. Status
+3. Scope or Applies To
+4. Purpose
+5. Authority and Precedence
+6. Normative Inputs
+7. Core Rules
+8. Non-Goals
+9. Exit Criteria
+
+## Writing Rules
+
+- Write in normative language.
+- Integrate only decisions that have already been closed.
+- Keep design exploration and option analysis out of the spec body.
+- Preserve clear boundaries between shell, workspace, and integration specs.
+
+## Upstream Rule
+
+Specs should normally be fed by:
+
+1. agendas that frame the open Studio topic,
+2. decisions that close the product or interaction choice,
+3. pull-request plans that define propagation,
+4. then spec integration.
+
+If a spec edit would require guessing unresolved UI behavior, stop and surface the missing decision first.