---
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.