prometeu-studio/discussion/workflow/plans/PLN-0049-scene-workspace-spec-and-boundary-propagation.md

id	ticket	title	status	created	completed	tags
PLN-0049	studio-scene-workspace	Propagate DEC-0026 into Scene Workspace and Assets specs	abandoned	2026-04-14		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.