---
id: PLN-0049
ticket: studio-scene-workspace
title: Propagate DEC-0026 into Scene Workspace and Assets specs
status: abandoned
created: 2026-04-14
completed:
tags:
  - studio
  - specs
  - scene
  - workspace
  - assets
---

## Objective

Turn `DEC-0026` into normative Studio specifications so execution can proceed against stable written contracts for `Scene Workspace`, `Assets`, and shell integration.

## Background

`DEC-0026` locks the ownership boundary between `Scene Workspace` and `Assets`, the wave-1 tilemap scope, the explicit scene-to-asset binding rule, and the rule that `Assets` may create `SCENE` assets but must not author scenes.

The repository already has shell and assets workspace specifications but does not yet have a dedicated `Scene Workspace` specification.

## Scope

### Included
- Add a new `Scene Workspace` specification under `docs/specs/studio`.
- Propagate the ownership boundary into `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`.
- Propagate the `Assets` limitation and handoff rules into `docs/specs/studio/4. Assets Workspace Specification.md`.
- Record the wave-1 UI composition, save model, binding contract, and non-goals in normative English.

### Excluded
- Java implementation.
- Serialization format design beyond what `DEC-0026` already locks.
- Packer publication rules.

## Execution Steps

### Step 1 - Add the Scene Workspace specification

**What:**
Create a dedicated normative spec for `Scene Workspace`.

**How:**
Author a new Studio spec document that captures:
- workspace purpose and authority;
- scene-first navigation;
- explicit distinction between scene artifact and linked `SCENE` asset;
- wave-1 `Tilemap` layout;
- save rules;
- tileset selection rules;
- tool-scope inclusions and exclusions;
- explicit exclusions for camera/lights/AABB and advanced paint tools.

**File(s):**
- `docs/specs/studio/9. Scene Workspace Specification.md` or the next appropriate numbered spec file.

### Step 2 - Propagate shell-level workspace presence

**What:**
Update the shell spec so `Scene Workspace` is a baseline Studio workspace.

**How:**
Amend the shell workspace set and topology language to include `Scene Workspace` as a first-class shell workspace, while keeping workspace-local detail delegated to the new workspace spec.

**File(s):**
- `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`

### Step 3 - Propagate the Assets boundary

**What:**
Update the `Assets` workspace spec so it can create a `SCENE` asset without absorbing scene-authoring responsibility.

**How:**
Add explicit normative language that:
- `Assets` may create a `SCENE` asset;
- `Assets` must delegate subsequent scene authoring to `Scene Workspace`;
- `Assets` must not expose map-painting or scene-editor interactions;
- contextual handoff into `Scene Workspace` is supported.

**File(s):**
- `docs/specs/studio/4. Assets Workspace Specification.md`

### Step 4 - Align accepted project-local state implications

**What:**
Clarify whether `Scene Workspace` introduces accepted project-local restoration categories in this wave.

**How:**
Inspect the current `Project-Local Studio State` scope and either:
- explicitly keep scene restoration out of wave 1; or
- add only the minimum accepted shell layout/restoration state required by `DEC-0026`.

The update must not invent persistence categories that the decision does not support.

**File(s):**
- `docs/specs/studio/8. Project-Local Studio State Specification.md`

## Test Requirements

### Unit Tests

- None required for spec-only changes.

### Integration Tests

- None required for spec-only changes.

### Manual Verification

- Confirm each `DEC-0026` normative rule appears in at least one Studio spec.
- Confirm no spec text gives `Assets` ownership over scene editing.
- Confirm the new `Scene Workspace` spec remains limited to wave-1 `Tilemap`.

## Acceptance Criteria

- [ ] A dedicated `Scene Workspace` specification exists in `docs/specs/studio`.
- [ ] Shell specs name `Scene Workspace` as a first-class workspace.
- [ ] `Assets` specs explicitly allow `SCENE` asset creation but forbid scene editing.
- [ ] The spec set clearly distinguishes scene artifact save from asset-management flow.
- [ ] The written specs are sufficient for implementation planning without reopening `DEC-0026`.

## Dependencies

- `DEC-0026-studio-scene-workspace.md`

## Risks

- Misplacing binding or save semantics into the wrong spec would blur workspace ownership.
- Adding too much persistence detail at the spec stage could outrun the accepted decision.
- Reusing `Assets` wording too heavily could accidentally reintroduce asset-first ownership into the scene editor.

## Abandonment

Abandoned on 2026-04-15 because the parent decision `DEC-0026` was explicitly abandoned by the user.