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