Submetido, pendente, agendado, online: porque importam

Todas as folhas de cálculo para submissões a diretórios começam da mesma maneira: uma coluna chamada «estado», três valores — por fazer, feito, talvez «à espera» — e um total lá em baixo que sobe sempre que alguém carrega em submeter. Duas semanas depois o total diz 40, o número de listagens que um estranho consegue mesmo encontrar diz 6, e ninguém explica a diferença sem reabrir todas as contas.

A diferença não é preguiça. É que se pediu a «feito» que respondesse a cinco perguntas diferentes ao mesmo tempo. Este artigo é sobre essas perguntas, sobre porque é que o tracker da LaunchRepo dá um estado próprio a cada uma, e sobre dois exemplos da nossa execução com o seomap.dev em que um único «feito» teria estado errado.

Uma coluna, cinco perguntas

Quando submetes um produto a um diretório, quem se interessa pelo resultado quer saber coisas diferentes:

• O trabalho do meu lado está feito? Preenchi tudo e carreguei no botão?
• A plataforma recebeu? Uma página de agradecimento, um e-mail, uma entrada na conta.
• Está à espera de alguma coisa? Moderação, um lugar na fila, uma aprovação, uma data.
• O público consegue ver? Um URL que abre para quem não tem sessão iniciada e que não traz uma etiqueta de «pendente».
• Tenho de fazer alguma coisa? Um CAPTCHA, um pedido de dois fatores, um badge no meu site, uma decisão sobre uma via paga.

«Feito» responde à primeira pergunta e, em silêncio, reclama a quarta. É assim que um total de 40 se torna um total de 6.

Os estados, e a pergunta a que cada um responde

O tracker da LaunchRepo (o record.py a escrever no submissions.csv, e as mesmas regras no painel local) usa onze estados. Cada um está ligado a uma observação mínima — o que tens mesmo de ter visto antes de o registares. Agrupados pela pergunta a que respondem:

Trabalho do teu lado

• draft — a preparação existe, a submissão final não foi confirmada. Um formulário guardado é um rascunho.
• prepared_needs_human — algo preciso bloqueia o trabalho preparado e só uma pessoa o pode resolver: CAPTCHA, 2FA, um estado de conta pouco claro. A nota diz exatamente o quê.

A plataforma recebeu

• submitted_pending_review — a plataforma reconheceu explicitamente a receção e a moderação continua aberta.
• queued — a plataforma confirmou uma posição na fila ou um estado de lista de espera. Diferente de estar em revisão: existe uma fila, e tu estás nela.
• scheduled — a plataforma confirmou uma data de lançamento igual ou posterior à tua data mais cedo de lançamento. Se a aprovação ainda estiver pendente, isso vai para a nota; o estado continua scheduled.

O público consegue ver

• live — uma listagem pública foi verificada, sem etiqueta de pendente. Exige o URL público e uma confirmação explícita no momento do registo.
• already_listed — uma listagem pública já existente foi encontrada e verificada antes de teres submetido seja o que for. Mesmo requisito de URL e de confirmação.

Parou, por um motivo que sabes nomear

• blocked — elegibilidade, capacidade da conta ou um facto obrigatório que não tens.
• deferred_paid — a única via utilizável custa dinheiro; nada foi comprado.
• not_a_fit — o produto não cumpre o público ou os critérios do diretório.
• unavailable — a via ou a plataforma não puderam ser usadas; a nota regista o que foi observado.

Onze parece muito. Na prática, cada um existe porque juntá-lo ao vizinho produziu um relatório errado pelo menos uma vez.

Exemplo 1: SaaSHub — pública, mas pendente

A submissão à SaaSHub, documentada no guia público da SaaSHub, produziu uma página de produto acessível publicamente. Qualquer pessoa com o link a conseguia abrir. Também trazia uma etiqueta visível: «Pending approval» (aprovação pendente).

Um tracker de uma só coluna regista isso como feito, ou até como online — afinal, a página abre. A regra da LaunchRepo é a oposta: a acessibilidade pública, só por si, não é prova de aceitação. A listagem fica em submitted_pending_review enquanto a página disser pendente, e passa a live apenas depois de alguém a voltar a abrir, não ver etiqueta de pendente e registar o URL com a flag de confirmação. No caso da SaaSHub, isso significou que a contagem de «online» não subiu no dia da submissão, e que o ficheiro de seguimento ficou com uma data para voltar a verificar.

O detalhe adicional que o guia acrescenta: na SaaSHub, a verificação de propriedade do domínio é um pedido separado do início de sessão na conta. É uma segunda coisa que pode ficar pendente de forma independente, e uma nota na linha é o sítio certo para a guardar.

Exemplo 2: TinyLaunch — agendado com aprovação pendente

A TinyLaunch, documentada no guia da TinyLaunch, oferecia um lugar de lançamento semanal no futuro. O caminho observado passou por um lançamento «Standard», um passo de serviços opcionais posto a nenhum, uma confirmação de agendamento e um segundo diálogo de upgrade com a opção «continue with free launch» (continuar com o lançamento gratuito) antes de aparecer a página de sucesso. O painel mostrou então a data confirmada — e, ao lado dela, «Waiting for approval» (a aguardar aprovação).

Duas formas erradas de registar isto: live, porque há uma data num calendário; ou submitted_pending_review, porque a aprovação está pendente. O tracker regista scheduled com a data confirmada passada explicitamente, e mantém a aprovação pendente na nota. Os dois factos sobrevivem: existe uma data, e pode não se manter. O artigo sobre lançamentos sem orçamento trata a parte do upsell desse mesmo fluxo.

É também aqui que a data mais cedo de lançamento importa. O product.json guarda um earliest_launch_date; o tracker recusa registar scheduled com uma data anterior a essa. Um programador a solo que definiu o limite para «depois de a página de preço ir para o ar» não pode agendar sem querer um lançamento para amanhã só porque um diretório ofereceu o lugar.

Três regras que saem dos estados

Um ecrã de agradecimento não é online. É, no melhor dos casos, submitted_pending_review. A maioria dos diretórios que revê submissões à mão demora dias a semanas; vários planos gratuitos na nossa execução demoraram mais do que isso. O guia de acompanhamento de estados é explícito: uma estimativa longa de revisão não é um prazo nem uma garantia.

Uma submissão é uma linha. Alguns diretórios oferecem uma caixa de «distribuir também para os nossos sites parceiros». Assinalá-la não cria uma segunda submissão até a segunda plataforma confirmar a receção por si. O tracker mantém uma linha atual por plataforma e exige substituição explícita para a mudar, para que uma caixa de parceiros não possa inflacionar a contagem em silêncio.

As passagens para humano são um estado, não uma falha. Quando um agente esbarra num CAPTCHA ou num pedido de dois fatores, regista prepared_needs_human com a ação seguinte exata e para. O painel agrupa estes casos em «precisa de ti». Marcá-los como outra coisa qualquer — tentar de novo, «pendente», saltar — ou contorna um controlo da plataforma ou esconde trabalho que ainda tens de fazer.

Porque é que um agente precisa disto mais do que tu

Se submeteres a cinco diretórios à mão, lembras-te de qual está pendente e de qual mostrou um calendário. Um agente de IA que corre uma sessão, a fecha e é reiniciado amanhã — possivelmente outro agente, noutra máquina — não se lembra. Lê primeiro o tracker e decide o que fazer a partir do estado:

• prepared_needs_human e lançamentos em scheduled com verificação por fazer vêm primeiro.
• As linhas em submitted_pending_review cuja janela de revisão já passou são reverificadas — o registo existente, não uma nova submissão para saltar a fila.
• As linhas em live ficam em paz.

Todas estas decisões estão erradas se o estado estiver errado. Registar live para a página da SaaSHub teria significado que ninguém voltaria a verificar se foi aprovada. Registar a TinyLaunch como submetida teria significado que ninguém verificaria o lançamento na data confirmada. Os estados são a memória do agente, e o passo a passo com o Claude Code mostra como uma execução os lê no início de cada sessão.

Como é um bom relatório

Em vez de «40 feitos», o painel mostra algo assim: 6 online com URL público, 21 em revisão com datas para voltar a verificar, 4 agendados com datas confirmadas, 3 à espera de ti, 2 adiados porque a via gratuita não existia, 4 sem encaixe. O total continua a ser 40. Todos os números se defendem, e cada grupo tem uma ação seguinte óbvia.

É para isto que serve um tracker. Não para impressionar — para dizer à pessoa seguinte, ou ao agente seguinte, o que é verdade e o que fazer.

Se estás a preparar a tua própria execução, como funciona a LaunchRepo mostra onde o tracker entra no fluxo, a página para fundadores de SaaS cobre a configuração de um produto com um calendário de lançamento real, e a página de preço tem a licença de pagamento único para o repositório em que o tracker vem.

Fontes: RUNBOOK.md e AGENTS.md no repositório da LaunchRepo (tabela de estados e observações mínimas), os guias públicos da SaaSHub e da TinyLaunch (observados a 2026-09-13) e o guia de acompanhamento de estados de submissão. Os números do relatório na última secção são ilustrativos, não medidos.