Uma execução de lançamento do início ao fim

O runbook do kit descreve um lançamento como um ciclo repetível e não como um evento único: construir um briefing verdadeiro, escolher um lote pequeno, trabalhar uma plataforma de cada vez, registar o que observaste, retomar da próxima vez sem refazer nada. Este guia acompanha uma execução por esse ciclo. Assume que os guias de configuração estão feitos — o espaço de trabalho existe, o browser está ligado e o onboarding registou as tuas permissões. O fluxo completo, produto → agente → diretórios → tracker, está desenhado na página como funciona.

1. Começa por um briefing verdadeiro

Toda a execução começa no product.json e no copy.md: nome, URL canónico, público, funcionalidades verificadas, um resumo de preços e uma data de revisão. O runbook é rigoroso com as pequenas mentiras que se infiltram: um trial limitado por créditos é um trial mesmo que começar seja gratuito; um facto obrigatório que não sabes é registado como desconhecido, não adivinhado; as capturas de ecrã são da interface real, redimensionadas a partir dos originais e verificadas quanto à qualidade; não se reutilizam contagens de clientes nem testemunhos de outros. Prepara um logótipo quadrado e uma descrição curta e uma longa a partir desses factos. O agente nunca deriva capacidades de um concorrente.

2. Escolhe três a cinco plataformas

O índice de playbooks deixa o agente escolher por público e pré-requisito. Começa com três a cinco, não cinquenta. Os playbooks condicionais — um diretório de IA que exige uma capacidade de IA real, um diretório de empresas que quer factos da empresa autorizados pelo dono — são orientação útil incluída no kit, não uma promessa de que todos os produtos têm um lugar gratuito. Para cada plataforma escolhida, o agente lê o playbook completo antes de navegar, verifica a linha existente no tracker, procura no diretório o nome e o domínio do produto e inspeciona a conta autenticada. Uma listagem existente que é tua é reclamada ou editada, não duplicada; uma tentativa anterior pouco clara é resolvida antes de começar uma nova. O artigo sobre lançamentos sem orçamento mostra como foi um lote destes em plataformas reais.

3. Uma plataforma de cada vez

Os seis passos do runbook para cada plataforma:

1. Reverifica o formulário atual, preços, elegibilidade, limite de conta e consentimento exigido.
2. Prepara apenas texto verificado e assets genuínos; valida todos os campos importados.
3. Reabre os campos guardados ou pré-visualiza o rascunho para confirmar que persistiu.
4. Inspeciona o total final e os extras opcionais. Na política por defeito, para em qualquer pagamento obrigatório. Se um badge for obrigatório, verifica a autorização de site registada, usa a marcação oficial e verifica a página pública publicada antes de atestar.
5. Submete dentro da autorização do dono; inspeciona o painel resultante e a etiqueta de moderação; guarda um resumo não sensível.
6. Regista o resultado e a próxima ação de imediato, e só depois avança.

«De imediato» carrega muito peso no passo 6. O kit trata uma submissão a diretório como inacabada até o resultado estar no tracker, porque um agente que regista dez resultados no fim de uma sessão vai lembrar-se mal de pelo menos um.

4. Escolhe os estados a partir da evidência

O estado vem do que foi observado, não do que foi tentado. Um ecrã de agradecimento não é live. Uma página acessível com a etiqueta Pending approval é submitted_pending_review. Um lugar confirmado com aprovação pendente é scheduled, com a reserva na nota e um --launch-date igual ou posterior à data mínima. Um pagamento obrigatório é deferred_paid e nada é comprado. A tabela completa, o comando e as regras das notas estão no guia de registo de resultados.

5. Retoma, não repitas

A sessão seguinte abre a ler o tracker. Passagens para humano e lançamentos agendados com verificação por fazer vêm primeiro, depois as submissões pendentes cuja janela de revisão já passou. Não se inventa nenhum SLA de plataforma; se um diretório não indica prazo, acorda-se contigo uma data de acompanhamento. Resubmeter para subir numa fila é proibido — reverifica-se o registo existente. Os projetos reais e a evidência do browser ficam privados; com vários agentes, cada um tem o seu próprio perfil de browser e a sua atribuição de plataformas, e o tracker coordena apenas as escritas locais.

Como é uma primeira execução realista

Três a cinco plataformas, uma sessão de agente e um tracker que diz algo como: um submitted_pending_review, um scheduled com aprovação pendente, um prepared_needs_human à espera de que resolvas um CAPTCHA, um deferred_paid. Possivelmente zero live no primeiro dia — as vias gratuitas publicam ao ritmo do diretório, semanas depois, que é toda a razão de existir da data mínima. Isso não é uma execução falhada; é o aspeto da fila vista de dentro. Para uma versão narrada com um agente específico, vê o passo a passo com o Claude Code ou a página do Codex.