Do download ao primeiro agente.

Um instalador para a sua conta. Reutiliza o ambiente existente, mostra cada mudança e leva você até o primeiro projeto.

Protótipo de experiência. Os botões simulam ações; nada será instalado, autenticado, reiniciado ou removido.

PiCode SetupSIMULATION

Download→Instalar PiCode→Escolher CLI→Conectar conta→Abrir projeto→Criar agente

Uma entrega pequena, com o ciclo completo

A proposta é gerar um PiCode-Setup.exe por usuário com NSIS, aproveitando a shell Tauri e o bootstrap Windows/WSL existentes. NSIS seria uma ferramenta do build e do CI; o usuário final recebe somente o instalador.

Dentro da v1 proposta

Windows x64, instalação online e uma conta local.
Detectar WSL e adotar Ubuntu compatível com confirmação.
Habilitar WSL quando faltar e retomar depois do reinício.
Shell, servidor Linux e componentes necessários.
Escolha livre do CLI no primeiro uso.
Atualização, reparo e remoção com dados preservados.

Depois da primeira entrega

Distribuição WSL dedicada e importada.
Pacote totalmente offline.
Instalação para todos os usuários e gestão de equipes.
Promoção no winget ou Microsoft Store.
Outros sistemas e Windows ARM64 após validação própria.

O que muda em relação ao plano anterior

A ADR-0098 escolheu um script PowerShell como porta de entrada e não um wizard. Este protótipo propõe revisar essa escolha: oferecer download e instalação guiada mantendo a lógica de convergência existente. A implementação depende dessa decisão do proprietário.

Proposta, não capacidade entregue.

O bootstrap e a shell existem. O pacote NSIS está desativado na configuração atual; este wizard, o onboarding integrado e a tela de manutenção ainda precisam ser implementados e validados. O código já deixa a escolha dos CLIs para o usuário.

Como o instalador seria gerado

O build produz a shell Windows, a ferramenta de bootstrap e o servidor Linux com a mesma versão.
O CI prepara NSIS e empacota a shell e a ferramenta no Setup.exe. A distribuição precisa permitir acesso aos downloads sem exigir acesso ao repositório privado.
O pacote registra atalhos e desinstalação. Os estágios existentes cuidam do WSL e verificam o servidor Linux antes da instalação.
O fluxo só declara sucesso quando o servidor responde e a shell abre. Atualizações precisam validar a compatibilidade dos três componentes.

NSIS não substitui o bootstrap, não habilita WSL sozinho e não elimina avisos de reputação do Windows. O tratamento de assinatura e distribuição é uma decisão separada.

Benchmarks que orientam a proposta

Referência oficial	Comportamento observado	Adaptação proposta
VS Code	User Setup recomendado, atualizações sem elevação.	Instalação pessoal como padrão.
Docker Desktop	Instalação por usuário e backend WSL.	Separar direitos do aplicativo e preparação do sistema.
Rancher Desktop	Requisitos explícitos; remoção preserva dados e distribuições.	Preflight claro e desinstalação conservadora.
Tauri / NSIS	Setup.exe, instalação por usuário e hooks.	Empacotar a shell existente e chamar o bootstrap.
WebView2	Evergreen compartilhado e atualizado pela Microsoft.	Detectar e instalar o runtime somente quando faltar.
Inno Setup	Modo sem elevação disponível.	Alternativa; NSIS combina com a shell já existente.

Referência visual interna

Adaptação da barra Cursor/Linear: etapas compactas, uma ação principal por tela, erro com caminho de recuperação e retorno imediato. Os protótipos usam os tokens atuais do PiCode, sem reproduzir a interface de um editor.

Pontos em aberto antes de implementar

Aprovar a revisão da ADR-0098 para Setup.exe.
Definir distribuição dos binários fora do repositório privado.
Tratar assinatura e reputação: empacotar não resolve SmartScreen. Orientação Microsoft.
Validar UAC, reinício, certificados, login e atualização na VM Windows.
Confirmar política de acesso inicial e exposição de rede; o protótipo não altera o modelo de segurança atual.

Quando podemos chamar a v1 de pronta

Os cenários abaixo são critérios propostos. O protótipo demonstra decisões; não prova que o instalador real funciona.

Condição	Resultado esperado	Evidência necessária
Sem WSL	Preparar sistema, pedir reinício e retomar a etapa pendente.	VM limpa; UAC e retomada observados.
Ubuntu existente	Mostrar alterações e instalar apenas após confirmação.	VM com projetos, ferramentas e configurações preexistentes.
Múltiplas distribuições	Escolher explicitamente a compatível; preservar a padrão.	Teste Windows com duas distribuições.
Distribuição não suportada	Explicar bloqueio; oferecer caminho compatível sem remover a atual.	Estado bloqueado no instalador real.
Virtualização indisponível	Parar antes de alterar o sistema; explicar próximo passo.	VM ou host com recurso desativado.
Rede falha / checksum inválido	Não executar o arquivo; permitir nova tentativa verificável.	Injeção de falha; checksum adulterado.
Instalação interrompida / repetida	Reavaliar estado sem duplicar tarefas ou alterar dados.	Interrupção em cada estágio; segunda execução.
CLI já instalado	Reutilizar, com conta nativa intacta.	Teste com CLI real e configuração preexistente.
Nenhum CLI / login recusado	PiCode abre; instalar ou conectar depois; próxima ação visível.	Primeiro uso sem CLI e cancelamento do login.
Projeto vazio	Convidar a selecionar projeto ou explorar antes.	Estado vazio e caminho sem projeto.
Atualização / falha parcial	Manter versões compatíveis; recuperar execução anterior quando seguro.	Atualização dos três componentes e falhas por etapa.
Desinstalação	Remover PiCode; preservar projetos, CLIs e distribuição adotada.	Comparação de arquivos antes/depois.

Medir durante o piloto

Tempo até abrir PiCode e até o primeiro agente, tamanho total baixado, reinícios solicitados, ações manuais e falhas por estágio. Não há promessa de minutos ou tamanho sem medição real.