tderoussel/overnight-build

Prompt de build noturno

O template completo está em references/overnight-build-template.md. Leia-o antes de compor. Não derive a estrutura de regras de memória — preencha suas seções [ENTRE_COLCHETES] com as especificidades do usuário e preserve quaisquer edições que ele tenha feito em sua própria cópia.

Inegociável

Cada saída deve conter obrigatoriamente a Regra 8 (sobreviver a reinícios de uso) e a seção LANÇADOR. São elas que tornam o build reiniciável; um prompt sem elas recomeça silenciosamente do zero após o primeiro reset de uso e queima uma noite.

Compor

1. Leia o template. Se o usuário mantiver uma cópia editada, a dele vence — preserve suas alterações.
2. Preencha a especificação — o que construir, contexto, requisitos de design, requisitos técnicos, funcionalidades em ordem de prioridade, dados de semente, implantação, critérios de sucesso. Especificidade aqui é o jogo todo; uma especificação vaga produz uma noite vaga.
3. Defina as fases — 4 a 8, cada uma independentemente concluível e verificável, com alocações de tempo que somem o orçamento.
4. Preencha o playbook de pivô com bloqueadores específicos do projeto, além dos fixos do template.
5. Pergunte uma vez qual lançador eles querem (A: agendador do SO · B: loop bash · C: um MCP de tarefa agendada), se a solicitação não disser. Pergunte uma vez — depois prossiga.
6. Forneça a saída como um único bloco de código copiável e lembre-os de salvá-lo em overnight-build-prompt.txt na raiz do projeto antes de lançar.

Sinalização de conclusão

O prompt deve instruir o build a emitir BUILD_COMPLETE como sua linha final — o executor de loop bash grep por ela para sair. Indique claramente, no prompt, que omitir BUILD_COMPLETE é correto quando qualquer critério P0 não for genuinamente atendido. Um executor que sai em um build inacabado é pior do que um que continua.

Guardrails

Um agente não supervisionado não tem ninguém para perguntar, então o prompt deve carregar seus próprios limites.

Se o alvo for uma base de código de produção existente, derive primeiro a propriedade dos arquivos e uma lista de NÃO FAZER (a skill fleet-brief produz ambas) e carregue as verificações de validação do projeto na fase de teste, para que "pronto" signifique verificado, não apenas mesclado.

Nunca permita que um prompt noturno autorize aplicar migrações de banco de dados, enviar schema, implantar via CLI de hospedagem, comprar ou liberar números de telefone ou domínios, ou enviar mensagens para contatos reais. Isso precisa de um humano acordado. Adicione as próprias ações irreversíveis do projeto a essa lista.

Entregáveis que o build deve escrever

• BUILD_LOG.md — entradas de fase, decisões, pivôs, problemas conhecidos e blocos ## CHECKPOINT — <ISO> com o próximo passo exato
• RESEARCH_NOTES.md — descobertas de pesquisa antes do início da implementação

Ao retomar, a primeira ação literal do build é ler BUILD_LOG.md de cima a baixo e continuar a partir do checkpoint mais recente — nunca repesquisar, reestruturar ou reiniciar.