138 lines
4.7 KiB
Markdown
138 lines
4.7 KiB
Markdown
---
|
|
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.
|