Obrigado pelo review. Vou separar o que aceito, o que preciso explicar melhor e o que vou mudar.

O que aceito sem discussão

• Ciclo de vida: fechar a aba realmente não mata o servidor quando o navegador já estava aberto. Hoje ele encerra quando o processo de navegador iniciado pelo Fenestra termina, ou após 4 horas ociosas. Isso é frágil e mal explicado. Vou adicionar um comando explícito de parada e reduzir/documentar o timeout.
• Update check: você tem razão. Checagem automática sem consentimento e aba abrindo sozinha é comportamento invasivo, mesmo sem telemetria. Vou tornar isso opt-in, desligado por padrão; --check-update continua manual.
• Associação .html: é opcional, mas o risco que você descreveu existe. Um HTML baixado que precise de origem pode expor a pasta local. Vou deixar isso explícito e estudar uma confirmação/limite para pastas que não parecem build.
• Duplicação .NET + Go: é dívida real. O motivo histórico foi tamanho (120 KB vs ~7 MB) e não exigir SDK no Windows, mas manter duas bases custa mais do que economiza. Vou avaliar unificar no Go.
• SmartScreen/Gatekeeper e o “kit de montagem” no macOS: são atritos reais. Assinatura/notarização não são gratuitas; a documentação precisa ser mais honesta sobre isso.

O que preciso corrigir na crítica

• HTML comum não sobe servidor: o Fenestra abre file:// quando a página não precisa de origem. O servidor só entra para módulos ES, caminhos absolutos, fetch ou service worker.
• Para quem já está no terminal, python3 -m http.server resolve. O público que justifica a ferramenta é outro: abrir um build pelo gerenciador de arquivos, um artefato de CI, um projeto recebido por ZIP — e ter porta estável, fallback de SPA e confinamento de caminhos, que o http.server não tem.
• Chamar de “phone home” é justo no consentimento; nos dados, não: a requisição é um GET estático, sem identificador, sem projeto, sem uso.

O que vou fazer

1. Update check opt-in e aba só depois do consentimento.
2. --stop e timeout menor, com documentação clara.
3. Aviso e limite no handler .html.
4. Avaliar um único código Go para os três sistemas.
5. Deixar as limitações ainda mais visíveis, incluindo o público-alvo real.

Se você testar a próxima versão, quero saber se esses pontos ficaram menos defensáveis. Obrigado por perder tempo com o projeto.

O review acerta em três pontos que eu mudaria de verdade: update check opt-in, ciclo de vida explícito e unificação da stack. O resto é debate legítimo de escopo: para quem já vive no terminal, a ferramenta é redundante; para quem não vive, ela resolve um atrito real.