A ideia que a gente quer resolver
Abrir um projeto raramente significa só abrir um aplicativo. Pode ser editor, terminal, diretórios, navegador, áudio, notificações e uma organização de workspace que você montou por um motivo.
Work Environments tenta representar esse contexto de forma explícita. Não como script mágico, e muito menos como “vamos serializar seu cérebro e torcer”.
Restaurar só o que dá pra identificar
A ativação analisa capacidades, mostra uma proposta e só então executa. Cada item pode terminar como restaurado exatamente, restaurado pelo próprio app, aproximado, excluído por privacidade, falho ou não suportado.
- Rules organizam janelas; não lançam apps.
- O contexto pode reutilizar processos já abertos.
- Sessão nativa do aplicativo tem preferência quando existe.
- Contextos privados e sensíveis ficam fora por padrão.
- Sair do contexto não fecha trabalho sem confirmação.
O que é realmente viável
Abrir um `.kra`, um diretório de projeto, uma workspace de editor ou um terminal numa pasta é bem mais realista do que tentar recuperar qualquer texto nunca salvo dentro de qualquer app.
Então o produto precisa mostrar fidelidade de restauração, não esconder as limitações atrás de um check verde gigante.
Sets ainda são canônicos
Os documentos canônicos atuais definem Sets. Work Environments é uma proposta de refinamento de produto preparada em paralelo enquanto a Fase 2 continua ativa.
Até uma mudança explícita no decision register, implementação de backend continua seguindo a semântica canônica de Sets. O site mostra a direção sem fingir que a migração já aconteceu.
Estado atual
Existe design preparatório detalhado, mas isso não é uma feature disponível nem uma API congelada. Backend pertence a fases posteriores e a experiência mais completa depende do desktop/profile que conseguir oferecer cada capacidade.