editor workspace foundation
This commit is contained in:
parent
868006dd6b
commit
3a3bd407ce
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -1,4 +1,4 @@
|
||||
{"type":"meta","next_id":{"DSC":12,"AGD":12,"DEC":9,"PLN":15,"LSN":26,"CLSN":1}}
|
||||
{"type":"meta","next_id":{"DSC":12,"AGD":12,"DEC":9,"PLN":15,"LSN":27,"CLSN":1}}
|
||||
{"type":"discussion","id":"DSC-0001","status":"done","ticket":"studio-docs-import","title":"Import docs/studio into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["studio","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0001","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0001-assets-workspace-execution-wave-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0002","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0002-bank-composition-editor-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0003","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0003-mental-model-asset-mutations-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0004","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0004-mental-model-assets-workspace-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0005","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0005-mental-model-studio-events-and-components-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0006","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0006-mental-model-studio-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0007","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0007-pack-wizard-shell-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0008","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0008-project-scoped-state-and-activity-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0016","file":"discussion/lessons/DSC-0001-studio-docs-import/LSN-0016-studio-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
|
||||
{"type":"discussion","id":"DSC-0002","status":"open","ticket":"palette-management-in-studio","title":"Palette Management in Studio","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["studio","legacy-import","palette-management","tile-bank","packer-boundary"],"agendas":[{"id":"AGD-0002","file":"AGD-0002-palette-management-in-studio.md","status":"open","created_at":"2026-03-26","updated_at":"2026-03-26"}],"decisions":[],"plans":[],"lessons":[]}
|
||||
{"type":"discussion","id":"DSC-0003","status":"done","ticket":"packer-docs-import","title":"Import docs/packer into discussion-framework artifacts","created_at":"2026-03-26","updated_at":"2026-03-26","tags":["packer","migration","discussion-framework","docs-import"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0009","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0009-mental-model-packer-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0010","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0010-asset-identity-and-runtime-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0011","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0011-foundations-workspace-runtime-and-build-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0012","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0012-runtime-ownership-and-studio-boundary-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0013","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0013-metadata-convergence-and-runtime-sink-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0014","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0014-pack-wizard-summary-validation-and-pack-execution-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0015","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0015-tile-bank-packing-contract-legacy.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"},{"id":"LSN-0017","file":"discussion/lessons/DSC-0003-packer-docs-import/LSN-0017-packer-docs-import-pattern.md","status":"done","created_at":"2026-03-26","updated_at":"2026-03-26"}]}
|
||||
@ -8,5 +8,5 @@
|
||||
{"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":"in_progress","ticket":"studio-code-editor-workspace-foundations","title":"Establish Code Editor workspace foundations in Studio without LSP","created_at":"2026-03-30","updated_at":"2026-03-30","tags":["studio","editor","workspace","multi-frontend","lsp-deferred"],"agendas":[{"id":"AGD-0010","file":"AGD-0010-studio-code-editor-workspace-foundations.md","status":"accepted","created_at":"2026-03-30","updated_at":"2026-03-30"}],"decisions":[{"id":"DEC-0008","file":"DEC-0008-studio-code-editor-read-only-workspace-foundations.md","status":"accepted","created_at":"2026-03-30","updated_at":"2026-03-30","ref_agenda":"AGD-0010"}],"plans":[{"id":"PLN-0012","file":"PLN-0012-studio-code-editor-spec-propagation.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30","ref_decisions":["DEC-0008"]},{"id":"PLN-0013","file":"PLN-0013-editor-workspace-layout-and-passive-surfaces.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30","ref_decisions":["DEC-0008"]},{"id":"PLN-0014","file":"PLN-0014-project-navigator-snapshot-and-read-only-file-opening.md","status":"done","created_at":"2026-03-30","updated_at":"2026-03-30","ref_decisions":["DEC-0008"]}],"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"}]}
|
||||
|
||||
@ -1,246 +0,0 @@
|
||||
---
|
||||
id: AGD-0010
|
||||
ticket: studio-code-editor-workspace-foundations
|
||||
title: Iniciar foundations do Code Editor no Studio sem LSP
|
||||
status: open
|
||||
created: 2026-03-30
|
||||
resolved: 2026-03-30
|
||||
decision: DEC-0008
|
||||
tags:
|
||||
- studio
|
||||
- editor
|
||||
- workspace
|
||||
- multi-frontend
|
||||
- lsp-deferred
|
||||
---
|
||||
|
||||
## Pain
|
||||
|
||||
O shell do Studio ja assume `Code Editor` como parte do baseline workspace set, mas a implementacao atual do `EditorWorkspace` ainda e apenas um `CodeArea` com texto hardcoded e botoes sem modelo real de documento, tabs, arquivos, modo read-only organizado ou sessao de projeto.
|
||||
|
||||
Ao mesmo tempo, queremos iniciar os trabalhos do editor agora, com foco em UI e infraestrutura robusta para varios frontends, mas sem cair em uma dependencia prematura de LSP e sem fechar a porta para ele como provedor semantico futuro.
|
||||
|
||||
Sem fechar a boundary agora, a implementacao pode desviar para tres extremos ruins:
|
||||
|
||||
- o Studio virar uma casca quase vazia que depende de cada frontend ate para abrir, salvar e manter buffers;
|
||||
- ou o Studio absorver semantica demais e virar uma segunda autoridade sobre parsing, diagnosticos e modelo de compilacao.
|
||||
- ou a primeira wave endurecer a arquitetura em torno de uma implementacao local que depois conflita com a integracao de LSP.
|
||||
|
||||
## Context
|
||||
|
||||
Domain owner: `studio`
|
||||
Owner surface: `docs/specs/studio`
|
||||
Cross-domain input: `compiler`
|
||||
|
||||
Superficies relevantes hoje:
|
||||
|
||||
- `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md` ja define `Code Editor` como workspace baseline do shell;
|
||||
- `docs/specs/studio/2. Studio UI Foundations Specification.md` exige workspaces com composicao root, event bus tipado, lifecycle-managed controls e infra reutilizavel;
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java` hoje monta um `CodeArea` simples sem modelo de arquivos do projeto;
|
||||
- `prometeu-studio/src/main/java/p/studio/projects/ProjectLanguageCatalogService.java` ja consome `FrontendRegistryService` e `FrontendSpec`, o que mostra que o Studio ja reconhece multiplos frontends e source roots por linguagem;
|
||||
- `prometeu-compiler/.../FrontendSpec.java` ja modela `languageId`, `allowedExtensions`, `sourceRoots`, `caseSensitive` e versoes de stdlib;
|
||||
- `DSC-0011` acabou de fechar que o compiler possui entrypoints canonicos `analyze`, `compile` e `build`, com `analyze` como superficie sem write side effects e `AnalysisSnapshot` como contrato minimo de resultado;
|
||||
- `docs/roadmaps/lsp/` ja existe como trilha separada, mas esta wave quer editor sem depender de LSP;
|
||||
- o precedente do packer fixa uma boa disciplina de ownership, mas ele nao deve ser copiado mecanicamente para o editor sem discutir a diferenca entre semantica de dominio e sessao generica de edicao.
|
||||
|
||||
O ponto mais sensivel desta agenda e justamente essa diferenca:
|
||||
|
||||
- no packer, Studio nao deve reinventar semantica de asset, snapshots operacionais ou write lanes de dominio;
|
||||
- no editor, leitura de arquivos fonte, buffers em memoria para arquivos abertos e snapshots documentais/estruturais fazem parte da propria experiencia do workspace e nao sao, por si so, semantica de linguagem.
|
||||
|
||||
Direcao adicional ja explicitada para a UX:
|
||||
|
||||
- o editor deve seguir um baseline proximo ao modelo do IntelliJ;
|
||||
- a ala esquerda deve ser uma stack vertical com `Project Navigator` funcional no topo e uma regiao de `Outline` ja delimitada abaixo, ainda apenas como placeholder estrutural nesta wave;
|
||||
- o `Project Navigator` deve mostrar todos os arquivos e diretorios do projeto, com tagging visual dos source roots relevantes para o frontend selecionado em `prometeu.json`;
|
||||
- o `Project Navigator` deve ordenar pastas antes de arquivos, em ordem alfabetica, sem filtros sofisticados nesta wave, incluindo arquivos ocultos por padrao;
|
||||
- a area central deve ter tabs de arquivos abertos no topo e o editor rico no corpo principal;
|
||||
- a regiao inferior deve ser um helper persistente apenas para demarcar espaco nesta wave, funcionando como placeholder passivo;
|
||||
- a primeira wave tambem pode incluir um `status bar` passivo: breadcrumb do arquivo ativo na esquerda e, na direita, `L:C`, line separator, modo de tabs/espacos, extensao/linguagem e um cadeado de `read-only` apenas visual, sem efeito funcional ainda; `L:C` pode nascer como placeholder visual nesta wave.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- [x] O primeiro wave do editor deve nascer com tabs multiplas e sessao multi-documento completa, ou tabs multiplas com uma politica mais simples de documentos ativos/carregados?
|
||||
Fechamento: todo arquivo ainda nao aberto deve abrir em nova tab; a primeira wave tera uma faixa de tabs responsiva, mostrando quantas tabs couberem na largura disponivel e mandando o restante para um controle de overflow no estilo IntelliJ; a tab ativa deve permanecer visivel; comportamento mais rico pode ser adicionado depois.
|
||||
- [x] Como o `EditorWorkspace` descobre quais arquivos e source roots sao editaveis a partir de `ProjectReference.languageId` e `FrontendSpec`?
|
||||
Fechamento: o editor pode abrir todos os arquivos do projeto; `prometeu.json` define o frontend selecionado e serve para taggear corretamente os source roots/diretorios fonte no `Project Navigator`; a wave continua read-only.
|
||||
- [x] Quem detecta modificacoes externas em arquivos abertos e como o conflito entre disco e buffer em memoria deve aparecer para o usuario?
|
||||
Fechamento: o projeto recebe um refresh inicial ao abrir e aceita refresh manual a qualquer momento por um botao proprio no `Project Navigator`; como a wave e read-only, nao existe resolucao de merge local ainda.
|
||||
- [x] Alem do baseline ja aceito (`Project Navigator`, tabs, editor central, helper inferior), a primeira wave tambem deve incluir `outline` ou `status bar`, ou esses elementos ficam explicitamente para depois?
|
||||
Fechamento: `status bar` entra nesta wave; `outline` fica fora como componente funcional, mas sua regiao ja deve ficar delimitada visualmente abaixo do `Project Navigator` como placeholder estrutural.
|
||||
- [x] Qual e o modelo de eventos editoriais minimo desta wave: arquivo aberto/fechado, troca de tab ativa, dirty state, save, reload externo, erro de IO e mudanca de selecao no navigator?
|
||||
Fechamento: esta agenda nao vai fechar um contrato formal de eventos agora; se necessario, deixar apenas comentarios de implementacao, nao requisitos normativos.
|
||||
- [x] O que fica explicitamente fora desta wave por ausencia de LSP: autocomplete, go to definition, semantic diagnostics ao digitar, symbols, rename, code actions?
|
||||
Fechamento: esta wave nao lida com codigo em si, apenas com gerenciamento de arquivos, abertura de tabs e composicao editorial do workspace.
|
||||
|
||||
## Options
|
||||
|
||||
### Option A - Studio como casca pura; frontend/backends fazem o resto
|
||||
- **Approach:** O Studio hospeda a area visual do editor, mas leitura, escrita, buffers, snapshots e demais operacoes relevantes ficam delegadas a adaptadores por linguagem ou a servicos externos.
|
||||
- **Pro:** Mantem o Studio "leve" e minimiza responsabilidade local.
|
||||
- **Con:** Duplica infraestrutura generica em cada frontend, acopla UX basica a backend de linguagem e torna dificil sustentar uma experiencia coerente multi-FE sem LSP.
|
||||
- **Maintainability:** Fraca. A boundary fica formalmente limpa, mas o custo reaparece como fragmentacao de sessao, inconsistencias de UX e adaptadores repetidos.
|
||||
|
||||
### Option B - Studio possui sessao generica de documentos; semantica vem depois por integracao
|
||||
- **Approach:** O Studio passa a possuir uma camada generica de editor para descoberta de arquivos, leitura, tabs, estado ativo, refresh manual, snapshot estrutural da arvore e gerenciamento dos documentos abertos em memoria em modo read-only; provedores semanticos futuros, incluindo LSP, consomem essa base depois por uma seam explicita.
|
||||
- **Pro:** Cria uma base robusta para varios frontends mesmo sem LSP, evita duplicacao de infra generica e mantem a semantica de linguagem fora do workspace visual.
|
||||
- **Con:** Exige disciplina para nao confundir `snapshot documental` com resultado semantico e para nao deixar a camada generica vazar regras de linguagem ou hardcodes anti-LSP.
|
||||
- **Maintainability:** Forte. A separacao entre sessao de edicao e semantica de linguagem fica clara e expansivel.
|
||||
|
||||
### Option C - Cada frontend possui seu proprio stack de editor end-to-end
|
||||
- **Approach:** O Studio oferece apenas um host de workspace, e cada frontend implementa seu proprio editor, file model, snapshots e event wiring do zero.
|
||||
- **Pro:** Maxima liberdade por linguagem.
|
||||
- **Con:** Destrói a chance de um framework comum de editor, duplica problema de tabs/buffers/save/conflicts e torna a shell dependente de N mini-produtos locais.
|
||||
- **Maintainability:** Fraca. Funciona para prototipos isolados, mas nao para um Studio que quer suportar varios FEs sob uma UX comum.
|
||||
|
||||
### Option D - Esperar LSP e desenhar o editor em torno dele
|
||||
- **Approach:** Adiar a infra editorial mais seria ate que exista um backend LSP suficientemente funcional e modelar o editor a partir desse contrato.
|
||||
- **Pro:** Pode reduzir retrabalho se o LSP for a unica fronteira desejada.
|
||||
- **Con:** Conflita com o objetivo desta wave, atrasa o editor, e ainda nao resolve ownership de file IO, buffers e dirty state, que continuam existindo mesmo com LSP.
|
||||
- **Maintainability:** Media para baixa. O LSP ajuda na semantica, mas nao substitui a sessao generica de edicao.
|
||||
|
||||
## Discussion
|
||||
|
||||
O precedente do packer e util, mas ele nao responde sozinho a pergunta desta agenda.
|
||||
|
||||
No packer, a semantica de dominio e forte:
|
||||
|
||||
- identidade de asset;
|
||||
- validacao;
|
||||
- write lane;
|
||||
- snapshots operacionais;
|
||||
- causality de eventos.
|
||||
|
||||
Nessa area, faz sentido Studio atuar mais como adaptador editorial do que como autoridade.
|
||||
|
||||
No editor de codigo, porem, existe uma camada anterior a qualquer semantica de linguagem:
|
||||
|
||||
- abrir arquivo;
|
||||
- manter buffer em memoria;
|
||||
- alternar tabs;
|
||||
- versionar snapshots documentais;
|
||||
- reagir a mudancas externas;
|
||||
- expor um modelo de sessao que qualquer FE consiga consumir.
|
||||
|
||||
Essas responsabilidades nao sao "semantica de compiler". Sao responsabilidades normais de um editor.
|
||||
Se o Studio se recusar a possui-las, cada frontend ou integracao futura precisara reinventar a mesma infraestrutura.
|
||||
|
||||
Do ponto de vista de UX, a direcao mais solida e assumir um baseline de tres regioes dentro do `EditorWorkspace`:
|
||||
|
||||
1. `Project Navigator` na esquerda
|
||||
2. `Editor Workarea` no centro, com tabs acima e editor no corpo
|
||||
3. `Editor Helper Panel` na base, para tips, prompts, hints e feedback contextual
|
||||
|
||||
Dentro da coluna esquerda, o layout ja deve nascer preparado para a composicao futura:
|
||||
|
||||
1. `Project Navigator` funcional no topo;
|
||||
2. regiao de `Outline` reservada abaixo;
|
||||
3. `Outline` ainda sem comportamento real, sem arvore fake e sem semantica local nesta wave.
|
||||
|
||||
Esse painel inferior ainda nao precisa nascer com funcao real.
|
||||
Nesta wave ele existe apenas para demarcar o espaco futuro da composicao, como placeholder passivo.
|
||||
|
||||
O boundary mais saudavel parece ser:
|
||||
|
||||
1. o Studio possui a sessao generica de documentos e a UX editorial comum;
|
||||
2. essa sessao cobre organizacao de componentes, buffers abertos em memoria, tabs, refresh/reload e o minimo necessario para gerenciamento editorial read-only dos arquivos;
|
||||
3. parsing, name resolution, diagnostics, semantic tokens, completions e afins continuam fora da camada generica do editor;
|
||||
4. LSP, quando existir, entra como um provedor de semantica sobre essa base, nao como substituto da base e nao como dependencia obrigatoria desta wave.
|
||||
|
||||
O estado atual do compiler ajuda a nao exagerar o escopo desta agenda.
|
||||
`DSC-0011` fechou o pipeline canonico e os entrypoints publicos do compiler.
|
||||
Isso e suficiente, por enquanto, para esta agenda assumir apenas que o editor nao deve bloquear integracoes semanticas futuras.
|
||||
Esta discussion nao precisa decidir agora o contrato final entre `document snapshots` e `analyze`, nem substituir LSP por uma semantica local improvisada no Studio.
|
||||
|
||||
Isso tambem ajuda com a meta de varios FEs:
|
||||
|
||||
- `FrontendSpec` ja informa roots e extensoes;
|
||||
- o `EditorWorkspace` pode montar a superficie a partir disso;
|
||||
- e cada linguagem ou integracao futura fica livre para plugar semantica sem destruir o modelo editorial comum.
|
||||
|
||||
Com isso, o foco desta agenda fica mais limpo:
|
||||
|
||||
1. composicao visual do workspace editor;
|
||||
2. gerenciamento de arquivos abertos em memoria;
|
||||
3. modelo de tabs e documento ativo;
|
||||
4. refresh em modo read-only;
|
||||
5. `Project Navigator` completo sobre o projeto com tagging de source roots relevantes;
|
||||
6. `status bar` passivo com informacoes editoriais basicas;
|
||||
7. reserva de seams para providers semanticos futuros, sem acoplamento prematuro.
|
||||
|
||||
Tabs precisam nascer de forma pragmatica nesta wave.
|
||||
O objetivo nao e fechar ainda persistencia de sessao, drag-and-drop, pinning, grupos, split view ou navegacao avancada.
|
||||
O que fica fechado e o baseline visual e operacional:
|
||||
|
||||
1. arquivos ainda nao abertos entram em nova tab;
|
||||
2. a faixa de tabs deve ser responsiva e mostrar quantas tabs couberem na largura disponivel;
|
||||
3. tabs adicionais devem ficar acessiveis por um controle de overflow estilo IntelliJ;
|
||||
4. a tab ativa deve permanecer visivel;
|
||||
5. o rotulo da tab usa apenas o nome do arquivo com extensao;
|
||||
6. comportamento mais rico pode ser adicionado depois sem mudar o contrato visual inicial.
|
||||
|
||||
O `Project Navigator` tambem fica mais claro:
|
||||
|
||||
1. ele nao deve limitar a edicao apenas aos arquivos fonte tagged;
|
||||
2. ele deve mostrar todos os arquivos e diretorios do projeto;
|
||||
3. `prometeu.json` e o frontend selecionado servem para destacar roots relevantes, nao para esconder o restante do projeto.
|
||||
4. ele deve manter um snapshot estrutural em memoria da arvore do projeto para navegacao e estado visual;
|
||||
5. esse snapshot estrutural nao substitui o filesystem como source of truth;
|
||||
6. snapshots de conteudo continuam restritos aos arquivos abertos no editor;
|
||||
7. a arvore faz um refresh inicial ao abrir o projeto e permite refresh manual a qualquer momento por um botao proprio;
|
||||
8. arquivos ocultos entram por padrao;
|
||||
9. arquivos nao-textuais ou nao suportados podem aparecer no navigator, mas devem abrir um modal simples avisando que o arquivo nao e suportado nesta wave.
|
||||
|
||||
A regiao de `Outline` deve entrar apenas como reserva estrutural.
|
||||
Ela ajuda a estabilizar a composicao da coluna esquerda agora, sem puxar semantica prematura para dentro desta agenda.
|
||||
Se houver texto placeholder, ele deve ser discreto e claramente nao funcional.
|
||||
|
||||
O `status bar` entra como componente editorial passivo nesta primeira wave.
|
||||
Na esquerda ele mostra o breadcrumb do arquivo ativo, por exemplo `proj > src > file.pbs`.
|
||||
Na direita ele mostra:
|
||||
|
||||
1. posicao atual em `L:C`;
|
||||
2. line separator;
|
||||
3. modo de tabs/espacos, por exemplo `Spaces: 2` ou `Spaces: 4`;
|
||||
4. extensao ou linguagem do arquivo ativo;
|
||||
5. um cadeado de `read-only` apenas visual, reservado para funcionalidade futura do editor, sem efeito nesta wave.
|
||||
|
||||
Como a primeira wave e read-only, ela nao fecha agora dirty tracking, save ou merge entre buffer local e disco.
|
||||
O comportamento minimo fica reduzido a:
|
||||
|
||||
1. abrir arquivos em memoria para leitura;
|
||||
2. atualizar a visao a partir de refresh manual e refresh inicial;
|
||||
3. deixar escrita, dirty state e resolucao de conflitos para wave posterior.
|
||||
|
||||
Tambem nao vale persistir estado de sessao agora.
|
||||
Expansao da arvore, tabs abertas e qualquer outro estado visual vivem apenas na sessao atual; persistencia entre execucoes fica para depois.
|
||||
|
||||
Nao vale a pena transformar esta agenda em contrato detalhado de eventos agora.
|
||||
Se algum evento precisar aparecer durante implementacao, ele deve entrar apenas como comentario/local detail e nao como fechamento normativo desta discussion.
|
||||
|
||||
## Resolution
|
||||
|
||||
Recommended direction: seguir com **Option B**.
|
||||
|
||||
A agenda deve convergir para uma decisao com os seguintes fechamentos:
|
||||
|
||||
1. o Studio deve possuir uma camada generica de `document/session` para o Code Editor;
|
||||
2. essa camada deve operar em modo read-only nesta primeira wave, podendo abrir arquivos fonte e manter snapshots documentais em memoria apenas para leitura;
|
||||
3. essa camada deve ser responsavel por organizacao de componentes, tabs, buffers abertos, refresh/reload e snapshot estrutural do projeto, sem dirty tracking, save ou merge local nesta wave;
|
||||
4. essa camada nao deve possuir semantica de linguagem, parsing autoritativo, diagnosticos ou ownership de comportamento tipico de LSP;
|
||||
5. a primeira wave deve reservar um seam explicito para provedores semanticos futuros, incluindo LSP, sem torna-los dependencia imediata e sem endurecer o editor contra eles;
|
||||
6. a primeira wave do editor deve normatizar explicitamente o baseline visual do workspace: `Project Navigator` na esquerda, tabs no topo da area central, editor rico no corpo, `Editor Helper Panel` inferior reservado e `status bar` passivo;
|
||||
7. a coluna esquerda deve reservar uma regiao de `Outline` abaixo do `Project Navigator`, mas sem comportamento funcional nesta wave;
|
||||
8. o `Project Navigator` deve mostrar todos os arquivos e diretorios do projeto, incluindo arquivos ocultos por padrao, ordenando pastas antes de arquivos em ordem alfabetica e usando `prometeu.json` apenas para taggear corretamente roots/fontes relevantes ao frontend selecionado;
|
||||
9. o `Project Navigator` deve manter um snapshot estrutural em memoria da arvore do projeto para navegacao e estado visual, sem substituir o filesystem como source of truth;
|
||||
10. a arvore do projeto deve fazer refresh inicial ao abrir o projeto e permitir refresh manual a qualquer momento por um botao proprio no `Project Navigator`;
|
||||
11. snapshots de conteudo em memoria ficam restritos aos arquivos abertos no editor;
|
||||
12. arquivos nao-textuais ou nao suportados podem aparecer no navigator, mas devem abrir um modal simples avisando que o arquivo nao e suportado nesta wave;
|
||||
13. a primeira wave de tabs deve abrir todo arquivo novo em nova tab, usar uma faixa responsiva com overflow no estilo IntelliJ, manter a tab ativa visivel e usar apenas o nome do arquivo com extensao como rotulo da tab;
|
||||
14. o `status bar` deve mostrar breadcrumb do arquivo ativo na esquerda e, na direita, `L:C`, line separator, modo de tabs/espacos, extensao/linguagem e um cadeado visual de `read-only` sem efeito funcional ainda; `L:C` pode nascer como placeholder visual nesta wave;
|
||||
15. o `Editor Helper Panel` nasce passivo na primeira wave apenas para demarcar espaco, sem funcao real ainda;
|
||||
16. expansao da arvore, tabs abertas e demais estados visuais vivem apenas na sessao atual; persistencia entre execucoes fica para depois;
|
||||
17. ficam explicitamente fora desta wave escrita, save, dirty tracking, merge de conflitos, autocomplete, go to definition, semantic diagnostics ao digitar, symbols, rename, code actions e qualquer decisao detalhada de integracao com LSP;
|
||||
18. esta agenda nao fecha agora um contrato normativo de eventos editoriais; qualquer necessidade imediata pode aparecer apenas como detalhe de implementacao ou comentario.
|
||||
|
||||
Next step suggestion: converter esta agenda em uma `decision` que feche o escopo da primeira wave read-only do `EditorWorkspace`, incluindo composicao visual, tabs, `Project Navigator`, `status bar`, snapshot estrutural da arvore, buffers abertos em memoria e o que fica explicitamente fora da wave por ausencia de escrita/semantica/LSP.
|
||||
@ -1,216 +0,0 @@
|
||||
---
|
||||
id: DEC-0008
|
||||
ticket: studio-code-editor-workspace-foundations
|
||||
title: Read-only foundations for the Studio Code Editor workspace
|
||||
status: accepted
|
||||
created: 2026-03-30
|
||||
accepted: 2026-03-30
|
||||
agenda: AGD-0010
|
||||
plans:
|
||||
- PLN-0012
|
||||
- PLN-0013
|
||||
- PLN-0014
|
||||
tags:
|
||||
- studio
|
||||
- editor
|
||||
- workspace
|
||||
- read-only
|
||||
- lsp-deferred
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
The Studio shell already treats `Code Editor` as part of the baseline workspace set, but the current `EditorWorkspace` is still only a hardcoded text area.
|
||||
|
||||
AGD-0010 closed the scope of the first editor wave around structural workspace foundations only.
|
||||
This decision does not close language semantics, compiler integration details, or LSP behavior.
|
||||
Its job is to define the first stable Studio-owned editor shell that can host real project navigation and file opening without prematurely absorbing semantic ownership.
|
||||
|
||||
This decision depends on the current Studio shell and UI foundations:
|
||||
|
||||
1. `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`
|
||||
2. `docs/specs/studio/2. Studio UI Foundations Specification.md`
|
||||
|
||||
It is also compatible with DEC-0007/DSC-0011, which keeps compiler semantics behind explicit entrypoints and therefore does not force this editor wave to own semantic behavior now.
|
||||
|
||||
## Decision
|
||||
|
||||
The `studio` domain SHALL implement the first `Code Editor` workspace wave as a read-only editorial foundation.
|
||||
|
||||
This wave SHALL establish:
|
||||
|
||||
1. the baseline visual composition of the editor workspace,
|
||||
2. project-tree navigation over the full project,
|
||||
3. opening project files into responsive tabs,
|
||||
4. in-memory buffers for opened files in read-only mode,
|
||||
5. passive placeholder regions for future `Outline` and helper surfaces,
|
||||
6. a passive status bar with baseline editor metadata,
|
||||
7. and a future-safe seam for semantic providers such as LSP without making them a dependency of this wave.
|
||||
|
||||
This wave SHALL NOT implement:
|
||||
|
||||
1. file saving or other write behavior,
|
||||
2. dirty tracking,
|
||||
3. local merge/conflict resolution,
|
||||
4. semantic diagnostics, autocomplete, go-to-definition, symbols, rename, code actions, or other LSP-like features,
|
||||
5. an active `Outline`,
|
||||
6. a functional helper panel,
|
||||
7. or persistence of editor session state across Studio executions.
|
||||
|
||||
## Rationale
|
||||
|
||||
The correct ownership boundary for this wave is editorial, not semantic.
|
||||
Studio should own the common workspace composition, project navigation, tabs, and passive file presentation layer.
|
||||
It should not, in this wave, become the authority for parsing, diagnostics, or language behavior.
|
||||
|
||||
This decision also intentionally keeps the first implementation smaller and more stable:
|
||||
|
||||
1. read-only mode avoids premature decisions about saving, dirty state, and merge behavior,
|
||||
2. structural placeholders avoid future layout churn when `Outline`, helper features, and semantic integrations arrive,
|
||||
3. and a full-project navigator avoids hiding relevant project files behind frontend-only views while still allowing frontend-aware tagging from `prometeu.json`.
|
||||
|
||||
## Technical Specification
|
||||
|
||||
### 1. Workspace Layout
|
||||
|
||||
The `Code Editor` workspace MUST expose the following baseline layout:
|
||||
|
||||
1. a left column,
|
||||
2. a central editor work area,
|
||||
3. a bottom helper region,
|
||||
4. and a bottom status bar.
|
||||
|
||||
The left column MUST be a vertical stack containing:
|
||||
|
||||
1. a functional `Project Navigator` at the top,
|
||||
2. and a reserved `Outline` region below it.
|
||||
|
||||
The `Outline` region MUST exist structurally in this wave, but MUST NOT provide real outline behavior yet.
|
||||
It MAY show a discreet placeholder state, but it MUST NOT fake semantic structure.
|
||||
|
||||
The bottom helper region MUST exist structurally in this wave, but MUST remain passive.
|
||||
It exists only to stabilize layout and reserve space for future contextual/editor-owned assistance.
|
||||
|
||||
### 2. Project Navigator
|
||||
|
||||
The `Project Navigator` MUST:
|
||||
|
||||
1. show all files and directories in the project,
|
||||
2. include hidden files by default,
|
||||
3. order folders before files,
|
||||
4. order items alphabetically within those groups,
|
||||
5. and use `prometeu.json` plus the selected frontend only to tag relevant source roots or source directories.
|
||||
|
||||
The `Project Navigator` MUST NOT hide non-source project files simply because they are not part of the selected frontend roots.
|
||||
|
||||
The `Project Navigator` MUST maintain an in-memory structural snapshot of the project tree for navigation and visual state.
|
||||
That structural snapshot MUST NOT replace the filesystem as the source of truth.
|
||||
|
||||
Refresh rules for this wave are:
|
||||
|
||||
1. the tree MUST perform one initial refresh when the project opens,
|
||||
2. the tree MUST allow manual refresh at any time,
|
||||
3. the manual refresh control MUST be exposed directly on the `Project Navigator`,
|
||||
4. and filesystem watching MUST NOT be baseline behavior in this wave.
|
||||
|
||||
### 3. File Opening and Tabs
|
||||
|
||||
The workspace MUST allow project files to be opened into editor tabs.
|
||||
|
||||
Tab rules are:
|
||||
|
||||
1. selecting a file that is not already open MUST open it in a new tab,
|
||||
2. the tab strip MUST be responsive,
|
||||
3. the visible tab count MUST be driven by available width rather than a fixed numeric limit,
|
||||
4. overflow tabs MUST remain reachable through an IntelliJ-style overflow control,
|
||||
5. the active tab MUST remain visible,
|
||||
6. and the tab label MUST use only the file name with extension.
|
||||
|
||||
This wave MUST NOT define pinning, drag-and-drop tab reordering, grouped tabs, split editors, or session-persistent tab restoration.
|
||||
|
||||
### 4. Read-only File Model
|
||||
|
||||
This wave MUST operate in read-only mode.
|
||||
|
||||
Opened files MAY be loaded into in-memory buffers for display and navigation, but those buffers MUST remain read-only in this wave.
|
||||
|
||||
Consequences:
|
||||
|
||||
1. the editor MUST NOT write files,
|
||||
2. the editor MUST NOT provide save behavior,
|
||||
3. the editor MUST NOT define dirty tracking,
|
||||
4. and the editor MUST NOT define local merge behavior against disk changes.
|
||||
|
||||
Unsupported or non-text files MAY still appear in the `Project Navigator`, but attempting to open them MUST show a simple modal stating that the file is not supported in this wave.
|
||||
|
||||
### 5. Status Bar
|
||||
|
||||
The workspace MUST include a passive status bar.
|
||||
|
||||
Its left side MUST show the breadcrumb path of the active file, such as `proj > src > file.pbs`.
|
||||
|
||||
Its right side MUST show:
|
||||
|
||||
1. `L:C`,
|
||||
2. line separator,
|
||||
3. tabs/spaces mode,
|
||||
4. file extension or language,
|
||||
5. and a read-only lock icon.
|
||||
|
||||
For this wave:
|
||||
|
||||
1. `L:C` MAY remain a visual placeholder,
|
||||
2. and the lock icon MUST be visual only, with no functional enforcement beyond signaling read-only intent.
|
||||
|
||||
### 6. Placeholder Surfaces
|
||||
|
||||
The `Outline` region and the helper region MUST remain passive in this wave.
|
||||
|
||||
Rules:
|
||||
|
||||
1. they exist to stabilize composition and reserve future workspace surfaces,
|
||||
2. they MUST NOT claim semantic capabilities they do not yet have,
|
||||
3. and they MUST NOT become dumping grounds for global shell logging.
|
||||
|
||||
### 7. Session State
|
||||
|
||||
Any visual/editorial state in this wave is session-local only.
|
||||
|
||||
This includes at minimum:
|
||||
|
||||
1. open tabs,
|
||||
2. active tab selection,
|
||||
3. tree expansion state,
|
||||
4. and similar visual workspace state.
|
||||
|
||||
This decision MUST NOT require persistence of that state across Studio executions.
|
||||
|
||||
### 8. Deferred Scope
|
||||
|
||||
The following are explicitly deferred and MUST NOT be treated as part of this wave:
|
||||
|
||||
1. write/save behavior,
|
||||
2. dirty state,
|
||||
3. merge/conflict resolution,
|
||||
4. watcher-driven automatic filesystem synchronization,
|
||||
5. semantic analysis surfaces,
|
||||
6. LSP integration details,
|
||||
7. autocomplete, go-to-definition, symbols, rename, code actions, and semantic diagnostics while typing,
|
||||
8. active outline behavior,
|
||||
9. helper panel functionality,
|
||||
10. and a normative editor event contract.
|
||||
|
||||
If implementation needs local events internally, they MAY exist as implementation detail, but they MUST NOT be treated as the normative output of this decision.
|
||||
|
||||
## Constraints
|
||||
|
||||
1. This decision is Studio-owned and applies to the `studio` domain, not to compiler semantic ownership.
|
||||
2. This decision MUST remain compatible with future semantic providers, including LSP.
|
||||
3. This decision MUST NOT infer or hardcode a semantic provider contract prematurely.
|
||||
4. This decision MUST preserve compatibility with existing Studio shell and UI foundations specs.
|
||||
5. Any future move from read-only mode to editable mode MUST occur through a new explicit decision or an explicit revision of this decision.
|
||||
|
||||
## Revision Log
|
||||
|
||||
- 2026-03-30: Initial draft from AGD-0010.
|
||||
- 2026-03-30: Accepted and decomposed into PLN-0012, PLN-0013, and PLN-0014.
|
||||
@ -1,130 +0,0 @@
|
||||
---
|
||||
id: PLN-0012
|
||||
ticket: studio-code-editor-workspace-foundations
|
||||
title: Propagate DEC-0008 into Studio shell and workspace specs
|
||||
status: done
|
||||
created: 2026-03-30
|
||||
completed: 2026-03-30
|
||||
tags:
|
||||
- studio
|
||||
- editor
|
||||
- specs
|
||||
- read-only
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
Propagate DEC-0008 into the normative Studio spec surface so the read-only first wave of the `Code Editor` workspace is explicit before or alongside implementation.
|
||||
|
||||
## Background
|
||||
|
||||
DEC-0008 locks the first `Code Editor` wave as a read-only editorial foundation with:
|
||||
|
||||
- `Project Navigator` over the full project,
|
||||
- reserved `Outline` region,
|
||||
- responsive tab strip with overflow,
|
||||
- read-only file opening,
|
||||
- passive helper region,
|
||||
- passive status bar,
|
||||
- manual refresh only,
|
||||
- and explicit deferral of save/dirty/LSP/semantic behavior.
|
||||
|
||||
The current Studio spec corpus defines shell-level workspace presence and shared UI foundations, but it does not yet define the concrete contract of the `Code Editor` workspace itself.
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- Add a dedicated `Code Editor` workspace specification to the Studio spec corpus.
|
||||
- Update Studio spec navigation so the new chapter is discoverable.
|
||||
- Align shell/foundations references so DEC-0008 terminology is consistent with existing Studio norms.
|
||||
|
||||
### Excluded
|
||||
- Java implementation changes in `prometeu-studio`.
|
||||
- LSP or semantic-provider contract design.
|
||||
- Editable-mode design, save behavior, or conflict-resolution policy.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1 - Add a dedicated Code Editor workspace specification
|
||||
|
||||
**What:**
|
||||
Create a new Studio spec chapter that normatively defines the read-only `Code Editor` workspace baseline from DEC-0008.
|
||||
|
||||
**How:**
|
||||
Add a new chapter under `docs/specs/studio/` covering:
|
||||
1. workspace layout,
|
||||
2. `Project Navigator` ownership and full-project visibility,
|
||||
3. reserved `Outline` region,
|
||||
4. responsive tabs with overflow,
|
||||
5. read-only file opening,
|
||||
6. unsupported-file modal behavior,
|
||||
7. passive helper region,
|
||||
8. passive status bar fields,
|
||||
9. manual refresh,
|
||||
10. and deferred scope for save/LSP/semantic features.
|
||||
|
||||
**File(s):**
|
||||
- `docs/specs/studio/5. Code Editor Workspace Specification.md`
|
||||
|
||||
### Step 2 - Update Studio spec navigation and cross-references
|
||||
|
||||
**What:**
|
||||
Make the new spec reachable from the Studio spec index and aligned with the current corpus order.
|
||||
|
||||
**How:**
|
||||
Update the Studio README reading order and current-corpus list to include the new chapter.
|
||||
Add or adjust cross-references where shell/foundations specs should point to workspace-local ownership rather than implying global responsibility.
|
||||
|
||||
**File(s):**
|
||||
- `docs/specs/studio/README.md`
|
||||
- `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`
|
||||
- `docs/specs/studio/2. Studio UI Foundations Specification.md`
|
||||
|
||||
### Step 3 - Align terminology and deferred-scope language
|
||||
|
||||
**What:**
|
||||
Ensure the spec corpus consistently uses DEC-0008 language for the first editor wave.
|
||||
|
||||
**How:**
|
||||
Normalize references to:
|
||||
1. read-only first wave,
|
||||
2. passive helper and `Outline` placeholder,
|
||||
3. manual refresh,
|
||||
4. and explicit deferral of semantic/LSP features and save/write behavior.
|
||||
|
||||
**File(s):**
|
||||
- `docs/specs/studio/5. Code Editor Workspace Specification.md`
|
||||
- `docs/specs/studio/1. Studio Shell and Workspace Layout Specification.md`
|
||||
- `docs/specs/studio/2. Studio UI Foundations Specification.md`
|
||||
|
||||
## Test Requirements
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- No Java unit tests are required for this editorial plan.
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- No runtime integration tests are required for this editorial plan.
|
||||
|
||||
### Manual Verification
|
||||
|
||||
- Verify the new spec chapter is listed in `docs/specs/studio/README.md`.
|
||||
- Verify the new chapter matches DEC-0008 exactly on read-only scope, manual refresh, and deferred LSP/save behavior.
|
||||
- Verify shell/foundations wording does not contradict workspace-local ownership defined by the new chapter.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] The Studio spec corpus contains a dedicated `Code Editor` workspace specification.
|
||||
- [ ] The spec explicitly states that the first wave is read-only and excludes save/dirty/LSP/semantic behavior.
|
||||
- [ ] The spec defines the baseline layout: navigator, reserved outline region, responsive tabs, editor body, passive helper, passive status bar.
|
||||
- [ ] Studio spec navigation and cross-references are updated to make the new chapter discoverable and consistent.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- DEC-0008 accepted content.
|
||||
|
||||
## Risks
|
||||
|
||||
- A too-light writeup could leave implementation inventing behavior that DEC-0008 already closed.
|
||||
- Over-editing shell/foundations docs could blur shell-owned versus workspace-owned responsibilities.
|
||||
@ -1,123 +0,0 @@
|
||||
---
|
||||
id: PLN-0013
|
||||
ticket: studio-code-editor-workspace-foundations
|
||||
title: Implement the read-only Code Editor workspace shell and passive surfaces
|
||||
status: done
|
||||
created: 2026-03-30
|
||||
completed: 2026-03-30
|
||||
tags:
|
||||
- studio
|
||||
- editor
|
||||
- implementation
|
||||
- layout
|
||||
- ui
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
Replace the current hardcoded `EditorWorkspace` with the DEC-0008 read-only workspace shell: left navigator column with reserved `Outline` region, central tab/editor area, passive helper region, and passive status bar.
|
||||
|
||||
## Background
|
||||
|
||||
The current `EditorWorkspace` is only a `CodeArea` mounted under a toolbar.
|
||||
DEC-0008 requires a stable read-only composition that reserves future surfaces without implementing semantic or writable behavior yet.
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- Recompose `EditorWorkspace` into the DEC-0008 structural layout.
|
||||
- Introduce passive placeholder surfaces for `Outline`, helper, and status bar.
|
||||
- Replace write-oriented/editorially misleading controls with a first-wave read-only shell.
|
||||
- Keep the central editor body ready to host read-only opened file content.
|
||||
|
||||
### Excluded
|
||||
- Project-tree scanning and refresh logic.
|
||||
- Actual file opening/session state orchestration beyond the minimum shell integration points.
|
||||
- Save, dirty tracking, write controls, or semantic/LSP behavior.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1 - Replace the current EditorWorkspace composition root
|
||||
|
||||
**What:**
|
||||
Turn `EditorWorkspace` into a composition root that mounts the DEC-0008 layout instead of a single hardcoded `CodeArea`.
|
||||
|
||||
**How:**
|
||||
Refactor the current border-pane structure into explicit regions:
|
||||
1. left column for navigator + reserved outline region,
|
||||
2. central work area for tab strip + read-only editor body,
|
||||
3. bottom helper placeholder,
|
||||
4. bottom status bar.
|
||||
Prefer dedicated controls/panels over one large monolithic workspace class.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
|
||||
### Step 2 - Introduce passive placeholder controls
|
||||
|
||||
**What:**
|
||||
Add concrete passive UI surfaces for the reserved regions required by DEC-0008.
|
||||
|
||||
**How:**
|
||||
Create lightweight controls/panels for:
|
||||
1. reserved `Outline` region,
|
||||
2. passive helper region,
|
||||
3. passive status bar,
|
||||
4. and the tab-strip shell.
|
||||
These controls should be visually real, but functionally passive where DEC-0008 says behavior is deferred.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
|
||||
### Step 3 - Align editor chrome with read-only first-wave scope
|
||||
|
||||
**What:**
|
||||
Remove or neutralize UI affordances that imply writable/editor-semantic behavior not present in this wave.
|
||||
|
||||
**How:**
|
||||
Review the current toolbar and shell-level controls so the first-wave editor does not imply:
|
||||
1. save,
|
||||
2. run/build from inside the editor,
|
||||
3. active outline,
|
||||
4. or helper-driven functionality that does not exist yet.
|
||||
If a control must remain for layout reasons, make it visually passive and consistent with DEC-0008.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorToolbar.java`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
|
||||
## Test Requirements
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- Add focused tests for any pure layout/session-state model extracted from the workspace shell composition.
|
||||
- If dedicated status/tab placeholder models are introduced, cover their default state with unit tests.
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- No JavaFX full integration harness is required as a prerequisite for this plan.
|
||||
|
||||
### Manual Verification
|
||||
|
||||
- Verify the workspace visually matches DEC-0008 layout.
|
||||
- Verify the left column contains navigator + reserved outline region.
|
||||
- Verify the helper and status bar are present but passive.
|
||||
- Verify no visible control implies save/write behavior in the first wave.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `EditorWorkspace` is no longer a single hardcoded `CodeArea` view.
|
||||
- [ ] The workspace visibly contains navigator, reserved outline region, central tab/editor area, helper placeholder, and status bar.
|
||||
- [ ] The first-wave shell is visually coherent with DEC-0008 read-only scope.
|
||||
- [ ] Placeholder surfaces are present without implying semantic or writable functionality.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- DEC-0008 accepted.
|
||||
- PLN-0012 should land first or in parallel if the wording is stable.
|
||||
|
||||
## Risks
|
||||
|
||||
- If the composition stays monolithic, later navigator/session work will be harder to integrate cleanly.
|
||||
- Leaving write-oriented controls visible would immediately contradict DEC-0008 and confuse later implementation waves.
|
||||
@ -1,148 +0,0 @@
|
||||
---
|
||||
id: PLN-0014
|
||||
ticket: studio-code-editor-workspace-foundations
|
||||
title: Implement the Project Navigator snapshot and read-only file opening flow
|
||||
status: done
|
||||
created: 2026-03-30
|
||||
completed: 2026-03-30
|
||||
tags:
|
||||
- studio
|
||||
- editor
|
||||
- implementation
|
||||
- navigator
|
||||
- tabs
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
Implement the DEC-0008 operational core of the first `Code Editor` wave: full-project navigator snapshot, manual refresh, opening files into responsive tabs, read-only buffers, and unsupported-file modal behavior.
|
||||
|
||||
## Background
|
||||
|
||||
DEC-0008 requires the editor to operate over the full project, maintain an in-memory structural snapshot for the navigator, tag frontend-relevant roots using `prometeu.json`, and open supported files into read-only tabs without save/dirty/merge behavior.
|
||||
|
||||
The current codebase already includes project services such as `ProjectReference`, `ProjectLanguageCatalogService`, and `ProjectStudioPaths`, but the editor workspace does not yet use them to build a real project tree or manage open files.
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- Build a structural project-tree snapshot model for the navigator.
|
||||
- Add initial and manual refresh behavior.
|
||||
- Open supported files into read-only tabs.
|
||||
- Keep opened-file content in memory for the active session only.
|
||||
- Show a simple modal for unsupported/non-text files.
|
||||
|
||||
### Excluded
|
||||
- Save, dirty tracking, write flows, or merge/conflict resolution.
|
||||
- Watcher-driven automatic refresh.
|
||||
- Semantic/LSP integration.
|
||||
- Cross-session restoration of tabs or tree state.
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1 - Implement the Project Navigator structural snapshot
|
||||
|
||||
**What:**
|
||||
Create a structural project-tree model that covers the full project and the DEC-0008 ordering/tagging rules.
|
||||
|
||||
**How:**
|
||||
Introduce a navigator snapshot service/model that:
|
||||
1. scans all project files and directories, including hidden files,
|
||||
2. orders folders before files and sorts alphabetically,
|
||||
3. derives frontend-relevant tags from `prometeu.json` and the selected frontend,
|
||||
4. and keeps filesystem truth outside the in-memory snapshot itself.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
- `prometeu-studio/src/main/java/p/studio/projects/ProjectLanguageCatalogService.java`
|
||||
- `prometeu-studio/src/main/java/p/studio/projects/ProjectReference.java`
|
||||
- `prometeu-studio/src/main/java/p/studio/projects/ProjectStudioPaths.java`
|
||||
|
||||
### Step 2 - Wire refresh behavior into the navigator shell
|
||||
|
||||
**What:**
|
||||
Support the refresh model closed by DEC-0008.
|
||||
|
||||
**How:**
|
||||
Ensure the navigator:
|
||||
1. performs one initial refresh when the workspace loads,
|
||||
2. exposes a manual refresh button directly on the navigator surface,
|
||||
3. and never assumes watcher-based automatic refresh in this wave.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
|
||||
|
||||
### Step 3 - Implement read-only file opening and tab session state
|
||||
|
||||
**What:**
|
||||
Open supported files into read-only tabs while keeping session state in memory only for the current Studio run.
|
||||
|
||||
**How:**
|
||||
Add editor session models/services that:
|
||||
1. open a new tab when the selected file is not already open,
|
||||
2. keep the active tab visible in the responsive tab strip,
|
||||
3. label tabs with file name plus extension only,
|
||||
4. load supported text file contents into read-only editor buffers,
|
||||
5. and keep tab/tree state session-local only.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/EditorWorkspace.java`
|
||||
|
||||
### Step 4 - Handle unsupported files explicitly
|
||||
|
||||
**What:**
|
||||
Reject unsupported/non-text file opening through the UX rule closed by DEC-0008.
|
||||
|
||||
**How:**
|
||||
When a navigator selection targets an unsupported file type, show a simple modal stating that the file is not supported in this wave instead of trying to fake a preview or partially open it.
|
||||
|
||||
**File(s):**
|
||||
- `prometeu-studio/src/main/java/p/studio/workspaces/editor/`
|
||||
|
||||
## Test Requirements
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- Add unit tests for the structural project-tree snapshot model:
|
||||
- hidden-file inclusion,
|
||||
- folder-before-file ordering,
|
||||
- alphabetical ordering,
|
||||
- frontend-root tagging.
|
||||
- Add unit tests for any editor tab/session model extracted from the UI layer:
|
||||
- open-new-tab behavior,
|
||||
- no duplicate tab on reopening the same file,
|
||||
- label formatting,
|
||||
- session-local state behavior.
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- No full JavaFX integration harness is required, but any extracted coordinator/service should be exercised through focused tests where possible.
|
||||
|
||||
### Manual Verification
|
||||
|
||||
- Verify the navigator shows the full project, including hidden files.
|
||||
- Verify the manual refresh button rebuilds the tree on demand.
|
||||
- Verify supported text files open read-only in tabs.
|
||||
- Verify unsupported files trigger the simple modal.
|
||||
- Verify no save/dirty/write affordance appears in the resulting flow.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] The editor has a structural navigator snapshot that covers the whole project and tags frontend-relevant roots.
|
||||
- [x] The navigator performs initial refresh and supports manual refresh without watcher dependency.
|
||||
- [x] Supported files open into read-only tabs with responsive/overflow behavior preserved.
|
||||
- [x] Unsupported files trigger a simple modal instead of a partial preview.
|
||||
- [x] Opened-file content and visual tab state remain session-local only.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- DEC-0008 accepted.
|
||||
- PLN-0012 should land first or in parallel if naming/spec wording is stable.
|
||||
- PLN-0013 should land before or alongside this plan because navigator and tabs need the new workspace shell surfaces.
|
||||
|
||||
## Risks
|
||||
|
||||
- If snapshot and tab state live only inside UI controls, the implementation will become hard to test and harder to evolve later.
|
||||
- If unsupported-file handling is loose, the first wave will silently imply file-format support it does not actually have.
|
||||
Loading…
x
Reference in New Issue
Block a user