Documentação

Entregar ao cliente

O menu Entregar, no topo, reúne o que você precisa para mostrar o trabalho: a prévia ao vivo, a publicação na Vercel ou na Cloudflare Pages e o relatório em PDF.

Prévia ao vivo#

Clique em Entregar e em Abrir prévia. O site abre numa janela própria.

• Site estático: o app acha sozinho o index.html (na raiz do projeto, em public ou em dist) e recarrega a prévia quando os agentes salvam arquivos.
• Site com servidor de desenvolvimento: se não houver index.html, o menu pede o endereço, por exemplo http://localhost:5173. O app lembra esse endereço para o projeto. O servidor precisa estar rodando (num terminal ou pedido a um agente) e cuida ele mesmo de recarregar.

Publicar na Vercel#

Você precisa do Node.js instalado e de uma conta na Vercel.

1. Clique em Entregar e em Publicar na Vercel.
2. Se o site não foi revisado na última hora, o app propõe a revisão antes. Veja a seção seguinte.
3. Abre um painel de terminal chamado Publicação. Na primeira vez, o app instala a Vercel (só uma vez) e a Vercel pede login no navegador.
4. O site é publicado em produção. Em seguida o app deixa o site público, desativando o login da Vercel neste projeto.
5. No fim, o endereço aparece no menu, em “No ar em”, com a data, e uma mensagem no topo da janela. O botão passa a se chamar Publicar de novo.

A pasta .towerctl (memória, cópias dos ajudantes e relatórios) nunca vai junto: o app a coloca no .vercelignore do projeto.

Sem o Node.js, o painel de publicação avisa “Para publicar, instale o Node.js (nodejs.org) e tente de novo.” Clicar em publicar enquanto uma publicação está rodando só leva você até ela.

Escolher onde publicar#

No menu Entregar, em Publicar, o grupo Onde publicar tem duas opções: Vercel e Cloudflare Pages. O botão logo abaixo muda de nome conforme a escolha (Publicar na Vercel ou Publicar na Cloudflare). A escolha fica salva para o projeto.

Para os sites de negócios locais que você entrega a clientes, a Cloudflare Pages costuma ser a melhor escolha: é grátis e o site fica no ar com o domínio do cliente depois. Escolha a Vercel quando o site precisa de servidor, como Next ou Nuxt com rotas de API.

Publicar na Cloudflare Pages#

Você precisa do Node.js instalado e de uma conta grátis na Cloudflare.

1. Clique em Entregar, escolha Cloudflare Pages em Onde publicar e clique em Publicar na Cloudflare.
2. Se o site não foi revisado na última hora, o app propõe a revisão antes de publicar.
3. Abre o painel de terminal Publicação. Na primeira vez, o app instala a ferramenta da Cloudflare (o wrangler), só uma vez.
4. Se você ainda não entrou na Cloudflare, o painel diz “Entrando na sua conta da Cloudflare (abre o navegador)...” e abre o navegador. Entre na sua conta e autorize. O TowerCTL nunca vê a sua senha nem o seu token: o login fica com a ferramenta da Cloudflare.
5. O app cria o projeto na Cloudflare Pages (se já existir, usa o que existe) e envia o site.
6. No fim, o endereço https://nome.pages.dev aparece no menu, em “No ar em”, com a data, e uma mensagem no topo da janela. O botão passa a se chamar Publicar de novo na Cloudflare.

O nome do site#

O nome do projeto na Cloudflare vem do nome da pasta do projeto, em minúsculas, sem acentos e com traços no lugar de espaços e símbolos. Uma pasta “Clínica Sorriso” vira clinica-sorriso, e o site fica em clinica-sorriso.pages.dev. Se o nome já for de outra pessoa, a Cloudflare escolhe um endereço parecido, e o app mostra o que ela escolheu.

Só sites estáticos#

A publicação pelo TowerCTL na Cloudflare é para sites estáticos: páginas HTML, CSS, JavaScript e imagens.

• Sem passo de build (não há build no package.json): a pasta do projeto é o site, e o index.html precisa estar nela.
• Com build no package.json: o app instala as dependências se faltarem (npm install), roda npm run build e publica a primeira pasta que tiver um index.html entre dist, build, out e _site. Serve para Vite, Astro, Eleventy e similares.
• Next e Nuxt: só publicam aqui se estiverem configurados para exportar um site estático (a saída em out ou dist). Do contrário, o painel avisa que não achou a pasta do site e pede a Vercel ou a exportação estática. Para esses, use a Vercel.
• Funções da Cloudflare (a pasta functions e o arquivo _worker.js na raiz) não são publicadas. O painel avisa: “funções da Cloudflare não são publicadas por aqui, só o site estático”.

Se o build falhar, o painel diz “O build do projeto falhou: veja o erro acima.”. Peça ao agente para corrigir e publique de novo.

O que vai e o que não vai#

O app não envia a pasta do projeto inteira. Ele faz antes uma cópia limpa, só com os arquivos do site, e envia a cópia. Ficam de fora, em qualquer pasta:

• a pasta .towerctl (memória, cópias dos ajudantes e relatórios), .git e node_modules;
• arquivos de senhas e chaves: .env e variantes, .dev.vars, .npmrc, *.pem e *.key;
• arquivos de configuração e estado de ferramentas, como wrangler.toml, .vercelignore, .claude, .vscode e .cache.

A cópia é apagada no fim, e nenhum arquivo temporário da Cloudflare fica no projeto do cliente.

Se algo der errado#

• “Para publicar, instale o Node.js (nodejs.org) e tente de novo.”: instale o Node.js.
• “Não foi possível entrar na Cloudflare.”: o login no navegador não terminou. Publique de novo e conclua o login.
• “Não foi possível instalar a Cloudflare (wrangler).”: sem internet ou sem permissão para instalar. Tente de novo.

Quando a publicação falha ou termina, você recebe um aviso no sino.

A revisão antes de publicar#

Em todos os perfis, outra IA revisa o site antes de ele chegar ao cliente. Ao clicar em publicar, se não houve revisão na última hora, aparece uma pergunta:

• OK: revisar agora. Depois da revisão, é só clicar em publicar de novo.
• Cancelar: publicar sem revisar.

O app abre o painel Revisão antes de publicar, de preferência numa IA diferente da do líder da missão. Ele escolhe entre Claude, Codex e Gemini os que estão instalados e abaixo de 90% do limite de 5 horas (ou cujo uso o app não conhece), começando pelo de menor uso. Se nenhuma outra IA servir, a revisão fica com a mesma IA do líder; no Claude, o app pede o modelo Opus.

Sem um líder aberto na missão, o revisor abre com o modelo e o esforço padrão da IA escolhida.

O revisor não edita nada. Ele confere, como um visitante:

• se todas as páginas abrem e se links e botões levam a algum lugar;
• se os formulários validam e dizem o que acontece ao enviar;
• o layout no celular (375 px) e no computador;
• se as imagens carregam, não estão distorcidas e têm texto alternativo;
• erros de digitação e textos de exemplo esquecidos, títulos e descrições das páginas;
• erros no console do navegador e chaves ou senhas expostas no código.

O resultado vem em português, um problema por linha, com gravidade (alta, média ou baixa), onde está e como corrigir. Se a missão tem um líder aberto, a lista vai para ele, que corrige. Se não tem, a lista aparece no próprio painel do revisor.

A revisão vale por uma hora. Depois disso, o app pergunta de novo.

Relatório para o cliente#

1. Clique em Entregar.
2. Em Relatório para o cliente, escreva o nome da sua agência. Ele aparece no topo do relatório, e o app lembra para a próxima vez. Dá para guardar o nome de uma vez nas Configurações, na seção Geral, em Nome da sua agência.
3. Escolha o período: Últimos 7 dias, Últimos 30 dias ou Desde o início.
4. Deixe Foto do site marcado para incluir uma imagem do site publicado (ou da página local, se ainda não foi publicado).
5. Clique em Gerar PDF. O relatório abre sozinho. Para abrir depois, use Abrir de novo.

O PDF, junto com uma versão em HTML, fica em .towerctl/relatorios, dentro do projeto. Ele traz:

• os números do período: tarefas concluídas, sessões de trabalho e arquivos criados ou alterados;
• o endereço e a foto do site;
• O que foi feito e Próximos passos, das tarefas marcadas com - [x] e - [ ] em tarefas.md;
• as sessões de trabalho, as decisões de decisoes.md e os arquivos do período.