prometeu-studio/discussion/workflow/agendas/AGD-0034-vscode-editor-migration-feasibility.md

id	ticket	title	status	created	resolved	decision	tags
AGD-0034	studio-editor-workspace-cleanup	Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados	accepted	2026-05-05	2026-05-05	DEC-0031	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.