Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity

housekeeping

Browse Source
This commit is contained in:
bQUARKz 2026-05-08 09:17:43 +01:00
parent 0e6a2cd5bc
commit ef814b2420
Signed by: bquarkz
SSH Key Fingerprint: SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
16 changed files with 215 additions and 1274 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
discussion/.backups/index.ndjson.20260331-092554.bak
View File

@ -1,13 +0,0 @@
{"type":"meta","next_id":{"DSC":13,"AGD":13,"DEC":10,"PLN":19,"LSN":27,"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":"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":"open","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":[{"id":"AGD-0012","file":"AGD-0012-studio-editor-document-vfs-boundary.md","status":"in_progress","created_at":"2026-03-31","updated_at":"2026-03-31"}],"decisions":[{"id":"DEC-0009","file":"DEC-0009-studio-prometeu-vfs-project-document-boundary.md","status":"in_progress","created_at":"2026-03-31","updated_at":"2026-03-31","ref_agenda":"AGD-0012"}],"plans":[{"id":"PLN-0015","file":"PLN-0015-propagate-dec-0009-into-studio-specs.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0009"]},{"id":"PLN-0016","file":"PLN-0016-build-prometeu-vfs-filesystem-backed-core.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0009"]},{"id":"PLN-0017","file":"PLN-0017-add-studio-project-session-ownership-for-prometeu-vfs.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0009"]},{"id":"PLN-0018","file":"PLN-0018-migrate-code-editor-to-prometeu-vfs.md","status":"done","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0009"]}],"lessons":[]}

35
discussion/.backups/index.ndjson.20260508-091553.bak Normal file
View File

@ -0,0 +1,35 @@
{"type":"meta","next_id":{"DSC":35,"AGD":38,"DEC":35,"PLN":75,"LSN":49,"CLSN":1}}
{"type":"discussion","id":"DSC-0034","status":"done","ticket":"frontend-semantic-host-projection-flexibility","title":"Frontend semantic vocabulary flexibility and declarative host projection","created_at":"2026-05-06","updated_at":"2026-05-07","tags":["compiler","compiler-general","frontend","semantics","vscode","host-projection","lsp"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0048","file":"discussion/lessons/DSC-0034-frontend-semantic-host-projection-flexibility/LSN-0048-frontend-owned-semantic-vocabularies-with-declarative-host-projection.md","status":"done","created_at":"2026-05-07","updated_at":"2026-05-07"}]}
{"type":"discussion","id":"DSC-0033","status":"in_progress","ticket":"frontend-visual-theme-spec-and-css-retirement","title":"Frontend visual theme spec and retirement of host-consumed semantic CSS","created_at":"2026-05-06","updated_at":"2026-05-06","tags":["compiler","compiler-general","frontend","presentation","theming","studio","vscode","lsp","pbs"],"agendas":[{"id":"AGD-0036","file":"AGD-0036-frontend-visual-theme-spec-and-css-retirement.md","status":"accepted","created_at":"2026-05-06","updated_at":"2026-05-06"}],"decisions":[{"id":"DEC-0033","file":"DEC-0033-frontend-visual-theme-spec-and-css-retirement.md","status":"accepted","created_at":"2026-05-06","updated_at":"2026-05-06","ref_agenda":"AGD-0036"}],"plans":[{"id":"PLN-0068","file":"PLN-0068-frontend-visual-contract-and-pbs-migration.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0069","file":"PLN-0069-lsp-visual-theme-transport-and-selection.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0070","file":"PLN-0070-studio-visual-theme-adapter-and-css-retirement.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0071","file":"PLN-0071-vscode-dynamic-theme-translation-adapter.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]}],"lessons":[]}
{"type":"discussion","id":"DSC-0032","status":"done","ticket":"studio-new-lsp-api-and-v1-boundary","title":"Novo boundary entre lsp-api, lsp-v1 e a extensao VS Code","created_at":"2026-05-05","updated_at":"2026-05-07","tags":["studio","lsp","vscode","protocol","api","boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0047","file":"discussion/lessons/DSC-0032-studio-new-lsp-api-and-v1-boundary/LSN-0047-project-scoped-lsp-boundary-and-protocol-containment.md","status":"done","created_at":"2026-05-07","updated_at":"2026-05-07"}]}
{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"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":[]}
{"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"}]}

6
discussion/index.ndjson
View File

@ -1,8 +1,8 @@
{"type":"meta","next_id":{"DSC":35,"AGD":38,"DEC":35,"PLN":75,"LSN":49,"CLSN":1}}
{"type":"meta","next_id":{"DSC":35,"AGD":38,"DEC":35,"PLN":75,"LSN":51,"CLSN":1}}
{"type":"discussion","id":"DSC-0034","status":"done","ticket":"frontend-semantic-host-projection-flexibility","title":"Frontend semantic vocabulary flexibility and declarative host projection","created_at":"2026-05-06","updated_at":"2026-05-07","tags":["compiler","compiler-general","frontend","semantics","vscode","host-projection","lsp"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0048","file":"discussion/lessons/DSC-0034-frontend-semantic-host-projection-flexibility/LSN-0048-frontend-owned-semantic-vocabularies-with-declarative-host-projection.md","status":"done","created_at":"2026-05-07","updated_at":"2026-05-07"}]}
{"type":"discussion","id":"DSC-0033","status":"in_progress","ticket":"frontend-visual-theme-spec-and-css-retirement","title":"Frontend visual theme spec and retirement of host-consumed semantic CSS","created_at":"2026-05-06","updated_at":"2026-05-06","tags":["compiler","compiler-general","frontend","presentation","theming","studio","vscode","lsp","pbs"],"agendas":[{"id":"AGD-0036","file":"AGD-0036-frontend-visual-theme-spec-and-css-retirement.md","status":"accepted","created_at":"2026-05-06","updated_at":"2026-05-06"}],"decisions":[{"id":"DEC-0033","file":"DEC-0033-frontend-visual-theme-spec-and-css-retirement.md","status":"accepted","created_at":"2026-05-06","updated_at":"2026-05-06","ref_agenda":"AGD-0036"}],"plans":[{"id":"PLN-0068","file":"PLN-0068-frontend-visual-contract-and-pbs-migration.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0069","file":"PLN-0069-lsp-visual-theme-transport-and-selection.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0070","file":"PLN-0070-studio-visual-theme-adapter-and-css-retirement.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]},{"id":"PLN-0071","file":"PLN-0071-vscode-dynamic-theme-translation-adapter.md","status":"open","created_at":"2026-05-06","updated_at":"2026-05-06","ref_decisions":["DEC-0033"]}],"lessons":[]}
{"type":"discussion","id":"DSC-0033","status":"done","ticket":"frontend-visual-theme-spec-and-css-retirement","title":"Frontend visual theme spec and retirement of host-consumed semantic CSS","created_at":"2026-05-06","updated_at":"2026-05-08","tags":["compiler","compiler-general","frontend","presentation","theming","studio","vscode","lsp","pbs"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0050","file":"discussion/lessons/DSC-0033-frontend-visual-theme-spec-and-css-retirement/LSN-0050-frontend-owned-visual-themes-with-structured-contract-and-host-adapters.md","status":"done","created_at":"2026-05-08","updated_at":"2026-05-08"}]}
{"type":"discussion","id":"DSC-0032","status":"done","ticket":"studio-new-lsp-api-and-v1-boundary","title":"Novo boundary entre lsp-api, lsp-v1 e a extensao VS Code","created_at":"2026-05-05","updated_at":"2026-05-07","tags":["studio","lsp","vscode","protocol","api","boundary"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0047","file":"discussion/lessons/DSC-0032-studio-new-lsp-api-and-v1-boundary/LSN-0047-project-scoped-lsp-boundary-and-protocol-containment.md","status":"done","created_at":"2026-05-07","updated_at":"2026-05-07"}]}
{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"lessons":[]}
{"type":"discussion","id":"DSC-0031","status":"done","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-08","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0049","file":"discussion/lessons/DSC-0031-studio-editor-workspace-cleanup/LSN-0049-remove-the-embedded-editor-stack-before-rebuilding-code-workflows.md","status":"done","created_at":"2026-05-08","updated_at":"2026-05-08"}]}
{"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"}]}

84
discussion/lessons/DSC-0031-studio-editor-workspace-cleanup/LSN-0049-remove-the-embedded-editor-stack-before-rebuilding-code-workflows.md Normal file
View File

@ -0,0 +1,84 @@
---
id: LSN-0049
discussion: DSC-0031
title: Remove the embedded editor stack before rebuilding code workflows
status: done
created: 2026-05-08
updated: 2026-05-08
tags: [studio, editor, cleanup, lsp, vfs, shell, migration]
---
## Original Problem
Studio still carried an embedded `Code Editor` workspace together with a `prometeu-vfs` boundary and a legacy `prometeu-lsp` path that existed only to support that editor.
That stack had become architectural drag:
- the JavaFX editor was no longer a product direction;
- the legacy `VFS` and `LSP` contracts were shaped around that editor model;
- shell state and project session still persisted editor-specific assumptions;
- and keeping those surfaces alive made any future code-backend redesign harder.
## Consolidated Decision
`DEC-0031` locked a full cleanup of the embedded editor stack.
The repository removed:
- the `Code Editor` workspace as an active Studio surface;
- the legacy editor-owned `VFS` boundary;
- the legacy editor-era `LSP` assumptions;
- shell/session/state dependencies that expected the editor to exist;
- and normative references that treated that stack as current architecture.
The decision also locked an equally important limit:
- this cleanup was not allowed to define the future code backend;
- a replacement LSP or automation boundary had to come later, in separate discussion.
## Final Result
The Studio shell now opens with surviving workspaces only: `Assets`, `Debug`, and `Shipper`.
Project-local state no longer persists editor restoration or editor layout fields, while still loading old state safely and falling back to surviving shell behavior.
The cleanup also succeeded without freezing the repository in a "no LSP ever again" state.
Later work in `DSC-0032` introduced a new project-scoped LSP boundary as separate architecture, which is exactly what `DEC-0031` required: remove the old stack first, then rebuild cleanly under a new decision.
## Implementation Notes
The cleanup landed in three coordinated waves:
1. shell/session/state cleanup removed `WorkspaceId.EDITOR`, editor restoration state, and editor-owned session composition;
2. the old editor-era `VFS` and `LSP` stack stopped being the active Studio foundation;
3. specs, tests, and historical references were revised so the removed editor stack no longer appears as current product guidance.
This produced an important boundary reset:
- Studio remains responsible for launcher, assets, shipper, debug, build, and run orchestration;
- code-editing architecture is no longer smuggled in through dead UI or legacy session seams.
## Example
Before the cleanup, an old `.studio/state.json` could still restore editor-centric state.
After the cleanup, the same persisted payload is treated defensively:
- old editor fields are ignored;
- the selected workspace falls back safely when `EDITOR` is present;
- the project reopens into a surviving workspace instead of reviving a dead surface.
## Pitfalls and Anti-Patterns
- Do not preserve dead editor-era boundaries "for compatibility" when the product direction has already moved.
- Do not treat naming continuity as architectural continuity. A later `prometeu-lsp` module can be valid if it comes from a new discussion and a new boundary.
- Do not leave project-local state as an accidental migration trap; persisted legacy fields must degrade safely.
## References
- `AGD-0034` Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados
- `DEC-0031` Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados
- `PLN-0062` Shell Session and State Cleanup After Editor Removal
- `PLN-0063` Legacy LSP and VFS Module Removal with Runtime Preservation
- `PLN-0064` Normative Test and Lesson Cleanup for Editor Stack Removal
- `LSN-0047` Project-scoped LSP boundary and protocol containment

93
discussion/lessons/DSC-0033-frontend-visual-theme-spec-and-css-retirement/LSN-0050-frontend-owned-visual-themes-with-structured-contract-and-host-adapters.md Normal file
View File

@ -0,0 +1,93 @@
---
id: LSN-0050
discussion: DSC-0033
title: Frontend-owned visual themes with structured contract and host adapters
status: done
created: 2026-05-08
updated: 2026-05-08
tags: [compiler, compiler-general, frontend, presentation, theming, lsp, vscode, pbs]
---
## Original Problem
Frontend semantic presentation was frontend-owned in principle, but not in a form that could survive multiple hosts.
PBS still depended on authored semantic CSS as the practical visual source of truth, which created three problems:
- CSS was a host-facing artifact rather than a compiler-general contract;
- VS Code could only approximate frontend intent through manual translation;
- every host risked drifting away from the frontend's real visual identity.
## Consolidated Decision
`DEC-0033` replaced authored host-consumed semantic CSS with a structured frontend-owned visual contract.
That contract now owns:
- the frontend theme list;
- the default active theme;
- token-scoped styles;
- editor-surface palette data;
- and host projections used to translate frontend semantic keys into host-native semantic selectors.
Hosts are adapters over this data.
They do not own frontend visual truth.
## Final Result
The canonical visual source now lives in `FrontendSemanticPresentationSpec`, with concrete PBS theme data and host projections authored in structured Java models instead of CSS resources.
The new LSP path transports:
- frontend semantic keys;
- visual themes;
- active theme identity;
- and host projection metadata.
The VS Code extension consumes that payload and writes semantic token and workbench color customizations dynamically, which means routine frontend color changes no longer require hand-edited extension theme tables.
The old PBS semantic CSS still exists only as migration residue and derivative compatibility material.
It is no longer the authored canonical contract.
## Implementation Notes
The decision was realized across four layers:
1. compiler/frontend metadata grew a structured presentation contract;
2. PBS migrated its theme definition into that contract;
3. the LSP description path started exporting visual themes and host projections;
4. the VS Code extension became a mechanical translator of the contract at runtime.
This also clarified the relationship between `DSC-0033` and `DSC-0034`:
- `DSC-0033` established the structured theme contract and CSS retirement;
- `DSC-0034` established that host projections belong in the frontend contract rather than in the host.
Together they define the current highlight pipeline.
## Example
For PBS today:
- the frontend publishes semantic keys such as `pbs-keyword` and `pbs-service`;
- the same frontend publishes the canonical theme colors and emphasis flags for those keys;
- the LSP sends the theme plus a `vscode` host projection;
- the VS Code extension applies both the canonical semantic selectors and the projected host selectors.
This is why a color change in PBS theme data can flow to VS Code without a new curated palette in `package.json`.
## Pitfalls and Anti-Patterns
- Do not reintroduce CSS as a silent second source of truth.
- Do not move frontend theme authorship into host adapters just because one host has capability gaps.
- Do not collapse frontend semantic identity into generic host categories during transport; host categories are projections, not the canonical vocabulary.
## References
- `AGD-0036` Frontend Visual Theme Spec and Retirement of Host-Consumed Semantic CSS
- `DEC-0033` Frontend-owned visual theme spec as canonical presentation contract
- `PLN-0068` Frontend Visual Contract and PBS Migration
- `PLN-0069` LSP Visual Theme Transport and Theme Selection Propagation
- `PLN-0070` Studio Visual Theme Adapter and CSS Retirement
- `PLN-0071` VS Code Dynamic Theme Translation Adapter
- `LSN-0048` Frontend-owned semantic vocabularies with declarative host projection

106
discussion/workflow/agendas/AGD-0034-vscode-editor-migration-feasibility.md
View File

@ -1,106 +0,0 @@
---
id: AGD-0034
ticket: studio-editor-workspace-cleanup
title: Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados
status: accepted
created: 2026-05-05
resolved: 2026-05-05
decision: DEC-0031
tags: [studio, editor, cleanup, vfs, lsp, migration]
---
## Pain
O repositório ainda carrega um `Workspace Editor` no `prometeu-studio` junto com camadas de `VFS` e `LSP` desenhadas especificamente para esse editor embutido.
Esse conjunto virou um legado arquitetural:
- o editor JavaFX não é mais a direção do produto;
- o `prometeu-vfs` atual está acoplado ao modelo editorial do editor embutido;
- o `prometeu-lsp` atual está acoplado ao `VFS` e ao host local do Studio;
- e manter essa base viva só aumenta o custo da futura reconstrução correta do backend de código.
## Context
- O monorepo já separa `prometeu-compiler`, `prometeu-packer` e `prometeu-studio`, mas o `prometeu-lsp` e o `prometeu-vfs` atuais nasceram como suporte ao editor embutido.
- A capacidade de compilação dos projetos deve continuar existindo no Studio.
- O alvo imediato não é discutir o novo LSP nem o novo contrato de automação.
- O alvo imediato é remover:
- o `Workspace Editor`;
- o `prometeu-lsp` legado usado por ele;
- e o `prometeu-vfs` acoplado a esse modelo editorial.
- O Studio continua existindo como produto fora do editor:
- shell e launcher de projeto;
- assets workspace;
- shipper/build surfaces;
- play/stop e integração com runtime/debug.
- Uma agenda futura poderá discutir a reconstrução do backend de código e do novo servidor LSP, mas isso fica fora deste artefato.
## Open Questions
- Quais partes do `prometeu-vfs` atual pertencem exclusivamente ao `Workspace Editor` e podem ser removidas integralmente?
- Existe algum consumer ainda válido do `prometeu-lsp` legado fora do editor embutido?
- O fluxo `play` ou qualquer outro fluxo do Studio depende hoje, mesmo indiretamente, de APIs do editor legado, do `VFS` legado ou do `LSP` legado?
- A limpeza deve remover apenas código de produção ou também specs, testes, lessons e referências que tratam o editor embutido como superfície ativa?
- Quais contratos de compilação precisam ser preservados explicitamente enquanto a camada de edição é removida?
## Options
### Option A - Manter o editor legado até a reconstrução completa do backend de código
- **Approach:** adiar a limpeza e preservar temporariamente `Workspace Editor`, `prometeu-vfs` legado e `prometeu-lsp` legado até o novo backend existir.
- **Pro:** menor ruptura imediata.
- **Con:** prolonga a vida do legado, aumenta custo de manutenção e deixa a futura reconstrução mais confusa.
- **Maintainability:** fraca.
### Option B - Limpeza completa agora, preservando apenas a compilação do Studio
- **Approach:** remover `Workspace Editor`, `prometeu-lsp` legado e o `prometeu-vfs` acoplado a esse modelo, mantendo apenas as superfícies de compilação e execução que não dependem desse stack.
- **Pro:** reduz o legado antes da reconstrução, clarifica boundaries e impede que o futuro LSP nasça comprometido por compatibilidade acidental.
- **Con:** cria um período sem editor embutido e sem backend de código novo dentro do Studio.
- **Maintainability:** forte.
Vamos de Option B.
## Discussion
O trabalho desta agenda não é desenhar o novo backend de código.
O trabalho desta agenda é remover o legado que impediria esse redesenho.
Isso implica alguns cortes diretos:
- o `Workspace Editor` deixa de ser superfície ativa do Studio;
- o `prometeu-lsp` atual deixa de ser tratado como base evolutiva;
- o `prometeu-vfs` atual, por ser acoplado ao modelo editorial do editor embutido, sai junto com esse stack;
- as capacidades de compilação, build e execução que não dependem desse stack devem ser preservadas.
O princípio aqui é de limpeza arquitetural antes de reconstrução:
- não carregar compatibilidade acidental com o editor antigo;
- não manter um `VFS` ou `LSP` cujo contrato nasce de um modelo que já foi abandonado;
- e não misturar, nesta discussão, a limpeza do legado com o desenho do futuro servidor LSP.
Isso também reduz o risco de falsa migração:
- em vez de adaptar o editor atual, o repositório assume explicitamente que ele vai morrer;
- em vez de reaproveitar um `LSP` embrionário acoplado ao host local, o repositório aceita que um novo backend de código será desenhado depois;
- e em vez de preservar o `VFS` por inércia, o repositório valida se ele ainda possui valor fora do modelo que o originou.
## Resolution
Recomendação preliminar:
- seguir com a Option B;
- tratar esta agenda exclusivamente como limpeza completa do `Workspace Editor` do Studio;
- remover junto o `prometeu-lsp` legado e o `prometeu-vfs` acoplado a esse modelo;
- preservar explicitamente a capacidade de compilação e os fluxos do Studio que não dependem desse stack;
- e abrir uma discussão futura separada para o backend de código novo, o novo LSP e o contrato de automação.
## Next Step
Se a direção fizer sentido, o próximo passo disciplinado é fechar uma `decision` com:
1. o escopo exato da remoção do `Workspace Editor`;
2. o escopo exato da remoção do `prometeu-lsp` legado;
3. o escopo exato da remoção do `prometeu-vfs` acoplado a esse modelo;
4. as capacidades de compilação e execução que devem sobreviver intactas;
5. e os artefatos normativos, testes e código que precisam ser limpos ou preservados.

147
discussion/workflow/agendas/AGD-0036-frontend-visual-theme-spec-and-css-retirement.md
View File

@ -1,147 +0,0 @@
---
id: AGD-0036
ticket: frontend-visual-theme-spec-and-css-retirement
title: Frontend Visual Theme Spec and Retirement of Host-Consumed Semantic CSS
status: accepted
created: 2026-05-06
resolved: 2026-05-06
decision: DEC-0033
tags: [compiler, compiler-general, frontend, presentation, theming, studio, vscode, lsp, pbs]
---
## Pain
The current semantic highlighting path is no longer strong enough now that Prometeu must project frontend-owned presentation into more than one host.
Today the frontend still effectively ships a host-facing CSS file as the practical source of truth for visual presentation.
That works tolerably for the legacy Studio editor path, but it collapses once the same frontend presentation must be exported to VS Code through LSP semantic tokens.
The result is a weak cross-host contract:
- the frontend publishes semantic keys, but not a complete visual spec,
- `semantic-highlighting.css` still acts as the real authored presentation artifact,
- VS Code only receives a partial hand-translated approximation,
- and each host risks drifting away from the frontend's intended visual identity.
The CSS file should be treated as migration input only and must die by the end of this refactor.
## Context
Domain owner: `compiler/general`
Propagation targets are expected in at least three places:
- compiler frontend metadata and contracts,
- Studio host consumption,
- VS Code extension host consumption.
Relevant historical context already exists in `LSN-0029`, which established frontend ownership of semantic presentation metadata through `FrontendSpec`.
That lesson is still useful for ownership boundaries, but it is not sufficient for the next wave because the current contract is too weak and too resource-oriented.
Current state:
- `FrontendSemanticPresentationSpec` exposes only `semanticKeys` and opaque `resources`,
- PBS publishes `/themes/pbs/semantic-highlighting.css` as a semantic presentation resource,
- Studio can consume that resource directly,
- VS Code cannot consume that CSS directly and must approximate it via `package.json` and semantic token theming,
- recent LSP work now transports PBS semantic token types, but the host-side rendering still falls short of the original PBS editor look.
What is missing is a frontend-owned visual spec that is structured enough to be exported to multiple hosts without making CSS the canonical source.
## Open Questions
- [x] What is the canonical replacement for `semantic-highlighting.css` inside `FrontendSpec`?
R: a structured visual presentation spec (a JSON) that includes semantic token styles and editor-level colors.
- [x] Which parts of frontend presentation are normative and cross-host, and which are host-specific adapters only?
R: a ideia eh que o FE presentation possa ser completamente expostado para os clientes como o VSCode.
- [x] Should the visual contract be semantic-token-centric only, or should it also include editor-level colors such as base foreground, selection, gutter, and accent surfaces?
R: o contrato visual pode ofertar toda essa gama de atributos para cada token, o cliente (VSCode) pode usa-los para compor o tema, mas o contrato deve ser token-centric para garantir que a intenção visual seja sempre atrelada a chaves semânticas.
- [x] How should Studio consume the new visual spec without keeping CSS as a hidden canonical source?
R: o FE Presentation na medida que o servidor eh described oferece um contrato visual estruturado, o cliente (VSCode extension) deve consumir esse contrato e gerar o que tiver que gerar para compor o tema. Se o cliente usar CSS que gere isso.
- [x] How should VS Code consume the new visual spec: static generated contribution, runtime translation, or both?
R: A ideia eh que o cliente seja bem burro, ele deve ser uma maquina que traduz o contrato visual para um formato que o VSCode entenda, seja isso um contribution estatico ou uma tradução dinamica, o importante eh que o contrato visual seja o unico input e a fonte de verdade para a intencao visual do frontend.
- [x] How do we phase out existing frontend-owned CSS resources without breaking current Studio rendering during migration?
R: nada no studio depende desse CSS, ele eh um artefato de migração para o PBS. O contrato visual deve ser definido e implementado no PBS primeiro, usando o CSS como input para derivar o formato estruturado. Depois disso, o CSS pode ser descontinuado.
- [x] How do we version and validate the visual contract so new frontends can implement it consistently?
R: o contrato deve viver dentro de `FrontendSpec` e ser versionado junto com ele.
## Options
### Option A - Keep CSS as the canonical frontend artifact and add exporters around it
- **Approach:** Preserve `semantic-highlighting.css` as the frontend-owned source and build tooling that parses or translates it into Studio and VS Code outputs.
- **Pro:** Smallest migration cost in the short term, because PBS already has authored CSS.
- **Con:** Keeps host-facing CSS as the source of truth, which is the wrong abstraction for multi-host consumption and weak for validation.
- **Maintainability:** Poor. Every new host would need a CSS interpretation path or a CSS-to-host adapter with lossy translation rules.
### Option B - Introduce a structured frontend visual spec and treat CSS as a temporary migration input
- **Approach:** Replace the current resource-centric semantic presentation contract with a structured visual spec published by the frontend. Use the existing CSS only as bootstrap input while migrating PBS, then retire it as canonical data.
- **Pro:** Creates a real multi-host contract that can be exported mechanically to Studio and VS Code while preserving frontend ownership.
- **Con:** Requires contract design, adapter work in both hosts, and a migration story for current frontend resources.
- **Maintainability:** Strong. New frontends would author one canonical visual contract and hosts would implement stable adapters.
### Option C - Split the contract into semantic vocabulary plus host-owned themes
- **Approach:** Keep frontend ownership only over semantic keys and let each host define its own visual theme for those keys.
- **Pro:** Simplifies frontend metadata and gives each host more freedom.
- **Con:** Reintroduces host ownership over frontend meaning in practice and guarantees visual drift between Studio and VS Code.
- **Maintainability:** Medium at best. It reduces frontend burden but loses the core requirement of frontend-owned identity.
## Tradeoffs
Option A looks attractive because it reuses existing assets, but it cements the wrong boundary.
If CSS remains canonical, the compiler/frontend layer still cannot describe its own presentation in a host-neutral way.
Option C is cleaner than the current situation from a tooling perspective, but it fails the product goal.
The user experience would vary per host because visual meaning would no longer be frontend-owned.
Option B is the only direction that preserves the previous ownership decision while extending it into a credible cross-host architecture.
Its cost is real, but that cost is exactly the work we need to make the contract durable.
## Recommendation
Adopt Option B.
The frontend should publish a structured visual presentation spec as canonical data.
That spec should become the only normative source for frontend semantic/editor appearance that is intended to survive across hosts.
`semantic-highlighting.css` should be used only as migration input for PBS while we derive the first structured visual spec.
After migration, CSS may remain as a generated Studio adapter artifact for a while, but it must no longer be treated as authored truth.
The new contract likely needs at least these conceptual layers:
- semantic token styles,
- editor surface colors,
- optional UI accent colors tied to the editing surface,
- explicit host adapter boundaries.
The LSP path should transport structured visual data or enough structured metadata for the VS Code extension to render the same frontend-owned intent without reverse-engineering CSS.
## Discussion
This agenda is intentionally narrower than “general editor theming”.
The problem is not to invent a universal Prometeu theme engine first.
The problem is to stop using frontend-authored CSS as the canonical semantic/editor presentation contract and replace it with a frontend-owned visual spec that survives host translation.
The most important discipline point is ownership:
- compiler/frontend owns semantic and visual intent,
- LSP transports frontend-owned intent,
- Studio and VS Code are rendering adapters,
- host adapters may have capability gaps, but they must not become canonical.
There is also an important migration constraint:
- PBS is the first frontend and will define the initial shape,
- but the contract must not become “PBS-specific metadata with generic naming later”,
- instead it must be valid as a compiler-general surface that PBS implements first.
## Resolution
Accepted on 2026-05-06.
The discussion resolves in favor of a structured frontend-owned visual theme specification with support for multiple themes per frontend.
Themes remain tied to the frontend's own semantic vocabulary.
Studio and the VS Code extension act as adapters over that contract.
`semantic-highlighting.css` remains migration input only and must be retired as canonical authored truth.

148
discussion/workflow/decisions/DEC-0031-studio-editor-workspace-cleanup.md
View File

@ -1,148 +0,0 @@
---
id: DEC-0031
ticket: studio-editor-workspace-cleanup
title: Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados
status: in_progress
created: 2026-05-05
accepted: 2026-05-05
agenda: AGD-0034
plans: [PLN-0062, PLN-0063, PLN-0064]
tags: [studio, editor, cleanup, vfs, lsp, migration]
---
## Decision
O repositório SHALL remover integralmente o `Workspace Editor` do Studio como superfície ativa do produto.
Essa remoção SHALL incluir:
1. o workspace de código embutido em `prometeu-studio`;
2. o `prometeu-lsp` legado usado por esse workspace;
3. o `prometeu-vfs` legado acoplado ao modelo editorial desse workspace;
4. os pontos de integração do shell, da sessão de projeto e do bootstrap que assumem a existência desse stack;
5. e os artefatos normativos, testes e referências documentais que tratam esse stack como superfície vigente.
Ao mesmo tempo, esta decisão ALSO locks que:
1. a capacidade de compilação dos projetos MUST permanecer disponível no Studio;
2. os fluxos atuais de `build`, `play`, `run` e `debug` MUST permanecer funcionais desde que não dependam do editor legado, do `prometeu-lsp` legado ou do `prometeu-vfs` legado;
3. esta decisão MUST NOT introduzir o novo backend de código, o novo servidor LSP ou o futuro contrato de automação;
4. qualquer reconstrução dessas superfícies MUST acontecer em discussão posterior e separada.
## Rationale
O `Workspace Editor`, o `prometeu-lsp` atual e o `prometeu-vfs` atual formam um stack único, criado especificamente para o editor embutido do Studio.
Esse stack não é mais alinhado à direção do produto:
1. o editor JavaFX deixou de ser a direção principal;
2. o `prometeu-lsp` atual não deve ser tratado como base séria para um futuro servidor LSP;
3. o `prometeu-vfs` atual carrega um contrato editorial pensado para o editor embutido;
4. manter esse legado vivo aumenta o custo de reconstrução e preserva boundaries errados por inércia.
Portanto, a limpeza precisa acontecer antes da reconstrução.
## Technical Specification
### 1. Editor Workspace Removal
O Studio MUST remover a superfície `Code Editor` do shell.
Isso inclui:
1. remover `WorkspaceId.EDITOR`;
2. remover o `EditorWorkspace` e todos os controles, painéis, modelos e helpers sob `prometeu-studio/.../workspaces/editor`;
3. remover a presença do editor na workspace rail, no layout principal e no fluxo de restauração de shell;
4. remover strings, ícones e estado visual exclusivos dessa superfície.
### 2. Legacy LSP Removal
O repositório MUST remover o `prometeu-lsp` legado como módulo ativo.
Isso inclui:
1. remover os módulos `prometeu-lsp-api` e `prometeu-lsp-v1`;
2. remover `LspService`, `LspServiceFactory` e todos os DTOs/messages específicos desse stack legado;
3. remover a criação e injeção dessas dependências no `AppContainer`, no `Container`, na sessão de projeto e nos testes associados;
4. remover a hipótese de que esse `LSP` será evoluído para o futuro backend de código.
Os conceitos úteis descobertos nesse stack MAY ser reaproveitados mais tarde, mas esta decisão não preserva compatibilidade de código, pacote ou contrato com ele.
### 3. Legacy VFS Removal
O repositório MUST remover o `prometeu-vfs` legado como módulo ativo.
Isso inclui:
1. remover os módulos `prometeu-vfs-api` e `prometeu-vfs-v1`;
2. remover `VfsProjectDocument`, `ProjectDocumentVfsFactory` e implementações filesystem-backed associadas;
3. remover a criação e posse desse `VFS` na sessão de projeto;
4. remover qualquer regra que trate esse `VFS` como boundary documental vigente do Studio.
Esta decisão assume que o `prometeu-vfs` atual pertence ao modelo do editor legado e, portanto, não deve sobreviver por compatibilidade acidental.
### 4. Session and Shell Cleanup
O Studio MUST reconfigurar a sessão de projeto e o shell principal para não depender do stack removido.
Isso inclui:
1. remover `LSP` e `VFS` legados da estrutura de `StudioProjectSession`;
2. remover sua criação em `StudioProjectSessionFactory`;
3. remover dependências globais correspondentes do bootstrap e do container;
4. remover persistência de layout e restauração editorial específicas do editor.
### 5. State Cleanup
O estado local do projeto MUST deixar de persistir dados exclusivos do editor legado.
Isso inclui:
1. remover `editorRestoration`;
2. remover `shellLayout.editorLayout`;
3. garantir fallback seguro para estados antigos já persistidos em `.studio/state.json`;
4. preservar apenas os campos ainda pertencentes a workspaces vivos e ao shell remanescente.
### 6. Documentation and Test Cleanup
O repositório MUST limpar artefatos normativos e testes que descrevem o stack legado como vigente.
Isso inclui:
1. revisar ou remover as specs do `Code Editor`, do `Project Document VFS` e do `Integrated LSP Semantic Read Phase`;
2. revisar `docs/specs/studio/README.md`;
3. remover ou arquivar testes exclusivos do editor, do `prometeu-lsp` legado e do `prometeu-vfs` legado;
4. revisar lessons e referências históricas para deixar explícito que se tratam de legado, quando forem mantidas.
### 7. Capabilities That MUST Survive
As seguintes capacidades MUST sobreviver a esta limpeza:
1. compilação de projetos pelo pipeline canônico existente;
2. build de artefatos via `BuilderPipelineService`;
3. preparação do fluxo de shipper;
4. `play`, `run` e `debug` do Studio, desde que apoiados nas superfícies remanescentes e não no stack removido;
5. workspaces `Assets`, `Shipper` e `Debug`, além do launcher e do shell geral.
### 8. Explicit Non-Goals
Esta decisão MUST NOT:
1. definir o novo servidor LSP;
2. definir o novo contrato de automação;
3. definir o novo modelo de sessão de código;
4. definir integração com VS Code;
5. reter compatibilidade com o `LSP` ou `VFS` legados por conveniência.
## Constraints
1. A limpeza MUST preservar o pipeline canônico `analyze`, `compile` e `build` já existente no compiler.
2. A limpeza MUST evitar remover ou degradar fluxos de `build/run/debug` que hoje dependem apenas de `compiler`, `shipper`, runtime e shell.
3. A limpeza MUST deixar o shell do Studio em estado coerente, sem workspace fantasma, sem layout órfão e sem dependências mortas.
4. A limpeza MUST tratar specs e estado persistido como parte do trabalho, não como detalhe pós-código.
5. A futura reconstrução do backend de código SHALL nascer em discussão separada, sem herdar obrigação de compatibilidade com o stack removido.
## Revision Log
- 2026-05-05: Initial draft from AGD-0034.
- 2026-05-05: Accepted and decomposed into PLN-0062, PLN-0063, and PLN-0064.

152
discussion/workflow/decisions/DEC-0033-frontend-visual-theme-spec-and-css-retirement.md
View File

@ -1,152 +0,0 @@
---
id: DEC-0033
ticket: frontend-visual-theme-spec-and-css-retirement
title: Frontend-owned visual theme spec as canonical presentation contract
status: accepted
created: 2026-05-06
accepted: 2026-05-06
agenda: AGD-0036
plans: [PLN-0068, PLN-0069, PLN-0070, PLN-0071]
tags: [compiler, compiler-general, frontend, presentation, theming, studio, vscode, lsp, pbs]
---
## Decision
Prometeu SHALL replace frontend-authored host-consumed semantic CSS with a structured frontend-owned visual theme specification as the canonical presentation contract.
This decision locks the following normative points:
1. Each `FrontendSpec` MUST publish its own semantic vocabulary and MAY publish multiple visual themes for that vocabulary.
2. Visual themes MUST be frontend-owned and MUST remain associated with the semantic tokens defined by that same frontend.
3. `semantic-highlighting.css` MUST be treated as migration input only and MUST cease to be an authored canonical contract by the end of this refactor.
4. Studio and the VS Code extension MUST act as rendering adapters over the frontend-owned visual contract and MUST NOT become owners of frontend theme data.
5. The VS Code extension MUST translate the frontend visual contract dynamically or mechanically from the contract itself, so frontend visual adjustments do not require extension maintenance for each theme change.
## Rationale
The current model is structurally weak for multi-host consumption.
PBS still carries a CSS resource that works as the practical source of visual truth, while VS Code can only consume a partial manual approximation through semantic token configuration.
That creates the wrong ownership boundary:
1. the frontend owns semantic meaning but does not fully own its exported visual contract;
2. hosts are forced to reinterpret or approximate visual intent;
3. every frontend visual adjustment risks requiring host edits;
4. visual drift becomes likely across Studio and VS Code.
The repository already established that semantic presentation belongs to the frontend.
This decision extends that ownership model into a stronger cross-host contract:
1. the frontend authors semantic and visual intent once;
2. LSP transports that intent;
3. hosts adapt it without redefining it.
## Technical Specification
### 1. Canonical Visual Contract
`FrontendSpec` MUST evolve to expose a structured visual presentation contract as canonical data.
That contract MUST:
1. live with the frontend definition;
2. be versioned together with `FrontendSpec`;
3. be sufficient for multiple hosts to render the frontend's intended appearance without interpreting CSS as the source of truth;
4. remain compiler-general even if PBS is the first frontend to implement it.
The canonical contract MAY be encoded as JSON-backed structured data or as an equivalent strongly-typed model, but the authored source of truth MUST be the structured visual contract, not CSS.
### 2. Frontend-Owned Themes
Each frontend MAY publish multiple visual themes.
Rules:
1. themes MUST belong to the frontend that defines the semantic vocabulary they style;
2. themes MUST be expressed in terms of that frontend's own semantic token keys and related editor presentation surfaces;
3. hosts MAY select which frontend theme is active;
4. hosts MUST NOT redefine the theme contract as host-owned authored data.
This means theme ownership is:
1. frontend authors themes,
2. host selects and applies themes,
3. host does not author the frontend visual semantics.
### 3. Token-Centric Contract with Editor Surfaces
The visual contract MUST be token-centric, but it SHALL also support editor-level presentation data where needed to preserve frontend visual intent.
Therefore the contract MUST be able to express:
1. token-scoped presentation such as foreground, emphasis, and related token styling attributes;
2. editor surface colors such as base foreground, selection, gutter, and other editing-surface colors when they are part of frontend visual intent;
3. optional frontend-specific accents tied to the editing experience.
Token-centricity remains mandatory because semantic meaning MUST stay anchored to semantic keys.
Editor-surface data is allowed because semantic fidelity alone is insufficient to reproduce frontend identity across hosts.
### 4. Host Adapter Responsibilities
Studio and the VS Code extension MUST consume the frontend visual contract as adapters.
Studio:
1. MUST consume the structured frontend visual contract;
2. MAY render through generated CSS or another host mechanism;
3. MUST NOT treat generated CSS as the canonical frontend artifact.
VS Code extension:
1. MUST consume the frontend visual contract through the server description path or an equivalent frontend-owned transport surface;
2. MUST translate that contract into whatever VS Code requires, whether through runtime translation, generated contributions, or another adapter mechanism;
3. MUST behave as a mechanical translator of the frontend contract;
4. MUST NOT require hand-maintained extension theme edits whenever a frontend changes a color, emphasis rule, or theme variant.
### 5. LSP Transport Responsibilities
The LSP path MUST transport enough structured frontend-owned visual information for hosts to render the active frontend theme.
It MUST preserve:
1. frontend identity,
2. semantic token identity,
3. theme identity where multiple themes exist,
4. visual attributes needed by the host adapter.
LSP MUST NOT collapse frontend themes into host-authored generic theme categories.
### 6. Migration and CSS Retirement
`semantic-highlighting.css` is allowed only as migration input for the first structured contract derivation.
Migration rules:
1. PBS SHALL be the first frontend migrated;
2. the existing PBS CSS MAY be parsed or manually transcribed into the first canonical structured visual contract;
3. once the structured contract becomes authoritative, the CSS MUST no longer be treated as authored truth;
4. any remaining CSS after migration MAY exist only as generated adapter output or as temporary compatibility residue scheduled for removal;
5. the refactor is not complete while host-consumed semantic CSS remains the canonical frontend presentation source.
### 7. Extension Stability Requirement
This decision explicitly locks an operational requirement for `tools/vscode-extension`:
1. frontend visual changes MUST be expressible by changing frontend-owned contract data;
2. such frontend changes MUST NOT force routine extension source edits;
3. the extension SHALL be stable as a contract adapter rather than a repository of manually curated frontend theme rules.
## Constraints
1. The canonical source of frontend visual intent MUST move out of authored CSS.
2. Theme ownership MUST remain with the frontend.
3. The contract MUST support multiple themes per frontend.
4. The contract MUST remain compiler-general and MUST NOT hardcode PBS as the universal model.
5. Hosts MUST remain adapters and MUST NOT become fallback authors of frontend visual identity.
6. Any derived plan MUST include an explicit migration path for PBS and explicit retirement of `semantic-highlighting.css` as canonical data.
7. Any derived plan MUST cover compiler contract changes, transport propagation, Studio consumption, and VS Code consumption.
## Revision Log
- 2026-05-06: Initial accepted decision from AGD-0036.
- 2026-05-06: Decomposed into PLN-0068, PLN-0069, PLN-0070, and PLN-0071.

91
discussion/workflow/plans/PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md
View File

@ -1,91 +0,0 @@
---
id: PLN-0062
ticket: studio-editor-workspace-cleanup
title: Shell Session and State Cleanup After Editor Removal
status: done
created: 2026-05-05
completed: 2026-05-05
tags: [studio, editor, cleanup, shell, session, state]
---
## Objective
Remove the `Code Editor` workspace from the Studio shell and reconfigure project session and persisted state so the application remains coherent without any editor-owned concepts.
## Background
`DEC-0031` locks the complete removal of the embedded editor stack. The shell, project session, workspace registry, and `.studio/state.json` currently still assume the existence of `WorkspaceId.EDITOR`, `EditorWorkspace`, editor restoration state, and editor-specific layout state.
## Scope
### Included
- Remove `WorkspaceId.EDITOR` from the Studio shell.
- Remove `EditorWorkspace` registration and shell integration.
- Remove editor-specific state persistence and restoration paths.
- Remove `LSP`/`VFS` legacy ownership from `StudioProjectSession` and `StudioProjectSessionFactory`.
- Keep `Assets`, `Shipper`, `Debug`, launcher, and shell flows functional.
### Excluded
- Removal of the `prometeu-lsp` and `prometeu-vfs` module source trees themselves.
- Documentation and lesson cleanup.
- New code backend or replacement LSP architecture.
## Execution Steps
### Step 1 - Remove editor workspace registration from the shell
**What:** Remove all shell-level references to the `Code Editor` workspace.
**How:** Update the main window composition to stop creating `EditorWorkspace`, remove the editor rail item, stop selecting or restoring `WorkspaceId.EDITOR`, and ensure shell fallback remains stable when old persisted state still references the editor.
**File(s):** `prometeu-studio/src/main/java/p/studio/window/MainView.java`, `prometeu-studio/src/main/java/p/studio/workspaces/WorkspaceId.java`, any directly related shell controls or selectors.
### Step 2 - Remove editor-owned state and restoration from project-local state
**What:** Remove editor layout and restoration data from persisted project-local Studio state.
**How:** Simplify `ProjectLocalStudioState` to remove `editorRestoration` and `shellLayout.editorLayout`, update normalization/defaults, and make loading old `.studio/state.json` degrade safely without crashes or stale editor assumptions.
**File(s):** `prometeu-studio/src/main/java/p/studio/projectstate/ProjectLocalStudioState.java`, `prometeu-studio/src/main/java/p/studio/projectstate/ProjectLocalStudioStateService.java`, any callers that write or restore editor state.
### Step 3 - Reconfigure project session to stop owning editor legacy dependencies
**What:** Remove legacy editor-driven `LSP` and `VFS` ownership from project session composition.
**How:** Refactor `StudioProjectSession` and `StudioProjectSessionFactory` so opening a project no longer constructs `VfsProjectDocument` or `LspService`, and so close semantics remain valid without those resources.
**File(s):** `prometeu-studio/src/main/java/p/studio/projectsessions/StudioProjectSession.java`, `prometeu-studio/src/main/java/p/studio/projectsessions/StudioProjectSessionFactory.java`, dependent tests.
### Step 4 - Remove bootstrap/container dependencies that only existed for the editor stack
**What:** Remove application bootstrap and container seams that exist only to inject legacy editor stack services.
**How:** Delete `LspServiceFactory` and `ProjectDocumentVfsFactory` accessors from the container surfaces once shell/session no longer depend on them, and update `AppContainer` accordingly.
**File(s):** `prometeu-studio/src/main/java/p/studio/Container.java`, `prometeu-app/src/main/java/p/studio/AppContainer.java`, directly affected tests.
## Test Requirements
### Unit Tests
- Update session and state tests to reflect the absence of editor state.
- Add coverage for loading old persisted project-local state without editor restoration fields being required.
### Integration Tests
- Verify the main Studio shell opens a project and activates a surviving workspace without editor registration.
- Verify session close still saves valid project-local state and shuts down surviving services cleanly.
### Manual Verification
- Open the Studio shell and confirm only surviving workspaces appear.
- Reopen a project with stale `.studio/state.json` containing editor data and confirm safe fallback.
- Confirm project switching and shell startup remain stable.
## Acceptance Criteria
- [x] `WorkspaceId.EDITOR` no longer exists in production code.
- [x] `MainView` no longer instantiates or restores `EditorWorkspace`.
- [x] Project-local state no longer persists editor restoration or editor layout fields.
- [x] `StudioProjectSession` no longer owns legacy editor `LSP`/`VFS` resources.
- [x] The Studio shell remains functional with surviving workspaces.
## Dependencies
- `DEC-0031` accepted and normatively locked.
- Knowledge of all shell/session/state call sites that currently assume the editor exists.
## Risks
- Shell restoration may break if old persisted state is not normalized defensively.
- Session teardown may regress if hidden resource ownership remains after field removal.
- Removing editor assumptions too early may temporarily orphan callers still using editor-specific state APIs.

91
discussion/workflow/plans/PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md
View File

@ -1,91 +0,0 @@
---
id: PLN-0063
ticket: studio-editor-workspace-cleanup
title: Legacy LSP and VFS Module Removal with Runtime Preservation
status: done
created: 2026-05-05
completed: 2026-05-05
tags: [studio, editor, cleanup, lsp, vfs, runtime]
---
## Objective
Remove the legacy `prometeu-lsp` and `prometeu-vfs` modules and all remaining code references to them while preserving compiler, shipper, play, run, and debug flows that do not depend on the editor stack.
## Background
`DEC-0031` treats the current `prometeu-lsp` and `prometeu-vfs` modules as part of the embedded editor legacy stack. The Studio execution path must continue to compile, build, package, and run projects through the existing compiler and runtime orchestration layers.
## Scope
### Included
- Remove `prometeu-lsp` modules from Gradle settings and codebase references.
- Remove `prometeu-vfs` modules from Gradle settings and codebase references.
- Remove tests dedicated to these legacy modules.
- Verify `StudioShipperService`, `StudioPlayStopCoordinator`, and runtime/debug flows remain intact.
### Excluded
- Shell/editor state cleanup handled by a separate plan.
- Documentation/spec/lesson cleanup handled by a separate plan.
- New replacement backend services.
## Execution Steps
### Step 1 - Remove Gradle module registration for legacy editor stack modules
**What:** Stop building the legacy `prometeu-lsp` and `prometeu-vfs` modules.
**How:** Remove the module includes and any direct module dependencies that point to `prometeu-lsp:*` and `prometeu-vfs:*`, then fix resulting build graph fallout in Studio modules.
**File(s):** `settings.gradle.kts`, affected `build.gradle.kts` files in `prometeu-app`, `prometeu-studio`, and module directories.
### Step 2 - Remove legacy module source trees and direct test coverage
**What:** Delete the legacy `prometeu-lsp` and `prometeu-vfs` code once all consumers are detached.
**How:** Remove module source files and their dedicated tests only after production call sites no longer compile against them.
**File(s):** `prometeu-lsp/**`, `prometeu-vfs/**`, related test sources in `prometeu-studio`.
### Step 3 - Preserve compiler and shipper build flow
**What:** Ensure build preparation still uses the canonical compiler pipeline without editor legacy dependencies.
**How:** Validate and adjust `StudioShipperService` and any shipper/build callers so they continue using `BuilderPipelineService`, `BuilderPipelineConfig`, and `BuilderPipelineContext` directly without reintroducing removed editor-layer seams.
**File(s):** `prometeu-studio/src/main/java/p/studio/shipper/StudioShipperService.java`, affected compiler/shipper integration tests.
### Step 4 - Preserve play, run, and debug execution flow
**What:** Ensure runtime orchestration continues to function after legacy module removal.
**How:** Re-test and patch `StudioPlayStopCoordinator`, runtime handshake services, execution session handling, and debug workspace projections if any hidden import or event dependency pointed at removed editor-stack modules.
**File(s):** `prometeu-studio/src/main/java/p/studio/execution/StudioPlayStopCoordinator.java`, `prometeu-studio/src/main/java/p/studio/debug/runtime/**`, `prometeu-studio/src/main/java/p/studio/workspaces/debug/**`, related tests.
## Test Requirements
### Unit Tests
- Update or remove module-specific tests for `prometeu-lsp` and `prometeu-vfs`.
- Preserve unit coverage for execution session, play/stop coordination, and runtime handshake behavior.
### Integration Tests
- Run compiler pipeline integration tests that cover `analyze`, `compile`, and `build`.
- Run shipper/build integration tests that exercise `StudioShipperService`.
- Run runtime/debug integration or coordinator tests that validate play/stop behavior.
### Manual Verification
- Trigger Studio build flow and confirm artifact generation still works.
- Trigger Studio play flow and confirm runtime launch/stop still works.
- Open Debug and Shipper workspaces and confirm they remain operational.
## Acceptance Criteria
- [x] `prometeu-lsp` is no longer part of the build graph.
- [x] `prometeu-vfs` is no longer part of the build graph.
- [x] No production Studio class imports legacy `LSP` or `VFS` module types.
- [x] Compiler and shipper build flows still work.
- [x] Play/run/debug flows still work without the removed modules.
## Dependencies
- `DEC-0031` accepted and normatively locked.
- Shell/session cleanup completed enough that no surviving production code still requires legacy `LSP`/`VFS` types.
## Risks
- Hidden transitive dependencies may keep the build graph coupled to removed modules longer than expected.
- Runtime or debug flows may have indirect event or session assumptions not obvious from imports alone.
- Deleting modules too early may obscure compile errors that should instead be fixed in surviving Studio code first.

90
discussion/workflow/plans/PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md
View File

@ -1,90 +0,0 @@
---
id: PLN-0064
ticket: studio-editor-workspace-cleanup
title: Normative Test and Lesson Cleanup for Editor Stack Removal
status: done
created: 2026-05-05
completed: 2026-05-05
tags: [studio, editor, cleanup, docs, tests, lessons]
---
## Objective
Remove or revise the normative documentation, tests, lessons, and user-facing resources that describe the embedded editor stack as a current Studio surface.
## Background
`DEC-0031` treats the editor stack removal as both code cleanup and normative cleanup. The repository currently contains active specs, README entries, i18n resources, and lessons that define `Code Editor`, `prometeu-vfs`, and the integrated semantic-read phase as active architecture.
## Scope
### Included
- Remove or rewrite Studio specs dedicated to the embedded editor stack.
- Update the Studio specs index and README.
- Remove or archive editor/LSP/VFS-specific tests that are no longer valid.
- Reclassify legacy lessons and references so they are not presented as active guidance.
- Remove user-facing i18n strings that only existed for the editor stack.
### Excluded
- Implementation of shell/session/module cleanup itself.
- Future specs for the replacement backend or replacement external-editor strategy.
## Execution Steps
### Step 1 - Clean normative Studio specs
**What:** Remove or replace specs that define the embedded editor stack as active architecture.
**How:** Delete or explicitly retire the `Code Editor`, `Project Document VFS`, and `Integrated LSP Semantic Read Phase` specs, then rewrite any remaining Studio README/index material so it no longer points to dead architecture.
**File(s):** `docs/specs/studio/5. Code Editor Workspace Specification.md`, `docs/specs/studio/6. Project Document VFS Specification.md`, `docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md`, `docs/specs/studio/README.md`.
### Step 2 - Clean user-facing resources and shell references
**What:** Remove editor-specific strings, labels, and messages that no longer correspond to product surfaces.
**How:** Delete `workspace.code` and `codeEditor.*` message keys and any equivalent theme or resource references still tied to removed editor UI.
**File(s):** `prometeu-studio/src/main/resources/i18n/messages.properties`, any directly related theme or resource files.
### Step 3 - Clean tests and update surviving expectations
**What:** Remove tests whose sole purpose was validating the editor stack and update remaining tests to stop expecting that stack.
**How:** Delete or rewrite tests for editor workspace behavior, legacy `LSP`, legacy `VFS`, session expectations, and any shell assertions that still require the editor workspace.
**File(s):** `prometeu-studio/src/test/java/p/studio/projectsessions/**`, editor-related tests, `prometeu-lsp/**/test/**`, `prometeu-vfs/**/test/**`, any shell-level tests affected by workspace removal.
### Step 4 - Reclassify lessons and historical references
**What:** Ensure discussion lessons remain historically useful without being mistaken for current architecture.
**How:** Review the lessons and references tied to editor/VFS/LSP waves and either archive them, mark them as legacy, or update index/readme material so they are not treated as active operational guidance.
**File(s):** affected files under `discussion/lessons/DSC-0010*`, `DSC-0012*`, `DSC-0013*`, `DSC-0014*`, `DSC-0016*`, `DSC-0017*`, `DSC-0020*`, `DSC-0021*`, plus any summary/index surfaces that present them.
## Test Requirements
### Unit Tests
- Ensure no surviving test suite still references removed editor stack types or message keys.
- Add assertions where needed that remaining shell/resource state is internally consistent.
### Integration Tests
- Validate the Studio docs/spec tree remains internally linked after removal or retirement of the editor specs.
- Validate the build/test graph no longer includes editor-stack-only suites.
### Manual Verification
- Read the Studio spec README and confirm it no longer advertises the removed stack as active.
- Inspect project lessons/readme surfaces and confirm editor-stack lessons are clearly historical or retired.
- Launch the application and confirm no missing i18n keys or dead UI labels remain.
## Acceptance Criteria
- [x] Studio specs no longer define the embedded editor stack as an active surface.
- [x] Studio README/index material no longer points to removed editor/VFS/LSP architecture as current.
- [x] Editor-specific i18n keys are removed or no longer consumed.
- [x] Obsolete tests are removed or rewritten.
- [x] Historical lessons are clearly demoted from active operational guidance.
## Dependencies
- `DEC-0031` accepted and normatively locked.
- Sufficient implementation progress that the codebase no longer depends on the removed specs/resources/tests.
## Risks
- Removing normative docs too early may temporarily leave the repo without clear current guidance.
- Historical lessons may still be valuable; deleting them outright could lose context that should instead be reclassified.
- Partial cleanup can leave broken links or missing i18n keys that only appear at runtime.

118
discussion/workflow/plans/PLN-0068-frontend-visual-contract-and-pbs-migration.md
View File

@ -1,118 +0,0 @@
---
id: PLN-0068
ticket: frontend-visual-theme-spec-and-css-retirement
title: Frontend Visual Contract and PBS Migration
status: open
created: 2026-05-06
completed:
tags: [compiler, compiler-general, frontend, pbs, presentation, theming, contract]
---
## Objective
Introduce the canonical structured frontend visual contract in `FrontendSpec`, migrate PBS to that contract, and demote `semantic-highlighting.css` from authored truth to migration-only input.
## Background
`DEC-0033` locks that frontend visual intent must become structured canonical data, support multiple themes per frontend, remain token-centric, and retire authored host-consumed semantic CSS as the canonical source.
PBS is the first frontend and therefore defines the first concrete migration path, but the contract MUST remain compiler-general rather than PBS-shaped by accident.
## Scope
### Included
- Evolve compiler/frontend metadata to publish a structured visual contract.
- Define the contract shape for semantic-token styling, editor surfaces, and theme identity.
- Migrate PBS to the new contract.
- Preserve any temporary migration utility needed to derive the first contract from the existing PBS CSS.
- Add validation tests that make the new contract normative and stable.
### Excluded
- LSP transport changes.
- Studio rendering changes.
- VS Code runtime translation changes.
## Non-Goals
- Designing a generic host-owned theme engine.
- Supporting every possible frontend visual attribute in wave 1.
- Keeping authored CSS as a parallel canonical source.
## Execution Steps
### Step 1 - Define the structured visual contract in compiler-general surfaces
**What:** Replace the resource-centric semantic presentation shape with a canonical structured visual contract in `FrontendSpec`.
**How:** Add or evolve frontend metadata models so each frontend can publish:
1. semantic token vocabulary ownership,
2. one or more named visual themes,
3. token-centric visual rules,
4. editor-surface colors needed to preserve frontend identity.
The model MUST be compiler-general and MUST NOT encode PBS-specific assumptions into the shared type system.
**File(s):** `prometeu-compiler/prometeu-compiler-core/src/main/java/p/studio/compiler/models/**`, affected frontend registry/definition surfaces.
### Step 2 - Define the theme and token rule semantics explicitly
**What:** Make the contract operational rather than descriptive.
**How:** Specify exact fields, invariants, and null/empty behavior for:
1. theme identity,
2. theme selection metadata if needed at the contract layer,
3. token style rules,
4. editor surface colors,
5. versioning semantics inside or alongside `FrontendSpec`.
The implementation MUST make it possible for hosts to translate the contract mechanically without inferring missing meaning.
**File(s):** `prometeu-compiler/prometeu-compiler-core/src/main/java/**`, associated tests in compiler modules.
### Step 3 - Migrate PBS from authored CSS truth to structured contract truth
**What:** Make PBS the first frontend to author the new contract.
**How:** Update `PBSDefinitions` and related PBS presentation metadata to publish one or more frontend-owned themes through the new contract. The existing `semantic-highlighting.css` MAY be parsed or manually transcribed to bootstrap the migration, but once the structured contract is in place, CSS MUST no longer be treated as authored truth.
**File(s):** `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/**`, `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/resources/themes/pbs/**`, related PBS tests.
### Step 4 - Lock contract validity with tests
**What:** Prevent future drift back to opaque resource ownership.
**How:** Add tests that assert:
1. frontends publish structured visual themes,
2. PBS token vocabulary and theme definitions are coherent,
3. required token styles and editor-surface data resolve correctly,
4. authored CSS is no longer the canonical contract source.
**File(s):** compiler-general and PBS test suites.
## Test Requirements
### Unit Tests
- Validate model invariants for theme IDs, token rules, and editor-surface fields.
- Validate `FrontendSpec` copies and exposes structured theme data safely.
- Validate PBS publishes at least one coherent theme using the new contract.
### Integration Tests
- Run targeted compiler and PBS tests proving the contract compiles, resolves, and remains discoverable through frontend definitions.
### Manual Verification
- Inspect the PBS frontend definition and confirm the structured contract is the readable authored source of truth.
- Confirm any remaining CSS is clearly migration-only or generated-output-only.
## Acceptance Criteria
- [ ] `FrontendSpec` publishes a structured canonical visual contract.
- [ ] The contract supports multiple themes per frontend.
- [ ] The contract is token-centric and can also express editor-surface colors.
- [ ] PBS is migrated to the new contract.
- [ ] `semantic-highlighting.css` is no longer treated as authored canonical frontend presentation data.
## Dependencies
- `DEC-0033` accepted and normatively locked.
## Risks
- Overfitting the first contract to PBS would weaken future frontend adoption.
- An underspecified token-style model would force host inference and violate the decision.
- Keeping CSS alive as a silent parallel truth source would nullify the migration.

114
discussion/workflow/plans/PLN-0069-lsp-visual-theme-transport-and-selection.md
View File

@ -1,114 +0,0 @@
---
id: PLN-0069
ticket: frontend-visual-theme-spec-and-css-retirement
title: LSP Visual Theme Transport and Theme Selection Propagation
status: open
created: 2026-05-06
completed:
tags: [studio, lsp, protocol, transport, presentation, theming, compiler]
---
## Objective
Extend the LSP boundary and transport surfaces so hosts receive frontend-owned visual theme data, theme identity, and active-theme information without collapsing that contract into host-authored categories.
## Background
`DEC-0033` requires LSP to transport enough structured frontend-owned visual information for hosts to render the active frontend theme, preserve frontend and token identity, and avoid forcing the extension to keep hand-maintained theme rules.
The compiler contract itself is handled by `PLN-0068`. This plan covers the transport boundary that carries that contract into host adapters.
## Scope
### Included
- Extend internal LSP-facing description or capability surfaces to expose structured frontend visual contract data.
- Transport theme identity and active-theme information where needed.
- Preserve semantic token identity and frontend ownership through mapping layers.
- Add transport-level tests for the new visual contract payloads.
### Excluded
- Defining the compiler-general contract itself.
- Studio-side rendering implementation.
- VS Code-side rendering implementation.
## Non-Goals
- Inventing host-owned fallback theme categories.
- Expanding LSP beyond what is required to carry the visual contract.
- Building transport that requires hand-curated per-frontend extension updates.
## Execution Steps
### Step 1 - Extend internal LSP descriptions to carry visual contract data
**What:** Evolve the LSP-side server/bridge description surfaces to expose frontend-owned visual contract data instead of ad hoc token metadata only.
**How:** Update `lsp-api` and `lsp-v1` internal description models so they can carry:
1. frontend identity,
2. semantic token legend identity,
3. available theme definitions or references,
4. active theme selection.
The payload shape MUST remain faithful to the frontend contract and MUST NOT normalize it into host-owned abstractions.
**File(s):** `prometeu-lsp/prometeu-lsp-api/src/main/java/**`, `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`.
### Step 2 - Thread the visual contract through bridge and mapper layers
**What:** Ensure the compiler-backed bridge and protocol mappers preserve visual theme data end to end.
**How:** Update bridge services, protocol mappers, server description responses, and any capability/bootstrap path that currently exposes token data so they now expose the structured visual contract and active theme metadata.
**File(s):** `prometeu-lsp/prometeu-lsp-v1/src/main/java/p/studio/lsp/services/**`, `.../messages/**`, `.../mapping/**`.
### Step 3 - Define theme selection behavior for host consumption
**What:** Make active-theme semantics operational.
**How:** Define and implement the transport rule for which theme a host should apply:
1. single-theme frontend behavior,
2. multi-theme frontend behavior,
3. default theme behavior when no host override is in play,
4. how active-theme selection is surfaced to adapters.
The transport MUST make host behavior deterministic without host-owned guessing.
**File(s):** `prometeu-lsp/prometeu-lsp-api/**`, `prometeu-lsp/prometeu-lsp-v1/**`, tests.
### Step 4 - Add transport conformance tests
**What:** Prevent regression back to token-only or host-shaped payloads.
**How:** Add tests that verify:
1. theme payloads are present,
2. token identities survive transport unchanged,
3. active-theme information is deterministic,
4. no mapper collapses frontend-owned visual data into host-authored categories.
**File(s):** `prometeu-lsp/prometeu-lsp-v1/src/test/java/**`, `prometeu-lsp/prometeu-lsp-api/src/test/java/**` if needed.
## Test Requirements
### Unit Tests
- Validate DTO/model invariants for theme payloads and active-theme fields.
- Validate mapper behavior for full visual contract transport.
### Integration Tests
- Run targeted LSP tests proving a compiler-backed frontend description reaches the host adapter layer with visual theme data intact.
### Manual Verification
- Inspect initialize/description pathways and confirm theme metadata is present and frontend-shaped.
## Acceptance Criteria
- [ ] LSP description/transport surfaces carry structured frontend visual theme data.
- [ ] Theme identity and active-theme semantics are deterministic.
- [ ] Semantic token identity remains frontend-owned end to end.
- [ ] No LSP layer introduces host-owned theme abstractions as canonical transport data.
## Dependencies
- `DEC-0033` accepted and normatively locked.
- `PLN-0068` for the compiler-side contract shape and PBS migration.
## Risks
- Transporting too little theme data would force host inference and violate the decision.
- Transporting host-shaped payloads would silently recreate the wrong ownership boundary.
- Theme selection semantics can become ambiguous unless explicitly defined in this plan.

101
discussion/workflow/plans/PLN-0070-studio-visual-theme-adapter-and-css-retirement.md
View File

@ -1,101 +0,0 @@
---
id: PLN-0070
ticket: frontend-visual-theme-spec-and-css-retirement
title: Studio Visual Theme Adapter and CSS Retirement
status: open
created: 2026-05-06
completed:
tags: [studio, editor, presentation, theming, adapter, css-retirement]
---
## Objective
Make Studio consume the structured frontend visual contract as an adapter, remove any remaining dependency on authored frontend semantic CSS as the canonical source, and keep any host rendering mechanism clearly derivative.
## Background
`DEC-0033` locks that Studio is a rendering adapter over frontend-owned visual themes and that generated CSS is acceptable only as an adapter mechanism, not as the canonical frontend artifact.
This plan applies that rule to the Studio side of the stack.
## Scope
### Included
- Update Studio-side presentation registries or rendering services to consume structured frontend visual contract data.
- Generate or map host rendering artifacts from the structured contract if Studio still needs CSS or equivalent host render descriptors.
- Remove reliance on authored frontend semantic CSS as a direct semantic presentation contract.
- Add Studio tests proving the adapter path is derivative and deterministic.
### Excluded
- Compiler-side contract design.
- LSP transport contract design.
- VS Code adapter behavior.
## Non-Goals
- Rebuilding the deleted legacy Studio editor stack.
- Introducing Studio-owned frontend themes.
- Preserving authored semantic CSS as a parallel truth source.
## Execution Steps
### Step 1 - Update Studio presentation consumption to use the structured contract
**What:** Make Studio consume frontend-owned visual theme data instead of resource-only semantic presentation.
**How:** Update presentation registries, semantic highlighting services, or other editor-related rendering seams so they resolve structured visual theme data from the frontend description path.
**File(s):** `prometeu-studio/src/main/java/**`, any remaining editor/presentation adapter surfaces still active after cleanup.
### Step 2 - Derive host rendering artifacts from the contract
**What:** Keep Studio rendering mechanical.
**How:** If Studio still requires CSS or CSS-like structures, generate or map them from the structured frontend visual contract. The host-generated artifact MUST be clearly derivative and MUST NOT be treated as authored frontend truth.
**File(s):** `prometeu-studio/src/main/java/**`, possible theme/presentation helper modules, generated resource paths if adopted.
### Step 3 - Remove direct canonical dependence on frontend semantic CSS
**What:** Retire the old consumption model.
**How:** Remove or rewrite any code path that treats frontend semantic CSS resources as the canonical semantic presentation input. Leave only temporary compatibility or generated-output behavior if strictly needed during rollout.
**File(s):** `prometeu-studio/**`, related frontend resource loading code.
### Step 4 - Add Studio adapter conformance tests
**What:** Lock the adapter boundary.
**How:** Add tests that verify:
1. Studio consumes structured frontend visual themes,
2. token style rendering inputs are contract-derived,
3. any generated CSS is derivative,
4. Studio does not silently fall back to host-authored frontend theme logic.
**File(s):** `prometeu-studio/src/test/java/**` and any relevant integration test modules.
## Test Requirements
### Unit Tests
- Validate contract-to-rendering translation logic.
- Validate theme selection consumption on the Studio side.
### Integration Tests
- Run targeted Studio-side tests proving frontend presentation resolves from structured contract data and not from authored semantic CSS.
### Manual Verification
- Inspect the Studio path and confirm remaining CSS, if any, is generated or compatibility-only.
## Acceptance Criteria
- [ ] Studio consumes structured frontend visual contract data.
- [ ] Any Studio-side CSS or equivalent rendering descriptor is derivative, not canonical.
- [ ] Direct canonical dependence on authored frontend semantic CSS is removed.
- [ ] Studio does not reauthor frontend visual identity locally.
## Dependencies
- `DEC-0033` accepted and normatively locked.
- `PLN-0068` for the canonical compiler/frontend contract.
- `PLN-0069` for transport of visual contract data into the host boundary.
## Risks
- Studio may still hide old CSS assumptions in helper layers unless the migration is exhaustive.
- Generated CSS can accidentally become the new silent truth source if ownership boundaries are not explicit in code and tests.
- Residual editor cleanup from earlier refactors may obscure the remaining active consumption path.

100
discussion/workflow/plans/PLN-0071-vscode-dynamic-theme-translation-adapter.md
View File

@ -1,100 +0,0 @@
---
id: PLN-0071
ticket: frontend-visual-theme-spec-and-css-retirement
title: VS Code Dynamic Theme Translation Adapter
status: open
created: 2026-05-06
completed:
tags: [vscode, extension, lsp, presentation, theming, adapter]
---
## Objective
Turn the VS Code extension into a stable adapter that translates frontend-owned visual theme contracts into VS Code-compatible rendering behavior without requiring source edits for routine frontend theme changes.
## Background
`DEC-0033` explicitly locks that the extension must not become a repository of manually curated frontend theme rules. The extension must translate the contract it receives rather than being edited whenever a frontend changes colors, emphasis, or theme variants.
This plan covers the client-side adapter behavior that satisfies that requirement.
## Scope
### Included
- Replace hardcoded per-frontend visual theme rules with dynamic or generated translation based on the transported frontend contract.
- Define the minimum static VS Code contribution surface still required by the platform.
- Support multi-theme frontend data consumption and active-theme application.
- Add extension tests or verification coverage around theme translation.
### Excluded
- Compiler-side contract definition.
- LSP transport definition.
- Studio rendering behavior.
## Non-Goals
- Building a general-purpose VS Code theme marketplace artifact.
- Allowing the extension to become a second authored source of frontend theme truth.
- Solving unrelated reconnect or transport lifecycle issues beyond what this adapter needs.
## Execution Steps
### Step 1 - Identify the minimal static VS Code contribution surface
**What:** Separate what the extension must declare statically from what it can translate dynamically.
**How:** Keep only the minimal `package.json` contribution data required for VS Code to recognize semantic token kinds or activate the extension. Remove hardcoded frontend-specific color rules from static configuration where dynamic translation can take over.
**File(s):** `tools/vscode-extension/package.json`, related extension bootstrap files.
### Step 2 - Implement contract-to-VS Code theme translation
**What:** Translate frontend-owned visual contract data into VS Code-understandable configuration.
**How:** Update extension runtime code to receive the transported visual theme contract, map token and editor-surface data into the VS Code APIs/configuration model, and apply the active frontend theme deterministically.
**File(s):** `tools/vscode-extension/src/**`, mirrored build outputs only if local toolchain constraints require temporary manual sync.
### Step 3 - Support multi-theme frontends without extension source edits
**What:** Make frontend theme growth operationally cheap.
**How:** Ensure that adding or changing frontend-owned themes does not require new extension source logic unless the VS Code platform itself introduces a new capability boundary. Theme identity, token rules, and active selection must be data-driven.
**File(s):** `tools/vscode-extension/src/**`, possible supporting protocol model surfaces if consumed directly.
### Step 4 - Add adapter verification coverage
**What:** Protect the no-manual-theme-maintenance rule.
**How:** Add tests or deterministic verification around:
1. translation of token rules,
2. translation of editor-surface colors where supported,
3. handling of multiple frontend themes,
4. absence of hardcoded PBS-only theme logic in the adapter path.
**File(s):** `tools/vscode-extension/src/test/**` if present, or equivalent test harness/verification approach adopted by the extension module.
## Test Requirements
### Unit Tests
- Validate translation of structured token rules into VS Code-compatible theme rules.
- Validate active-theme switching behavior for data-driven frontend themes.
### Integration Tests
- Run extension-targeted validation proving the frontend contract can change without source-level theme edits.
### Manual Verification
- Open PBS content through the extension and confirm the active theme is applied from transported contract data rather than hardcoded `package.json` color tables.
## Acceptance Criteria
- [ ] The extension no longer depends on hardcoded frontend-specific theme rules as the primary rendering source.
- [ ] Frontend theme changes are driven by contract data rather than extension source edits.
- [ ] Multi-theme frontend payloads can be translated and applied deterministically.
- [ ] The remaining static VS Code contribution surface is minimal and structural only.
## Dependencies
- `DEC-0033` accepted and normatively locked.
- `PLN-0069` for transport of visual theme data to the extension.
## Risks
- VS Code platform constraints may force a hybrid static/runtime model that must stay carefully bounded.
- The current local Node/TypeScript environment issues can slow validation.
- Leaving too much theme data in `package.json` would preserve the current maintenance problem under a new name.