diff --git a/discussion/workflow/agendas/AGD-0029-studio-scene-workspace.md b/discussion/workflow/agendas/AGD-0029-studio-scene-workspace.md
deleted file mode 100644
index 7f87e63e..00000000
--- a/discussion/workflow/agendas/AGD-0029-studio-scene-workspace.md
+++ /dev/null
@@ -1,295 +0,0 @@
----
-id: AGD-0029
-ticket: studio-scene-workspace
-title: Scene Workspace for SCENE Authoring
-status: abandoned
-created: 2026-04-14
-resolved: 2026-04-14
-decision: DEC-0026
-tags:
-  - studio
-  - workspace
-  - scene
-  - tilemap
-  - asset
-  - runtime-alignment
----
-
-## Pain
-
-O Studio ainda nao possui um workspace dedicado para autoria e inspecao de scenes.
-
-Sem esse workspace:
-
-- o Studio nao oferece uma experiencia autoral propria para scenes como dominio editorial;
-- a equipe fica sem uma superficie visual para editar o artefato intermediario de scene que depois alimenta o asset `SCENE`;
-- o Studio perde a chance de ensinar o modelo correto de scene como asset versionado, com quatro layers e contrato proprio;
-- a futura expansao para camera bounds, lights, AABB e outros aspectos acaba sem composicao clara desde a primeira wave.
-
-## Context
-
-Domain owner: `studio`
-
-Owner documental esperado:
-
-- `docs/specs/studio`
-
-Cross-domain impact:
-
-- `../runtime` para o contrato canonico de `SCENE`, `SceneBank` e `SceneLayer`;
-- `Assets` workspace apenas na fronteira de criacao/descoberta do asset `SCENE`.
-
-Rastro relevante ja existente:
-
-- o runtime ja convergiu para `SCENE` como payload binario versionado;
-- `SceneBank` e o modelo canonico carregado no runtime possuem exatamente `4` layers;
-- cada `SceneLayer` possui seu proprio `TileMap`, com dimensoes independentes;
-- viewport cache, camera movement e renderer nao fazem parte do modelo canonico de authoring do scene;
-- o `Assets` workspace ja define o padrao de navegador customizado, asset-first e path-aware, que deve inspirar a navegacao do `Scene Workspace` sem virar um file explorer generico.
-
-Escopo inicial solicitado pelo usuario:
-
-- novo workspace chamado `Scene Workspace`;
-- navegador de scenes na lateral esquerda, similar ao `Assets` workspace;
-- o `Scene Workspace` trabalha com scenes como scenes, nao como assets;
-- a scene editada no workspace vira um artefato intermediario de autoria;
-- o `Scene Workspace` pode criar uma scene nova e, ao fazer isso, criar tambem o asset `SCENE` correspondente;
-- o `Assets` workspace pode criar um asset `SCENE`, mas nao pinta mapa nem faz configuracoes editoriais da scene;
-- depois de criado, o trabalho de conteudo e configuracao da scene fica delegado ao `Scene Workspace`;
-- cada scene como mapa de `4` layers;
-- cada layer com largura e altura independentes, em estilo similar ao `Tiled`;
-- faixa superior com abas de aspectos da ferramenta;
-- primeira aba: `Tilemap`;
-- aba `Tilemap` com mapa no centro;
-- painel superior direito com dimensoes e detalhes do tilemap;
-- painel inferior direito com aquarela/paleta de tiles para selecao e pintura;
-- tileset vindo de assets, com suporte a selecionar qualquer glyph bank ou marcar glyph banks como tileset apenas no Studio;
-- outras abas futuras previstas: camera boundaries, lights, AABB, etc., mas fora da primeira wave.
-
-## Open Questions
-
-- [x] O `Scene Workspace` deve abrir scenes apenas por seu catalogo proprio, ou tambem aceitar handoff contextual quando um asset `SCENE` for criado no `Assets`?
-- [x] Qual identidade o navegador da esquerda deve priorizar: scene authoring artifact, path do projeto, ou algum catalogo editorial proprio do `Scene Workspace`?
-- [x] O Studio deve tratar a edicao de scene como staged editing com `apply/reset`, ou como documento editavel com save integrado?
-- [x] Como o Studio relaciona uma scene autoral com o asset `SCENE` correspondente: referencia por path, UUID proprio do artefato intermediario, ou binding mediado por metadata do Studio?
-- [x] Como o Studio seleciona o glyph bank usado como tileset em cada layer ou scene: referencia editorial na scene ou vinculacao resolvida pelo proprio `Scene Workspace`?
-- [x] O contrato do runtime ja determina metadados suficientes por layer para authoring inicial, ou o Studio precisara propor extensoes antes da implementacao do workspace?
-- [x] Como representar tiles vazios, brush, fill e selecao sem colidir com a semantica canonica de tile vazio ja aceita no runtime?
-- [x] A primeira wave deve permitir apenas pintura bruta por tile, ou ja precisa incluir ferramentais como marquee, bucket, eyedropper e multi-layer visibility/lock?
-- [x] As abas futuras devem ser somente placeholders estruturais agora, ou a wave inicial deve expor apenas a aba `Tilemap` para nao sugerir suporte inexistente?
-
-## Options
-
-### Option A - `Scene Workspace` como workspace dedicado no shell
-- **Approach:** Criar um workspace proprio de `Scene Workspace`, com navegador de scenes na esquerda, header com tabs de aspecto e composicao interna especializada por aba.
-- **Pro:** Da visibilidade de primeira classe a `SCENE`, cria uma arquitetura clara para expansao futura por aspectos e preserva a fronteira entre shell e detalhe operacional do workspace.
-- **Con:** Introduz mais uma entrada no shell e exige decidir como ele se relaciona com a descoberta de assets no fluxo ja existente.
-- **Maintainability:** Strong, porque estabiliza ownership e composicao desde a primeira wave.
-
-### Option B - editor especializado dentro do `Assets` workspace
-- **Approach:** Manter tanto o asset `SCENE` quanto a edicao do artefato intermediario dentro do `Assets`, usando a selecao do asset como ponto de entrada do editor.
-- **Pro:** Reaproveita navegacao asset-first existente e concentra toda a historia de scene em um unico lugar.
-- **Con:** Colapsa duas naturezas diferentes em uma mesma superficie: gerenciamento de asset packer-facing e authoring de scene como conteudo editorial.
-- **Maintainability:** Weak, porque incentiva o `Assets` workspace a absorver ownership que nao e dele.
-
-### Option C - workspace autoral proprio com integracao via asset
-- **Approach:** O `Scene Workspace` edita e cria a scene como dominio proprio; o `Assets` workspace apenas pode criar/mostrar o asset `SCENE` e delega a autoria da scene para o `Scene Workspace`.
-- **Pro:** Separa claramente authoring editorial de scene da gestao asset-first do `Assets`, sem deixar o `Assets` absorver o editor.
-- **Con:** Exige fechar um contrato de binding entre scene autoral e asset `SCENE`, alem de definir handoff entre os dois workspaces.
-- **Maintainability:** Strong, porque o `Scene Workspace` permanece owner do conteudo e o `Assets` fica restrito a criacao/gestao do asset.
-
-## Discussion
-
-O ponto mais importante desta discussao nao e apenas layout. O runtime ja tem um contrato canonico claro o bastante para impor restricoes no editor:
-
-1. o payload final `SCENE` nao e um documento arbitrario; e um asset binario versionado com `4` layers fixos;
-2. cada layer possui `TileMap` proprio e, portanto, o editor nao deve assumir um canvas unificado com dimensoes compartilhadas;
-3. viewport cache, camera drift e outras preocupacoes de renderizacao nao pertencem ao modelo canonico do scene workspace;
-4. o `Scene Workspace` nao deve editar o payload final do asset diretamente; ele deve editar um material intermediario proprio;
-5. o tileset precisa se alinhar aos glyph banks que ja existem como assets, sem criar um segundo sistema de tiles paralelo no Studio.
-
-Tambem existe uma decisao estrutural de produto a ser tomada cedo:
-
-- se o `Scene Workspace` for somente um modo interno do `Assets`, o Studio arrisca repetir o anti-pattern de transformar um workspace asset-first em container generico de editores;
-- se ele nascer como workspace proprio, a arquitetura de abas por aspecto e a expansao futura para boundaries/lights/AABB ficam mais honestas;
-- como a scene autoral nao e o proprio asset, a costura correta passa por um contrato entre artefato intermediario e asset `SCENE`, nao por subordinacao de um workspace ao outro;
-- o `Assets` pode oferecer criacao de asset `SCENE`, mas a autoria e manutencao do conteudo da scene devem ser delegadas ao `Scene Workspace`.
-
-Outro ponto aberto e a semantica do tileset:
-
-- permitir qualquer glyph bank maximiza flexibilidade e reaproveitamento;
-- exigir uma tag editorial de "tileset" melhora discoverability e reduz selecao invalida;
-- uma combinacao pode ser a melhor direcao: qualquer glyph bank tecnicamente valido, com tagging opcional no Studio para curadoria UX.
-
-Por fim, a primeira wave precisa resistir a overreach:
-
-- a aba `Tilemap` ja e um escopo suficientemente grande;
-- placeholders de abas futuras so fazem sentido se a shell structure realmente precisar reservar esse contrato agora;
-- caso contrario, placeholders podem comunicar suporte inexistente e gerar pressao artificial sobre uma decision ainda nao tomada.
-
-### Convergence pass - recommended answers for the open questions
-
-#### 1. Workspace proprio ou extensao do `Assets`
-
-Recomendacao: `Scene Workspace` deve existir como workspace shell-level proprio e nao deve ser subordinado ao `Assets`.
-
-Motivo:
-
-- o shell ja foi especificado para hospedar workspaces independentes;
-- o `Assets` workspace deve continuar asset-first e didatico, nao virar um host generico de editores;
-- a scene autoral tem natureza propria e vira um artefato intermediario, nao o payload final do asset.
-- o `Scene Workspace` deve aceitar tanto abertura por seu proprio navegador quanto handoff contextual quando o `Assets` criar um asset `SCENE`.
-
-#### 2. Identidade do navegador da esquerda
-
-Recomendacao: a identidade primaria deve ser a scene autoral, nao o asset `SCENE`.
-
-Contexto de apoio:
-
-- path continua visivel como contexto secundario;
-- o workspace pode precisar de um identificador editorial proprio para a scene intermediaria;
-- o asset `SCENE` correspondente pertence ao `Assets` workspace e deve aparecer apenas como vinculacao ou estado derivado.
-
-Direcao adicional:
-
-- o navegador deve ser scene-first;
-- path de projeto entra como contexto secundario;
-- o asset vinculado pode aparecer como badge, status ou acao contextual, mas nao como unidade primaria de navegacao.
-
-#### 3. Modelo de edicao e persistencia
-
-Recomendacao: a primeira wave deve tratar a scene como documento/artefato autoral com save proprio, separado de qualquer fluxo de criacao ou gestao do asset no `Assets`.
-
-Motivo:
-
-- o usuario deixou explicito que o `Scene Manager` trabalha sobre um artefato intermediario proprio;
-- o `Scene Workspace` e owner do conteudo da scene;
-- o `Assets` pode continuar com fluxos proprios para criacao/gestao de asset, mas sem absorver a autoria da scene;
-- misturar save do conteudo autoral com `apply` do asset apagaria a fronteira entre autoria e empacotamento.
-
-Direcao adicional:
-
-- o `Scene Workspace` salva o artefato intermediario;
-- criar ou vincular o asset `SCENE` e um passo de integracao entre workspaces, nao a mesma operacao de salvar a scene.
-
-#### 4. Binding entre scene autoral e asset `SCENE`
-
-Recomendacao: o binding deve ser mediado por metadata do Studio, nao por inferencia de path como regra primaria.
-
-Motivo:
-
-- path pode mudar por rename ou reorganizacao de projeto;
-- a scene autoral precisa de identidade mais estavel do que localizacao fisica;
-- o `Assets` e o `Scene Workspace` precisam compartilhar um vinculo explicito sem colapsar um no outro.
-
-Direcao adicional:
-
-- a scene autoral deve ter um identificador proprio;
-- o asset `SCENE` correspondente deve referenciar esse identificador, ou vice-versa, por um contrato editorial do Studio;
-- path continua relevante como localizacao de arquivo, nao como ancora semantica principal do binding.
-
-#### 5. Selecao de glyph bank como tileset
-
-Recomendacao: a scene autoral deve poder referenciar glyph banks como tilesets em nivel editorial, e essa escolha deve ser owned pelo `Scene Workspace`.
-
-Motivo:
-
-- o runtime ja referencia `glyph_bank_id` por layer, nao um tipo separado de tileset;
-- criar um subtipo obrigatorio de asset agora inventaria uma regra de produto nao exigida pelo contrato canonico;
-- uma tag editorial ainda pode melhorar descoberta sem restringir um contrato que hoje e genericamente `GLYPH`.
-
-Direcao adicional:
-
-- a escolha de glyph bank por layer ou por scene deve ser resolvida no `Scene Workspace`;
-- o `Assets` nao deve redefinir tileset da scene;
-- tags editoriais opcionais no Studio podem melhorar filtragem e discoverability.
-
-#### 6. Metadados por layer
-
-Recomendacao: para a primeira wave, o contrato do runtime parece suficiente para authoring inicial de tilemap.
-
-Rastro observado no runtime:
-
-- `SceneLayer` ja possui `active`;
-- `glyph_bank_id`;
-- `tile_size`;
-- `motion_factor`;
-- `tilemap` com `width`, `height` e tiles.
-
-Conclusao:
-
-- isso e suficiente para uma aba `Tilemap` com visibilidade por layer, dimensoes independentes, tileset por layer e pintura;
-- camera bounds, lights e AABB ficam corretamente fora dessa wave e devem motivar metadados adicionais apenas quando virarem tema de nova decision.
-
-#### 7. Tile vazio, brush e pintura
-
-Recomendacao: o Studio deve respeitar a semantica canonica de presenca explicita por tile.
-
-Consequencias:
-
-- `glyph_id = 0` deve permanecer valido;
-- apagar um tile deve atuar sobre o bit/estado de presenca (`active = false`), nao sobre um glyph magico;
-- brush, eyedropper e futuras ferramentas devem operar sobre `active`, `glyph_id`, `palette_id`, `flip_x` e `flip_y`.
-
-#### 8. Ferramentas da primeira wave
-
-Recomendacao: limitar a primeira wave a pintura basica, apagador, seletor de tile e controles de layer como visibilidade/foco.
-
-Excluir agora:
-
-- marquee complexo;
-- bucket fill;
-- multi-select estrutural;
-- automacoes de brush avancadas.
-
-Motivo:
-
-- o objetivo da wave 1 e provar o fluxo canonico de scene authoring;
-- ferramentas mais ricas multiplicam edge cases antes de estabilizar modelo, persistencia e UX base.
-
-Direcao adicional:
-
-- `multi-layer visibility` e `layer focus` entram na wave 1;
-- `lock`, `marquee`, `bucket`, `flood fill` e automacoes avancadas ficam explicitamente fora.
-
-#### 9. Abas futuras agora ou depois
-
-Recomendacao: o workspace deve nascer com uma faixa superior de tabs, mas expor apenas a aba `Tilemap` na primeira wave.
-
-Motivo:
-
-- a estrutura de tabs faz parte da composicao arquitetural pedida;
-- tabs placeholder para `Camera`, `Lights` ou `AABB` sugeririam suporte que ainda nao existe;
-- reservar o componente estrutural agora facilita expansao futura sem mentir sobre cobertura funcional.
-
-## Resolution
-
-Abandoned on 2026-04-15 by explicit user request.
-
-The accepted direction captured here was superseded before implementation.
-
-Follow-up direction:
-
-- abandon the dedicated `Scene Workspace` approach;
-- open a new discussion for a `Tiled` parser;
-- manage the resulting authoring flow from `Assets` through a new asset type.
-
-Direcao recomendada: convergir para **Option C**, em que o `Scene Workspace` e um workspace autoral de primeira classe no shell e o `Assets` workspace permanece apenas como superficie asset-first capaz de criar ou exibir o asset `SCENE`, sem editar o conteudo da scene.
-
-Essa recomendacao parte de quatro principios:
-
-1. a scene autoral e um artefato intermediario proprio do dominio `Scene Workspace`;
-2. o asset `SCENE` pode ser criado tanto pelo `Scene Workspace` quanto pelo `Assets`, mas o conteudo da scene e owner do `Scene Workspace`;
-3. o `Assets` nao pinta mapa nem faz configuracoes editoriais da scene;
-4. o binding entre scene autoral e asset `SCENE` deve ser explicito e estavel;
-5. a primeira wave deve fechar apenas o aspecto `Tilemap`, sem fingir maturidade para camera bounds, lights ou AABB.
-
-Proximo passo sugerido: transformar esta agenda em uma decision que feche:
-
-1. `Scene Workspace` como workspace shell-level proprio e owner do artefato intermediario de scene;
-2. identidade primaria do workspace pela scene autoral, nao pelo asset;
-3. save proprio da scene autoral no `Scene Workspace`, separado da criacao/gestao do asset no `Assets`;
-4. contrato de binding entre scene intermediaria e asset `SCENE`;
-5. glyph banks como tilesets validos por contrato, com eventual curadoria editorial no Studio;
-6. aba unica `Tilemap` na primeira wave, preservando a shell de tabs para expansao futura;
-7. propagacao necessaria para specs do `studio`, incluindo a pequena extensao do `Assets` para criacao de scene asset e o ownership do `Scene Workspace` sobre a autoria da scene.
diff --git a/discussion/workflow/decisions/DEC-0026-studio-scene-workspace.md b/discussion/workflow/decisions/DEC-0026-studio-scene-workspace.md
deleted file mode 100644
index 5628520d..00000000
--- a/discussion/workflow/decisions/DEC-0026-studio-scene-workspace.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-id: DEC-0026
-ticket: studio-scene-workspace
-title: Scene Workspace Ownership and Wave-1 Tilemap Scope
-status: abandoned
-created: 2026-04-14
-accepted: 2026-04-14
-agenda: AGD-0029
-plans:
-  - PLN-0049
-  - PLN-0050
-  - PLN-0051
-  - PLN-0052
-tags:
-  - studio
-  - workspace
-  - scene
-  - tilemap
-  - asset
-  - runtime-alignment
----
-
-## Decision
-
-The Studio SHALL introduce a dedicated `Scene Workspace` as a first-class shell workspace for scene authoring.
-
-The `Scene Workspace` MUST own the authoring lifecycle of scenes as scenes, not as asset-detail forms.
-
-The Studio SHALL treat the edited scene as an intermediate authoring artifact owned by the `Scene Workspace`.
-
-The `Scene Workspace` MAY create a new scene and, as part of that flow, create the corresponding `SCENE` asset.
-
-The `Assets` workspace MAY also create a `SCENE` asset, but it MUST NOT paint tilemaps, edit scene content, choose scene tilesets, or own other editorial scene configuration.
-
-When a `SCENE` asset is created from `Assets`, authoring and subsequent editing MUST be delegated to the `Scene Workspace`.
-
-The first implementation wave of the `Scene Workspace` SHALL expose only the `Tilemap` aspect.
-
-The wave-1 `Tilemap` aspect MUST support:
-
-- a left scene navigator;
-- a central map editing surface;
-- a right-side tilemap details area with dimensions and layer-relevant detail;
-- a tile palette area for tile selection and painting;
-- four canonical scene layers;
-- independent layer dimensions;
-- scene-first navigation;
-- explicit tile presence semantics aligned with the runtime model;
-- basic painting, erasing, tile selection, layer visibility, and layer focus.
-
-The wave-1 `Scene Workspace` MUST NOT include:
-
-- authoring for camera boundaries;
-- authoring for lights;
-- authoring for AABB data;
-- placeholder tabs that imply those capabilities already exist;
-- advanced paint tools such as marquee, bucket fill, flood fill, or equivalent higher-order tooling.
-
-The `Scene Workspace` MUST use an explicit and stable binding between the intermediate scene artifact and the corresponding `SCENE` asset.
-
-That binding MUST NOT rely on path inference as its primary semantic anchor.
-
-The `Scene Workspace` MUST own editorial tileset selection for the scene.
-
-Any technically valid glyph bank MAY be referenced as a tileset under the scene-authoring model.
-
-Optional Studio-only curation such as tagging glyph banks for better discoverability MAY exist, but it MUST NOT redefine the underlying capability contract.
-
-## Rationale
-
-This decision separates two different responsibilities that would otherwise collapse into one another:
-
-- scene authoring as an editorial workspace concern;
-- asset management as an asset-first Studio concern.
-
-Keeping the `Scene Workspace` independent prevents the `Assets` workspace from becoming a generic container for heavy domain editors.
-
-That separation also matches the user-facing intent:
-
-- the `Assets` workspace can create or surface a `SCENE` asset;
-- the `Scene Workspace` is where the user actually authors the scene.
-
-Wave 1 is intentionally narrow.
-
-The goal is to prove the canonical scene-authoring loop around tilemaps, layers, tileset selection, and save semantics before introducing additional aspect domains such as camera, lights, or collision-adjacent editing.
-
-The decision also keeps the Studio aligned with the runtime model already present in `../runtime`:
-
-- four canonical layers;
-- per-layer tilemaps with independent dimensions;
-- explicit tile presence rather than magic empty glyph ids;
-- no leakage of viewport-cache or transient renderer concerns into authoring ownership.
-
-## Technical Specification
-
-### 1. Workspace Topology
-
-- The Studio shell MUST mount `Scene Workspace` as its own workspace entry.
-- The `Scene Workspace` MUST follow the same shell/workspace separation rules as other Studio workspaces.
-- The `Scene Workspace` MUST own its operational detail locally rather than pushing it into shell-global surfaces.
-
-### 2. Scene Ownership Model
-
-- A scene edited in `Scene Workspace` MUST be treated as a Studio-owned intermediate authoring artifact.
-- The scene authoring artifact MUST have its own stable identity.
-- The scene authoring artifact MUST be the primary navigation unit inside the `Scene Workspace`.
-- The related `SCENE` asset MUST appear only as linked context, status, or action, not as the primary navigation unit of the workspace.
-
-### 3. Relationship with `Assets`
-
-- `Assets` MAY create a `SCENE` asset.
-- `Scene Workspace` MAY create a `SCENE` asset as part of creating a new scene.
-- `Assets` MUST delegate scene-content authoring to `Scene Workspace`.
-- `Assets` MUST NOT expose map painting or equivalent scene-editor interactions.
-- The Studio SHOULD support contextual handoff from `Assets` to `Scene Workspace` after `SCENE` asset creation.
-
-### 4. Binding Contract
-
-- The relationship between a scene authoring artifact and a `SCENE` asset MUST be explicit.
-- The primary binding anchor MUST be Studio metadata or equivalent explicit identity linkage.
-- Path MAY be retained as secondary location context.
-- Rename or relocation MUST NOT silently break semantic linkage solely because paths changed.
-
-### 5. Wave-1 UI Composition
-
-- The left region MUST provide a scene navigator inspired by the custom-navigation discipline used in `Assets`, but it MUST remain scene-first rather than asset-first.
-- The top region of the workspace MUST provide an aspect-tab structure.
-- Wave 1 MUST expose only one visible tab: `Tilemap`.
-- The central region of the `Tilemap` tab MUST host the editable map canvas.
-- The right-side upper region MUST show tilemap dimensions and relevant details for the active scene/layer context.
-- The right-side lower region MUST show the tile palette used for picking and painting.
-
-### 6. Scene Model Expectations for Wave 1
-
-- The workspace MUST model exactly four scene layers.
-- Each layer MUST support independent dimensions.
-- Each layer MUST be editable in a way compatible with the runtime-aligned canonical scene model.
-- The workspace MUST NOT flatten all layers into one synthetic shared-size map contract.
-
-### 7. Tileset Rules
-
-- Tileset choice MUST be owned by `Scene Workspace`.
-- The workspace MAY resolve tileset selection per scene or per layer, as long as the chosen model remains explicit and internally consistent.
-- Any glyph bank that is technically valid for use as tileset data MAY be selected.
-- Optional Studio editorial tagging MAY improve filtering and discoverability, but MUST remain non-normative to the base capability.
-- `Assets` MUST NOT override editorial tileset selection from the scene workspace.
-
-### 8. Editing and Save Rules
-
-- The `Scene Workspace` MUST save the intermediate scene authoring artifact through its own save flow.
-- Saving the scene authoring artifact MUST remain distinct from asset creation or asset-management flows.
-- The workspace MUST support a normal save-oriented document/editing lifecycle for the scene artifact rather than an asset-form `apply/reset` lifecycle.
-
-### 9. Tooling Scope for Wave 1
-
-- Wave 1 MUST support basic painting.
-- Wave 1 MUST support erasing through explicit tile presence control.
-- Wave 1 MUST support selecting a tile and palette for painting.
-- Wave 1 MUST support layer visibility.
-- Wave 1 MUST support layer focus.
-- Wave 1 MUST NOT depend on bucket fill, marquee, flood fill, or equivalent advanced editing tools.
-
-### 10. Tile Semantics
-
-- Tile absence MUST be represented by explicit presence state.
-- `glyph_id = 0` MUST remain a valid glyph identifier.
-- Erasing a tile MUST clear presence state instead of writing a magic empty glyph value.
-- Painting behavior MUST operate over explicit tile data such as active state, glyph id, palette id, and flip state.
-
-## Constraints
-
-- This decision is limited to the `Scene Workspace` and its Studio-local boundary with `Assets`.
-- This decision MUST NOT be used to infer packer publication rules beyond the existence of a linked `SCENE` asset.
-- This decision MUST NOT be treated as approval for camera, lighting, AABB, or other future aspect tabs.
-- Any future change to the ownership boundary between `Scene Workspace` and `Assets` requires an explicit revision or replacement decision.
-- Any future change to the stable binding contract between scene artifact and `SCENE` asset requires an explicit revision or follow-up decision.
-
-## Revision Log
-
-- 2026-04-14: Initial accepted decision from AGD-0029.
-- 2026-04-15: Abandoned by explicit user request before implementation completion; follow-up work must proceed through a new discussion rather than this decision.
diff --git a/discussion/workflow/plans/PLN-0049-scene-workspace-spec-and-boundary-propagation.md b/discussion/workflow/plans/PLN-0049-scene-workspace-spec-and-boundary-propagation.md
deleted file mode 100644
index a58433c3..00000000
--- a/discussion/workflow/plans/PLN-0049-scene-workspace-spec-and-boundary-propagation.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-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.
diff --git a/discussion/workflow/plans/PLN-0050-scene-workspace-shell-and-project-state-foundations.md b/discussion/workflow/plans/PLN-0050-scene-workspace-shell-and-project-state-foundations.md
deleted file mode 100644
index ad741b83..00000000
--- a/discussion/workflow/plans/PLN-0050-scene-workspace-shell-and-project-state-foundations.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-id: PLN-0050
-ticket: studio-scene-workspace
-title: Build Scene Workspace shell and project-state foundations
-status: abandoned
-created: 2026-04-14
-completed:
-tags:
-  - studio
-  - workspace
-  - shell
-  - project-state
-  - scene
----
-
-## Objective
-
-Establish the shell, workspace registration, and project-state foundations required to mount `Scene Workspace` as a first-class Studio workspace.
-
-## Background
-
-`DEC-0026` requires `Scene Workspace` to exist as its own shell workspace and to own scene-authoring detail locally. The current shell and project-state code already support `Assets`, `Code Editor`, `Debug`, and `Shipper`, but no scene workspace entry exists yet.
-
-## Scope
-
-### Included
-- Add a `Scene Workspace` entry to the Studio shell workspace model.
-- Mount a first implementation composition root for `Scene Workspace`.
-- Extend project-local layout/state only where needed for accepted shell behavior.
-- Keep workspace-local operational state out of shell-global ownership.
-
-### Excluded
-- Full tilemap editor interactions.
-- Asset creation workflows.
-- Scene serialization and save internals.
-
-## Execution Steps
-
-### Step 1 - Extend workspace identifiers and shell selection
-
-**What:**
-Add `Scene Workspace` to the workspace identity model and shell-selection flow.
-
-**How:**
-Update the workspace enum/identifier, shell selection logic, and main window wiring so the shell can mount and switch to `Scene Workspace` like other first-class workspaces.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/WorkspaceId.java`
-- `prometeu-studio/src/main/java/p/studio/window/MainView.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/WorkspaceHost.java`
-
-### Step 2 - Add a Scene Workspace composition root
-
-**What:**
-Create the initial workspace class and composition surface for `Scene Workspace`.
-
-**How:**
-Introduce a new workspace package with a composition root that follows the Studio event-driven workspace framework and can initially host the wave-1 layout regions.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/scene/SceneWorkspace.java`
-- supporting classes under `prometeu-studio/src/main/java/p/studio/workspaces/scene/`
-
-### Step 3 - Wire workspace lifecycle and activity integration
-
-**What:**
-Ensure the new workspace participates correctly in the shared workspace lifecycle model.
-
-**How:**
-Use existing workspace lifecycle helpers and add any minimal shell-activity mapping needed for workspace open or scene-open events, without leaking scene-local detail into the shell.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/StudioWorkspaceLifecycleSupport.java`
-- `prometeu-studio/src/main/java/p/studio/controls/shell/StudioActivityEventMapper.java` if needed
-
-### Step 4 - Extend project-local shell state only as required
-
-**What:**
-Support accepted shell/layout restoration for `Scene Workspace` if the implementation needs persisted split/divider state in wave 1.
-
-**How:**
-Introduce the smallest project-local state additions necessary for shell restoration and workspace layout proportions. Do not persist scene-editor document state here unless a separate accepted rule exists.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/projectstate/ProjectLocalStudioState.java`
-- `prometeu-studio/src/main/java/p/studio/projectstate/ProjectLocalStudioStateService.java`
-- related tests under `prometeu-studio/src/test/java/p/studio/projectstate/`
-
-## Test Requirements
-
-### Unit Tests
-
-- Workspace id / shell restoration tests for the new workspace entry.
-- Project-local state normalization tests if new layout state is added.
-
-### Integration Tests
-
-- Main-view or shell-focused tests that verify `Scene Workspace` can mount and become the active workspace.
-
-### Manual Verification
-
-- Open a project and confirm `Scene Workspace` appears as a shell workspace.
-- Switch between `Assets`, `Scene Workspace`, and `Code Editor` without losing shell stability.
-- Reopen the project and confirm accepted shell layout restoration still behaves safely.
-
-## Acceptance Criteria
-
-- [ ] `Scene Workspace` is a selectable shell workspace.
-- [ ] The workspace mounts through the standard workspace host path.
-- [ ] No scene-local editing detail is pushed into shell-global state.
-- [ ] Any new project-local state is limited to accepted shell/workspace restoration concerns.
-
-## Dependencies
-
-- `DEC-0026-studio-scene-workspace.md`
-- `PLN-0049-scene-workspace-spec-and-boundary-propagation.md`
-
-## Risks
-
-- Overloading shell state with scene-editor detail would violate the workspace boundary.
-- Introducing restoration for unaccepted categories would outrun the decision.
-- Wiring shortcuts through `MainView` without a clean package boundary would make later tilemap work harder.
-
-## Abandonment
-
-Abandoned on 2026-04-15 because the parent decision `DEC-0026` was explicitly abandoned by the user.
diff --git a/discussion/workflow/plans/PLN-0051-scene-artifact-and-assets-handoff-contract.md b/discussion/workflow/plans/PLN-0051-scene-artifact-and-assets-handoff-contract.md
deleted file mode 100644
index f89623f5..00000000
--- a/discussion/workflow/plans/PLN-0051-scene-artifact-and-assets-handoff-contract.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-id: PLN-0051
-ticket: studio-scene-workspace
-title: Build scene artifact identity, save flow, and Assets handoff contract
-status: abandoned
-created: 2026-04-14
-completed:
-tags:
-  - studio
-  - scene
-  - asset
-  - binding
-  - save
----
-
-## Objective
-
-Implement the Studio-local data contract that gives scenes a stable authoring identity, supports save for the intermediate scene artifact, and allows explicit handoff between `Scene Workspace` and `Assets`.
-
-## Background
-
-`DEC-0026` requires a stable scene artifact identity, a save-oriented scene-authoring lifecycle, and an explicit binding between scene artifact and `SCENE` asset that does not rely primarily on path inference.
-
-## Scope
-
-### Included
-- Define and implement the scene artifact model used by `Scene Workspace`.
-- Add Studio-local binding metadata between scene artifact and `SCENE` asset.
-- Implement scene save/load for the intermediate authoring artifact.
-- Add `Assets` handoff behavior after `SCENE` asset creation.
-
-### Excluded
-- Final packer publication logic.
-- Advanced editing tools.
-- Future aspect tabs.
-
-## Execution Steps
-
-### Step 1 - Define the scene artifact DTO and persistence boundary
-
-**What:**
-Create a Studio-owned scene artifact model with stable identity and wave-1 tilemap data.
-
-**How:**
-Add DTOs and persistence helpers that capture:
-- scene identity;
-- linked `SCENE` asset identity when present;
-- four layers;
-- per-layer dimensions;
-- per-layer tileset reference;
-- tile presence and editable tile data.
-
-Keep the format explicitly intermediate and Studio-owned.
-
-**File(s):**
-- new files under `prometeu-studio/src/main/java/p/studio/workspaces/scene/model/`
-- new files under `prometeu-studio/src/main/java/p/studio/workspaces/scene/persistence/`
-
-### Step 2 - Implement save/load for the scene artifact
-
-**What:**
-Make `Scene Workspace` able to save and reopen the intermediate scene artifact.
-
-**How:**
-Build a dedicated repository/service for reading and writing scene artifacts using the chosen Studio-local format and metadata contract. Ensure identity survives rename/relocation independently of path.
-
-**File(s):**
-- new persistence/service classes under `prometeu-studio/src/main/java/p/studio/workspaces/scene/`
-- tests under `prometeu-studio/src/test/java/p/studio/workspaces/scene/`
-
-### Step 3 - Implement explicit scene-to-asset binding
-
-**What:**
-Introduce the explicit binding required by the decision.
-
-**How:**
-Store a stable scene artifact id and the linked `SCENE` asset reference in Studio metadata or equivalent explicit state. Avoid primary reliance on path inference. Make the binding readable from both `Scene Workspace` and `Assets`.
-
-**File(s):**
-- scene metadata / persistence files under `prometeu-studio/src/main/java/p/studio/workspaces/scene/`
-- `prometeu-studio/src/main/java/p/studio/projectstate/` only if the accepted metadata home belongs there
-
-### Step 4 - Add Assets-to-Scene handoff behavior
-
-**What:**
-Allow `Assets` to create a `SCENE` asset and then hand off authoring to `Scene Workspace`.
-
-**How:**
-Extend the asset-creation flow with the minimal family support needed for `SCENE`, then trigger explicit open/handoff into `Scene Workspace` without embedding editor controls into `Assets`.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/wizards/AddAssetWizard.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/AssetWorkspace.java`
-- new event/message classes under `prometeu-studio/src/main/java/p/studio/workspaces/assets/messages/events/` and/or `workspaces/scene/messages/`
-
-## Test Requirements
-
-### Unit Tests
-
-- Scene artifact serialization/deserialization tests.
-- Binding-identity stability tests across rename-like path changes.
-- Asset handoff event tests.
-
-### Integration Tests
-
-- End-to-end test: create `SCENE` asset, hand off to `Scene Workspace`, save scene artifact, reopen and preserve binding.
-
-### Manual Verification
-
-- Create a scene from `Scene Workspace` and verify a linked `SCENE` asset exists.
-- Create a `SCENE` asset from `Assets` and verify the UI hands off to `Scene Workspace`.
-- Rename or relocate the scene artifact and verify semantic linkage still resolves.
-
-## Acceptance Criteria
-
-- [ ] The scene authoring artifact has a stable identity independent of raw path.
-- [ ] `Scene Workspace` can save and reopen the intermediate scene artifact.
-- [ ] The binding between scene artifact and `SCENE` asset is explicit and stable.
-- [ ] `Assets` can create a `SCENE` asset and hand off authoring without embedding scene editing.
-
-## Dependencies
-
-- `DEC-0026-studio-scene-workspace.md`
-- `PLN-0049-scene-workspace-spec-and-boundary-propagation.md`
-- `PLN-0050-scene-workspace-shell-and-project-state-foundations.md`
-
-## Risks
-
-- Choosing the wrong metadata home could make binding brittle or leak scene ownership into the wrong layer.
-- Reusing asset-oriented DTOs for scene authoring could erase the boundary that the decision just locked.
-- Save/load work can sprawl if the intermediate format is not kept intentionally narrow for wave 1.
-
-## Abandonment
-
-Abandoned on 2026-04-15 because the parent decision `DEC-0026` was explicitly abandoned by the user.
diff --git a/discussion/workflow/plans/PLN-0052-scene-workspace-wave-1-tilemap-editor.md b/discussion/workflow/plans/PLN-0052-scene-workspace-wave-1-tilemap-editor.md
deleted file mode 100644
index a0e2134d..00000000
--- a/discussion/workflow/plans/PLN-0052-scene-workspace-wave-1-tilemap-editor.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-id: PLN-0052
-ticket: studio-scene-workspace
-title: Implement Scene Workspace wave-1 tilemap editor
-status: abandoned
-created: 2026-04-14
-completed:
-tags:
-  - studio
-  - scene
-  - workspace
-  - tilemap
-  - ui
----
-
-## Objective
-
-Implement the wave-1 `Tilemap` experience for `Scene Workspace` according to `DEC-0026`.
-
-## Background
-
-The accepted decision limits wave 1 to one visible tab, `Tilemap`, with four layers, independent layer dimensions, explicit tile presence semantics, scene-first navigation, and basic editing tools only.
-
-## Scope
-
-### Included
-- Left scene navigator.
-- Top tab strip with only `Tilemap` visible.
-- Central tilemap editing canvas.
-- Right-side tilemap details and tile palette regions.
-- Four-layer editing model with visibility and focus.
-- Basic painting, erasing, and tile selection.
-
-### Excluded
-- Camera boundaries.
-- Lights.
-- AABB authoring.
-- Placeholder tabs for unsupported aspects.
-- Advanced editing tools such as bucket fill, marquee, flood fill, or lock semantics.
-
-## Execution Steps
-
-### Step 1 - Build the workspace projection model
-
-**What:**
-Create projection/view-state types for the scene navigator, active scene, active layer, tile palette, and tilemap details.
-
-**How:**
-Follow the event-driven workspace framework already used by other Studio workspaces. Keep projection boundaries local so navigator, details, and palette can update without whole-workspace redraw.
-
-**File(s):**
-- new projection and message classes under `prometeu-studio/src/main/java/p/studio/workspaces/scene/`
-
-### Step 2 - Build the left navigator and scene selection flow
-
-**What:**
-Render a scene-first navigator that lists authoring scenes, not assets.
-
-**How:**
-Introduce a custom navigator control inspired by `Assets` patterns but scoped to scene identity, with linked asset context rendered only as secondary status.
-
-**File(s):**
-- new controls under `prometeu-studio/src/main/java/p/studio/workspaces/scene/list/`
-- `prometeu-studio/src/main/java/p/studio/workspaces/scene/SceneWorkspace.java`
-
-### Step 3 - Build the wave-1 Tilemap layout
-
-**What:**
-Implement the single visible tab and its three-region body.
-
-**How:**
-Compose:
-- central tilemap canvas;
-- right upper details panel;
-- right lower tile palette;
-- layer controls for visibility and focus.
-
-Do not expose unsupported tabs.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/scene/SceneWorkspace.java`
-- new controls under `prometeu-studio/src/main/java/p/studio/workspaces/scene/tilemap/`
-
-### Step 4 - Implement tile selection and painting
-
-**What:**
-Support the basic editing interactions required by the decision.
-
-**How:**
-Implement tile selection from the palette, paint on the active layer, erase by clearing explicit tile presence, and preserve valid `glyph_id = 0` semantics.
-
-**File(s):**
-- tilemap interaction classes under `prometeu-studio/src/main/java/p/studio/workspaces/scene/tilemap/`
-- scene model classes under `prometeu-studio/src/main/java/p/studio/workspaces/scene/model/`
-
-### Step 5 - Implement tileset resolution and layer detail rendering
-
-**What:**
-Resolve glyph-bank-backed tileset data for the active scene/layer and show dimensions/details in the side panel.
-
-**How:**
-Consume the scene-owned tileset choice, render available tiles and palette choices, and expose active layer dimensions and relevant properties without handing ownership to `Assets`.
-
-**File(s):**
-- scene workspace service/projection classes
-- tile palette and detail controls under `prometeu-studio/src/main/java/p/studio/workspaces/scene/tilemap/`
-
-## Test Requirements
-
-### Unit Tests
-
-- Projection-state tests for active scene, layer visibility, and focus.
-- Tile painting tests that preserve explicit presence semantics.
-- Palette-selection tests that keep `glyph_id = 0` valid.
-
-### Integration Tests
-
-- UI-oriented tests for scene selection, tile selection, paint, erase, and save-triggered refresh.
-
-### Manual Verification
-
-- Open `Scene Workspace`, create/open a scene, and confirm the navigator is scene-first.
-- Paint and erase on different layers with independent dimensions.
-- Verify layer visibility/focus changes do not corrupt scene data.
-- Verify only the `Tilemap` tab is visible in wave 1.
-
-## Acceptance Criteria
-
-- [ ] `Scene Workspace` renders a scene-first navigator.
-- [ ] Wave 1 exposes only the `Tilemap` tab.
-- [ ] The editor supports four layers with independent dimensions.
-- [ ] Painting and erasing respect explicit tile presence semantics.
-- [ ] Layer visibility and focus work in the tilemap editor.
-- [ ] Tile palette and details panels reflect the active scene/layer context.
-
-## Dependencies
-
-- `DEC-0026-studio-scene-workspace.md`
-- `PLN-0049-scene-workspace-spec-and-boundary-propagation.md`
-- `PLN-0050-scene-workspace-shell-and-project-state-foundations.md`
-- `PLN-0051-scene-artifact-and-assets-handoff-contract.md`
-
-## Risks
-
-- Overbuilding the first UI pass could quietly introduce unsupported aspect tabs or tools.
-- Canvas interaction code can become monolithic if projection boundaries are not enforced early.
-- Tileset rendering may drift toward asset-first ownership if scene-owned selection is not kept explicit.
-
-## Abandonment
-
-Abandoned on 2026-04-15 because the parent decision `DEC-0026` was explicitly abandoned by the user.