editor and lsp

2026-03-31 11:12:52 +01:00 · 2026-03-31 11:12:52 +01:00 · 91ca49a074
commit 91ca49a074
parent 2868203706
15 changed files with 1549 additions and 4 deletions
--- a/discussion/.backups/index.ndjson.20260331-103611.bak
+++ b/discussion/.backups/index.ndjson.20260331-103611.bak
@ -0,0 +1,14 @@
 {"type":"meta","next_id":{"DSC":14,"AGD":15,"DEC":10,"PLN":19,"LSN":28,"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":"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":"open","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-03-31","tags":["studio","editor","workspace","write","read-only","vfs","frontend-boundary"],"agendas":[{"id":"AGD-0013","file":"AGD-0013-studio-editor-write-wave-supported-non-frontend-files.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31"},{"id":"AGD-0014","file":"AGD-0014-studio-editor-frontend-edit-rights.md","status":"open","created_at":"2026-03-31","updated_at":"2026-03-31"}],"decisions":[],"plans":[],"lessons":[]}
--- a/discussion/.backups/index.ndjson.20260331-104906.bak
+++ b/discussion/.backups/index.ndjson.20260331-104906.bak
@ -0,0 +1,14 @@
 {"type":"meta","next_id":{"DSC":14,"AGD":15,"DEC":12,"PLN":19,"LSN":28,"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":"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":"open","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-03-31","tags":["studio","editor","workspace","write","read-only","vfs","frontend-boundary"],"agendas":[{"id":"AGD-0013","file":"AGD-0013-studio-editor-write-wave-supported-non-frontend-files.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31"},{"id":"AGD-0014","file":"AGD-0014-studio-editor-frontend-edit-rights.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31"}],"decisions":[{"id":"DEC-0010","file":"DEC-0010-studio-controlled-non-frontend-editor-write-wave.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31","ref_agenda":"AGD-0013"},{"id":"DEC-0011","file":"DEC-0011-studio-frontend-read-only-minimum-lsp-phase.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31","ref_agenda":"AGD-0014"}],"plans":[],"lessons":[]}
--- a/discussion/index.ndjson
+++ b/discussion/index.ndjson
@ -1,4 +1,4 @@
-{"type":"meta","next_id":{"DSC":13,"AGD":13,"DEC":10,"PLN":19,"LSN":28,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":14,"AGD":15,"DEC":12,"PLN":26,"LSN":28,"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"}]}
@ -11,3 +11,4 @@
 {"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":"open","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-03-31","tags":["studio","editor","workspace","write","read-only","vfs","frontend-boundary"],"agendas":[{"id":"AGD-0013","file":"AGD-0013-studio-editor-write-wave-supported-non-frontend-files.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31"},{"id":"AGD-0014","file":"AGD-0014-studio-editor-frontend-edit-rights.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31"}],"decisions":[{"id":"DEC-0010","file":"DEC-0010-studio-controlled-non-frontend-editor-write-wave.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31","ref_agenda":"AGD-0013"},{"id":"DEC-0011","file":"DEC-0011-studio-frontend-read-only-minimum-lsp-phase.md","status":"accepted","created_at":"2026-03-31","updated_at":"2026-03-31","ref_agenda":"AGD-0014"}],"plans":[{"id":"PLN-0019","file":"PLN-0019-propagate-dec-0010-into-studio-and-vfs-specs.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0010"]},{"id":"PLN-0020","file":"PLN-0020-build-dec-0010-vfs-access-policy-and-save-core.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0010"]},{"id":"PLN-0021","file":"PLN-0021-integrate-dec-0010-editor-write-ui-and-workflow.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0010"]},{"id":"PLN-0022","file":"PLN-0022-propagate-dec-0011-into-studio-vfs-and-lsp-specs.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0011"]},{"id":"PLN-0023","file":"PLN-0023-scaffold-flat-packed-prometeu-lsp-api-and-session-seams.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0011"]},{"id":"PLN-0024","file":"PLN-0024-implement-read-only-fe-diagnostics-symbols-and-definition.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0011"]},{"id":"PLN-0025","file":"PLN-0025-implement-fe-semantic-highlight-consumption.md","status":"review","created_at":"2026-03-31","updated_at":"2026-03-31","ref_decisions":["DEC-0011"]}],"lessons":[]}
--- a/discussion/workflow/agendas/AGD-0013-studio-editor-write-wave-supported-non-frontend-files.md
+++ b/discussion/workflow/agendas/AGD-0013-studio-editor-write-wave-supported-non-frontend-files.md
@ -0,0 +1,243 @@
 ---
 id: AGD-0013
 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
 status: accepted
 created: 2026-03-31
 resolved: 2026-03-31
 decision: DEC-0010
 tags:
  - studio
  - editor
  - workspace
  - write
  - read-only
  - vfs
  - frontend-boundary
 ---
 ## Pain
 O `Code Editor` do Studio ja saiu da fase de abertura somente leitura e agora existe pressao para iniciar a wave de edicao de arquivos.
 Mas o recorte pedido nao e "liberar escrita para tudo".
 O recorte correto e mais estreito:
 - editar apenas arquivos aceitos pelo sistema;
 - manter todos os arquivos relacionados ao frontend (`FE`) em `read-only` nesta etapa;
 - e evitar que o editor misture, por inferencia, tres conceitos diferentes:
  - arquivo suportado para abrir,
  - arquivo elegivel para highlight/presentacao,
  - arquivo elegivel para mutacao e persistencia.
 Se isso nao for fechado agora, a wave de escrita corre risco de nascer com uma regra pobre:
 - ou o editor libera escrita para qualquer texto suportado;
 - ou empilha `ifs` locais no `EditorWorkspace`;
 - ou trata "arquivo do FE" apenas como detalhe visual, sem uma politica operacional clara de mutabilidade.
 ## Context
 Domain owner: `studio`
 Owner surface: `docs/specs/studio`
 Superficies e referencias relevantes:
 - `docs/specs/studio/5. Code Editor Workspace Specification.md` ainda trava a wave atual como `read-only`;
 - `docs/specs/studio/6. Project Document VFS Specification.md` ja moveu classificacao de suporte e abertura de documento para `prometeu-vfs`;
 - `discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md` consolida que a primeira wave do editor foi propositalmente somente leitura;
 - `discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md` consolida que o editor deve consumir um boundary documental, nao virar owner de runtime de filesystem;
 - `FilesystemProjectDocumentVfs` hoje diferencia:
  - arquivos `json`/`ndjson`,
  - arquivos `bash`,
  - arquivos do frontend pela linguagem registrada,
  - e `text` generico;
 - `EditorWorkspace` ainda marca o `CodeArea` como `setEditable(false)`, ou seja, a wave de escrita exigira revisao normativa e nao apenas um ajuste tecnico.
 Clarificacao importante para esta discussion:
 - "arquivo aceito" nesta agenda significa arquivo que o sistema aceita abrir como documento textual no boundary atual;
 - isso nao implica automaticamente que o arquivo e editavel;
 - "arquivo relacionado ao FE" tambem nao pode ficar como intuicao editorial solta;
 - a fronteira precisa virar regra operacional explicita, provavelmente no boundary documental ou em politica derivada dele;
 - a verificacao deve ficar no `prometeu-vfs`, usando o enquadramento do `typeId` contra `allowedExtensions` do `FrontendSpec`.
 ## Open Questions
 - [x] O criterio canonico de "arquivo aceito para edicao" deve ser o mesmo universo de documentos suportados para abrir; a politica de acesso do `prometeu-vfs` decide se cada documento suportado fica `read-only` ou `editable` nesta wave.
 - [x] "Relacionado ao FE" deve ser definido no `prometeu-vfs` pelo enquadramento do `typeId` contra `allowedExtensions` do `FrontendSpec`.
 - [x] Fora do escopo classificado como `FE`, a wave editavel inicial fica limitada aos tipos textuais ja suportados hoje: `text`, `json`, `ndjson` e `bash`.
 - [x] O bloqueio de escrita para FE deve usar o item `read-only` na status bar, com espaco para evoluir para icone de cadeado aberto/fechado e futuro toggle de edicao; arquivos `FE` `read-only` tambem devem mostrar alerta no topo informando que nao podem ser salvos e que qualquer alteracao sera perdida.
 - [x] A politica de acesso documental deve morar sempre no `prometeu-vfs`, inclusive para `load` e `save`.
 - [x] A primeira wave de edicao inclui snapshot em memoria para documentos editaveis e persistencia em disco no `save` a partir desse snapshot.
 - [x] O menu global `Save` nao deve ser usado para este fluxo; `save` e acao local do editor e deve viver numa barra de comandos no topo do editor, inicialmente com `Save` e `Save All`.
 - [x] Tabs com arquivos FE `read-only` podem coexistir com tabs editaveis nao-FE no mesmo workspace, com estados visuais diferentes.
 - [x] Os arquivos editaveis desta wave nao fazem parte da build em si.
 - [x] O snapshot editavel em memoria desta wave deve permanecer contido e separado do snapshot documental usado pelos fluxos que participam da build.
 ## Options
 ### Option A - Liberar escrita para todo arquivo textual suportado
 - **Approach:** Tratar todo `VfsTextDocument` como potencialmente editavel, exceto binarios ou sem handler.
 - **Pro:** Menor custo inicial e quase nenhum metadado novo.
 - **Con:** Viola diretamente o recorte pedido, porque arquivos de FE tambem passariam a ser editaveis ou exigiriam excecoes tardias e espalhadas.
 - **Maintainability:** Baixa. A regra nasce ampla demais e depois precisa ser recortada por remendos.
 ### Option B - Manter suporte no VFS e derivar editabilidade so no `EditorWorkspace`
 - **Approach:** O `prometeu-vfs` continua apenas dizendo se o arquivo abre, e o editor decide localmente se aquele documento fica `read-only` ou editavel.
 - **Pro:** Mudanca pequena no boundary atual.
 - **Con:** Regride a disciplina arquitetural recente; o editor volta a carregar regra de produto que deveria ser compartilhavel e auditavel.
 - **Maintainability:** Media para baixa. Funciona rapido, mas enfraquece o boundary documental.
 ### Option C - Introduzir uma politica explicita de acesso documental acima do VFS
 - **Approach:** Manter o `prometeu-vfs` como owner de suporte/abertura e adicionar uma classificacao explicita de `document access mode`, distinguindo ao menos `unsupported`, `read-only` e `editable`.
 - **Pro:** Separa corretamente:
  - abrir o documento,
  - classificar o documento,
  - e decidir se esta wave permite mutacao.
 - **Con:** Exige desenhar melhor onde essa politica mora e como ela chega ao editor sem inflar o contrato cedo demais.
 - **Maintainability:** Forte. O sistema ganha uma regra clara e evolutiva para waves futuras.
 ### Option D - Colocar a politica de editabilidade dentro do contrato documental do `prometeu-vfs`
 - **Approach:** O proprio boundary documental passa a devolver metadados normativos de acesso, incluindo se o documento e `editable` ou `read-only` nesta wave.
 - **Pro:** Mantem suporte, tipo documental e politica de acesso no mesmo owner, reduzindo ambiguidade nos consumidores.
 - **Con:** Exige desenhar com cuidado o snapshot editavel em memoria, o ciclo de `save` e a fronteira do que continua fora da build.
 - **Maintainability:** Forte, desde que o contrato permaneça estreito e centrado em acesso documental, nao em UX.
 ## Discussion
 As discussoes anteriores fecharam duas coisas importantes:
 1. o editor nao deve fingir semantica de IDE cedo demais;
 2. o editor nao deve voltar a ser owner de concerns documentais que ja foram movidos para `prometeu-vfs`.
 Isso significa que a wave de escrita precisa evitar dois erros simetricos:
 - liberar mutacao ampla demais e quebrar o recorte de produto;
 - ou resolver a restricao de FE com condicionais locais no `EditorWorkspace`, quebrando a separacao arquitetural que acabou de ser criada.
 O ponto mais delicado aqui e que "arquivo textual aceito" e "arquivo editavel nesta etapa" ja nao sao a mesma coisa.
 Hoje o sistema ja consegue abrir um conjunto de documentos textuais, inclusive documentos associados ao frontend.
 Mas o pedido atual cria uma nova regra de produto:
 - alguns arquivos suportados continuarao `read-only`;
 - e isso nao acontece por incapacidade tecnica de abrir o arquivo, mas por decisao deliberada de wave.
 Portanto, o modelo tende a precisar de uma superficie nova de classificacao.
 Se ela nao existir, o editor fica tentado a usar heuristicas locais:
 - `typeId == languageId`
 - path em source roots
 - extensao
 - ou combinacoes desses sinais
 Esse caminho e rapido, mas ruim.
 Ele espalha a politica de mutabilidade pelo consumidor errado.
 Tambem houve um fechamento importante para a decisao:
 - o recorte canonico de `FE` deve ser verificado no `prometeu-vfs`;
 - essa verificacao deve usar o enquadramento do `typeId` contra `allowedExtensions` do `FrontendSpec`;
 - e o editor deve apenas consumir essa classificacao pronta, sem rederivar a regra localmente.
 Se isso nao for fechado, o time pode permitir escrita em arquivos do frontend por acidente apenas porque eles aparecem como `text`, `json` ou outro tipo textual generico.
 Outro fechamento importante desta agenda e que a primeira whitelist editavel nao cresce alem do que o produto ja suporta hoje como texto:
 - `text`
 - `json`
 - `ndjson`
 - `bash`
 Ou seja, a wave inicial de edicao nao abre novo suporte documental.
 Ela apenas permite mutacao em um subconjunto dos documentos textuais que ja existem hoje, excluindo o escopo classificado como `FE`.
 Tambem ja existe um fechamento arquitetural relevante sobre ownership:
 - a politica de acesso nao deve viver em policy layer solta no `studio`;
 - `prometeu-vfs` deve ser o owner de `load`, `save` e da classificacao `read-only` versus `editable`;
 - para documentos editaveis desta wave, o VFS deve manter um snapshot em memoria durante a sessao;
 - quando houver `save`, o VFS persiste em disco o conteudo desse snapshot;
 - o editor consome esse estado e dispara a intencao de salvar, mas nao reimplementa a politica nem o fluxo de persistencia.
 Tambem ficou fechado que o universo canonico de documentos continua sendo o conjunto suportado pelo VFS.
 O que muda nao e o universo de abertura, mas a politica de acesso aplicada a cada documento suportado:
 - alguns suportados permanecem `read-only`, como o escopo de `FE`;
 - outros suportados podem entrar como `editable` nesta wave;
 - e essa decisao continua centralizada no `prometeu-vfs`.
 Isso empurra a agenda com mais forca para a direcao de `Option D`.
 Outro limite importante tambem ficou explicitado:
 - os arquivos editaveis desta wave nao participam da build em si;
 - portanto, a wave de escrita nao pode inferir integracao com pipeline, recompilacao, invalidacao de artefatos ou qualquer contrato de build;
 - o escopo aqui e documental/editorial, nao de toolchain.
 - isso tambem significa que o snapshot editavel em memoria nao deve se misturar com snapshots documentais ou entradas que alimentem a build;
 - deve existir contencao clara entre:
  - o estado editorial temporario usado pela sessao de edicao;
  - e o estado documental/build-facing que outros fluxos do sistema possam consumir.
 Essa contencao importa porque "ter snapshot em memoria" nao pode virar permissao implicita para o restante do produto observar rascunhos editoriais como se fossem input canonico de build.
 A direcao mais coerente hoje parece ser preservar o boundary documental e introduzir um conceito explicito de politica de acesso.
 Essa politica pode morar:
 1. dentro do `prometeu-vfs`, se quisermos que o owner documental responda tambem pela mutabilidade da wave;
 2. ou numa camada de policy ainda no dominio `studio`, mas acima do VFS, desde que o `EditorWorkspace` continue apenas consumindo a decisao pronta.
 Com o fechamento atual, a agenda ja converge para descartar a segunda alternativa.
 O que parece fraco e empurrar isso para o `EditorWorkspace`, e o usuario tambem ja fechou que a politica de acesso deve passar sempre por `prometeu-vfs`.
 No plano de UX, a direcao tambem ficou suficiente para a proxima etapa:
 - o estado `read-only` de `FE` deve aparecer na status bar;
 - essa superficie pode evoluir mais tarde para um toggle explicito de habilitar/desabilitar edicao por arquivo;
 - o `prometeu-vfs` deve, portanto, ja nascer pensando em contexto persistente de acesso por documento;
 - `Save` e `Save All` nao pertencem ao menu global do shell e sim ao editor, em uma barra de comandos propria no topo;
 - arquivos `FE` `read-only` nao podem ser salvos;
 - ao abrir esse tipo de arquivo, o editor deve mostrar um alerta no topo informando que ele e `read-only` e que qualquer alteracao sera perdida.
 Tambem vale registrar desde ja a implicacao para um futuro `prometeu-lsp` integrado ao Studio:
 - o objetivo nao e portar o suporte das linguagens Prometeu para VSCode ou para um editor externo;
 - portanto, a agenda de escrita nao deve introduzir dependencia de protocolo externo como fundamento da edicao;
 - um futuro `prometeu-lsp` integrado deve ser tratado como consumidor semantico in-process ou Studio-owned acima do mesmo substrate de sessao, e nao como dono da politica de acesso documental;
 - esse consumidor futuro deve observar o estado documental/snapshots editoriais necessarios para analise, sem colapsar a contencao entre estado editorial temporario e inputs canonicos de build;
 - `read-only` para `FE` nesta wave significa apenas bloqueio de mutacao editorial, nao proibicao de leitura ou analise semantica futura;
 - a integracao semantica continua sendo tema de decisao propria e nao deve ser inferida automaticamente a partir desta wave de escrita.
 Observacao cravada para o proximo ciclo:
 - quando o escopo de `FE` for liberado para edicao, o `prometeu-lsp` integrado ao Studio deve entrar em questao como consumidor do conteudo disponibilizado pelo `prometeu-vfs`;
 - para documentos abertos, a analise deve enxergar o snapshot em memoria da sessao;
 - para documentos nao abertos, a analise pode ler o estado em filesystem exposto pelo mesmo boundary;
 - isso reforca que `prometeu-vfs` precisa permanecer como substrate documental canonico do editor e da futura analise semantica integrada.
 ## Resolution
 Esta agenda convergiu para uma direcao suficiente para `decision`.
 Recomendacao final: evoluir para uma decisao que introduza uma classificacao explicita de acesso documental para o `Code Editor`, separando:
 1. arquivo nao suportado;
 2. arquivo suportado porem `read-only`;
 3. arquivo suportado e editavel.
 Fechamentos aceitos:
 - manter todo arquivo relacionado ao `FE` em `read-only` nesta wave;
 - deixar o `prometeu-vfs` verificar se o `typeId` do documento cai no conjunto de `allowedExtensions` do `FrontendSpec`;
 - manter como universo canonico os mesmos documentos suportados para abrir, sem criar registro paralelo de elegibilidade fora do `prometeu-vfs`;
 - limitar a wave editavel inicial, fora do escopo de `FE`, aos tipos ja suportados hoje: `text`, `json`, `ndjson` e `bash`;
 - fazer `prometeu-vfs` ser o owner de `load`, snapshot editavel em memoria e `save` em disco para esses documentos;
 - tratar essa wave como escopo documental que nao participa da build em si;
 - manter contencao explicita entre snapshot editorial em memoria e qualquer snapshot/build-input de carater canonico;
 - expor o estado `read-only` de `FE` na status bar, com espaco para futura evolucao a toggle por arquivo;
 - adicionar uma barra de comandos no topo do editor com `Save` e `Save All`, em vez de usar o menu global do shell;
 - permitir coexistencia de tabs `read-only` de `FE` com tabs editaveis nao-`FE`;
 - e mostrar alerta no topo para arquivos `FE` informando que sao `read-only`, nao podem ser salvos e que qualquer alteracao sera perdida.
 - registrar que um futuro `prometeu-lsp` integrado ao Studio deve consumir o mesmo substrate de sessao/documentos sem virar owner da politica de acesso ou forcar compatibilidade com editor externo.
 Next step suggestion: converter esta agenda em `decision` normativa para propagar a wave de escrita controlada do editor para specs, plano e implementacao.
--- a/discussion/workflow/agendas/AGD-0014-studio-editor-frontend-edit-rights.md
+++ b/discussion/workflow/agendas/AGD-0014-studio-editor-frontend-edit-rights.md
@ -0,0 +1,165 @@
 ---
 id: AGD-0014
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Definir a fase de FE read-only com LSP minimo no Code Editor do Studio
 status: accepted
 created: 2026-03-31
 resolved: 2026-03-31
 decision: DEC-0011
 tags:
  - studio
  - editor
  - workspace
  - write
  - frontend-boundary
  - lsp
  - access-policy
 ---
 ## Pain
 A agenda `AGD-0013` fechou a primeira wave de escrita deixando todo arquivo de `FE` em `read-only`.
 Isso foi a decisao correta para destravar a wave inicial, e agora abre uma fase intermediaria mais segura:
 - manter `FE` em `read-only`;
 - introduzir um `prometeu-lsp` minimo integrado ao Studio;
 - e validar o ganho semantico em cima do substrate documental do `prometeu-vfs`.
 O tema de liberacao efetiva de edicao para `FE` deixa de ser escopo desta agenda.
 Ele deve seguir para outra discussion propria.
 ## Context
 Domain owner: `studio`
 Owner surface: `docs/specs/studio`
 Superficies e referencias relevantes:
 - `AGD-0013` aceitou que, nesta wave, arquivos de `FE` permanecem `read-only`;
 - `AGD-0013` tambem cravou que um futuro `prometeu-lsp` integrado ao Studio deve consumir o conteudo exposto por `prometeu-vfs`, usando snapshot em memoria para documentos abertos e filesystem para documentos fechados;
 - `docs/specs/studio/6. Project Document VFS Specification.md` fecha `prometeu-vfs` como substrate documental de sessao;
 - `discussion/lessons/DSC-0010-studio-code-editor-workspace-foundations/LSN-0026-read-only-editor-foundations-and-semantic-deferral.md` consolida a regra de nao fingir semantica de IDE antes da hora;
 - `discussion/lessons/DSC-0012-studio-editor-document-vfs-boundary/LSN-0027-project-document-vfs-and-session-owned-editor-boundary.md` consolida que `prometeu-lsp` deve ser consumidor futuro acima de `prometeu-vfs`, nao seu substituto;
 - `prometeu-packer-api` ja oferece um exemplo util de flat packaging por superficie explicita, com pacotes como `dtos`, `messages`, `events` e subgrupos pequenos e nomeados;
 - a build e a analise semantica ja precisam continuar distintas: snapshot editorial em memoria nao pode virar input canonico de build por inferencia.
 Clarificacao importante desta agenda:
 - esta agenda nao libera edicao de `FE`;
 - esta agenda fecha apenas a fase `FE read-only + LSP minimo`;
 - a futura liberacao de mutacao e `save` para `FE` deve acontecer em outra discussion propria;
 - aqui o foco e definir o contrato minimo entre `prometeu-vfs` e `prometeu-lsp` integrado enquanto `FE` continua `read-only`.
 ## Open Questions
 - [x] Pode existir uma fase intermediaria com `FE` ainda `read-only`, mas ja com `prometeu-lsp` integrado minimo consumindo o `prometeu-vfs`; o direito de edicao do `FE` continua para uma fase posterior em outra discussion.
 - [x] Nesta fase `read-only`, o `prometeu-lsp` deve consumir o snapshot em memoria do `prometeu-vfs` para arquivos abertos e cair para filesystem apenas quando o arquivo estiver fechado.
 - [x] O escopo minimo do `prometeu-lsp` integrado nesta fase e `diagnostics`, `symbols`/`outline`, `definition` e `highlight`.
 - [x] `Completion` fica explicitamente fora desta fase minima por ainda nao existir direito de edicao de `FE`.
 - [x] Nao e necessario implementar agora persistencia de contexto de acesso por documento no `prometeu-vfs`, mas ja deve existir uma entidade de contexto onde esses valores possam ser consultados e alterados sob demanda, facilitando persistencia futura.
 - [x] O estado editorial em memoria de arquivos `FE` pode alimentar analise semantica sem nunca alimentar build; qualquer futura ponte com build fica fora desta agenda e de outra decisao propria.
 ## Options
 ### Option A - Misturar LSP minimo e futura liberacao de edicao na mesma agenda
 - **Approach:** Tentar resolver agora tanto a fase `read-only + LSP` quanto o futuro direito de edicao de `FE`.
 - **Pro:** Menos artefatos de workflow.
 - **Con:** Mistura readiness semantica com mutacao editorial e amplia demais o escopo.
 - **Maintainability:** Baixa. A agenda perde nitidez.
 ### Option B - Introduzir LSP minimo com FE ainda read-only, e liberar edicao depois em outra discussion
 - **Approach:** Primeiro integrar um `prometeu-lsp` minimo ao Studio enquanto arquivos de `FE` permanecem `read-only`; so depois, em uma fase seguinte, decidir a liberacao de `save` e mutacao editorial de `FE`.
 - **Pro:** Valida cedo a cadeia `prometeu-vfs` -> snapshots de sessao -> consumidor semantico, sem ainda assumir a responsabilidade de mutacao em arquivos de linguagem.
 - **Con:** Cria uma fase intermediaria a mais e exige disciplina para nao tratar "LSP minimo" como permissao implicita para editar.
 - **Maintainability:** Muito forte. Separa readiness semantica de direito de mutacao e reduz rework.
 ### Option C - Fazer uma fase minima ainda menor
 - **Approach:** Limitar o LSP minimo a `diagnostics` e talvez `symbols`, deixando `definition` e `highlight` para depois.
 - **Pro:** Reduz a primeira entrega semantica.
 - **Con:** Pode subentregar valor perceptivel e fragmentar demais a fase minima.
 - **Maintainability:** Media. So vale se a superficie tecnica ainda estiver imatura.
 ## Discussion
 O que a discussao atual ja deixa claro e que o `FE` tem peso diferente dos outros textos suportados hoje.
 Para `text`, `json`, `ndjson` e `bash`, a primeira wave editavel pode ser tratada como escopo editorial controlado:
 - `prometeu-vfs` carrega;
 - o editor altera;
 - o `prometeu-vfs` guarda snapshot;
 - e o `save` persiste em disco;
 - tudo isso sem envolver build nem semantica forte.
 Para `FE`, esse raciocinio parece insuficiente.
 O proprio caminho que foi cravado em `AGD-0013` indica a direcao correta:
 - quando `FE` for liberado, `prometeu-lsp` integrado entra em questao;
 - esse LSP deve consumir o mesmo substrate documental;
 - e o snapshot em memoria do VFS deve ser a verdade de analise para documentos abertos.
 O refinamento trazido agora melhora essa sequencia:
 - nao e necessario esperar a liberacao de edicao de `FE` para introduzir um `prometeu-lsp` minimo;
 - ao contrario, ter uma fase de `FE` ainda `read-only`, mas ja observavel semanticamente, parece um passo mais seguro;
 - isso deixa o time validar ingestao de snapshots, diagnosticos, outline ou outras leituras sem ainda assumir `save`, mutacao e UX de conflito para arquivos de linguagem.
 Isso tambem sugere que o tema de direito de edicao do `FE` deve sair desta agenda.
 Aqui basta fechar a fase de leitura semantica minima enquanto o `FE` continua bloqueado para mutacao.
 Tambem importa manter o boundary certo:
 - `prometeu-vfs` continua owner de documentos, snapshots e persistencia;
 - `prometeu-lsp` futuro consome esse estado para analise;
 - o editor continua owner de UX;
 - build continua fronteira separada.
 Tambem vale fechar desde ja um principio de organizacao da API:
 - o `prometeu-lsp` deve usar flat packaging tomando `prometeu-packer-api` como referencia;
 - isso favorece superficies explicitas para `dtos`, `messages`, `events` e tipos correlatos;
 - evita esconder o contrato do LSP em arvore profunda demais ou em pacotes acidentais por feature interna;
 - e ajuda a manter a fronteira publica do modulo legivel para Studio e consumidores futuros.
 Se isso for respeitado, um LSP integrado proprio do Studio faz mais sentido do que qualquer adaptacao para editor externo.
 O que interessa aqui e ter um consumidor semantico alinhado ao runtime documental do produto, nao compatibilidade com VSCode.
 O conjunto de ganhos mais plausivel para esta fase minima e:
 - `diagnostics`;
 - `documentSymbol`/`workspaceSymbol` e `Outline`;
 - `definition`;
 - `highlight` no `FE`.
 `Completion`, `rename`, code actions, formatting e direito de edicao devem ficar fora desta agenda.
 Tambem ficou fechado que:
 - nao precisamos implementar agora persistencia de contexto de acesso por documento no `prometeu-vfs`;
 - mas ja devemos agrupar esses valores em uma mesma entidade de contexto, para que possam ser buscados e alterados sob demanda;
 - isso deixa o caminho mais curto para persistir esse contexto depois, sem refazer a modelagem;
 - e o contrato nao deve bloquear a futura introducao de um toggle de `read-only`/edicao por arquivo.
 ## Resolution
 Recommended direction: seguir com **Option B**.
 Direcao recomendada neste momento:
 1. o `FE` permanece `read-only` nesta agenda;
 2. esta agenda fecha apenas a fase de `prometeu-lsp` minimo com `FE` ainda `read-only`;
 3. essa fase trata o `prometeu-lsp` integrado como consumidor do conteudo exposto por `prometeu-vfs`;
 4. para documentos de `FE` abertos, a analise observa o snapshot em memoria da sessao;
 5. para documentos de `FE` fechados, a analise pode cair para o estado em filesystem;
 6. `prometeu-vfs` continua owner de snapshots, persistencia e politica de acesso documental;
 7. `prometeu-lsp` nao vira owner de `save`, de persistencia nem de politica de acesso;
 8. esta agenda mira como escopo minimo `diagnostics`, `symbols`/`outline`, `definition` e `highlight`;
 9. `completion`, `rename`, code actions, formatting e a liberacao de edicao de `FE` ficam para depois;
 10. a futura liberacao de edicao de `FE` deve acontecer em outra discussion propria;
 11. nenhuma fase desta agenda pode misturar automaticamente snapshot editorial com input canonico de build.
 12. a API de `prometeu-lsp` deve preferir flat packaging no estilo de `prometeu-packer-api`, com superficies explicitas como `dtos`, `messages` e `events`.
 13. o `prometeu-vfs` nao precisa implementar agora contexto persistente de acesso por documento, mas deve introduzir uma entidade de contexto unica para esses valores, de modo que leitura/mutacao sob demanda ja exista e a persistencia futura seja uma extensao natural.
 Next step suggestion: converter esta agenda em `decision` normativa para a fase `FE read-only + LSP minimo`, deixando a futura liberacao de edicao de `FE` para outra discussion.
--- a/discussion/workflow/decisions/DEC-0010-studio-controlled-non-frontend-editor-write-wave.md
+++ b/discussion/workflow/decisions/DEC-0010-studio-controlled-non-frontend-editor-write-wave.md
@ -0,0 +1,136 @@
 ---
 id: DEC-0010
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Establish the controlled non-frontend editor write wave in Studio
 status: accepted
 created: 2026-03-31
 accepted: 2026-03-31
 agenda: AGD-0013
 plans:
  - PLN-0019
  - PLN-0020
  - PLN-0021
 tags:
  - studio
  - editor
  - workspace
  - write
  - read-only
  - vfs
  - frontend-boundary
 ---
 ## Context
 The first Studio `Code Editor` wave established a read-only editorial shell and later moved project-document ownership into `prometeu-vfs`.
 That left one immediate follow-up decision:
 - which files may become editable now,
 - which files must remain `read-only`,
 - where access policy lives,
 - how save works,
 - and how editorial in-memory state stays contained away from build-facing state.
 The accepted agenda closed the intended first write wave as deliberately narrower than "all supported text files":
 - the same supported-document universe remains valid for opening,
 - but access policy must distinguish `read-only` from `editable`,
 - frontend-scoped files remain `read-only`,
 - and only already-supported non-frontend text classes enter the first write wave.
 ## Decision
 1. Studio SHALL introduce a controlled first editor write wave only for supported non-frontend documents.
 2. The canonical document universe for this wave SHALL remain the same universe already supported for opening through `prometeu-vfs`.
 3. `prometeu-vfs` SHALL own document access policy for this wave, including `load`, `save`, and the classification of each supported document as `read-only` or `editable`.
 4. `EditorWorkspace` MUST consume access policy from `prometeu-vfs` and MUST NOT rederive editability rules locally.
 5. Frontend-scoped documents SHALL remain hard `read-only` in this wave.
 6. Frontend scope SHALL be decided inside `prometeu-vfs` using `FrontendSpec.allowedExtensions` as the source of truth.
 7. The `prometeu-vfs` contract SHALL evolve so that `typeId` canonically represents that frontend scope in a way compatible with `FrontendSpec.allowedExtensions`, rather than exposing only a raw dynamic language identifier.
 8. The initial editable non-frontend document classes SHALL be limited to the currently supported textual classes represented as `text`, `json`, `ndjson`, and `bash`.
 9. No additional document-support class SHALL be inferred or added by implementation convenience during this wave.
 10. For editable documents in this wave, `prometeu-vfs` SHALL maintain an in-memory editorial snapshot for the current Studio session.
 11. `save` SHALL persist that in-memory editorial snapshot to disk through `prometeu-vfs`.
 12. The global shell `Save` menu item MUST NOT be the save surface for this wave.
 13. Save actions for this wave SHALL live inside the editor itself through a top command bar containing at least `Save` and `Save All`.
 14. Frontend-scoped hard `read-only` tabs MAY coexist with editable non-frontend tabs in the same editor workspace.
 15. Frontend-scoped hard `read-only` documents SHALL expose a `read-only` state in the editor status bar.
 16. The status-bar `read-only` surface SHOULD be designed so that it can evolve later into a per-file toggle without requiring a model rewrite.
 17. Frontend-scoped hard `read-only` documents MUST NOT allow local editorial mutation in this wave.
 18. Opening a frontend-scoped hard `read-only` document SHALL also show a top-of-editor warning stating that the file is `read-only`, cannot be edited, and cannot be saved in this wave.
 19. The editable documents in this wave SHALL be treated as editorial scope and SHALL NOT participate in the build by implication.
 20. The in-memory editorial snapshot used for this wave MUST remain contained and MUST NOT be treated as canonical build input.
 21. No implementation in this wave MAY collapse editorial session snapshots into build-facing or artifact-facing document state by inference.
 ## Rationale
 This decision preserves the correct architectural order.
 The editor needed real write behavior, but not at the cost of undoing the `prometeu-vfs` boundary that was just established.
 Keeping access policy in `prometeu-vfs` prevents a return to editor-local conditional logic.
 Keeping frontend documents `read-only` avoids releasing mutation for language-owned files before semantic support is ready.
 At the same time, allowing already-supported non-frontend text classes to become editable gives the Studio a meaningful write wave without pretending that all textual files belong to the same product tier.
 The decision also protects the build boundary.
 Having an in-memory editorial snapshot is necessary for writing, but it must not silently become the source of truth for build consumers.
 ## Technical Specification
 ### 1. Access Policy Surface
 - `prometeu-vfs` MUST expose access policy as part of the document contract for supported files.
 - That policy MUST distinguish at least:
  - unsupported document,
  - supported `read-only` document,
  - supported editable document.
 - The editor MUST treat this classification as canonical.
 ### 2. Frontend Classification
 - `prometeu-vfs` MUST classify frontend scope internally.
 - `FrontendSpec.allowedExtensions` MUST be the source of truth for that classification.
 - The VFS contract MUST expose a frontend-compatible canonical `typeId` or equivalent scope marker derived from that source of truth.
 - The editor MUST NOT infer frontend scope from path heuristics, local UI state, or ad hoc extension checks.
 ### 3. Editable Non-Frontend Set
 - Editable scope in this wave is limited to the currently supported textual document classes:
  - `text`
  - `json`
  - `ndjson`
  - `bash`
 - Future additions require explicit decision revision or a new decision.
 ### 4. Editorial Snapshot and Save
 - Editable documents MUST have a session-owned in-memory editorial snapshot.
 - `prometeu-vfs` MUST own the mutation-ready document state that `Save` and `Save All` use.
 - Persisting to disk MUST happen through `prometeu-vfs`.
 - The editor MUST remain a caller of save intent, not the owner of persistence policy.
 ### 5. UI Surfaces
 - The editor MUST provide a top command bar with at least `Save` and `Save All`.
 - Frontend hard `read-only` state MUST be visible in the status bar.
 - A frontend hard `read-only` document MUST show a top warning that it cannot be edited or saved in this wave.
 - Mixed tabs between editable and `read-only` documents are allowed.
 ### 6. Boundary with Build
 - Editorial snapshots for this wave MUST remain separate from build-facing state.
 - This wave MUST NOT introduce recompilation, artifact invalidation, build triggers, or any implied build participation.
 - Any future bridge between editorial state and build-facing state requires a separate explicit decision.
 ## Constraints
 - This decision does not release frontend editing.
 - This decision does not authorize completion, semantic gating, or LSP-owned save policy.
 - This decision does not authorize build-side observation of editorial in-memory snapshots.
 - Any ambiguity found later in planning or implementation MUST be resolved by a new explicit clarification instead of local inference.
 ## Revision Log
 - 2026-03-31: Initial accepted decision from AGD-0013.
 - 2026-03-31: Clarified that `FrontendSpec.allowedExtensions` is the source of truth for frontend scope, that VFS `typeId` must represent that scope canonically, and that frontend documents are hard read-only in this wave.
--- a/discussion/workflow/decisions/DEC-0011-studio-frontend-read-only-minimum-lsp-phase.md
+++ b/discussion/workflow/decisions/DEC-0011-studio-frontend-read-only-minimum-lsp-phase.md
@ -0,0 +1,155 @@
 ---
 id: DEC-0011
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Establish the frontend read-only minimum LSP phase in Studio
 status: accepted
 created: 2026-03-31
 accepted: 2026-03-31
 agenda: AGD-0014
 plans:
  - PLN-0022
  - PLN-0023
  - PLN-0024
  - PLN-0025
 tags:
  - studio
  - editor
  - workspace
  - frontend-boundary
  - lsp
  - access-policy
 ---
 ## Context
 The controlled non-frontend write wave intentionally kept frontend-scoped documents `read-only`.
 After that closure, the next question was not "how to edit frontend now", but rather:
 - whether Studio could already gain semantic value over frontend documents while they remain `read-only`,
 - how `prometeu-lsp` should relate to `prometeu-vfs`,
 - what minimum semantic scope is worth shipping,
 - and how to keep this phase separate from the later decision that may release frontend editing.
 The accepted agenda closed that this phase should remain explicitly `read-only` for frontend documents while introducing a minimum integrated LSP layer over the same project-session document substrate.
 ## Decision
 1. Studio SHALL introduce a frontend `read-only` semantic phase before any frontend editing phase is considered.
 2. This phase SHALL keep frontend-scoped documents hard `read-only`.
 3. This phase SHALL introduce a minimum integrated `prometeu-lsp` consumer above `prometeu-vfs`.
 4. `prometeu-lsp` SHALL consume document state exposed by `prometeu-vfs`.
 5. For opened frontend documents, `prometeu-lsp` SHALL analyze the in-memory session snapshot exposed by `prometeu-vfs`.
 6. For unopened frontend documents, `prometeu-lsp` MAY fall back to filesystem-backed state exposed through the same document boundary.
 7. `prometeu-lsp` MUST NOT become the owner of document persistence, save policy, or access policy.
 8. `prometeu-vfs` SHALL remain the owner of document state, snapshots, persistence, and access-policy context.
 9. Frontend scope in this phase SHALL continue to use `FrontendSpec.allowedExtensions` as source of truth, and the VFS contract SHALL expose a frontend-compatible canonical `typeId` or equivalent scope marker derived from that source of truth.
 10. The minimum semantic scope of this phase SHALL include:
  - diagnostics,
  - document symbols and workspace symbols,
  - outline-facing structural symbol data,
  - definition,
  - highlight for frontend documents.
 11. Highlight for non-frontend documents MAY remain Studio-local as currently implemented in this phase.
 12. Highlight for frontend documents SHALL come from semantic information provided through `prometeu-lsp` and SHALL use frontend-owned color semantics rather than a Studio-local fallback scheme.
 13. `Completion` SHALL remain out of scope for this minimum `read-only` phase.
 14. `Rename`, code actions, formatting, and any frontend edit-right release SHALL remain out of scope for this phase.
 15. The future release of frontend editing SHALL be handled by a separate discussion and decision.
 16. The editorial in-memory state observed by `prometeu-lsp` MAY feed semantic analysis, but MUST NOT be treated as canonical build input by implication.
 17. Any future bridge between frontend editorial state and build-facing state SHALL require a separate explicit decision.
 18. `prometeu-lsp` API organization SHALL prefer flat packaging modeled after `prometeu-packer-api`, using explicit public surfaces such as `dtos`, `messages`, and `events` where appropriate.
 19. `prometeu-vfs` does not need to persist document-access context yet, but it SHALL introduce a single context entity for such values so that read, mutation, and future persistence remain a natural extension rather than a redesign.
 ## Rationale
 This decision separates semantic readiness from editing rights.
 That separation is valuable because frontend files are materially different from generic textual documents.
 For frontend documents, even a minimum Studio-integrated semantic consumer provides immediate value:
 - diagnostics,
 - outline and symbols,
 - definition,
 - highlight,
 - and a validated path from document session state into semantic reading.
 At the same time, keeping editing out of this phase protects the product from releasing mutation before its semantic consumer and editorial boundaries are ready.
 The decision also preserves a clean ownership model:
 - `prometeu-vfs` owns document state,
 - `prometeu-lsp` consumes that state,
 - the editor owns UX,
 - and build remains separate.
 ## Technical Specification
 ### 1. Phase Boundary
 - This decision defines a frontend semantic-read phase, not a frontend editing phase.
 - Frontend documents remain hard `read-only` throughout this decision's scope.
 - No plan derived from this decision may infer `save`, mutation, or frontend dirty-tracking rights.
 ### 2. Document Source of Truth for Analysis
 - Opened frontend documents MUST be analyzed from the in-memory document snapshot held by `prometeu-vfs`.
 - Closed frontend documents MAY be analyzed from filesystem-backed document state through the same boundary.
 - Frontend scope MUST continue to derive from `FrontendSpec.allowedExtensions`.
 - The VFS contract MUST expose a frontend-compatible canonical `typeId` or equivalent scope marker derived from that source of truth.
 - Consumers MUST NOT bypass `prometeu-vfs` with ad hoc file loading inside Studio UI code.
 ### 3. Minimum LSP Capability Set
 - The minimum phase MUST provide:
  - diagnostics,
  - document symbols,
  - workspace symbols,
  - outline-facing symbol structure,
  - go-to-definition,
  - frontend highlight.
 - `Completion` is explicitly excluded from this minimum phase.
 - Highlight for non-frontend files may remain Studio-local during this phase.
 - Highlight for frontend files MUST come from LSP semantic output and frontend-owned color semantics.
 ### 4. Ownership Rules
 - `prometeu-lsp` MUST remain a semantic consumer.
 - `prometeu-lsp` MUST NOT own:
  - save,
  - persistence,
  - document access policy,
  - frontend edit-right release.
 - `prometeu-vfs` MUST remain the owner of document state and access context.
 ### 5. Packaging Rules
 - The public API of `prometeu-lsp` SHOULD use flat packaging similar to `prometeu-packer-api`.
 - Public contract types SHOULD be grouped under explicit, shallow package surfaces such as:
  - `dtos`
  - `messages`
  - `events`
 - Deep packaging by internal implementation concern SHOULD be avoided for public contract surfaces.
 ### 6. Context Reservation
 - `prometeu-vfs` MUST introduce a single context entity for document-access-related values that may evolve later.
 - This context does not need persistence yet.
 - It MUST already support lookup and mutation under current demand so that future persistence can be added without reworking the model.
 ### 7. Boundary with Build
 - Semantic analysis over editorial in-memory state does not authorize build participation.
 - No implementation derived from this decision may treat editorial snapshots as canonical build inputs.
 - Build-facing transitions require separate decision work.
 ## Constraints
 - This decision does not release frontend editing.
 - This decision does not authorize completion.
 - This decision does not authorize semantic gating of save because save for frontend files remains out of scope.
 - This decision does not authorize external-editor compatibility requirements.
 ## Revision Log
 - 2026-03-31: Initial accepted decision from AGD-0014.
 - 2026-03-31: Clarified frontend scope source-of-truth via `FrontendSpec.allowedExtensions`, hardened frontend read-only semantics, and locked frontend highlight to LSP semantic output while non-frontend highlight remains Studio-local.
--- a/discussion/workflow/plans/PLN-0019-propagate-dec-0010-into-studio-and-vfs-specs.md
+++ b/discussion/workflow/plans/PLN-0019-propagate-dec-0010-into-studio-and-vfs-specs.md
@ -0,0 +1,115 @@
 ---
 id: PLN-0019
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Propagate DEC-0010 into Studio editor and VFS specs
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, editor, vfs, specs, write-wave]
 ---
 ## Objective
 Make the controlled non-frontend write wave normative across the Studio and VFS spec corpus before code changes begin.
 ## Background
 DEC-0010 locks a new first write wave for non-frontend textual documents, keeps frontend files hard `read-only`, moves access policy and save ownership into `prometeu-vfs`, and requires a local editor command bar rather than the global shell save surface.
 The current Studio/VFS specs still describe the first editor wave as read-only and do not yet express:
 - canonical frontend classification through `FrontendSpec.allowedExtensions`,
 - VFS-owned access policy,
 - hard frontend `read-only`,
 - editor-local `Save` and `Save All`,
 - or the non-build editorial boundary for in-memory write snapshots.
 ## Scope
 ### Included
 - update Studio specs to reflect the controlled write wave
 - update VFS specification text for canonical frontend scope and access policy
 - update spec index/read order if document ordering changes
 ### Excluded
 - code implementation
 - LSP semantic-read phase wording from DEC-0011
 - any frontend edit-right release
 ## Execution Steps
 ### Step 1 - Update the Code Editor Workspace Specification
 **What:**
 Replace the current read-only-first-wave wording with the DEC-0010 controlled write-wave contract.
 **How:**
 Amend the editor spec so it states:
 - non-frontend supported text classes may be editable,
 - frontend files remain hard `read-only`,
 - save actions live in an editor-local command bar,
 - mixed editable and `read-only` tabs are allowed,
 - frontend warnings and status-bar presentation are explicit.
 **File(s):**
 - `docs/specs/studio/5. Code Editor Workspace Specification.md`
 ### Step 2 - Update the Project Document VFS Specification
 **What:**
 Make the VFS spec the normative home for access policy and canonical frontend scope.
 **How:**
 Amend the VFS spec to state:
 - `FrontendSpec.allowedExtensions` is the source of truth,
 - VFS must expose a canonical frontend-compatible `typeId` or equivalent scope marker,
 - VFS owns access policy and save for editable non-frontend documents,
 - editorial snapshots stay out of build-facing state.
 **File(s):**
 - `docs/specs/studio/6. Project Document VFS Specification.md`
 ### Step 3 - Update Shell-Level and Index Documentation
 **What:**
 Keep the Studio spec corpus navigable after the write-wave decision lands.
 **How:**
 Update any shell-level wording and read-order/index docs that still imply the editor is fully read-only.
 **File(s):**
 - `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`
 - `docs/specs/studio/README.md`
 ## Test Requirements
 ### Unit Tests
 - none
 ### Integration Tests
 - none
 ### Manual Verification
 - verify the spec set no longer contradicts DEC-0010 on read-only versus editable scope
 - verify frontend hard `read-only` and editor-local save surfaces are both explicit
 - verify build separation for editorial snapshots is stated unambiguously
 ## Acceptance Criteria
 - [ ] Studio specs reflect the controlled non-frontend write wave
 - [ ] VFS specs state `FrontendSpec.allowedExtensions` as source of truth for frontend scope
 - [ ] editor-local `Save` and `Save All` are normatively placed in the editor, not the shell menu
 - [ ] hard frontend `read-only` is stated consistently across Studio and VFS specs
 - [ ] editorial in-memory snapshots are explicitly separated from build-facing state
 ## Dependencies
 - DEC-0010 accepted
 ## Risks
 - stale read-only wording may remain in sibling specs and confuse implementation
 - weak wording around canonical frontend scope could reintroduce contract ambiguity
 - editor-local save surfaces may be described inconsistently if shell docs are not updated
--- a/discussion/workflow/plans/PLN-0020-build-dec-0010-vfs-access-policy-and-save-core.md
+++ b/discussion/workflow/plans/PLN-0020-build-dec-0010-vfs-access-policy-and-save-core.md
@ -0,0 +1,128 @@
 ---
 id: PLN-0020
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Build DEC-0010 VFS access policy and save core
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, editor, vfs, write-wave, save, access-policy]
 ---
 ## Objective
 Implement the VFS-side contract required by DEC-0010: canonical frontend scope, access policy classification, editable snapshots, and save-to-disk ownership.
 ## Background
 DEC-0010 makes `prometeu-vfs` the owner of:
 - frontend scope classification from `FrontendSpec.allowedExtensions`,
 - canonical access policy per supported document,
 - editable in-memory document snapshots for non-frontend supported text classes,
 - and save persistence for those documents.
 That work must land before editor UI code can consume the new write-wave behavior safely.
 ## Scope
 ### Included
 - add VFS access-policy models
 - evolve VFS document/type contract so frontend scope is canonical
 - add snapshot mutation and save operations for editable non-frontend docs
 - add the document-access context entity reserved by the decision
 - update and expand VFS tests
 ### Excluded
 - editor command-bar UI
 - LSP API or semantic-read behavior
 - frontend editing
 ## Execution Steps
 ### Step 1 - Extend the Public VFS API
 **What:**
 Add the public contract needed for access policy, editable snapshots, and save.
 **How:**
 Extend `prometeu-vfs-api` with:
 - an explicit access-mode model,
 - canonical frontend scope exposure through `typeId` or equivalent scope marker,
 - document mutation/update operations for editable docs,
 - save and save-all oriented commands,
 - a document-access context entity that can be read and mutated now and persisted later.
 **File(s):**
 - `prometeu-vfs/prometeu-vfs-api/src/main/java/p/studio/vfs/**`
 ### Step 2 - Implement the Filesystem-Backed VFS Behavior
 **What:**
 Teach the filesystem-backed VFS to enforce DEC-0010 semantics.
 **How:**
 Update the VFS implementation so it:
 - derives frontend scope from `FrontendSpec.allowedExtensions`,
 - exposes canonical scope information through the VFS contract,
 - rejects local mutation for hard `read-only` frontend docs,
 - keeps editable non-frontend session snapshots in memory,
 - persists those snapshots to disk on save.
 **File(s):**
 - `prometeu-vfs/prometeu-vfs-v1/src/main/java/p/studio/vfs/FilesystemProjectDocumentVfs.java`
 - `prometeu-vfs/prometeu-vfs-v1/src/main/java/p/studio/vfs/FilesystemProjectDocumentVfsFactory.java`
 ### Step 3 - Add Conformance Tests
 **What:**
 Prove the VFS now owns the right boundary.
 **How:**
 Add tests that cover:
 - frontend scope classification from `allowedExtensions`,
 - hard `read-only` refusal for frontend docs,
 - editable snapshots for non-frontend supported docs,
 - save persistence,
 - separation between editorial snapshots and fresh filesystem state where applicable,
 - access-context lookup and mutation.
 **File(s):**
 - `prometeu-vfs/prometeu-vfs-v1/src/test/java/p/studio/vfs/FilesystemProjectDocumentVfsTest.java`
 - new `prometeu-vfs/**` test files as needed
 ## Test Requirements
 ### Unit Tests
 - access-policy classification
 - frontend hard `read-only` behavior
 - editable snapshot update/save behavior
 - access-context read/mutate behavior
 ### Integration Tests
 - filesystem-backed save roundtrip for editable non-frontend docs
 ### Manual Verification
 - confirm editable non-frontend docs roundtrip through save
 - confirm frontend docs stay non-mutable at the VFS boundary
 ## Acceptance Criteria
 - [ ] VFS exposes canonical access policy for supported documents
 - [ ] frontend scope derives from `FrontendSpec.allowedExtensions`
 - [ ] frontend docs are hard `read-only` at the VFS boundary
 - [ ] editable non-frontend docs have in-memory snapshots and save through VFS
 - [ ] a single access-context entity exists for current read/mutate demand
 ## Dependencies
 - DEC-0010 accepted
 - PLN-0019 review completed or otherwise stable enough for implementation
 ## Risks
 - overloading `typeId` incorrectly could break existing presentation routing
 - save semantics could leak into frontend scope if access policy is not enforced centrally
 - snapshot/context modeling could become too broad if it starts anticipating future LSP needs prematurely
--- a/discussion/workflow/plans/PLN-0021-integrate-dec-0010-editor-write-ui-and-workflow.md
+++ b/discussion/workflow/plans/PLN-0021-integrate-dec-0010-editor-write-ui-and-workflow.md
@ -0,0 +1,136 @@
 ---
 id: PLN-0021
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Integrate DEC-0010 editor write UI and workflow in Studio
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, editor, ui, save, read-only, write-wave]
 ---
 ## Objective
 Make the Studio editor consume the DEC-0010 VFS write contract and expose the intended UI workflow for editable non-frontend documents and hard frontend `read-only` documents.
 ## Background
 Once VFS access policy and save behavior exist, the editor still needs to:
 - stop being globally read-only,
 - surface mixed editable and frontend hard `read-only` tabs correctly,
 - expose editor-local save commands,
 - and keep frontend warnings/status consistent with the decision.
 ## Scope
 ### Included
 - wire editor UI to new VFS access policy and save commands
 - add editor-local `Save` and `Save All` command bar
 - keep frontend docs hard `read-only`
 - show frontend top warning and status-bar state
 - update editor tests
 ### Excluded
 - LSP integration
 - frontend editing
 - shell-global menu save behavior beyond remaining unused for this flow
 ## Execution Steps
 ### Step 1 - Rewire Editor Session State Around Access Policy
 **What:**
 Make the editor session aware of document access mode and save capability.
 **How:**
 Update open-file/session models so they track:
 - document access mode,
 - save eligibility,
 - frontend hard `read-only` state,
 - and editor-local command enablement.
 **File(s):**
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorOpenFileBuffer.java`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorOpenFileSession.java`
 ### Step 2 - Add the Editor Command Bar and Save Flow
 **What:**
 Expose the write commands in the editor itself.
 **How:**
 Add a top command bar or equivalent editor-local surface with `Save` and `Save All`, wired to VFS save operations for editable non-frontend docs only.
 **File(s):**
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
 - new `prometeu-studio/src/main/java/p/studio/workspaces/editor/**` command-bar surface as needed
 - `prometeu-studio/src/main/resources/themes/default-prometeu.css`
 ### Step 3 - Enforce Hard Frontend Read-Only in the Editor UX
 **What:**
 Make frontend files visibly hard `read-only`.
 **How:**
 Ensure FE files:
 - cannot be mutated in the editor UI,
 - show `read-only` in the status bar,
 - show the required top warning,
 - and can coexist with editable non-frontend tabs without ambiguity.
 **File(s):**
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorStatusBar.java`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorTabStrip.java`
 ### Step 4 - Update Editor Tests
 **What:**
 Keep editor tests focused on editor-owned behavior under the new mixed access-mode workflow.
 **How:**
 Add or adjust tests for:
 - editable non-frontend save command routing,
 - FE hard `read-only` UI state,
 - mixed tab behavior,
 - command enablement.
 **File(s):**
 - `prometeu-studio/src/test/java/p/studio/workspaces/editor/**`
 ## Test Requirements
 ### Unit Tests
 - mixed access-mode tab/session behavior
 - save command enablement
 - FE hard `read-only` presentation state
 ### Integration Tests
 - editor workspace integration against a VFS test double exposing editable and hard `read-only` docs
 ### Manual Verification
 - open editable `json`/`bash`/`text` docs and confirm save works
 - open FE docs and confirm they cannot be edited
 - confirm FE warning and status-bar state are visible
 ## Acceptance Criteria
 - [ ] editor consumes VFS access policy instead of local editability inference
 - [ ] `Save` and `Save All` live in the editor UI
 - [ ] FE docs are hard `read-only` in actual editor interaction
 - [ ] mixed editable and FE `read-only` tabs behave coherently
 - [ ] editor tests cover the new workflow
 ## Dependencies
 - DEC-0010 accepted
 - PLN-0020 review completed or otherwise stable enough for UI integration
 ## Risks
 - UI may accidentally permit FE mutation if command enablement and editor mutability diverge
 - save flow could become split-brained if some callsites bypass editor-local commands
 - warning/status surfaces may drift if they are implemented independently
--- a/discussion/workflow/plans/PLN-0022-propagate-dec-0011-into-studio-vfs-and-lsp-specs.md
+++ b/discussion/workflow/plans/PLN-0022-propagate-dec-0011-into-studio-vfs-and-lsp-specs.md
@ -0,0 +1,102 @@
 ---
 id: PLN-0022
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Propagate DEC-0011 into Studio, VFS, and LSP specs
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, lsp, vfs, specs, frontend-boundary]
 ---
 ## Objective
 Make the frontend read-only minimum LSP phase normative in the Studio/VFS spec corpus and establish the intended LSP contract shape before implementation.
 ## Background
 DEC-0011 introduces a dedicated phase:
 - FE remains hard `read-only`,
 - `prometeu-lsp` consumes VFS snapshots,
 - the minimum feature set is diagnostics, symbols/outline, definition, and frontend highlight,
 - non-frontend highlight may remain Studio-local,
 - and the API should follow flat packaging similar to `prometeu-packer-api`.
 ## Scope
 ### Included
 - propagate DEC-0011 into Studio and VFS specs
 - introduce or update LSP-facing specification text
 - document flat packaging and minimum LSP scope
 ### Excluded
 - code implementation
 - frontend edit-right release
 - completion
 ## Execution Steps
 ### Step 1 - Update Studio Editor and VFS Specifications
 **What:**
 Add the new frontend semantic-read phase to the existing Studio/VFS spec set.
 **How:**
 Amend the relevant specs so they explicitly state:
 - FE remains hard `read-only`,
 - LSP consumes VFS snapshots,
 - non-frontend highlight remains local for now,
 - frontend highlight comes from LSP semantics.
 **File(s):**
 - `docs/specs/studio/5. Code Editor Workspace Specification.md`
 - `docs/specs/studio/6. Project Document VFS Specification.md`
 ### Step 2 - Introduce an LSP-Focused Studio Specification
 **What:**
 Create a normative home for the integrated LSP phase.
 **How:**
 Add a Studio spec that defines:
 - integrated `prometeu-lsp` role,
 - read-only FE semantic phase,
 - minimum capability set,
 - flat packaging expectation,
 - and explicit non-goals such as completion and frontend editing.
 **File(s):**
 - new `docs/specs/studio/7. Integrated LSP Semantic Read Phase Specification.md`
 - `docs/specs/studio/README.md`
 ## Test Requirements
 ### Unit Tests
 - none
 ### Integration Tests
 - none
 ### Manual Verification
 - verify no contradiction exists between DEC-0010 and DEC-0011 in the specs
 - verify the new spec makes the minimum LSP scope and exclusions explicit
 ## Acceptance Criteria
 - [ ] the Studio spec set reflects the FE read-only minimum LSP phase
 - [ ] frontend highlight ownership is clearly separated from Studio-local non-frontend highlight
 - [ ] LSP flat packaging is stated normatively enough to guide implementation
 - [ ] completion and frontend edit rights remain explicitly out of scope
 ## Dependencies
 - DEC-0011 accepted
 - DEC-0010 stable enough to provide the underlying VFS/write boundary
 ## Risks
 - spec propagation may accidentally imply frontend editing
 - lack of a dedicated LSP spec could bury too much behavior in editor/VFS docs
 - packaging guidance may stay too vague if not stated explicitly
--- a/discussion/workflow/plans/PLN-0023-scaffold-flat-packed-prometeu-lsp-api-and-session-seams.md
+++ b/discussion/workflow/plans/PLN-0023-scaffold-flat-packed-prometeu-lsp-api-and-session-seams.md
@ -0,0 +1,110 @@
 ---
 id: PLN-0023
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Scaffold flat-packed prometeu-lsp API and Studio session seams
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, lsp, api, packaging, session]
 ---
 ## Objective
 Create the flat-packed `prometeu-lsp` module surfaces and the Studio/VFS session seams required by DEC-0011 before semantic capabilities are implemented.
 ## Background
 `prometeu-lsp` currently exists only as empty Gradle modules.
 DEC-0011 requires:
 - flat packaging in the style of `prometeu-packer-api`,
 - a Studio-integrated semantic consumer above VFS,
 - and a clean session-level seam for opened-document snapshots and closed-document filesystem fallback.
 ## Scope
 ### Included
 - scaffold public LSP API packages and contract types
 - scaffold runtime/v1 module shape
 - add Studio-side integration seam for a project-session-owned LSP consumer
 ### Excluded
 - actual diagnostics/symbol/definition/highlight logic
 - frontend editing
 - completion
 ## Execution Steps
 ### Step 1 - Create Flat API Surfaces
 **What:**
 Set up `prometeu-lsp-api` with explicit public package surfaces.
 **How:**
 Create shallow public packages such as:
 - `dtos`
 - `messages`
 - `events`
 along with the top-level service/factory/context contracts needed by Studio.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-api/src/main/java/**`
 ### Step 2 - Create Runtime/V1 Wiring
 **What:**
 Set up the first concrete implementation module.
 **How:**
 Add the initial runtime package layout in `prometeu-lsp-v1`, including factory and internal service skeletons that consume `prometeu-vfs` state rather than raw filesystem reads.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`
 - `prometeu-lsp/prometeu-lsp-v1/build.gradle.kts`
 ### Step 3 - Add Studio Session Integration Seams
 **What:**
 Make room for a project-session-owned LSP consumer in Studio.
 **How:**
 Introduce or extend Studio project-session types so an integrated LSP consumer can later be constructed from project context and VFS access without changing the architectural owner.
 **File(s):**
 - `prometeu-studio/src/main/java/p/studio/projectsessions/**`
 - `prometeu-studio/src/main/java/p/studio/window/MainView.java`
 - `prometeu-studio/src/main/java/p/studio/window/StudioWindowCoordinator.java`
 ## Test Requirements
 ### Unit Tests
 - API contract smoke tests where useful
 - session-seam construction tests
 ### Integration Tests
 - project-session integration test proving Studio can construct LSP scaffold without semantic behavior yet
 ### Manual Verification
 - confirm package layout is shallow and public surfaces are legible
 - confirm no direct filesystem ownership leaks into Studio UI code
 ## Acceptance Criteria
 - [ ] `prometeu-lsp-api` exposes flat public package surfaces
 - [ ] `prometeu-lsp-v1` contains concrete scaffold wiring above VFS
 - [ ] Studio has a session seam ready for an integrated LSP consumer
 - [ ] no semantic feature implementation is required yet for the scaffold to compile
 ## Dependencies
 - DEC-0011 accepted
 - PLN-0022 review completed or otherwise stable enough for contract shape
 - DEC-0010 major VFS contract direction already stable
 ## Risks
 - public API may accidentally mirror internal implementation packages too closely
 - Studio session ownership could drift if LSP is wired too low in the editor UI
 - premature semantic helpers may leak into the scaffold plan if scope is not kept tight
--- a/discussion/workflow/plans/PLN-0024-implement-read-only-fe-diagnostics-symbols-and-definition.md
+++ b/discussion/workflow/plans/PLN-0024-implement-read-only-fe-diagnostics-symbols-and-definition.md
@ -0,0 +1,120 @@
 ---
 id: PLN-0024
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Implement read-only FE diagnostics, symbols, and definition over VFS snapshots
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, lsp, diagnostics, symbols, definition, frontend]
 ---
 ## Objective
 Implement the non-highlight semantic capabilities of DEC-0011 for read-only frontend documents by consuming VFS snapshots through the integrated LSP seam.
 ## Background
 DEC-0011 defines a minimum semantic-read phase for FE documents.
 This plan focuses on the analysis-driven capabilities that do not depend on frontend highlight/color delivery:
 - diagnostics,
 - symbols/outline,
 - and definition.
 The compiler pipeline already exposes `analyze` as a no-write semantic entrypoint suitable for tooling.
 ## Scope
 ### Included
 - diagnostics for FE documents
 - symbol/outline data for FE documents
 - definition for FE documents
 - VFS-snapshot-backed analysis for open docs and filesystem fallback for closed docs
 ### Excluded
 - frontend highlight
 - completion
 - frontend editing
 ## Execution Steps
 ### Step 1 - Build Analysis Snapshot Ingestion
 **What:**
 Connect the integrated LSP runtime to the compiler `analyze` pipeline over VFS-provided document state.
 **How:**
 Implement the runtime path that:
 - reads open-document snapshot state from VFS,
 - falls back to filesystem-backed state for closed docs,
 - produces analysis snapshots,
 - and keeps build-side persistence out of scope.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`
 - `prometeu-compiler/prometeu-build-pipeline/**` callsites as needed
 ### Step 2 - Expose Diagnostics
 **What:**
 Surface FE diagnostics through the integrated LSP contracts.
 **How:**
 Map analysis results into LSP-facing DTOs/messages and ensure Studio consumers can receive them without requiring frontend editing.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-api/src/main/java/**`
 - `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`
 ### Step 3 - Expose Symbols, Outline, and Definition
 **What:**
 Provide enough semantic structure for FE read-only navigation.
 **How:**
 Use analysis facts to expose:
 - document symbols,
 - workspace symbols,
 - outline-facing structure,
 - go-to-definition.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-api/src/main/java/**`
 - `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorOutlinePanel.java`
 ## Test Requirements
 ### Unit Tests
 - analysis snapshot ingestion from open and closed document sources
 - diagnostics mapping
 - symbol/definition mapping
 ### Integration Tests
 - end-to-end FE semantic-read test over a project-session VFS snapshot
 ### Manual Verification
 - open FE docs and confirm diagnostics appear
 - confirm outline/symbol navigation works without unlocking editing
 - confirm definition resolves from open in-memory docs
 ## Acceptance Criteria
 - [ ] FE diagnostics work from VFS-backed analysis
 - [ ] FE symbols and outline data are available in read-only mode
 - [ ] go-to-definition works against the same semantic substrate
 - [ ] open docs use in-memory snapshot state while closed docs can use filesystem fallback
 ## Dependencies
 - DEC-0011 accepted
 - PLN-0023 review completed or otherwise stable enough to provide runtime seams
 - DEC-0010/editor-session substrate major pieces sufficiently stable
 ## Risks
 - analysis ingestion may accidentally bypass VFS and read files directly
 - outline/symbol shape may drift if not modeled cleanly in API contracts
 - definition support may require compiler facts not yet surfaced cleanly
--- a/discussion/workflow/plans/PLN-0025-implement-fe-semantic-highlight-consumption.md
+++ b/discussion/workflow/plans/PLN-0025-implement-fe-semantic-highlight-consumption.md
@ -0,0 +1,108 @@
 ---
 id: PLN-0025
 ticket: studio-editor-write-wave-supported-non-frontend-files
 title: Implement FE semantic highlight and editor consumption for the read-only LSP phase
 status: review
 created: 2026-03-31
 completed:
 tags: [studio, lsp, highlight, frontend, editor]
 ---
 ## Objective
 Implement frontend highlight delivery through `prometeu-lsp` semantics while leaving non-frontend highlighting Studio-local as DEC-0011 requires.
 ## Background
 DEC-0011 explicitly separates highlight ownership:
 - non-frontend highlight may remain local to the Studio editor,
 - frontend highlight must come from the integrated LSP semantic layer and frontend-owned color semantics.
 This deserves its own plan because it crosses API, runtime, and editor presentation boundaries.
 ## Scope
 ### Included
 - FE semantic highlight contracts in LSP
 - FE semantic highlight production in runtime
 - editor consumption path for FE highlight
 - frontend-owned color semantics integration
 ### Excluded
 - non-frontend highlight rewrite
 - completion
 - frontend editing
 ## Execution Steps
 ### Step 1 - Define FE Highlight Contracts
 **What:**
 Add LSP-facing contracts for semantic highlight delivery.
 **How:**
 Define DTOs/messages that carry FE semantic highlight spans and any required theme/color semantics without forcing Studio-local token rules onto FE documents.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-api/src/main/java/**`
 ### Step 2 - Implement Runtime Highlight Production
 **What:**
 Produce FE highlight data from the integrated LSP runtime.
 **How:**
 Implement the runtime path that derives semantic highlight facts for FE docs from the same read-only analysis substrate used by diagnostics and symbols.
 **File(s):**
 - `prometeu-lsp/prometeu-lsp-v1/src/main/java/**`
 ### Step 3 - Consume FE Highlight in the Editor
 **What:**
 Make the editor choose FE highlight from LSP while leaving other document types on the existing local path.
 **How:**
 Update editor presentation routing so:
 - FE docs use LSP semantic highlight results and frontend-owned color semantics,
 - non-FE docs continue using Studio-local highlighting.
 **File(s):**
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorDocumentPresentationRegistry.java`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
 - `prometeu-studio/src/main/java/p/studio/workspaces/editor/syntaxhighlight/**`
 - `prometeu-studio/src/main/resources/themes/editor/**`
 ## Test Requirements
 ### Unit Tests
 - FE highlight DTO/runtime mapping
 - editor routing between FE LSP highlight and non-FE local highlight
 ### Integration Tests
 - FE document read-only semantic highlight test through Studio + VFS + LSP path
 ### Manual Verification
 - open FE docs and confirm semantic highlight comes from LSP-driven data
 - open non-FE docs and confirm existing local highlighting still works
 ## Acceptance Criteria
 - [ ] FE highlight is produced by the integrated LSP runtime
 - [ ] FE highlight uses frontend-owned color semantics rather than Studio-local fallback token rules
 - [ ] non-FE highlighting remains on the existing local Studio path
 - [ ] editor presentation routing clearly separates FE and non-FE highlight ownership
 ## Dependencies
 - DEC-0011 accepted
 - PLN-0023 review completed or otherwise stable enough for LSP contracts/runtime
 - PLN-0024 review completed or otherwise stable enough to provide shared FE semantic facts
 ## Risks
 - FE highlight could accidentally duplicate or conflict with local Studio token rules
 - color-semantics contracts may become too UI-coupled if not modeled carefully
 - editor routing may become fragile if FE and non-FE ownership boundaries are not explicit
--- a/prometeu-compiler/prometeu-compiler-core/src/main/java/p/studio/compiler/models/FrontendSpec.java
+++ b/prometeu-compiler/prometeu-compiler-core/src/main/java/p/studio/compiler/models/FrontendSpec.java
@ -14,12 +14,10 @@ public class FrontendSpec {
    private final ReadOnlySet<String> sourceRoots;
    private final boolean caseSensitive;
    @Builder.Default
    private final String entryPointCallableName = "main";
    @Builder.Default
    private final List<Stdlib> stdlibVersions = List.of();
    public String toString() {
-        return String.format("FrontendSpec(language=%s, entryPoint=%s)", languageId, entryPointCallableName);
+        return String.format("FrontendSpec(language=%s)", languageId);
    }
    public enum StdlibType {