housekeeping e clean up

discussion/.backups/index.ndjson.20260330-234208.bak

@@ -1,12 +0,0 @@
-{"type":"meta","next_id":{"DSC":12,"AGD":12,"DEC":9,"PLN":12,"LSN":26,"CLSN":1}}
-{"type":"discussion","id":"DSC-0001","status":"done","ticket":"studio-docs-import","title":"Import docs/studio into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["studio","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0001","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0001-assets-workspace-execution-wave-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0002","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0002-bank-composition-editor-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0003","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0003-mental-model-asset-mutations-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0004","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0004-mental-model-assets-workspace-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0005","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0005-mental-model-studio-events-and-components-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0006","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0006-mental-model-studio-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0007","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0007-pack-wizard-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0008","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0008-project-scoped-state-and-activity-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0016","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0016-studio-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
-{"type":"discussion","id":"DSC-0002","status":"open","ticket":"palette-management-in-studio","title":"Palette Management in Studio","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["studio","legacy-import","palette-management","tile-bank","packer-boundary"],"agendas":[{"id":"AGD-0002","file":"AGD-0002-palette-management-in-studio.md","status":"open","created_at":"2026-03-26","updated_at":"2026-03-26"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0003","status":"done","ticket":"packer-docs-import","title":"Import docs/packer into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0009","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0009-mental-model-packer-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0010","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0010-asset-identity-and-runtime-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0011","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0011-foundations-workspace-runtime-and-build-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0012","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0012-runtime-ownership-and-studio-boundary-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0013","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0013-metadata-convergence-and-runtime-sink-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0014","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0014-pack-wizard-summary-validation-and-pack-execution-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0015","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0015-tile-bank-packing-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0017","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0017-packer-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
-{"type":"discussion","id":"DSC-0004","status":"open","ticket":"tilemap-and-metatile-runtime-binary-layout","title":"Tilemap and Metatile Runtime Binary Layout","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","legacy-import","tilemap","metatile","runtime-layout"],"agendas":[{"id":"AGD-0004","file":"AGD-0004-tilemap-and-metatile-runtime-binary-layout.md","status":"open","created_at":"2026-03-26","updated_at":"2026-03-26"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0005","status":"open","ticket":"variable-tile-bank-palette-serialization","title":"Variable Tile Bank Palette Serialization","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","legacy-import","tile-bank","palette-serialization","versioning"],"agendas":[{"id":"AGD-0005","file":"AGD-0005-variable-tile-bank-palette-serialization.md","status":"open","created_at":"2026-03-26","updated_at":"2026-03-26"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0006","status":"done","ticket":"pbs-game-facing-asset-refs-and-call-result-discard","title":"PBS Game-Facing Asset References and Ignored Call Result Lowering","created_at":"2026-03-27","updated_at":"2026-03-30","tags":["compiler","pbs","ergonomics","lowering","runtime","asset-identity","expression-statements"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0024","file":"discussion/lessons/DSC-0006-pbs-game-facing-asset-refs-and-call-result-discard/LSN-0024-addressable-surface-host-metadata-and-ignored-value-discipline.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30"}]}
-{"type":"discussion","id":"DSC-0007","status":"done","ticket":"pbs-learn-to-discussion-lessons-migration","title":"Migrate PBS Learn Documents into Discussion Lessons","created_at":"2026-03-27","updated_at":"2026-03-27","tags":["compiler","pbs","migration","discussion-framework","lessons","learn-prune"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0018","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0018-pbs-ast-and-parser-contract-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0019","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0019-pbs-name-resolution-and-linking-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0020","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0020-pbs-runtime-values-identity-memory-boundaries-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0021","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0021-pbs-diagnostics-and-conformance-governance-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0022","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0022-pbs-globals-lifecycle-and-published-entrypoint-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"}]}
-{"type":"discussion","id":"DSC-0008","status":"done","ticket":"pbs-low-level-asset-manager-surface","title":"PBS Low-Level Asset Manager Surface for Runtime AssetManager","created_at":"2026-03-27","updated_at":"2026-03-27","tags":["compiler","pbs","runtime","asset-manager","host-abi","stdlib","asset"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0023","file":"discussion/lessons/DSC-0008-pbs-low-level-asset-manager-surface/LSN-0023-lowassets-runtime-aligned-sdk-surface.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"}]}
-{"type":"discussion","id":"DSC-0009","status":"open","ticket":"studio-debugger-workspace-integration","title":"Integrate ../debugger into Studio as a dedicated workspace","created_at":"2026-03-30","updated_at":"2026-03-30","tags":["studio","debugger","workspace","integration","shell"],"agendas":[{"id":"AGD-0009","file":"AGD-0009-studio-debugger-workspace-integration.md","status":"open","created_at":"2026-03-30","updated_at":"2026-03-30"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0010","status":"review","ticket":"studio-code-editor-workspace-foundations","title":"Establish Code Editor workspace foundations in Studio without LSP","created_at":"2026-03-30","updated_at":"2026-03-30","tags":["studio","editor","workspace","multi-frontend","lsp-deferred"],"agendas":[{"id":"AGD-0010","file":"AGD-0010-studio-code-editor-workspace-foundations.md","status":"accepted","created_at":"2026-03-30","updated_at":"2026-03-30"}],"decisions":[{"id":"DEC-0008","file":"DEC-0008-studio-code-editor-read-only-workspace-foundations.md","status":"review","created_at":"2026-03-30","updated_at":"2026-03-30","ref_agenda":"AGD-0010"}],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0011","status":"done","ticket":"compiler-analyze-compile-build-pipeline-split","title":"Split compiler pipeline into analyze, compile, and build entrypoints","created_at":"2026-03-30","updated_at":"2026-03-30","tags":["compiler","pipeline","artifacts","build","analysis"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0025","file":"discussion/lessons/DSC-0011-compiler-analyze-compile-build-pipeline-split/LSN-0025-compiler-pipeline-entrypoints-and-result-boundaries.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30"}]}

discussion/.backups/index.ndjson.20260501-111858.bak

@@ -0,0 +1,31 @@
+{"type":"meta","next_id":{"DSC":31,"AGD":34,"DEC":31,"PLN":62,"LSN":47,"CLSN":1}}
+{"type":"discussion","id":"DSC-0030","status":"done","ticket":"studio-scene-pack-runtime-binary-contract","title":"Studio scene pack contract for runtime SCENE binary payload","created_at":"2026-04-24","updated_at":"2026-05-01","tags":["studio","packer","runtime","scene","asset-pack","binary-format","tiled"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0046","file":"discussion/lessons/DSC-0030-studio-scene-pack-runtime-binary-contract/LSN-0046-canonical-scene-owns-editorial-truth-while-pack-stays-request-driven.md","status":"done","created_at":"2026-05-01","updated_at":"2026-05-01"}]}
+{"type":"discussion","id":"DSC-0029","status":"done","ticket":"studio-frame-composer-syscall-and-sprite-alignment","title":"Studio Alignment with Runtime FrameComposer Syscalls and Sprite Composition","created_at":"2026-04-18","updated_at":"2026-04-18","tags":["studio","compiler","pbs","stdlib","runtime-alignment","abi","syscall","frame-composer","sprites"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0041","file":"discussion/lessons/DSC-0029-studio-frame-composer-syscall-and-sprite-alignment/LSN-0041-composer-must-own-public-sprite-composition.md","status":"done","created_at":"2026-04-18","updated_at":"2026-04-18"}]}
+{"type":"discussion","id":"DSC-0028","status":"done","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-23","tags":["studio","assets","scene","tiled","parser","asset-type"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0028-studio-tiled-parser-assets-scene-asset-type/LSN-0045-asset-owned-scene-bank-and-tiled-xml-workflow.md","status":"done","created_at":"2026-04-23","updated_at":"2026-04-23"}]}
+{"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"},{"id":"LSN-0044","file":"discussion/lessons/DSC-0024-jacoco-reports-consolidation/LSN-0044-jenkins-jacoco-alignment.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}
+{"type":"discussion","id":"DSC-0001","status":"done","ticket":"studio-docs-import","title":"Import docs/studio into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["studio","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0001","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0001-assets-workspace-execution-wave-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0002","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0002-bank-composition-editor-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0003","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0003-mental-model-asset-mutations-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0004","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0004-mental-model-assets-workspace-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0005","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0005-mental-model-studio-events-and-components-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0006","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0006-mental-model-studio-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0007","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0007-pack-wizard-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0008","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0008-project-scoped-state-and-activity-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0016","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0016-studio-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
+{"type":"discussion","id":"DSC-0002","status":"done","ticket":"palette-management-in-studio","title":"Palette Management in Studio","created_at":"2026-03-26","updated_at":"2026-04-23","tags":["studio","legacy-import","palette-management","tile-bank","packer-boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0042","file":"discussion/lessons/DSC-0002-palette-management-in-studio/LSN-0042-schema-driven-palette-authoring-and-local-metadata-events.md","status":"done","created_at":"2026-04-23","updated_at":"2026-04-23"}]}
+{"type":"discussion","id":"DSC-0003","status":"done","ticket":"packer-docs-import","title":"Import docs/packer into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0009","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0009-mental-model-packer-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0010","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0010-asset-identity-and-runtime-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0011","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0011-foundations-workspace-runtime-and-build-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0012","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0012-runtime-ownership-and-studio-boundary-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0013","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0013-metadata-convergence-and-runtime-sink-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0014","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0014-pack-wizard-summary-validation-and-pack-execution-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0015","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0015-tile-bank-packing-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0017","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0017-packer-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
+{"type":"discussion","id":"DSC-0004","status":"abandoned","ticket":"tilemap-and-metatile-runtime-binary-layout","title":"Tilemap and Metatile Runtime Binary Layout","created_at":"2026-03-26","updated_at":"2026-04-24","tags":["packer","legacy-import","tilemap","metatile","runtime-layout"],"agendas":[{"id":"AGD-0004","file":"AGD-0004-tilemap-and-metatile-runtime-binary-layout.md","status":"abandoned","created_at":"2026-03-26","updated_at":"2026-04-24","_override_reason":"Explicit user request on 2026-04-24 to abandon AGD-0004 because the agenda is no longer valid."}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0005","status":"open","ticket":"variable-tile-bank-palette-serialization","title":"Variable Tile Bank Palette Serialization","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","legacy-import","tile-bank","palette-serialization","versioning"],"agendas":[{"id":"AGD-0005","file":"AGD-0005-variable-tile-bank-palette-serialization.md","status":"open","created_at":"2026-03-26","updated_at":"2026-03-26"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0006","status":"done","ticket":"pbs-game-facing-asset-refs-and-call-result-discard","title":"PBS Game-Facing Asset References and Ignored Call Result Lowering","created_at":"2026-03-27","updated_at":"2026-03-30","tags":["compiler","pbs","ergonomics","lowering","runtime","asset-identity","expression-statements"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0024","file":"discussion/lessons/DSC-0006-pbs-game-facing-asset-refs-and-call-result-discard/LSN-0024-addressable-surface-host-metadata-and-ignored-value-discipline.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30"}]}
+{"type":"discussion","id":"DSC-0007","status":"done","ticket":"pbs-learn-to-discussion-lessons-migration","title":"Migrate PBS Learn Documents into Discussion Lessons","created_at":"2026-03-27","updated_at":"2026-03-27","tags":["compiler","pbs","migration","discussion-framework","lessons","learn-prune"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0018","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0018-pbs-ast-and-parser-contract-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0019","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0019-pbs-name-resolution-and-linking-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0020","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0020-pbs-runtime-values-identity-memory-boundaries-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0021","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0021-pbs-diagnostics-and-conformance-governance-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"},{"id":"LSN-0022","file":"discussion/lessons/DSC-0007-pbs-learn-to-discussion-lessons-migration/LSN-0022-pbs-globals-lifecycle-and-published-entrypoint-legacy.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"}]}
+{"type":"discussion","id":"DSC-0008","status":"done","ticket":"pbs-low-level-asset-manager-surface","title":"PBS Low-Level Asset Manager Surface for Runtime AssetManager","created_at":"2026-03-27","updated_at":"2026-03-27","tags":["compiler","pbs","runtime","asset-manager","host-abi","stdlib","asset"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0023","file":"discussion/lessons/DSC-0008-pbs-low-level-asset-manager-surface/LSN-0023-lowassets-runtime-aligned-sdk-surface.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"}]}
+{"type":"discussion","id":"DSC-0009","status":"done","ticket":"studio-debugger-workspace-integration","title":"Integrate ../debugger into Studio as a dedicated workspace","created_at":"2026-03-30","updated_at":"2026-04-07","tags":["studio","debugger","workspace","integration","shell"],"agendas":[],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0010","status":"done","ticket":"studio-code-editor-workspace-foundations","title":"Establish Code Editor workspace foundations in Studio without LSP","created_at":"2026-03-30","updated_at":"2026-03-31","tags":["studio","editor","workspace","multi-frontend","lsp-deferred"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0026","file":"discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31"}]}
+{"type":"discussion","id":"DSC-0011","status":"done","ticket":"compiler-analyze-compile-build-pipeline-split","title":"Split compiler pipeline into analyze, compile, and build entrypoints","created_at":"2026-03-30","updated_at":"2026-03-30","tags":["compiler","pipeline","artifacts","build","analysis"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0025","file":"discussion/lessons/DSC-0011-compiler-analyze-compile-build-pipeline-split/LSN-0025-compiler-pipeline-entrypoints-and-result-boundaries.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30"}]}
+{"type":"discussion","id":"DSC-0012","status":"done","ticket":"studio-editor-document-vfs-boundary","title":"Definir um boundary de VFS documental para tree/view/open files no Code Editor do Studio","created_at":"2026-03-31","updated_at":"2026-03-31","tags":["studio","editor","workspace","vfs","filesystem","boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0027","file":"discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31"}]}
+{"type":"discussion","id":"DSC-0013","status":"done","ticket":"studio-editor-write-wave-supported-non-frontend-files","title":"Definir a wave inicial de edicao no Code Editor apenas para arquivos aceitos e nao relacionados ao FE","created_at":"2026-03-31","updated_at":"2026-04-02","tags":["studio","editor","workspace","write","read-only","vfs","frontend-boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0028","file":"discussion/lessons/DSC-0013-studio-editor-write-wave-supported-non-frontend-files/LSN-0028-controlled-editor-write-wave-and-read-only-frontend-semantic-phase.md","status":"done","created_at":"2026-04-02","updated_at":"2026-04-02"}]}
+{"type":"discussion","id":"DSC-0014","status":"done","ticket":"studio-frontend-owned-semantic-editor-presentation","title":"Definir ownership do schema visual semantico do editor por frontend","created_at":"2026-04-02","updated_at":"2026-04-02","tags":["studio","editor","frontend","presentation","semantic-highlighting","compiler","pbs"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0029","file":"discussion/lessons/DSC-0014-studio-frontend-owned-semantic-editor-presentation/LSN-0029-frontend-owned-semantic-presentation-descriptor-and-host-consumption.md","status":"done","created_at":"2026-04-02","updated_at":"2026-04-02"}]}
+{"type":"discussion","id":"DSC-0015","status":"done","ticket":"pbs-service-facade-reserved-metadata","title":"SDK Service Bodies Calling Builtin/Intrinsic Proxies as Ordinary PBS Code","created_at":"2026-04-03","updated_at":"2026-04-03","tags":["compiler","pbs","sdk","stdlib","lowering","service","intrinsic","sdk-interface"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0030","file":"discussion/lessons/DSC-0015-pbs-service-facade-reserved-metadata/LSN-0030-sdk-service-bodies-over-private-reserved-proxies.md","status":"done","created_at":"2026-04-03","updated_at":"2026-04-03"}]}
+{"type":"discussion","id":"DSC-0016","status":"done","ticket":"studio-editor-scope-guides-and-brace-anchoring","title":"Scope Guides do Code Editor com ancoragem exata em braces e destaque do escopo ativo","created_at":"2026-04-03","updated_at":"2026-04-06","tags":["studio","editor","scope-guides","braces","semantic-read","frontend-contract"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0034","file":"discussion/lessons/DSC-0016-studio-editor-scope-guides-and-brace-anchoring/LSN-0034-active-scope-gutter-and-frontend-owned-structural-anchors.md","status":"done","created_at":"2026-04-06","updated_at":"2026-04-06"}]}
+{"type":"discussion","id":"DSC-0017","status":"done","ticket":"studio-editor-inline-type-hints-for-let-bindings","title":"Inline Type Hints for Let Bindings in the Studio Editor","created_at":"2026-04-03","updated_at":"2026-04-06","tags":["studio","editor","inline-hints","inlay-hints","lsp","pbs","type-inference"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0035","file":"discussion/lessons/DSC-0017-studio-editor-inline-type-hints-for-let-bindings/LSN-0035-frontend-owned-inline-hints-with-decorative-inline-rendering.md","status":"done","created_at":"2026-04-06","updated_at":"2026-04-06"}]}
+{"type":"discussion","id":"DSC-0018","status":"done","ticket":"studio-project-local-studio-state-under-dot-studio","title":"Persist project-local Studio state under .studio","created_at":"2026-04-04","updated_at":"2026-04-04","tags":["studio","project-session","project-state","persistence","dot-studio","shell","layout","setup"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0031","file":"discussion/lessons/DSC-0018-studio-project-local-studio-state-under-dot-studio/LSN-0031-project-local-studio-state-and-lifecycle-safe-layout-restoration.md","status":"done","created_at":"2026-04-04","updated_at":"2026-04-04"}]}
+{"type":"discussion","id":"DSC-0019","status":"done","ticket":"studio-project-local-setup-separate-from-main-studio-state","title":"Separate project-local setup from the main Studio state under .studio","created_at":"2026-04-04","updated_at":"2026-04-04","tags":["studio","project-session","project-state","persistence","dot-studio","setup","boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0032","file":"discussion/lessons/DSC-0019-studio-project-local-setup-separate-from-main-studio-state/LSN-0032-separate-project-config-from-session-restoration-state.md","status":"done","created_at":"2026-04-04","updated_at":"2026-04-04"}]}
+{"type":"discussion","id":"DSC-0020","status":"done","ticket":"studio-editor-indentation-policy-and-project-setup","title":"Indentation Policy, Status-Bar Semantics, and Project-Local Editor Setup","created_at":"2026-04-04","updated_at":"2026-04-04","tags":["studio","editor","indentation","tabs","setup","dot-studio","configuration","ux"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0033","file":"discussion/lessons/DSC-0020-studio-editor-indentation-policy-and-project-setup/LSN-0033-setup-owned-indentation-policy-and-project-bootstrap-defaults.md","status":"done","created_at":"2026-04-04","updated_at":"2026-04-04"}]}
+{"type":"discussion","id":"DSC-0021","status":"done","ticket":"studio-frontend-editor-write-and-save-wave","title":"Enable Frontend Editing and Save in the Studio Code Editor","created_at":"2026-04-04","updated_at":"2026-04-06","tags":["studio","editor","frontend","write","save","vfs","lsp","pbs","access-policy"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0036","file":"discussion/lessons/DSC-0021-studio-frontend-editor-write-and-save-wave/LSN-0036-vfs-owned-frontend-edit-and-save-wave.md","status":"done","created_at":"2026-04-06","updated_at":"2026-04-06"}]}
+{"type":"discussion","id":"DSC-0022","status":"done","ticket":"studio-play-stop-cartridge-flow","title":"Wire the Studio Play/Stop button to shipper phase 1 cartridge preparation and runtime execution","created_at":"2026-04-06","updated_at":"2026-04-07","tags":["studio","play-stop","shipper","runtime","cartridge","shell"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0043","file":"discussion/lessons/DSC-0022-studio-play-stop-and-debugger-integration/LSN-0043-studio-play-stop-and-debugger-integration.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}
+{"type":"discussion","id":"DSC-0023","status":"done","ticket":"gradle-version-catalog-migration","title":"Move dependency version management to Version Catalog (TOML)","created_at":"2026-04-07","updated_at":"2026-04-07","tags":["gradle","buildSrc","dependency-management","version-catalog"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0037","file":"discussion/lessons/DSC-0023-gradle-version-catalog-migration/LSN-0037-gradle-version-catalog-adoption.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}

discussion/index.ndjson

@@ -1,5 +1,5 @@
-{"type":"meta","next_id":{"DSC":31,"AGD":34,"DEC":31,"PLN":62,"LSN":46,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":31,"AGD":34,"DEC":31,"PLN":62,"LSN":47,"CLSN":1}}
-{"type":"discussion","id":"DSC-0030","status":"in_progress","ticket":"studio-scene-pack-runtime-binary-contract","title":"Studio scene pack contract for runtime SCENE binary payload","created_at":"2026-04-24","updated_at":"2026-04-30","tags":["studio","packer","runtime","scene","asset-pack","binary-format","tiled"],"agendas":[{"id":"AGD-0032","file":"AGD-0032-studio-scene-pack-runtime-binary-contract.md","status":"accepted","created_at":"2026-04-24","updated_at":"2026-04-29"},{"id":"AGD-0033","file":"AGD-0033-revise-scene-bank-editorial-model-to-single-tmx-per-scene.md","status":"accepted","created_at":"2026-04-30","updated_at":"2026-04-30","supersedes":["AGD-0032"],"_reason":"Explicit user request on 2026-04-30 to revise the editorial direction after concluding the current Tiled integration model is wrong."}],"decisions":[{"id":"DEC-0029","file":"DEC-0029-studio-scene-pack-runtime-binary-contract.md","status":"accepted","created_at":"2026-04-29","updated_at":"2026-04-29","ref_agenda":"AGD-0032"},{"id":"DEC-0030","file":"DEC-0030-studio-native-scene-canonical-model-with-tiled-import-export.md","status":"accepted","created_at":"2026-04-30","updated_at":"2026-04-30","ref_agenda":"AGD-0033","supersedes":["DEC-0029"],"_scope":"Supersedes only the editorial-model portion of DEC-0029 while preserving its canonical publication boundary."}],"plans":[{"id":"PLN-0059","file":"PLN-0059-scene-pack-contract-spec-propagation.md","status":"done","created_at":"2026-04-29","updated_at":"2026-04-29","ref_decisions":["DEC-0029"]},{"id":"PLN-0060","file":"PLN-0060-scene-bank-studio-request-projection-and-acceptance.md","status":"done","created_at":"2026-04-29","updated_at":"2026-04-29","ref_decisions":["DEC-0029"]},{"id":"PLN-0061","file":"PLN-0061-scene-pack-request-materialization-and-packer-build.md","status":"done","created_at":"2026-04-29","updated_at":"2026-04-29","ref_decisions":["DEC-0029"]},{"id":"PLN-0062","file":"PLN-0062-scene-canonical-model-revision-spec-propagation.md","status":"done","created_at":"2026-04-30","updated_at":"2026-04-30","ref_decisions":["DEC-0030"]},{"id":"PLN-0063","file":"PLN-0063-studio-canonical-scene-entity-analysis-and-pack-request-projection.md","status":"done","created_at":"2026-04-30","updated_at":"2026-04-30","ref_decisions":["DEC-0030"]},{"id":"PLN-0064","file":"PLN-0064-tiled-scene-import-and-tileset-export-interoperability.md","status":"done","created_at":"2026-04-30","updated_at":"2026-04-30","ref_decisions":["DEC-0030"]}],"lessons":[]}
+{"type":"discussion","id":"DSC-0030","status":"done","ticket":"studio-scene-pack-runtime-binary-contract","title":"Studio scene pack contract for runtime SCENE binary payload","created_at":"2026-04-24","updated_at":"2026-05-01","tags":["studio","packer","runtime","scene","asset-pack","binary-format","tiled"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0046","file":"discussion/lessons/DSC-0030-studio-scene-pack-runtime-binary-contract/LSN-0046-canonical-scene-owns-editorial-truth-while-pack-stays-request-driven.md","status":"done","created_at":"2026-05-01","updated_at":"2026-05-01"}]}
 {"type":"discussion","id":"DSC-0029","status":"done","ticket":"studio-frame-composer-syscall-and-sprite-alignment","title":"Studio Alignment with Runtime FrameComposer Syscalls and Sprite Composition","created_at":"2026-04-18","updated_at":"2026-04-18","tags":["studio","compiler","pbs","stdlib","runtime-alignment","abi","syscall","frame-composer","sprites"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0041","file":"discussion/lessons/DSC-0029-studio-frame-composer-syscall-and-sprite-alignment/LSN-0041-composer-must-own-public-sprite-composition.md","status":"done","created_at":"2026-04-18","updated_at":"2026-04-18"}]}
 {"type":"discussion","id":"DSC-0028","status":"done","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-23","tags":["studio","assets","scene","tiled","parser","asset-type"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0028-studio-tiled-parser-assets-scene-asset-type/LSN-0045-asset-owned-scene-bank-and-tiled-xml-workflow.md","status":"done","created_at":"2026-04-23","updated_at":"2026-04-23"}]}
 {"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":[]}

discussion/lessons/DSC-0030-studio-scene-pack-runtime-binary-contract/LSN-0046-canonical-scene-owns-editorial-truth-while-pack-stays-request-driven.md

@@ -0,0 +1,60 @@
+---
+id: LSN-0046
+ticket: studio-scene-pack-runtime-binary-contract
+title: Canonical scene owns editorial truth while pack stays request-driven
+created: 2026-05-01
+tags: [studio, packer, runtime, scene, tiled, import-export]
+---
+
+## Context
+
+`Scene Bank` needed a stable path from Studio authoring to runtime `SCENE` bytes without letting editor-specific files become the product contract. The first accepted direction closed the `studio -> packer -> runtime` boundary correctly, but the initial editorial implementation still treated `TMX` as if it were the unit of truth. That created friction because the supported external editor (`Tiled`) was being modeled around the wrong ownership boundary.
+
+The final state of `DSC-0030` keeps the publication contract from `DEC-0029` and replaces only the mistaken editorial model through `DEC-0030`.
+
+## Key Decisions
+
+### Request-driven publication boundary
+
+**What:** Publication of `Scene Bank` assets uses a canonical `studio -> packer` request that packer compiles directly into runtime `SCENE` payload bytes.
+
+**Why:** This keeps `prometeu-packer` isolated from `TMX`, `TSX`, and any future editor-specific format. It also preserves runtime ownership of `glyph_asset_id -> slot` resolution instead of leaking runtime operational details back into Studio.
+
+**Trade-offs:** Studio must project editorial state into a separate publication representation, so the system carries more than one representation of the same scene on purpose.
+
+### Studio-owned canonical scene entity
+
+**What:** The primary editorial source of truth is a Studio-native canonical scene entity, not `TMX`, not `TSX`, and not the pack request itself.
+
+**Why:** The external editor format should remain replaceable. If `TMX` becomes the canonical model, Studio evolution gets trapped by Tiled semantics and every future interoperability choice becomes harder.
+
+**Trade-offs:** Studio now owns more editorial modeling and validation logic internally instead of delegating shape decisions to external files.
+
+### Tiled as compatibility, not authority
+
+**What:** `TMX (Tiled)` scene import/export and `TSX (Tiled)` glyph export are compatibility workflows around the canonical scene entity.
+
+**Why:** This preserves interoperability with the supported wave-1 tooling while making it explicit that external files are adapters, not authoritative persistence.
+
+**Trade-offs:** Import must reject unsupported structural mutations instead of silently absorbing arbitrary external edits.
+
+## Patterns and Algorithms
+
+- Keep three representations distinct: Studio canonical scene entity, canonical pack request, and runtime `SCENE` bytes.
+- Validate canonical scene integrity in `Analyse` and/or `Pack`, not by treating editor files as the lifecycle owner.
+- Use import compatibility checks before mutating canonical state, and fail without partial rewrite on unsupported structural divergence.
+- Keep packer request-driven so tests can prove scene packing succeeds without parsing `TMX` or `TSX`.
+
+## Pitfalls
+
+- Do not let a supported editor file become a hidden canonical model just because it is easy to serialize.
+- Do not collapse the canonical Studio scene entity into the pack request; publication shape and editorial shape serve different purposes.
+- Do not reintroduce `TMX per layer` or any equivalent workflow that makes scene cohesion secondary.
+- Do not relax the packer boundary by teaching packer to read editor-native files directly.
+
+## Takeaways
+
+- Scene editorial truth belongs to Studio.
+- Scene publication truth belongs to the canonical request.
+- Runtime operational truth belongs to the runtime `SCENE` contract and slot resolution logic.
+- Import/export support should stay replaceable as long as it materializes the same request boundary.

discussion/workflow/agendas/AGD-0032-studio-scene-pack-runtime-binary-contract.md

@@ -1,247 +0,0 @@
----
-id: AGD-0032
-ticket: studio-scene-pack-runtime-binary-contract
-title: Studio scene pack contract for runtime SCENE binary payload
-status: accepted
-created: 2026-04-24
-resolved: 2026-04-27
-decision:
-tags: [studio, packer, runtime, scene, asset-pack, binary-format, tiled]
----
-
-## Pain
-
-O runtime ja possui um payload binario `SCENE` versionado e com decoder real, mas o Studio/paker ainda para em `TMX`/`TSX` e nao fecha a publicacao desse asset para `assets.pa`.
-
-Isso deixa um gap claro entre:
-
-- authoring/editorial workflow no dominio `studio`;
-- materializacao e packing no dominio `packer`;
-- contrato efetivamente consumido no dominio `runtime`.
-
-Dominio owner desta agenda: `studio`.
-Boundary explicito: `studio -> packer -> runtime`.
-
-## Context
-
-- O runtime define `SCENE` v1 com magic `SCNE`, version `1`, `4` layers fixas, metadata vazio no header do asset table e payload binario por layer.
-- O decoder de `SCENE` ja valida:
-  version;
-  layer count;
-  tile size;
-  parallax factor;
-  `width * height == tile_count`;
-  `decoded_size`;
-  ausencia de trailing bytes.
-- O runtime tambem ja instala `SceneBank` em scene slots, mas a dependencia de glyph por layer agora eh `glyph_asset_id`, nao mais `glyph_bank_id`.
-- O runtime resolve `glyph_asset_id -> glyph slot` internamente durante `bind_scene` e `render_frame`, mantendo a alocacao de slot como concern operacional de runtime.
-- O Studio hoje trata `Scene Bank` como asset owner de authoring/validation, com `scene-bank.studio.json`, `TMX` por layer e `TSX` gerado por glyph bank especializado em tileset.
-- A decision consolidada em `DSC-0028` fechou o modelo wave 1 de authoring em `TMX`/`TSX`, mas deixou explicitamente o scene packing runtime como concern posterior.
-- O packer atual reconhece `SCENE_BANK` como familia e `SCENE/tilemap_v1` como output format, mas ainda nao faz walk/materialization de scene e falha deliberadamente no pack execution para familias fora de `GLYPH_BANK`.
-
-Findings tecnicos relevantes desta agenda:
-
-1. O formato binario ja existe no runtime e nao esta “a decidir”.
-2. O packer atual nao produz payload `SCENE`.
-3. O maior buraco contratual hoje nao eh o layout binario em si, mas a traducao editorial de `TMX`/`TSX` para os campos exigidos pelo runtime.
-4. O campo mais sensivel continua sendo a dependencia de glyph por layer, mas o runtime atual passou a usar `glyph_asset_id` no `SCENE` e resolver `asset_id -> slot` internamente.
-5. Isso remove do Studio/paker a necessidade de conhecer previamente o glyph slot operacional do runtime para serializar a scene.
-
-## Open Questions
-
-- [x] Quem deve ser o owner da compilacao `TMX`/`TSX -> SCENE`: `prometeu-packer` embutido no Studio, uma camada editorial do Studio, ou outro componente?
-  Resposta atual da discussao:
-  o `Asset Workspace` gera e usa `TMX`/`TSX` apenas como support/editorial surfaces;
-  esses formatos nao devem ser empurrados para o `prometeu-packer`;
-  o `prometeu-packer` deve receber um protocolo proprio de requisicao;
-  o `Scene Bank` no Studio deve validar e extrair, no passo de `Accept`, os dados necessarios dos artefatos editoriais para esse request.
-- [x] Qual deve ser o contrato canonico da dependencia de glyph por layer?
-  Resposta validada contra o runtime atual:
-  o payload `SCENE` deve carregar `glyph_asset_id`;
-  a resolucao `asset_id -> slot` pertence ao runtime;
-  Studio e packer nao precisam serializar slot de glyph no contrato da scene.
-- [x] O `Scene Bank` deve persistir `glyph_asset_id` explicitamente no metadata/request do Studio ou derivar isso sempre a partir do asset referenciado na layer?
-  Resposta atual da discussao:
-  `glyph_asset_id` eh derivado do tileset/glyph asset selecionado no form da layer, mantendo uma unica fonte da verdade.
-- [x] Onde devem viver os `parallax_factor` por layer, que o runtime exige mas o metadata atual do Studio nao modela?
-  Resposta atual da discussao:
-  `parallax_factor` deve ser adicionado ao form da layer no Studio.
-- [x] De onde vem o `palette_id` por layer/tile no request atual?
-  Resposta atual da discussao:
-  `palette_id` ainda nao existe no workflow atual e deve ser adicionado ao form da layer no Studio, ou em surface editorial equivalente no mesmo nivel.
-- [x] Como o workflow editorial indica se uma layer entra ou nao na publicacao?
-  Resposta atual da discussao:
-  o checkbox existente no form da layer indica se a layer esta ativa/sera usada.
-- [x] Qual eh a regra oficial de traducao de tiles do Tiled para records do payload runtime:
-  `gid` base;
-  flip flags;
-  `glyph_id`;
-  `palette_id`?
-  Resposta atual da discussao:
-  cada tile eh mapeado pelo `TSX`, e o `TSX` aponta para o glyph asset;
-  `flip` e `palette_id` por tile podem vir como properties no `TMX`, por serem dados do tile especifico;
-  `glyph_id` ja existe como property no `TSX`.
-- [x] O wave 1 continua estritamente limitado a um `TSX` por `TMX`/layer tambem no scene pack runtime, ou precisamos abrir espaco para multi-tileset antes de fechar o contrato?
-  Resposta atual da discussao:
-  sim, wave 1 continua com exatamente `1 TSX` por `TMX`/layer.
-- [x] A aceitacao no Studio deve ser gate obrigatorio para publicar `SCENE` em pack, ou apenas um estado editorial recomendado?
-  Resposta atual da discussao:
-  o criterio continua sendo o usual do workflow: nenhum diagnostic error bloqueante.
-- [x] O `SCENE/tilemap_v1` no manifest representa o payload binario runtime final, ou ainda esta sendo usado ambiguamente para o estado editorial baseado em `TMX`?
-  Resposta atual da discussao:
-  vamos manter `SCENE/tilemap_v1` por enquanto;
-  o runtime nao exige mudanca desse nome neste momento.
-- [x] Qual deve ser o shape exato do request `studio -> packer`?
-  Resposta atual da discussao:
-  o request deve ser construido backwards a partir dos dados do payload binario `SCENE`, como um data class o mais proximo possivel do binario final.
-  Shape atual assentado na agenda:
-  ```text
-  ScenePackRequest
-  - version: int
-  - layers: [ScenePackLayerRequest; 4]
-
-  ScenePackLayerRequest
-  - active: bool
-  - glyph_asset_id: int
-  - tile_size: int
-  - parallax_factor_x: float
-  - parallax_factor_y: float
-  - width: int
-  - height: int
-  - tiles: List<ScenePackTileRequest>
-
-  ScenePackTileRequest
-  - active: bool
-  - glyph_id: int
-  - palette_id: int
-  - flip_x: bool
-  - flip_y: bool
-  ```
-  Observacoes do shape assentado:
-  `request -> SCENE` deve ser quase isomorfico;
-  `tile_count` pode ser derivado de `width * height`;
-  campos reservados do binario nao precisam existir no request.
-
-## Options
-
-### Option A - Studio Accepts Tiled and Emits a Packer-Owned Scene Request
-
-- **Approach:** manter o Studio como owner de authoring, validation e acceptance de `TMX`/`TSX`, e fazer o `Scene Bank` aceito extrair um request proprio e estavel para o `prometeu-packer`; o packer compila esse request para o payload binario `SCENE` sem conhecer `TMX`/`TSX`.
-- **Pro:** preserva `TMX`/`TSX` como concern editorial do Studio e evita contaminar o packer com detalhes de tooling externo.
-- **Con:** exige fechar um boundary formal novo entre Studio e packer, incluindo o schema desse request.
-- **Maintainability:** boa, desde que o contrato editorial/runtime fique explicito e versionado.
-
-### Option B - Add a Studio-Owned Intermediate Scene Representation First
-
-- **Approach:** antes de empacotar, introduzir um modelo normalizado intermediario no Studio ou em shared tooling, e so depois converter esse modelo para o payload binario runtime.
-- **Pro:** pode simplificar validacao e testes sem depender diretamente de parsing de `TMX` no packer.
-- **Con:** reabre o risco de criar uma segunda surface de scene alem de `TMX`, contrariando a direcao recente de evitar schema paralelo cedo demais.
-- **Maintainability:** media; melhora isolamento interno, mas adiciona outra camada contratual para manter.
-
-### Option C - Make Packer Parse TMX/TSX Directly
-
-- **Approach:** fazer o `prometeu-packer` ler `TMX`/`TSX` diretamente e produzir o payload runtime a partir dessas surfaces editoriais.
-- **Pro:** reduz o numero aparente de etapas entre authoring e pack final.
-- **Con:** acopla o packer a uma surface editorial do Studio e ao tooling externo, o que contraria a direcao explicitada nesta discussao.
-- **Maintainability:** fraca; qualquer evolucao do authoring/editorial tende a vazar para o contrato operacional do packer.
-
-## Discussion
-
-O estado atual sugere que o layout binario do runtime ja esta suficientemente maduro para servir como contrato de destino. A discussao principal nao deveria voltar para “qual eh o formato binario da scene”, e sim para “como o Studio/paker chegam nele de forma disciplinada”.
-
-Ha uma restricao importante aqui: a decision anterior sobre `Scene Bank` em Assets e `TMX`/`TSX` como surfaces wave 1 continua valida. Portanto esta agenda nao deve reinterpretar `DSC-0028` como se o Studio precisasse ganhar um scene workspace, um editor pesado ou um schema proprietario paralelo por conveniencia.
-
-Direcao ja explicitada nesta thread:
-
-- `TMX` e `TSX` ficam confinados ao dominio editorial do Studio;
-- o `Asset Workspace` deve conseguir validar e extrair do estado aceito os dados relevantes para pack;
-- o `prometeu-packer` nao deve conhecer Tiled nem depender de `TMX`/`TSX`;
-- o boundary Studio -> packer deve ser um protocolo proprio, estavel e independente das surfaces editoriais.
-
-Os pontos mais arriscados no boundary sao:
-
-1. `glyph_asset_id`:
-   o runtime agora aceita identidade estavel de asset na scene e resolve `asset_id -> slot` internamente; a discussao ja convergiu que esse valor eh derivado do tileset/glyph asset selecionado no form da layer.
-2. `parallax_factor`:
-   o runtime exige esse campo por layer; a direcao atual eh adiciona-lo ao form da layer, no mesmo nivel editorial de configuracoes como dimensao do mapa.
-3. traducao de tiles:
-   a direcao atual ja convergiu que cada tile eh resolvido pelo `TSX`, com `flip` e `palette_id` podendo vir do `TMX`; o request do packer deve preservar esses campos de forma quase isomorfica ao record runtime.
-4. `palette_id`:
-   a direcao atual eh adiciona-lo ao form da layer, com possibilidade de override por tile via properties editoriais no `TMX`.
-5. gate editorial:
-   o checkbox de layer ativa ja cobre o uso editorial da layer, e o gate atual para publicar continua sendo ausencia de diagnostic error bloqueante.
-## Settled So Far
-
-Os pontos abaixo ficam cravados nesta agenda como direcao atual da discussao:
-
-1. `TMX` e `TSX` permanecem surfaces editoriais do Studio e nao entram no protocolo operacional do packer.
-2. `TMX` e `TSX` sao surfaces editoriais suportadas em wave 1, mas nao sao a surface canonica do contrato de publicacao e permanecem substituiveis por outros editores suportados no futuro.
-3. O `Asset Workspace` deve extrair, no passo de `Accept`, um request proprio para o `prometeu-packer`.
-4. O payload runtime `SCENE` carrega `glyph_asset_id`, e a resolucao `asset_id -> slot` pertence ao runtime.
-5. `glyph_asset_id` eh derivado do tileset/glyph asset selecionado no form da layer.
-6. `parallax_factor` deve existir no form da layer.
-7. `palette_id` deve existir no form da layer, ou em surface editorial equivalente no mesmo nivel.
-8. O checkbox da layer define se ela esta ativa/sera usada.
-9. Cada tile eh resolvido via `TSX`; `glyph_id` ja existe como property no `TSX`.
-10. `flip` e `palette_id` por tile podem vir como properties no `TMX`.
-11. Wave 1 continua com exatamente `1 TSX` por `TMX`/layer.
-12. O gate atual para publicar continua sendo ausencia de diagnostic error bloqueante.
-13. O request `studio -> packer` deve ser derivado backwards do payload binario e `request -> SCENE` deve ser o mais direto possivel.
-14. O shape atual assentado do request e:
-    `ScenePackRequest(version, layers[4])`;
-    `ScenePackLayerRequest(active, glyph_asset_id, tile_size, parallax_factor_x, parallax_factor_y, width, height, tiles)`;
-    `ScenePackTileRequest(active, glyph_id, palette_id, flip_x, flip_y)`.
-15. O manifest permanece com `SCENE/tilemap_v1` por enquanto.
-
-## Recommendation
-
-Seguir com a `Option A`.
-
-Direcao recomendada:
-
-1. manter `TMX`/`TSX` como surfaces editoriais wave 1 no dominio `studio`;
-2. registrar explicitamente que `TMX`/`TSX` nao sao a surface canonica do contrato e podem coexistir no futuro com outros editores suportados, desde que materializem o mesmo request canonico;
-3. fechar uma decision nova para o boundary `studio/packer/runtime` do `Scene Bank`;
-4. fazer o `Asset Workspace` aceitar e extrair do estado editorial um request proprio para o packer;
-5. fazer o `prometeu-packer` ser owner apenas da compilacao desse request para o payload binario `SCENE`;
-6. explicitar na decision:
-   modelagem da dependencia `glyph_asset_id`;
-   modelagem de `parallax_factor`;
-   modelagem de `palette_id`;
-   semantica da layer ativa no request;
-   gate baseado em diagnostics bloqueantes;
-   formato do request `studio -> packer`, derivado backwards do payload binario;
-   semantica oficial de `SCENE/tilemap_v1`;
-   carater nao-canonico e substituivel das surfaces editoriais suportadas.
-
-Essa direcao reaproveita o que ja existe, mantem o packer livre das ferramentas editoriais do Studio e concentra a publicacao runtime no subsistema que ja monta `assets.pa`.
-
-## Next Step Suggestion
-
-Converter esta agenda em uma decision focada no contrato de compilacao/publicacao de `Scene Bank`, cobrindo:
-
-1. ownership por dominio;
-2. formato do request `studio -> packer`, backwards a partir do payload binario;
-3. mapping editorial -> request -> runtime, com `request -> SCENE` o mais direto possivel;
-4. modelagem e validacao de `glyph_asset_id` por layer;
-5. gating de diagnostics para pack;
-6. propagation targets em `prometeu-packer`, `prometeu-studio` e specs relevantes.
-
-## Resolution
-
-Agenda aceita.
-
-Direcao consolidada:
-
-1. `TMX`/`TSX` permanecem estritamente editoriais no dominio `studio`.
-2. `TMX`/`TSX` sao surfaces editoriais suportadas em wave 1, mas nao sao a definicao canonica do asset nem do contrato de publicacao.
-3. Outros editores suportados no futuro podem substituir ou coexistir com `TMX`/`TSX`, desde que materializem o mesmo request canonico `studio -> packer` e passem pelas mesmas regras de validacao e `Accept`.
-4. O `Scene Bank` aceito deve extrair um request proprio e estavel para o `prometeu-packer`.
-5. O request `studio -> packer` deve ser derivado backwards do payload binario `SCENE` e `request -> SCENE` deve ser o mais direto possivel.
-6. O contrato runtime de dependencia de glyph por layer usa `glyph_asset_id`, com resolucao `asset_id -> slot` pertencendo ao runtime.
-7. O workflow editorial do Studio deve prover `glyph_asset_id` derivado do tileset selecionado, `parallax_factor`, `palette_id`, estado ativo da layer e a traducao por tile a partir de `TSX`/`TMX`.
-8. Wave 1 permanece com exatamente `1 TSX` por `TMX`/layer.
-9. O gate para publicacao continua sendo ausencia de diagnostic error bloqueante.
-10. O manifest permanece com `SCENE/tilemap_v1` por enquanto.
-
-Proximo passo sugerido: converter esta agenda em uma `decision` normativa para o boundary `studio -> packer -> runtime`.

discussion/workflow/agendas/AGD-0033-revise-scene-bank-editorial-model-to-single-tmx-per-scene.md

@@ -1,121 +0,0 @@
----
-id: AGD-0033
-ticket: studio-scene-pack-runtime-binary-contract
-title: Revise Scene Bank editorial model to Studio-native scene with TMX import-export
-status: accepted
-created: 2026-04-30
-resolved: 2026-04-30
-decision: DEC-0030
-tags: [studio, packer, runtime, scene, asset-pack, tiled, revision]
----
-
-## Pain
-
-A direcao aceita em `DEC-0029` e implementada por `PLN-0059` a `PLN-0061` tomou um atalho editorial errado: modelamos `1 layer -> 1 TMX`, com validacao e `Accept` por layer, quando o editor suportado (`Tiled`) opera naturalmente com `1 scene -> 1 TMX` contendo multiplos layers.
-
-Isso gerou uma friccao estrutural:
-
-- o fluxo atual separa artificialmente layers que pertencem ao mesmo mapa;
-- o `Accept` por layer conflita com a necessidade de publicar uma scene coesa;
-- o modelo atual esconde um erro conceitual ao tratar `TMX` como surface por layer, em vez de surface por scene;
-- a integracao editorial ficou mais fraca justamente no editor que estamos suportando em wave 1.
-
-Dominio owner desta agenda: `studio`.
-Boundary explicito: `studio -> packer -> runtime`.
-
-## Context
-
-- `DEC-0029` fechou corretamente que `TMX`/`TSX` sao surfaces editoriais suportadas, nao canonicas, e que o contrato normativo de publicacao continua sendo o request `studio -> packer -> SCENE`.
-- O erro nao esta nesse boundary canonico; o erro esta no shape editorial escolhido para a integracao com Tiled.
-- A implementacao atual assumiu:
-  - `1 layer -> 1 TMX`;
-  - `1 TMX -> 1 TSX`;
-  - geracao, validacao e `Accept` com foco em layer.
-- O problema observado no `tiled2` reforca essa distorcao: o fluxo de workflow passou a tentar aceitar layer isoladamente, quando o valor editorial real esta na scene inteira.
-- O Tiled comporta um `TMX` com multiplos layers; cada layer pode ter seu proprio tileset referenciado no mapa, e o authoring natural da scene acontece nesse documento unico.
-- O runtime continua nao dependendo de `TMX`; ele continua dependendo apenas do request canonico aceito e do payload binario `SCENE`.
-
-## Open Questions
-
-- [x] O modelo wave 1 deve ser formalmente revisado para `1 scene -> 1 TMX` com multiplos layers?
-  Resposta: parcialmente. Essa direcao corrige o erro imediato de `TMX por layer`, mas a escolha final nao eh promover `TMX unico` a surface principal. A direcao escolhida eh um modelo nativo de scene no Studio, com `TMX` tratado como formato suportado de import/export.
-- [x] Devemos abandonar completamente `validate layer` e `accept layer`, deixando apenas `generate scene`, `validate scene` e `accept scene`?
-  Resposta: sim, e mais do que isso: no modelo escolhido esses verbos deixam de ser a surface principal do workflow editorial. O Studio passa a operar com `import` e `export` via wizard para formatos suportados, com `Tiled` como primeira opcao. A validacao ocorre sobre o formato canonico do asset de scene no `Analyse` ou no `Pack`, nao sobre o formato externo.
-- [x] Como cada layer da scene referencia seu tileset no editor suportado?
-  Resposta: no caminho de compatibilidade com Tiled, o `TMX` pode carregar multiplos `TSX`, e a scene pode usar ate quatro tilesets distintos. Isso descreve a compatibilidade editorial do import/export, nao o modelo canonico interno do Studio.
-- [x] Como representar layers com tamanhos independentes dentro da scene?
-  Resposta: o modelo da scene deve aceitar layers com tamanho proprio. No caminho Tiled, mapas infinitos continuam suportados como concern editorial. Camera boundaries ficam para iteracao posterior.
-- [x] O `scene-bank.studio.json` deve continuar carregando `width`/`height` por layer, ou passar a carregar apenas metadata editorial complementar e bindings?
-  Resposta: o asset de scene deve manter uma entidade canonica propria, distinta do request de pack. `scene-bank.studio.json` pode continuar existindo como persistencia editorial dessa entidade, com metadata como `width` e `height` por layer quando fizer sentido, mas sem se confundir com o request `studio -> packer`.
-- [x] Como o request canonico deve ser projetado sem reintroduzir dependencia canonica em formato editorial?
-  Resposta: o request `studio -> packer` continua existindo, mas como projeção derivada da entidade canonica do asset de scene, nao como a propria entidade editorial. `TMX` entra apenas como formato suportado de importacao/exportacao; `import` atualiza a entidade canonica a partir do `TMX`, e `export` sobrescreve o `TMX` a partir da entidade canonica.
-- [x] O `import` de `TMX` deve aceitar qualquer alteracao editorial feita externamente no Tiled?
-  Resposta: nao. O `import` deve aplicar validacoes minimas de compatibilidade antes de alterar a entidade canonica. Mudancas como adicao de novos layers, adicao de novos tilesets, ou alteracao estrutural inesperada de layers/tilesets podem invalidar o `TMX` para importacao. Quando isso ocorrer, o Studio deve recusar o `import` e emitir logs/diagnostics claros de falha.
-- [x] Como o fluxo de `TSX` deve se comportar para glyph tilesets especializados?
-  Resposta: o glyph tileset pode gerar `TSX`, e isso passa a ser tratado como `export` para formato suportado `TSX (Tiled)`. O `export` sobrescreve o arquivo existente ou cria um novo, seguindo a mesma filosofia do `TMX`.
-- [x] Quais partes de `DEC-0029` permanecem validas e quais precisam ser substituidas explicitamente?
-  Resposta: permanece valida a parte que fixa `TMX`/`TSX` como surfaces editoriais nao canonicas e o request `studio -> packer` como contrato normativo. Deve ser substituida explicitamente a parte editorial implementada como `TMX por layer` e o workflow `generate / validate / accept` por layer.
-
-## Options
-
-### Option A - Keep per-layer TMX and patch workflow
-- **Approach:** Manter `1 layer -> 1 TMX`, corrigir o bug de workflow de `Accept`, e ajustar a UX ao redor disso.
-- **Pro:** Menor custo imediato sobre a implementacao existente.
-- **Con:** Preserva o erro de modelagem editorial e continua desalinhado com o uso natural do Tiled.
-- **Maintainability:** Fraca. Corrige sintomas sem corrigir o modelo.
-
-### Option B - Revise to single TMX per scene and scene-level workflow
-- **Approach:** Revisar a decision para `1 scene -> 1 TMX`, com multiplos layers editoriais no mesmo mapa, e mover `generate / validate / accept` para o nivel da scene.
-- **Pro:** Alinha o Studio ao modelo real do Tiled e fecha um boundary editorial mais coerente.
-- **Con:** Exige revisao normativa, refatoracao de specs e reimplementacao parcial do fluxo entregue em `PLN-0060` e `PLN-0061`.
-- **Maintainability:** Forte. Remove a distorcao estrutural e preserva o contrato canonico correto.
-
-### Option C - Introduce a Studio-native scene model now and demote TMX to import/export
-- **Approach:** Parar de tratar `TMX` como surface principal e assumir imediatamente um modelo proprio do Studio, usando Tiled apenas como compatibilidade.
-- **Pro:** Resolve de vez o acoplamento editorial ao Tiled.
-- **Con:** Exige refatoracao mais profunda agora, incluindo suporte nativo de scene, import/export, migracao editorial e revisao dos plans ja executados.
-- **Maintainability:** Melhor opcao de longo prazo. Remove o erro estrutural na raiz e abre espaco para multiplos editores suportados.
-
-Escolha fechada na agenda: `Option C`.
-
-## Discussion
-
-A correção necessária parece ser de direcao, nao apenas de bug.
-
-O problema central nao eh que o request canonico exista ou que o packer compile `SCENE`; isso continua correto. O problema eh que o lado editorial foi fatiado na unidade errada. Ao quebrar scene em `TMX` por layer, o Studio passou a operar contra a gravidade do editor suportado e abriu espaco para workflow incoerente.
-
-A agenda convergiu para um passo adicional: mesmo o modelo `TMX unico por scene` ainda seria uma otimizacao em torno do Tiled, nao uma surface editorial suficiente para o Studio no medio prazo. A escolha da `Option C` fecha uma direcao mais limpa:
-
-- preservar o boundary canonico `studio -> packer -> runtime`;
-- introduzir um modelo nativo de scene no Studio como surface principal;
-- tratar `TMX`/`TSX` como formatos suportados de importacao/exportacao e compatibilidade;
-- substituir `generate / validate / accept` por um workflow de `import / export` guiado por wizard para formatos suportados;
-- aplicar validacoes minimas de compatibilidade no `import`, com recusa e logs claros quando o artefato externo divergir estruturalmente do que o Studio suporta;
-- validar a entidade canonica da scene no `Analyse` ou no `Pack`;
-- manter o request canonico de pack como projeção derivada da entidade canonica da scene, e nao como espelho bruto de qualquer formato externo.
-
-Isso substitui explicitamente a parte editorial errada de `DEC-0029`, sem reabrir a parte do contrato canonico de publicacao que continuou correta.
-
-## Resolution
-
-Recomendacao final da agenda:
-
-- revisar `DEC-0029` para abandonar o modelo `TMX por layer`;
-- nao promover `TMX unico por scene` a surface principal do produto;
-- adotar um modelo nativo de scene no Studio como owner editorial principal;
-- tratar `TMX`/`TSX` como formatos suportados de import/export e compatibilidade;
-- substituir o workflow de `generate / validate / accept` por `import / export` com wizard;
-- exigir validacoes minimas no `import` de `TMX`, com falha explicita quando houver divergencia estrutural nao suportada, como novos layers, novos tilesets, ou alteracoes estruturais equivalentes;
-- tratar a geracao de `TSX` por glyph tileset como `export` para formato suportado `TSX (Tiled)`, com sobrescrita ou criacao do arquivo de destino;
-- validar a entidade canonica do asset de scene no `Analyse` ou no `Pack`;
-- preservar a separacao entre:
-  - entidade canonica do asset de scene no Studio;
-  - request `studio -> packer`;
-  - payload binario `SCENE` de runtime;
-- preservar como normativa a parte de `DEC-0029` que fixa `TMX`/`TSX` como surfaces editoriais nao canonicas e o request `studio -> packer` como contrato de publicacao.
-
-Proximo passo sugerido:
-
-- emitir uma nova decision de revisao, substituindo explicitamente a porcao editorial de `DEC-0029`;
-- derivar novos plans para `specs`, `studio` e `packer`, com migracao do fluxo atual;
-- tratar a implementacao entregue em `PLN-0060` e `PLN-0061` como baseline a ser revisada, nao como forma final do modelo editorial.

discussion/workflow/decisions/DEC-0029-studio-scene-pack-runtime-binary-contract.md

@@ -1,123 +0,0 @@
----
-id: DEC-0029
-ticket: studio-scene-pack-runtime-binary-contract
-title: Studio scene pack contract for runtime SCENE binary payload
-status: accepted
-created: 2026-04-29
-accepted: 2026-04-29
-agenda: AGD-0032
-plans:
-  - PLN-0059
-  - PLN-0060
-  - PLN-0061
-tags:
-  - studio
-  - packer
-  - runtime
-  - scene
-  - asset-pack
-  - binary-format
-  - tiled
----
-
-## Decision
-
-The canonical publication contract for `Scene Bank` assets SHALL be the `studio -> packer` scene-pack request and its direct compilation into runtime `SCENE` payload bytes.
-
-`TMX` and `TSX` SHALL remain supported editorial surfaces for wave 1 inside the `studio` domain, but they MUST NOT define the normative publication contract, the runtime asset shape, or the packer boundary.
-
-The system MAY support additional scene editors in the future. Any supported editor MUST materialize the same canonical scene-pack request and MUST pass the same validation and `Accept` gating rules before publication.
-
-`prometeu-packer` SHALL compile only the canonical scene-pack request into the runtime `SCENE` payload. It MUST NOT parse `TMX`, `TSX`, or any other editor-specific surface directly.
-
-The runtime `SCENE` dependency contract SHALL use `glyph_asset_id` per layer. Resolution from `glyph_asset_id` to runtime glyph slot SHALL remain a runtime concern and MUST NOT be serialized by Studio or packer as a pre-resolved slot.
-
-## Rationale
-
-This decision preserves the already accepted wave-1 editorial direction from `DSC-0028` while preventing Tiled from becoming the canonical asset model by accident.
-
-The binary `SCENE` runtime payload already exists and is the true sink of the pipeline. The missing architectural piece is therefore not a new scene schema, but a stable domain boundary that lets Studio accept editorial state and lets packer compile a runtime-owned request without absorbing external-tool concerns.
-
-Treating `TMX` and `TSX` as supported but non-canonical keeps the current workflow viable, while leaving the door open for future integrated editors or multiple editors without reopening the packer or runtime contract.
-
-## Technical Specification
-
-### 1. Domain Ownership
-
-- `studio` SHALL own editorial scene authoring, validation, diagnostics, and `Accept`.
-- `packer` SHALL own compilation of the canonical request into binary `SCENE`.
-- `runtime` SHALL own decoding, binding, and operational slot resolution for glyph dependencies.
-
-### 2. Supported Editorial Surfaces
-
-- Wave 1 SHALL support `TMX` and `TSX` as editorial surfaces in `studio`.
-- These surfaces MUST be treated as replaceable editor integrations, not as canonical publication artifacts.
-- Future editors MAY replace or coexist with Tiled-backed surfaces if they emit the same canonical request and satisfy the same validation semantics.
-
-### 3. Canonical `studio -> packer` Request
-
-The canonical request SHALL be defined as:
-
-```text
-ScenePackRequest
-- version: int
-- layers: [ScenePackLayerRequest; 4]
-
-ScenePackLayerRequest
-- active: bool
-- glyph_asset_id: int
-- tile_size: int
-- parallax_factor_x: float
-- parallax_factor_y: float
-- width: int
-- height: int
-- tiles: List<ScenePackTileRequest>
-
-ScenePackTileRequest
-- active: bool
-- glyph_id: int
-- palette_id: int
-- flip_x: bool
-- flip_y: bool
-```
-
-Normative rules:
-
-- `request -> SCENE` SHALL be as direct as possible.
-- `tile_count` SHALL be derived from `width * height`.
-- Binary reserved fields MUST NOT be mirrored into the request unless they gain explicit editorial meaning.
-- `layers` SHALL always materialize exactly `4` entries in wave 1.
-
-### 4. Layer and Tile Semantics
-
-- `glyph_asset_id` SHALL be derived from the glyph asset/tileset selected for the layer in Studio.
-- `parallax_factor_x` and `parallax_factor_y` SHALL be modeled as layer-owned editorial fields in Studio.
-- `palette_id` SHALL be modeled with a layer-level editorial default in Studio, with optional per-tile override when supported by the editorial surface.
-- `active` at layer scope SHALL indicate whether the layer participates in publication output.
-- `active` at tile scope SHALL indicate whether the tile contributes an active tile record to the published scene payload.
-- Wave 1 SHALL remain limited to exactly `1 TSX` per `TMX` per layer.
-
-### 5. Validation and Acceptance
-
-- Publication MUST be gated by absence of blocking diagnostic errors.
-- The `Accept` step in Studio SHALL be the moment where supported editorial state is validated and projected into the canonical request.
-- Studio MUST NOT silently auto-accept external editor mutations.
-
-### 6. Manifest and Runtime Projection
-
-- The manifest output format SHALL remain `SCENE/tilemap_v1` for this wave.
-- The runtime payload SHALL carry `glyph_asset_id` per layer.
-- Runtime slot allocation and `asset_id -> slot` resolution MUST remain runtime-internal behavior.
-
-## Constraints
-
-- This decision MUST NOT be interpreted as introducing a dedicated scene workspace.
-- This decision MUST NOT be interpreted as allowing packer to parse editor-specific formats directly.
-- This decision MUST NOT be interpreted as making Tiled temporary or deprecated; it is supported, but non-canonical.
-- This decision does not reopen wave-1 limits around single-tileset-per-layer authoring.
-- Any future change to the canonical request or runtime projection SHALL require explicit decision review.
-
-## Revision Log
-
-- 2026-04-29: Initial draft from AGD-0032.
-- 2026-04-29: Accepted and decomposed into implementation plans PLN-0059, PLN-0060, and PLN-0061.

discussion/workflow/decisions/DEC-0030-studio-native-scene-canonical-model-with-tiled-import-export.md

@@ -1,147 +0,0 @@
----
-id: DEC-0030
-ticket: studio-scene-pack-runtime-binary-contract
-title: Studio-native scene canonical model with Tiled import-export compatibility
-status: accepted
-created: 2026-04-30
-accepted: 2026-04-30
-agenda: AGD-0033
-plans:
-  - PLN-0062
-  - PLN-0063
-  - PLN-0064
-tags:
-  - studio
-  - packer
-  - runtime
-  - scene
-  - asset-pack
-  - tiled
-  - import-export
-  - revision
----
-
-## Decision
-
-`Scene Bank` authoring in `studio` SHALL move to a Studio-native canonical scene model.
-
-`TMX` and `TSX` SHALL remain supported formats, but only as import/export and compatibility surfaces. They MUST NOT be treated as the primary editorial model, the validation target, or the canonical publication state.
-
-The Studio workflow for scenes SHALL NOT use `generate`, `validate`, or `accept` over `TMX`, per-layer `TMX`, or any equivalent editor-owned surface. Instead, Studio SHALL own:
-
-- a canonical scene entity for the asset itself;
-- `import` from supported external formats into that canonical scene entity;
-- `export` from that canonical scene entity into supported external formats.
-
-For wave 1 of this revision:
-
-- `Tiled` SHALL be the first supported import/export option;
-- `TMX` scene import SHALL update the canonical scene entity from the external file;
-- `TMX` scene export SHALL overwrite the target `TMX` or create it if missing;
-- glyph-bank `TSX` generation SHALL be treated as `TSX (Tiled)` export and SHALL overwrite the target `TSX` or create it if missing.
-
-Validation SHALL occur over the canonical Studio scene entity during `Analyse` and/or `Pack`. The canonical Studio scene entity SHALL remain distinct from the `studio -> packer` scene-pack request, and that request SHALL remain distinct from the runtime `SCENE` binary payload.
-
-This decision SHALL supersede the editorial-model portion of `DEC-0029`. It SHALL preserve the parts of `DEC-0029` that define:
-
-- the canonical `studio -> packer` boundary as normative for publication;
-- `TMX`/`TSX` as non-canonical supported surfaces;
-- `prometeu-packer` as compiler of the canonical request only;
-- runtime ownership of `glyph_asset_id -> slot` resolution and of the final `SCENE` payload contract.
-
-## Rationale
-
-The previous direction corrected the publication boundary but still modeled the editorial surface around the wrong unit. Treating layers as separate `TMX` files forced the Studio workflow to move against the natural structure of supported external editors and produced a brittle acceptance model.
-
-Even revising that approach to a single `TMX` per scene would still make the external format too central. The selected direction avoids that trap by making the Studio's own scene entity the owner of editorial truth, while keeping Tiled available as an interoperability surface.
-
-This preserves long-term flexibility:
-
-- multiple external scene editors MAY be supported later;
-- the packer boundary remains editor-agnostic;
-- the runtime contract remains untouched;
-- editorial tooling can evolve independently of external file formats.
-
-## Technical Specification
-
-### 1. Canonical Scene Ownership
-
-- `studio` SHALL persist and operate on a canonical scene entity owned by the Studio domain.
-- That canonical scene entity MUST be the source of truth for scene editorial state.
-- The canonical scene entity MUST NOT be conflated with a `TMX`, `TSX`, or any other editor-specific file.
-- The canonical scene entity MUST NOT be conflated with the `studio -> packer` request.
-
-### 2. External Format Support
-
-- `TMX` and `TSX` SHALL be treated as supported interoperability formats.
-- Studio SHALL expose import/export operations for supported formats through wizard-driven workflow.
-- `Tiled` SHALL be the initial supported option for both scene and glyph-bank interoperability.
-- Import/export MAY later support additional formats without changing the canonical publication boundary.
-
-### 3. Import Semantics
-
-- `import` MUST read a supported external file and project its compatible content into the canonical Studio entity.
-- `import` MUST perform minimum structural compatibility validation before mutating canonical state.
-- `import` MUST fail explicitly, with logs or diagnostics, when the external file diverges in unsupported structural ways.
-
-Examples of structural divergence that MUST be treated as import failures unless explicitly supported by a later decision:
-
-- unexpected new layers;
-- unexpected new tilesets;
-- unexpected structural modification of existing layers or tilesets;
-- equivalent external mutations that the Studio compatibility contract does not accept.
-
-- Failed import MUST NOT silently partially rewrite canonical scene state.
-
-### 4. Export Semantics
-
-- `export` MUST serialize the canonical Studio entity into the selected supported format.
-- `TMX` export MUST overwrite the destination file if present, or create it if absent.
-- `TSX` export for glyph tilesets MUST overwrite the destination file if present, or create it if absent.
-- Exported files are compatibility artifacts. They MUST NOT become the canonical source of truth by virtue of existing on disk.
-
-### 5. Validation Surface
-
-- Validation of scene correctness SHALL target the canonical Studio scene entity.
-- `Analyse` and `Pack` SHALL be the normative validation surfaces for canonical scene integrity.
-- External files MAY be validated for import compatibility during import, but that validation does not replace canonical scene validation.
-- The old `validate layer`, `accept layer`, `validate scene from TMX`, and `accept scene from TMX` workflow MUST be removed or replaced so it no longer defines the editorial lifecycle.
-
-### 6. Separation of Contracts
-
-The system SHALL preserve three distinct layers of representation:
-
-1. the canonical Studio-owned scene entity;
-2. the canonical `studio -> packer` scene-pack request derived from that entity;
-3. the runtime `SCENE` binary payload derived by `prometeu-packer`.
-
-Normative implications:
-
-- the canonical scene entity MAY evolve editorially without forcing the same shape onto the pack request;
-- the pack request MUST remain a publication projection, not the editorial persistence model;
-- packer MUST continue compiling only the canonical request, never `TMX`, `TSX`, or any other editor-native file directly.
-
-### 7. Preserved Rules from DEC-0029
-
-This decision intentionally preserves the following normative rules from `DEC-0029`:
-
-- `TMX`/`TSX` remain supported but non-canonical;
-- the publication contract remains the canonical `studio -> packer` request;
-- `prometeu-packer` MUST NOT parse editor-specific formats directly;
-- runtime `SCENE` continues to depend on `glyph_asset_id` per layer;
-- runtime slot resolution remains runtime-owned;
-- any future change to the request shape or runtime payload contract still requires explicit decision review.
-
-## Constraints
-
-- This decision MUST NOT be interpreted as making Tiled deprecated or unsupported.
-- This decision MUST NOT be interpreted as collapsing the canonical Studio scene entity into the pack request.
-- This decision MUST NOT be interpreted as allowing import to accept arbitrary external edits without compatibility checks.
-- This decision MUST NOT be interpreted as preserving the old `TMX per layer` model.
-- This decision does not yet define the full canonical scene schema; that schema SHALL be specified by downstream plans and spec propagation derived from this decision.
-
-## Revision Log
-
-- 2026-04-30: Initial draft from AGD-0033.
-- 2026-04-30: Explicitly supersedes the editorial-model portion of DEC-0029 while preserving its canonical publication boundary.
-- 2026-04-30: Accepted and decomposed into implementation plans PLN-0062, PLN-0063, and PLN-0064.

discussion/workflow/plans/PLN-0059-scene-pack-contract-spec-propagation.md

@@ -1,116 +0,0 @@
----
-id: PLN-0059
-ticket: studio-scene-pack-runtime-binary-contract
-title: Propagate DEC-0029 into Studio and packer normative specifications
-status: done
-created: 2026-04-29
-completed: 2026-04-29
-tags:
-  - studio
-  - packer
-  - specs
-  - scene
-  - runtime-contract
----
-
-## Objective
-
-Update the normative documentation surfaces so DEC-0029 is fully reflected in Studio and packer specs before or alongside code implementation.
-
-## Background
-
-DEC-0029 locks the canonical publication contract for `Scene Bank` assets around a `studio -> packer` request that compiles directly into runtime `SCENE` bytes. It also locks `TMX`/`TSX` as supported but non-canonical editorial surfaces.
-
-The current codebase already contains wave-1 Tiled support and Scene Bank validation flows, but the normative specs do not yet describe:
-
-- the canonical scene-pack request,
-- the non-canonical status of `TMX`/`TSX`,
-- the `Accept` projection boundary,
-- or packer ownership of binary `SCENE` compilation from a request rather than from editor files.
-
-## Scope
-
-### Included
-- Update Studio specs to describe Scene Bank editorial ownership, validation, `Accept`, and canonical request projection.
-- Update packer specs to describe request-owned publication, `SCENE/tilemap_v1`, and the prohibition on direct parsing of editor-specific formats by packer.
-- Cross-link Studio and packer specs to DEC-0029 and to the existing Scene Bank asset-first wave.
-
-### Excluded
-- Java implementation changes in `prometeu-studio`.
-- Java implementation changes in `prometeu-packer`.
-- Lesson or housekeeping work for DSC-0030.
-
-## Execution Steps
-
-### Step 1 - Update Studio asset workspace specification
-
-**What:** Add normative Scene Bank language to the Studio `Assets` workspace spec.
-
-**How:** Extend the asset-family-specific rules in the Studio spec so Scene Bank authoring is explicitly asset-owned, `TMX`/`TSX` are editorial integrations rather than canonical publication artifacts, and `Accept` is defined as the projection point into the canonical pack request.
-
-**File(s):**
-- `docs/specs/studio/4. Assets Workspace Specification.md`
-
-### Step 2 - Update packer declaration and build-boundary specifications
-
-**What:** Describe the canonical request and packer-owned build behavior in packer specs.
-
-**How:** Amend the common asset contract spec and the operational/build specs so `SCENE/tilemap_v1` is documented as a runtime-oriented format whose packer input is the canonical scene-pack request produced by Studio, not raw editor files. Make explicit that editor-specific files remain tooling/editorial surfaces and MUST NOT be parsed directly by packer.
-
-**File(s):**
-- `docs/specs/packer/3. Asset Declaration and Virtual Asset Contract Specification.md`
-- `docs/specs/packer/4. Build Artifacts and Deterministic Packing Specification.md`
-- `docs/specs/packer/5. Diagnostics, Operations, and Studio Integration Specification.md`
-
-### Step 3 - Record canonical field semantics
-
-**What:** Add the canonical scene-pack request fields and rules.
-
-**How:** Document the fixed four-layer request shape, layer-level `glyph_asset_id`, `tile_size`, `parallax_factor`, `width`, `height`, tile-level `active`, `glyph_id`, `palette_id`, `flip_x`, `flip_y`, and the rule that `tile_count` is derived from dimensions. Lock the default-plus-override semantics for `palette_id`.
-
-**File(s):**
-- `docs/specs/studio/4. Assets Workspace Specification.md`
-- `docs/specs/packer/4. Build Artifacts and Deterministic Packing Specification.md`
-
-### Step 4 - Align gating and future-editor rules
-
-**What:** Ensure the specs preserve future editor substitution without weakening the current wave.
-
-**How:** Add explicit normative text that any future editor may replace or coexist with Tiled-backed editing only if it emits the same canonical request and passes the same validation and `Accept` rules. Preserve the wave-1 single-tileset-per-layer restriction.
-
-**File(s):**
-- `docs/specs/studio/4. Assets Workspace Specification.md`
-- `docs/specs/packer/5. Diagnostics, Operations, and Studio Integration Specification.md`
-
-## Test Requirements
-
-### Unit Tests
-
-- No code unit tests are required for this editorial plan.
-
-### Integration Tests
-
-- No automated integration tests are required for this editorial plan.
-
-### Manual Verification
-
-- Review the updated specs side by side with DEC-0029 and confirm that every normative rule in the decision has a corresponding spec statement.
-- Confirm there is no spec language implying that packer parses `TMX` or `TSX` directly.
-- Confirm the specs do not describe Tiled as deprecated or temporary.
-
-## Acceptance Criteria
-
-- [ ] The Studio spec defines Scene Bank `Accept` as the projection boundary into the canonical scene-pack request.
-- [ ] The packer specs define `SCENE/tilemap_v1` publication in terms of the canonical request, not editor files.
-- [ ] The specs state that `TMX`/`TSX` are supported but non-canonical editorial surfaces.
-- [ ] The specs allow future additional editors only through the same canonical request and validation path.
-- [ ] Every normative requirement in DEC-0029 is represented in at least one spec file.
-
-## Dependencies
-
-- DEC-0029 accepted.
-
-## Risks
-
-- Editorial drift between Studio and packer specs could reintroduce ambiguity about who owns the canonical request.
-- If the specs omit the field semantics for `palette_id` precedence or tile/layer `active`, code plans may diverge during implementation.

discussion/workflow/plans/PLN-0060-scene-bank-studio-request-projection-and-acceptance.md

@@ -1,137 +0,0 @@
----
-id: PLN-0060
-ticket: studio-scene-pack-runtime-binary-contract
-title: Build Scene Bank canonical request projection and acceptance in Studio
-status: done
-created: 2026-04-29
-completed: 2026-04-29
-tags:
-  - studio
-  - scene
-  - assets
-  - tiled
-  - acceptance
----
-
-## Objective
-
-Implement the Studio-owned projection from supported editorial scene state into the canonical scene-pack request, with validation and `Accept` gating aligned to DEC-0029.
-
-## Background
-
-Studio already owns Scene Bank support metadata, Tiled generation, diagnostics, validation, and explicit acceptance. Today, however, the acceptance flow persists only validation fingerprints and does not yet materialize the canonical `studio -> packer` request required by DEC-0029.
-
-This plan turns `Accept` from a pure approval marker into the normative projection boundary for Scene Bank publication.
-
-## Scope
-
-### Included
-- Extend Scene Bank support metadata and UI/editorial state to carry the fields required by the canonical request.
-- Generate and persist the canonical request during Scene Bank `Accept`.
-- Validate the editorial-to-request mapping, including layer defaults and tile overrides.
-- Keep Tiled integration as a supported editorial path without making it canonical.
-
-### Excluded
-- Binary `SCENE` encoding in packer.
-- Runtime decoder or runtime scene-binding changes.
-- A new integrated scene editor.
-
-## Execution Steps
-
-### Step 1 - Expand Scene Bank editorial metadata
-
-**What:** Add the missing layer-owned editorial fields required by the canonical request.
-
-**How:** Extend the Scene Bank metadata model and serialization so each layer can carry at minimum `parallax_factor_x`, `parallax_factor_y`, and a layer-level default `palette_id`, while preserving the existing enabled-state, dimensions, `tilemap`, and `tileset_asset_root` binding rules.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/metadata/AssetStudioSceneBankMetadata.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/metadata/AssetStudioSceneLayerBinding.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/metadata/AssetStudioMetadataService.java`
-- `prometeu-studio/src/test/java/p/studio/workspaces/assets/metadata/AssetStudioMetadataServiceTest.java`
-
-### Step 2 - Surface the new fields in the Scene Bank details UI
-
-**What:** Make the canonical request inputs editable and reviewable in Studio.
-
-**How:** Update the Scene Bank layer controls so the layer form exposes parallax values, default palette selection, and clearly ties `glyph_asset_id` derivation to the selected tileset asset. Preserve the existing enabled checkbox as the layer-level publication toggle.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/scene/AssetDetailsSceneLayersControl.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/AssetDetailsControl.java`
-- `prometeu-studio/src/main/java/p/studio/utilities/i18n/I18n.java`
-- `prometeu-studio/src/main/resources/i18n/messages.properties`
-
-### Step 3 - Build canonical request projection from accepted editorial state
-
-**What:** Materialize the canonical scene-pack request during `Accept`.
-
-**How:** Introduce Studio-side request DTOs or records for `ScenePackRequest`, `ScenePackLayerRequest`, and `ScenePackTileRequest`. Update `SceneBankWorkflowService` so `Accept` validates the supported editorial inputs, parses `TMX`/`TSX`, derives `glyph_asset_id`, applies layer-default plus per-tile `palette_id` overrides, resolves per-tile `glyph_id`, `flip_x`, `flip_y`, and persists the resulting canonical request as the accepted publication input for packer consumption.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/scene/SceneBankWorkflowService.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/scene/SceneBankWorkflowResult.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/tiled/TiledXmlCodec.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/tiled/TiledMapDocument.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/tiled/TiledTilesetDocument.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/tiled/TiledTilesetTile.java`
-
-### Step 4 - Tighten validation around canonical semantics
-
-**What:** Ensure Studio rejects editorial states that cannot be projected safely into the canonical request.
-
-**How:** Extend validation so it blocks acceptance when a layer lacks a resolvable tileset asset, when per-tile data cannot be mapped to a valid `glyph_id` or `palette_id`, when unsupported Tiled features would break canonical projection, or when wave-1 constraints such as single-tileset-per-layer are violated.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/scene/SceneBankWorkflowService.java`
-- `prometeu-studio/src/test/java/p/studio/workspaces/assets/scene/SceneBankWorkflowServiceTest.java`
-- `prometeu-studio/src/test/java/p/studio/workspaces/assets/tiled/TiledXmlCodecTest.java`
-- `prometeu-studio/src/test/java/p/studio/workspaces/assets/tiled/TiledAssetGenerationServiceTest.java`
-
-### Step 5 - Expose acceptance artifacts to downstream consumers
-
-**What:** Make the accepted canonical request visible to the rest of the Studio-to-packer flow.
-
-**How:** Persist the accepted request in a deterministic asset-local file or equivalent accepted artifact and update the details refresh flow so the accepted/publication-ready state reflects both validation success and presence of the canonical request artifact.
-
-**File(s):**
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/scene/SceneBankWorkflowService.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/messages/AssetWorkspaceAssetDetails.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/details/AssetDetailsViewStateFactory.java`
-- `prometeu-studio/src/main/java/p/studio/workspaces/assets/messages/AssetWorkspaceSceneBankValidation.java`
-
-## Test Requirements
-
-### Unit Tests
-
-- Add metadata serialization/deserialization coverage for the new layer fields.
-- Add request-projection tests for `glyph_asset_id` derivation, default `palette_id`, per-tile `palette_id` override, and tile flip mapping.
-
-### Integration Tests
-
-- Add Scene Bank workflow tests covering validate-then-accept for a valid layer set and failure cases for unsupported or incomplete editorial state.
-- Add acceptance-artifact tests proving external file mutation invalidates the accepted state until revalidation and reacceptance.
-
-### Manual Verification
-
-- Create or update a Scene Bank asset in the test project, validate it, accept it, and confirm the accepted artifact contains the full canonical request.
-- Change a `TMX` or `TSX` file after acceptance and confirm Studio returns the asset to a non-ready state.
-
-## Acceptance Criteria
-
-- [ ] Scene Bank metadata and UI expose the layer-owned fields required by DEC-0029.
-- [ ] `Accept` emits a deterministic canonical scene-pack request artifact from the supported editorial state.
-- [ ] Validation blocks any Scene Bank that cannot be projected into the canonical request without guessing.
-- [ ] Layer default and per-tile override semantics for `palette_id` are implemented and tested.
-- [ ] Studio continues to support Tiled-backed editing without making `TMX`/`TSX` the canonical publication surface.
-
-## Dependencies
-
-- DEC-0029 accepted.
-- PLN-0059 should land first or in parallel so the code aligns to updated specs.
-
-## Risks
-
-- The current Tiled parsing model may not yet expose every per-tile property needed for deterministic request projection.
-- If the accepted artifact shape is underspecified, packer integration may later depend on unstable serialization details.
-- UI additions for layer metadata can introduce partial-state bugs if draft/application flow is not kept consistent.

discussion/workflow/plans/PLN-0061-scene-pack-request-materialization-and-packer-build.md

@@ -1,130 +0,0 @@
----
-id: PLN-0061
-ticket: studio-scene-pack-runtime-binary-contract
-title: Compile the canonical Scene Bank request into runtime SCENE in packer
-status: done
-created: 2026-04-29
-completed: 2026-04-29
-tags:
-  - packer
-  - scene
-  - runtime
-  - binary-format
-  - build
----
-
-## Objective
-
-Implement the packer-owned path that reads the accepted canonical scene-pack request and emits runtime `SCENE` binary payloads for `Scene Bank` assets.
-
-## Background
-
-`prometeu-packer` already recognizes `SCENE_BANK` and the `SCENE/tilemap_v1` output format, but `SCENE_BANK` currently stops short of real materialization. DEC-0029 locks the rule that packer must compile a canonical request and must not parse `TMX` or `TSX` directly.
-
-This plan delivers the missing operational half of the boundary.
-
-## Scope
-
-### Included
-- Introduce packer-side models for the canonical Scene Bank request.
-- Validate the accepted request artifact as a packer input.
-- Encode runtime `SCENE` binary payloads from the canonical request.
-- Integrate Scene Bank packing into the existing runtime materialization/build flow.
-
-### Excluded
-- Studio UI and metadata authoring changes.
-- Runtime decoder changes beyond what is already assumed by DEC-0029.
-- Multi-tileset-per-layer or non-wave-1 scene authoring features.
-
-## Execution Steps
-
-### Step 1 - Add canonical request models to the packer API
-
-**What:** Define stable packer-side Java models for the canonical Scene Bank request.
-
-**How:** Add DTOs/records for `ScenePackRequest`, `ScenePackLayerRequest`, and `ScenePackTileRequest` in `prometeu-packer-api`, including validation helpers for fixed layer count, required dimensions, and field presence. These models must be editor-agnostic and must not mention `TMX` or `TSX`.
-
-**File(s):**
-- `prometeu-packer/prometeu-packer-api/src/main/java/p/packer/messages/assets/`
-- `prometeu-packer/prometeu-packer-api/build.gradle.kts` if package exports or module wiring need updates
-
-### Step 2 - Teach packer to read and validate the accepted request artifact
-
-**What:** Load Scene Bank publication input from the accepted request artifact rather than from editor files.
-
-**How:** Extend the Scene Bank walking/materialization path so packer looks for the accepted canonical request artifact in the asset root, validates the fixed four-layer structure, checks `width * height` against tile counts, rejects missing or malformed request content, and emits structural diagnostics when the request is absent or invalid.
-
-**File(s):**
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/repositories/PackerAssetWalker.java`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/repositories/PackerRuntimeAssetMaterializer.java`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/services/FileSystemPackerWorkspaceService.java`
-
-### Step 3 - Encode runtime `SCENE` payload bytes
-
-**What:** Turn the canonical request into the runtime binary representation.
-
-**How:** Implement a Scene Bank packer encoder that maps each canonical layer and tile entry directly into the versioned `SCENE` payload layout, including `glyph_asset_id`, tile size, parallax, dimensions, active state, tile activity, palette IDs, flips, and derived `tile_count`. Keep request-to-binary projection as close to isomorphic as possible and avoid injecting editor-only fields.
-
-**File(s):**
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/repositories/`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/models/`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/services/`
-
-### Step 4 - Integrate Scene Bank artifacts into pack output
-
-**What:** Make Scene Bank assets participate in actual pack output and runtime metadata emission.
-
-**How:** Update the relevant packer services so `SCENE_BANK` assets contribute emitted runtime files and asset-table metadata in the same build lane used by other runtime asset families, while preserving `SCENE/tilemap_v1` as the declared output format.
-
-**File(s):**
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/services/FileSystemPackerWorkspaceService.java`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/repositories/PackerRuntimeRegistry.java`
-- `prometeu-packer/prometeu-packer-v1/src/main/java/p/packer/repositories/PackerRuntimeLoader.java`
-
-### Step 5 - Prove packer/editor boundary discipline with tests
-
-**What:** Prevent regression toward direct editor parsing in packer.
-
-**How:** Add tests that succeed with a valid accepted canonical request even when Tiled files are ignored by packer, and tests that fail when the accepted request is missing or structurally invalid. Assert that packer diagnostics talk about the canonical request artifact rather than raw Tiled file concerns.
-
-**File(s):**
-- `prometeu-packer/prometeu-packer-v1/src/test/java/p/packer/services/FileSystemPackerWorkspaceServiceTest.java`
-- `prometeu-packer/prometeu-packer-v1/src/test/java/p/packer/repositories/PackerRuntimeAssetMaterializerTest.java`
-- `prometeu-packer/prometeu-packer-v1/src/test/java/p/packer/testing/`
-
-## Test Requirements
-
-### Unit Tests
-
-- Add model validation tests for the canonical Scene Bank request records.
-- Add encoder tests for field-level request-to-binary mapping, including `glyph_asset_id`, parallax, dimensions, activity flags, palette IDs, and flips.
-
-### Integration Tests
-
-- Add workspace/build tests covering a valid Scene Bank asset end to end from accepted request artifact to emitted `assets.pa`.
-- Add failure tests for missing request artifact, invalid layer counts, invalid tile counts, and malformed field values.
-
-### Manual Verification
-
-- Run a pack build on a project containing an accepted Scene Bank and inspect the emitted runtime artifact summary to confirm the scene asset is present.
-- Verify that modifying only `TMX`/`TSX` without regenerating the accepted request does not cause packer to silently read the editor files directly.
-
-## Acceptance Criteria
-
-- [ ] Packer can read a canonical Scene Bank request artifact without depending on `TMX` or `TSX`.
-- [ ] `SCENE_BANK` assets produce runtime `SCENE` payload bytes in pack output.
-- [ ] Structural diagnostics exist for missing or malformed accepted request artifacts.
-- [ ] Request-to-binary mapping is covered by automated tests.
-- [ ] Packer behavior preserves the editor-agnostic boundary locked by DEC-0029.
-
-## Dependencies
-
-- DEC-0029 accepted.
-- PLN-0060 must land before final end-to-end validation because Studio owns generation of the accepted canonical request artifact.
-- PLN-0059 should land first or in parallel so packer implementation aligns to updated specs.
-
-## Risks
-
-- The exact runtime `SCENE` binary layout may still need careful reconciliation with existing runtime decoder assumptions.
-- If the accepted request artifact versioning is not explicit from the start, future format evolution may become harder to stage safely.
-- Scene Bank integration may touch several packer build phases, increasing regression risk in `assets.pa` generation.

discussion/workflow/plans/PLN-0062-scene-canonical-model-revision-spec-propagation.md

@@ -1,101 +0,0 @@
----
-id: PLN-0062
-ticket: studio-scene-pack-runtime-binary-contract
-title: Propagate DEC-0030 into Studio and packer specifications
-status: done
-created: 2026-04-30
-completed: 2026-04-30
-tags: [studio, packer, runtime, scene, specs, import-export]
----
-
-## Objective
-
-Update the normative documentation surfaces so DEC-0030 is fully represented before or alongside code changes. The resulting specs must make the Studio-owned canonical scene entity, import/export workflow, and request separation unambiguous.
-
-## Background
-
-DEC-0030 supersedes the editorial-model portion of DEC-0029. The publication boundary locked by DEC-0029 remains valid, but the Studio editorial model changes materially:
-
-- Studio owns a canonical scene entity;
-- `TMX`/`TSX` become import/export compatibility formats;
-- validation moves to the canonical scene entity in `Analyse` and `Pack`;
-- the scene asset model remains distinct from the `studio -> packer` request.
-
-The existing specs currently describe or imply the older `TMX per layer` and `validate/accept` workflow and therefore require explicit propagation.
-
-## Scope
-
-### Included
-- Update Studio specs to define the canonical scene entity as the primary editorial model.
-- Update Studio specs to define `TMX` and `TSX` as import/export formats, not canonical persistence.
-- Update packer specs to reaffirm that packer consumes only the canonical request derived from the canonical scene entity.
-- Cross-reference DEC-0029 and DEC-0030 with explicit note about what changed and what remains locked.
-- Define the validation surface shift from editor files to canonical scene analysis/pack validation.
-
-### Excluded
-- Code changes in `prometeu-studio`.
-- Code changes in `prometeu-packer`.
-- Final canonical scene schema details beyond what DEC-0030 already locks.
-
-## Execution Steps
-
-### Step 1 - Update Studio normative scene workflow documentation
-
-**What:** Rewrite the Studio scene authoring spec so it names the Studio-owned canonical scene entity as the source of truth.
-**How:** Replace language that describes `TMX` generation, per-layer `TMX`, or `validate/accept` as the editorial workflow. Introduce import/export wizard language and preserve the distinction between canonical scene entity and external compatibility files.
-**File(s):** `docs/studio/specs/...` files that currently define Scene Bank workflow and Tiled integration.
-
-### Step 2 - Update Studio validation and interoperability specification
-
-**What:** Document import compatibility checks, export overwrite semantics, and validation ownership.
-**How:** Add normative statements for:
-- import compatibility failure on unsupported structural mutations;
-- diagnostic/logging requirements for failed imports;
-- `TMX` export overwrite/create behavior;
-- `TSX` export overwrite/create behavior for glyph tilesets;
-- canonical scene validation during `Analyse` and `Pack`.
-**File(s):** Studio scene and glyph tileset spec files.
-
-### Step 3 - Update packer normative boundary documentation
-
-**What:** Reaffirm the packer contract after DEC-0030.
-**How:** Clarify that packer still consumes only the canonical scene-pack request and remains isolated from editor-native formats, even though Studio now owns an additional canonical scene entity layer upstream.
-**File(s):** `docs/packer/specs/...` scene packing contract files.
-
-### Step 4 - Record supersession and preserved rules
-
-**What:** Make the DEC-0029 to DEC-0030 relationship explicit in the relevant specs.
-**How:** Note that DEC-0030 replaces only the old editorial-model assumptions, while preserving the canonical publication boundary, runtime ownership, and request compilation model.
-**File(s):** Updated Studio and packer spec references.
-
-## Test Requirements
-
-### Unit Tests
-
-No code tests. Editorial review only.
-
-### Integration Tests
-
-No runtime integration tests. Validate consistency across affected spec surfaces.
-
-### Manual Verification
-
-- Read updated Studio and packer specs side by side with DEC-0030.
-- Confirm there is no remaining normative language that presents `TMX`/`TSX` as canonical scene persistence.
-- Confirm there is no remaining normative language that treats `validate/accept` of external editor files as the scene editorial lifecycle.
-
-## Acceptance Criteria
-
-- [ ] Every normative requirement in DEC-0030 is represented in at least one spec surface.
-- [ ] Studio specs clearly distinguish canonical scene entity, external import/export files, and pack request.
-- [ ] Packer specs clearly preserve the editor-agnostic request compilation boundary.
-- [ ] Spec language no longer implies `TMX per layer` or `validate/accept` over `TMX` as the primary workflow.
-
-## Dependencies
-
-- DEC-0030 accepted.
-
-## Risks
-
-- Leaving mixed old/new vocabulary in specs would create implementation ambiguity.
-- Over-specifying the canonical scene schema here would preempt downstream implementation design that DEC-0030 intentionally leaves for planning.

discussion/workflow/plans/PLN-0063-studio-canonical-scene-entity-analysis-and-pack-request-projection.md

@@ -1,107 +0,0 @@
----
-id: PLN-0063
-ticket: studio-scene-pack-runtime-binary-contract
-title: Introduce the Studio canonical scene entity and project it into analysis and pack requests
-status: done
-created: 2026-04-30
-completed: 2026-04-30
-tags: [studio, scene, canonical-model, analysis, pack-request]
----
-
-## Objective
-
-Implement the Studio-owned canonical scene entity and make it the sole editorial source of truth for Scene Bank assets, including canonical validation during `Analyse` and projection into the `studio -> packer` request.
-
-## Background
-
-DEC-0030 removes the old `TMX per layer` workflow and replaces it with a Studio-native canonical scene entity. The Studio must now own:
-
-- canonical scene persistence;
-- canonical scene analysis/diagnostics;
-- derivation of the canonical scene-pack request from canonical scene state.
-
-This is the core refactor that re-centers the domain model. External `TMX`/`TSX` interoperability is handled separately.
-
-## Scope
-
-### Included
-- Define and persist a canonical scene entity for Scene Bank assets.
-- Replace old scene validation state that depends on `TMX`/layer acceptance.
-- Move diagnostics and validation to the canonical scene entity in `Analyse` and asset-pack readiness surfaces.
-- Derive the canonical `studio -> packer` request from the canonical scene entity.
-- Remove or retire the old layer-level `validate/accept` workflow from Studio scene handling.
-
-### Excluded
-- `TMX` scene import/export implementation details.
-- `TSX` export implementation details.
-- Changes to runtime `SCENE` binary decoding.
-
-## Execution Steps
-
-### Step 1 - Define canonical scene persistence and metadata model
-
-**What:** Introduce the persisted Studio-owned scene entity and associated metadata structures.
-**How:** Add or revise Scene Bank metadata classes and persistence so the canonical scene entity is stored independently of `TMX` and independently of the pack request artifact. Preserve explicit layer metadata and any required editorial fields without treating external files as the source of truth.
-**File(s):** `prometeu-studio` Scene Bank metadata models, persistence services, and asset details mappings.
-
-### Step 2 - Replace old workflow state and actions
-
-**What:** Remove the old `validate layer`, `accept layer`, and `accept scene from TMX` lifecycle as the authoritative workflow.
-**How:** Delete or refactor workflow services, action wiring, and UI status logic so Scene Bank readiness is derived from canonical scene analysis rather than per-layer external-file fingerprints.
-**File(s):** `SceneBankWorkflowService`, asset details controls, scene layer controls, message/status models, and related UI wiring.
-
-### Step 3 - Implement canonical analysis and diagnostics
-
-**What:** Make `Analyse` and pack-readiness diagnostics validate the canonical scene entity.
-**How:** Add validators that check canonical layer structure, glyph asset references, layer/tile invariants, and request derivation preconditions directly from canonical scene data. Ensure diagnostics remain explicit and actionable.
-**File(s):** Studio analysis services, scene diagnostics, asset details status surfaces, and any supporting validators.
-
-### Step 4 - Project canonical scene state into the pack request
-
-**What:** Derive the `studio -> packer` request exclusively from the canonical scene entity.
-**How:** Replace the old `TMX`-driven request projection with canonical entity projection, preserving the existing request/runtime boundary. Persist the request artifact only as a publication projection, not as canonical editorial state.
-**File(s):** Scene request projection services, request serialization, asset workflow persistence, and related tests.
-
-### Step 5 - Migrate or adapt project fixtures and internal examples
-
-**What:** Update test fixtures and example assets so they reflect the new canonical scene model.
-**How:** Replace sample assets, metadata fixtures, and scene workflow tests that currently depend on `TMX per layer` acceptance semantics.
-**File(s):** `test-projects/main`, Studio workflow tests, fixture generators, and scene sample assets.
-
-## Test Requirements
-
-### Unit Tests
-
-- Canonical scene persistence round-trip tests.
-- Canonical scene validation tests for blocking and non-blocking diagnostics.
-- Request projection tests proving the canonical scene entity, not `TMX`, drives the generated scene-pack request.
-
-### Integration Tests
-
-- End-to-end Studio asset workflow tests covering scene analysis and pack-request artifact generation from canonical scene state.
-- Regression tests proving old layer acceptance files no longer define readiness.
-
-### Manual Verification
-
-- Open a Scene Bank asset and confirm there is no primary `validate/accept TMX` workflow.
-- Run `Analyse` and verify diagnostics reflect canonical scene state.
-- Confirm pack-request generation occurs from canonical scene state and not from external editor files.
-
-## Acceptance Criteria
-
-- [ ] Scene Bank assets persist a Studio-owned canonical scene entity distinct from both `TMX` and the pack request.
-- [ ] Studio readiness/diagnostics for scenes are driven by canonical scene analysis.
-- [ ] The old `validate/accept` layer-centric workflow no longer defines scene publication readiness.
-- [ ] The `studio -> packer` request is derived from canonical scene state only.
-- [ ] Existing request/runtime boundary semantics from DEC-0029 remain preserved.
-
-## Dependencies
-
-- DEC-0030 accepted.
-- PLN-0062 should land first or in parallel so code aligns with updated specs.
-
-## Risks
-
-- Hidden dependencies on old acceptance fingerprint files may remain in the UI or workspace services.
-- If canonical schema design is underspecified in code, the implementation may accidentally recreate a `TMX-shaped` persistence model under a different name.
-- Fixture migration may expose broad assumptions in tests and project samples.

discussion/workflow/plans/PLN-0064-tiled-scene-import-and-tileset-export-interoperability.md

@@ -1,105 +0,0 @@
----
-id: PLN-0064
-ticket: studio-scene-pack-runtime-binary-contract
-title: Implement Tiled scene import and glyph tileset export as compatibility workflows
-status: done
-created: 2026-04-30
-completed: 2026-04-30
-tags: [studio, tiled, tmx, tsx, import-export, interoperability]
----
-
-## Objective
-
-Implement `Tiled` interoperability as explicit compatibility workflow: scene `TMX` import into the canonical Studio scene entity, scene `TMX` export from that entity, and glyph tileset `TSX` export for Tiled consumption.
-
-## Background
-
-DEC-0030 keeps `TMX` and `TSX` as supported formats, but only for import/export. This means external file handling becomes adapter logic around the canonical scene and glyph-bank models, with explicit compatibility checks and overwrite semantics.
-
-## Scope
-
-### Included
-- Wizard-driven `TMX (Tiled)` import flow for Scene Bank assets.
-- Wizard-driven `TMX (Tiled)` export flow for Scene Bank assets.
-- Wizard-driven or equivalent `TSX (Tiled)` export flow for glyph tilesets.
-- Import compatibility validation and failure diagnostics for unsupported structural divergence.
-- Overwrite/create semantics for exported `TMX` and `TSX`.
-
-### Excluded
-- Additional external scene formats beyond Tiled.
-- Packer-side parsing of `TMX` or `TSX`.
-- Broader native scene editing UX beyond what is required to support compatibility flow integration.
-
-## Execution Steps
-
-### Step 1 - Build Tiled import compatibility validation
-
-**What:** Add import-time structural checks for supported `TMX` scene files.
-**How:** Validate the incoming `TMX` against the Studio compatibility contract before mutating canonical scene state. Reject unsupported mutations such as unexpected layers, unexpected tilesets, unsupported structural changes, or equivalent divergences. Produce explicit logs/diagnostics on failure.
-**File(s):** Tiled scene parsing/import services, diagnostics types, and import workflow orchestration.
-
-### Step 2 - Implement canonical scene mutation from imported TMX
-
-**What:** Update canonical scene state from accepted `TMX` imports.
-**How:** Translate compatible Tiled scene content into the canonical Studio scene entity without storing the `TMX` itself as source of truth. Ensure failed imports do not partially mutate canonical state.
-**File(s):** Scene import services, canonical scene mutation helpers, asset persistence layer, and import wizard state.
-
-### Step 3 - Implement TMX export from canonical scene state
-
-**What:** Serialize the canonical scene entity back into `TMX (Tiled)`.
-**How:** Generate or overwrite the destination `TMX` from canonical scene state using stable export rules. Ensure the output is explicit compatibility output and not the canonical persistence model.
-**File(s):** Tiled scene export services, wizard flows, and file-writing surfaces.
-
-### Step 4 - Reframe TSX generation as export
-
-**What:** Convert glyph tileset `TSX` generation into explicit `TSX (Tiled)` export behavior.
-**How:** Rename or refactor the current glyph tileset generation flow so it is clearly an export operation, with overwrite/create semantics and no implication that `TSX` is canonical storage.
-**File(s):** Glyph tileset export/generation services, UI actions, workflow naming, and related tests.
-
-### Step 5 - Wire import/export into Studio UI and logs
-
-**What:** Expose the interoperability workflow in the Studio asset UI.
-**How:** Add wizard entry points, action labels, progress/error reporting, and logs for successful export, successful import, and rejected imports.
-**File(s):** Asset details UI, Scene Bank controls, glyph tileset controls, event/log surfaces, and i18n messages.
-
-## Test Requirements
-
-### Unit Tests
-
-- Import validation tests for supported and rejected `TMX` structures.
-- Scene import mutation tests proving canonical state changes only on successful import.
-- `TMX` export tests proving overwrite/create behavior.
-- `TSX` export tests proving overwrite/create behavior.
-
-### Integration Tests
-
-- End-to-end import workflow test from `TMX` into canonical scene state.
-- End-to-end export workflow tests for `TMX` and `TSX`.
-- Regression tests proving failed imports do not partially rewrite canonical state.
-
-### Manual Verification
-
-- Import a supported Tiled scene and confirm canonical scene state updates.
-- Import an unsupported Tiled scene mutation and confirm the import is rejected with clear logs.
-- Export a scene to `TMX` and confirm the destination file is overwritten or created.
-- Export a glyph tileset to `TSX` and confirm the destination file is overwritten or created.
-
-## Acceptance Criteria
-
-- [ ] Scene `TMX` import exists as explicit compatibility workflow and validates minimum structural compatibility before mutation.
-- [ ] Failed imports emit clear diagnostics/logs and do not partially rewrite canonical state.
-- [ ] Scene `TMX` export exists as explicit compatibility workflow with overwrite/create semantics.
-- [ ] Glyph tileset `TSX` export exists as explicit compatibility workflow with overwrite/create semantics.
-- [ ] Studio UI reflects `import/export` terminology rather than the old `generate/validate/accept` model for Tiled interoperability.
-
-## Dependencies
-
-- DEC-0030 accepted.
-- PLN-0063 must land before final import/export integration because import/export targets the canonical scene entity owned by Studio.
-- PLN-0062 should land first or in parallel so UI and code terminology align with updated specs.
-
-## Risks
-
-- If import compatibility rules are too loose, external files will silently reshape canonical scene state.
-- If import compatibility rules are too strict, Tiled interoperability will be noisy and frustrating.
-- UI naming may remain half-migrated if old action labels or logs are left behind.