discussion/index.ndjson

@@ -1,4 +1,6 @@
-{"type":"meta","next_id":{"DSC":27,"AGD":29,"DEC":26,"PLN":49,"LSN":40,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":29,"AGD":31,"DEC":27,"PLN":53,"LSN":40,"CLSN":1}}
+{"type":"discussion","id":"DSC-0028","status":"open","ticket":"studio-tiled-parser-assets-scene-asset-type","title":"Tiled Parser and Scene Asset-Type Ownership in Assets Workspace","created_at":"2026-04-15","updated_at":"2026-04-15","tags":["studio","assets","scene","tiled","parser","asset-type"],"agendas":[{"id":"AGD-0030","file":"AGD-0030-tiled-parser-and-scene-asset-type.md","status":"open","created_at":"2026-04-15","updated_at":"2026-04-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0027","status":"abandoned","ticket":"studio-scene-workspace","title":"Scene Workspace for SCENE Authoring","created_at":"2026-04-14","updated_at":"2026-04-15","tags":["studio","workspace","scene","tilemap","asset","runtime-alignment"],"agendas":[{"id":"AGD-0029","file":"AGD-0029-studio-scene-workspace.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","_override_reason":"Explicit user request on 2026-04-15 to abandon the accepted agenda and its downstream work."}],"decisions":[{"id":"DEC-0026","file":"DEC-0026-studio-scene-workspace.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","ref_agenda":"AGD-0029","_override_reason":"Explicit user request on 2026-04-15 to abandon the accepted decision and stop using it as normative guidance."}],"plans":[{"id":"PLN-0049","file":"PLN-0049-scene-workspace-spec-and-boundary-propagation.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","ref_decisions":["DEC-0026"],"_override_reason":"Explicit user request on 2026-04-15 to abandon all plans derived from DEC-0026."},{"id":"PLN-0050","file":"PLN-0050-scene-workspace-shell-and-project-state-foundations.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","ref_decisions":["DEC-0026"],"_override_reason":"Explicit user request on 2026-04-15 to abandon all plans derived from DEC-0026."},{"id":"PLN-0051","file":"PLN-0051-scene-artifact-and-assets-handoff-contract.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","ref_decisions":["DEC-0026"],"_override_reason":"Explicit user request on 2026-04-15 to abandon all plans derived from DEC-0026."},{"id":"PLN-0052","file":"PLN-0052-scene-workspace-wave-1-tilemap-editor.md","status":"abandoned","created_at":"2026-04-14","updated_at":"2026-04-15","ref_decisions":["DEC-0026"],"_override_reason":"Explicit user request on 2026-04-15 to abandon all plans derived from DEC-0026."}],"lessons":[]}
 {"type":"discussion","id":"DSC-0026","status":"done","ticket":"glyph-bank-naming-alignment-with-runtime","title":"Glyph Bank Naming Alignment with Runtime DEC-0006","created_at":"2026-04-10","updated_at":"2026-04-10","tags":["packer","studio","naming","asset-contract","runtime-alignment","glyph-bank"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0040","file":"discussion/lessons/DSC-0026-glyph-bank-naming-alignment-with-runtime/LSN-0040-glyph-bank-artifact-naming-alignment.md","status":"done","created_at":"2026-04-10","updated_at":"2026-04-10"}]}
 {"type":"discussion","id":"DSC-0025","status":"done","ticket":"packer-pipeline-metadata-ownership","title":"Pipeline Metadata Ownership and Runtime Contract","created_at":"2026-04-09","updated_at":"2026-04-10","tags":["packer","metadata","runtime-contract","tooling","studio"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0039","file":"discussion/lessons/DSC-0025-packer-pipeline-metadata-ownership/LSN-0039-runtime-header-boundary-and-tooling-owned-pipeline-metadata.md","status":"done","created_at":"2026-04-10","updated_at":"2026-04-10"}]}
 {"type":"discussion","id":"DSC-0024","status":"done","ticket":"jacoco-reports-consolidation","title":"JaCoCo Reports Consolidation in Gradle","created_at":"2026-04-07","updated_at":"2026-04-07","tags":["infra","gradle","jacoco","coverage","jenkins"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0038","file":"discussion/lessons/DSC-0024-jacoco-reports-consolidation/LSN-0038-jacoco-reports-consolidation.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}

discussion/workflow/agendas/AGD-0029-studio-scene-workspace.md

@@ -0,0 +1,295 @@
+---
+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.

discussion/workflow/agendas/AGD-0030-tiled-parser-and-scene-asset-type.md

@@ -0,0 +1,115 @@
+---
+id: AGD-0030
+ticket: studio-tiled-parser-assets-scene-asset-type
+title: Tiled Parser and Scene Asset-Type Ownership in Assets Workspace
+status: open
+created: 2026-04-15
+resolved:
+decision:
+tags:
+  - studio
+  - assets
+  - scene
+  - tiled
+  - parser
+  - asset-type
+---
+
+## Pain
+
+The current abandoned direction assumed a dedicated `Scene Workspace` as the primary authoring owner for scenes.
+
+That no longer matches the intended product direction.
+
+Without a new direction:
+
+- the Studio has no agreed path for scene authoring;
+- the `Assets` workspace still lacks a defined ownership model for scene-like content;
+- there is no agreed contract for importing or interpreting `Tiled` data;
+- implementation risks rebuilding a custom scene editor model that the team has already decided to discard.
+
+## Context
+
+Domain owner: `studio`
+
+Expected documentation owner:
+
+- `docs/studio/specs`
+
+Cross-domain impact:
+
+- asset typing and creation flows in the `Assets` workspace;
+- Studio-side parsing/import rules for `Tiled`;
+- possible downstream alignment with runtime-facing `SCENE` publication, depending on the chosen import boundary.
+
+User direction explicitly provided on 2026-04-15:
+
+- abandon `DEC-0026` and its derived plans;
+- do not proceed with a dedicated `Scene Workspace`;
+- instead, write a parser for `Tiled`;
+- create a new asset type managed from the `Assets` workspace.
+
+This agenda exists to turn that direction into a disciplined technical recommendation rather than jumping directly into implementation with undefined ownership and file-contract assumptions.
+
+## Open Questions
+
+- [ ] Which `Tiled` surface is the primary input contract: TMX XML, JSON export, TSX, or a constrained subset of those?
+- [ ] Is the new asset type a raw imported `Tiled` document, a normalized Studio-owned intermediate asset, or a published runtime-facing `SCENE` derivative?
+- [ ] Should `Assets` own only creation/import and metadata management, or also the main editing/reimport flow for this new asset type?
+- [ ] How should tileset references inside `Tiled` map onto existing glyph-bank assets and asset identity rules in Studio?
+- [ ] What parts of `Tiled` are intentionally out of scope for the first wave: object layers, properties, flips, collisions, infinite maps, templates, Wang sets, animations?
+- [ ] Does the parser need to preserve full round-trip fidelity with `Tiled`, or only import the supported subset into Studio-owned structures?
+- [ ] What is the canonical failure model when a `Tiled` document references unsupported constructs or broken external assets?
+
+## Options
+
+### Option A - Import `Tiled` into a new Studio-owned scene asset type in `Assets`
+- **Approach:** Introduce a new asset type in `Assets`; parse supported `Tiled` files into a Studio-owned asset model managed from that workspace.
+- **Pro:** Aligns with the requested ownership shift, keeps authoring/import centered in `Assets`, and allows Studio to define a strict supported subset.
+- **Con:** Requires defining a clean normalized asset contract and a mapping layer from `Tiled` concepts to Studio/runtime concepts.
+- **Maintainability:** Strong, if the supported subset and ownership boundary are made explicit early.
+
+### Option B - Treat `Tiled` files as external source documents and keep Studio as a thin importer/viewer
+- **Approach:** Keep `Tiled` as the primary authoring format and let Studio mostly import, validate, and publish from it.
+- **Pro:** Minimizes Studio-owned scene-model invention and stays close to existing `Tiled` authoring workflows.
+- **Con:** Couples Studio behavior heavily to `Tiled`'s full document model and makes partial support/error handling harder to reason about.
+- **Maintainability:** Medium, because unsupported `Tiled` breadth can leak into every implementation phase.
+
+### Option C - Create a new Studio asset type unrelated to `Tiled` and only offer one-time conversion
+- **Approach:** Use `Tiled` only as an optional bootstrap/import tool, then move fully into a separate Studio-native asset format.
+- **Pro:** Gives Studio maximum control over the final asset model and future editing behavior.
+- **Con:** Moves away from the user's stated direction of writing a `Tiled` parser as a central path and may reintroduce the same custom-model burden the previous direction had.
+- **Maintainability:** Medium, but only if the conversion boundary is very clearly justified.
+
+## Discussion
+
+The key architectural change here is not only "use `Tiled`".
+
+It is also a change in ownership:
+
+- scene-related authoring/import should no longer justify a dedicated `Scene Workspace`;
+- the `Assets` workspace becomes the management surface for the relevant asset type;
+- any parser choice must therefore fit an asset-first workflow instead of a separate editor-first workflow.
+
+That creates several decisions that should be made deliberately:
+
+1. what exact `Tiled` contract Studio supports in wave 1;
+2. whether Studio stores `Tiled` data directly or through a normalized asset form;
+3. how glyph banks and tilesets map without creating identity ambiguity;
+4. how much of `Tiled` fidelity is preserved versus normalized away;
+5. whether editing is a reimport/update flow, a direct managed-asset flow, or some hybrid.
+
+There is already one strong constraint from the user:
+
+- the previous `Scene Workspace` split should be considered discarded;
+- the new work should be organized around `Assets` plus a `Tiled` parser.
+
+That makes Option A the current best fit for convergence, but it still needs the agenda to narrow the supported `Tiled` subset and the resulting asset contract before a new decision can be written.
+
+## Resolution
+
+Recommended next step:
+
+- converge this agenda around a first-wave `Tiled` subset;
+- define whether the new asset type is raw-imported or normalized;
+- then write a replacement decision for asset ownership, parser boundary, and wave-1 scope.

discussion/workflow/decisions/DEC-0026-studio-scene-workspace.md

@@ -0,0 +1,181 @@
+---
+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.

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

@@ -0,0 +1,137 @@
+---
+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.

discussion/workflow/plans/PLN-0050-scene-workspace-shell-and-project-state-foundations.md

@@ -0,0 +1,126 @@
+---
+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.

discussion/workflow/plans/PLN-0051-scene-artifact-and-assets-handoff-contract.md

@@ -0,0 +1,135 @@
+---
+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.

discussion/workflow/plans/PLN-0052-scene-workspace-wave-1-tilemap-editor.md

@@ -0,0 +1,151 @@
+---
+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.

test-projects/main/assets/scenes/primeiro mapa.tmx

@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<map version="1.10" tiledversion="1.12.1" orientation="orthogonal" renderorder="right-down" width="25" height="25" tilewidth="16" tileheight="16" infinite="0" nextlayerid="4" nextobjectid="12">
+ <tileset firstgid="1" source="primeiro tileset.tsx"/>
+ <layer id="1" name="Tile Layer 1" width="25" height="25">
+  <data encoding="csv">
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
+</data>
+ </layer>
+ <objectgroup id="3" name="Object Layer 1">
+  <object id="11" x="16" y="16" width="64" height="64"/>
+ </objectgroup>
+</map>

test-projects/main/assets/scenes/primeiro tileset.tsx

@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<tileset version="1.10" tiledversion="1.12.1" name="primeiro tileset" tilewidth="16" tileheight="16" tilecount="1" columns="0">
+ <grid orientation="orthogonal" width="1" height="1"/>
+ <tile id="0">
+  <image source="../recovered/atlas2/confirm.png" width="16" height="16"/>
+ </tile>
+</tileset>

test-projects/main/assets/scenes/scene1.tiled-project

@@ -0,0 +1,14 @@
+{
+    "automappingRulesFile": "",
+    "commands": [
+    ],
+    "compatibilityVersion": 1100,
+    "extensionsPath": "extensions",
+    "folders": [
+        "."
+    ],
+    "properties": [
+    ],
+    "propertyTypes": [
+    ]
+}

test-projects/main/assets/scenes/scene1.tiled-session

@@ -0,0 +1,38 @@
+{
+    "activeFile": "primeiro tileset.tsx",
+    "expandedProjectPaths": [
+        "."
+    ],
+    "fileStates": {
+        "primeiro mapa.tmx": {
+            "scale": 2.55,
+            "selectedLayer": 1,
+            "viewCenter": {
+                "x": 200,
+                "y": 200.58823529411768
+            }
+        },
+        "primeiro tileset.tsx": {
+            "dynamicWrapping": true,
+            "scaleInDock": 1,
+            "scaleInEditor": 1
+        }
+    },
+    "last.imagePath": "/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/studio/test-projects/main/assets/recovered/atlas2",
+    "map.height": 25,
+    "map.lastUsedFormat": "tmx",
+    "map.tileHeight": 16,
+    "map.tileWidth": 16,
+    "map.width": 25,
+    "openFiles": [
+        "primeiro mapa.tmx",
+        "primeiro tileset.tsx"
+    ],
+    "project": "scene1.tiled-project",
+    "recentFiles": [
+        "primeiro mapa.tmx",
+        "primeiro tileset.tsx"
+    ],
+    "tileset.lastUsedFormat": "tsx",
+    "tileset.type": 1
+}