Registar resultados: estados, evidência e record.py

Toda a tentativa num diretório termina com um comando. O scripts/record.py escreve uma única linha atual por plataforma no submissions.json da pasta do produto, e recusa linhas que o kit considera não provadas ou inseguras. Essa recusa é todo o objetivo: o tracker é o que impede que «submetemos a 40 diretórios» signifique «preenchemos 40 formulários e esperámos pelo melhor». Este guia cobre os estados, a evidência que cada um exige, as flags do comando e o que pode e não pode ir numa nota. É um resumo do RUNBOOK.md e das verificações do próprio script, não um substituto.

O comando

O exemplo do runbook, a partir do diretório do kit com uma pasta de projeto privada já criada:

No Windows, usa py -3 em vez de python3 nos comandos abaixo (ou python se esse comando executar Python 3.10 ou mais recente). Mantém o espaço de trabalho numa pasta local privada fora do OneDrive e de outras pastas sincronizadas. No PowerShell, coloca os exemplos de shell multilinha numa única linha e remove os caracteres \ no fim de cada linha.

python3 scripts/record.py --project ../private-product pitchwall draft \
  --note "Product import corrected; final form not sent" \
  --next-action "Check saved profile and review final form"

Dois argumentos posicionais (id da plataforma, estado) e duas opções obrigatórias (--note, --next-action). As flags opcionais são --public-url, --confirmed-public, --launch-date e --replace. O id da plataforma tem de ser um slug em minúsculas, o estado tem de ser um dos onze abaixo, e o tracker termina com uma explicação sempre que uma regra não é cumprida. O formulário de registo do painel local chama a mesma função com as mesmas regras.

Os onze estados e a sua evidência mínima

A tabela do runbook, em resumo:

Estado	O que tens de ter observado
draft	Trabalho preparado; submissão final não confirmada.
prepared_needs_human	Uma ação precisa do dono ou um desafio (CAPTCHA, 2FA) bloqueia o trabalho preparado.
submitted_pending_review	A plataforma recebeu explicitamente a submissão; a moderação continua.
queued	A plataforma confirma uma posição na fila ou um estado de lista de espera.
scheduled	A plataforma confirma uma data de lançamento igual ou posterior à data mínima; aprovação pendente fica na nota.
live	Listagem pública verificada, sem etiqueta de pendente; URL público e --confirmed-public obrigatórios.
already_listed	Uma listagem pública já existente verificada; mesmos requisitos de live.
blocked	Elegibilidade, capacidade da conta ou um facto obrigatório em falta impede o progresso.
deferred_paid	A via utilizável exige pagamento; nada foi comprado.
not_a_fit	O produto não cumpre os critérios de público ou de listagem.
unavailable	A via ou a plataforma não pode ser usada de momento; anota o problema.

As distinções que mais importam são rascunho vs. submetido e pendente vs. live. Um ecrã de agradecimento não torna uma listagem live. Uma página que consegues abrir pode ainda estar pendente de aprovação. Uma caixa «distribuir também aos nossos parceiros» assinalada não significa que uma segunda plataforma tenha recebido algo. O resultado de cada plataforma fica independente para que os totais nunca sejam inflacionados.

As regras que o script impõe

• Os estados públicos precisam de prova. live e already_listed exigem --public-url com um URL HTTPS revisto — sem query string, sem fragmento, sem caminhos de conta, painel ou login — e --confirmed-public, a tua declaração de que olhaste para a página.
• Agendado precisa de data. --launch-date YYYY-MM-DD é obrigatório e não pode ser anterior ao earliest_launch_date do product.json; o guia da data mínima de lançamento explica porquê.
• As notas ficam limpas. Notas e próximas ações não podem conter links, endereços de e-mail, pares do tipo password= nem prefixos de token conhecidos. O ficheiro do tracker foi pensado para ser partilhável; evidência com URLs de conta pertence a armazenamento privado.
• Uma linha por plataforma. Se a plataforma já tem uma linha, o comando falha a menos que passes --replace — depois de inspecionares a linha existente e a plataforma. Substituir é intencional, nunca um efeito secundário.
• Sem symlinks, escritas atómicas, um ficheiro de lock. Detalhes aborrecidos, mas são a razão por que dois agentes a escrever ao mesmo tempo não corrompem o tracker.

Retomar sem duplicados

No início da sessão seguinte, lê o tracker antes de tocar em qualquer formulário. Dá prioridade às passagens para humano e aos lançamentos agendados com verificação por fazer, depois às submissões pendentes cuja janela de revisão indicada já passou. Se uma plataforma não indica prazo de revisão, acorda uma data de acompanhamento com o dono em vez de inventar uma. E nunca resubmetas para subir numa fila: reverifica o registo existente. O tracker guarda o estado atual, não o histórico; se precisares de um rasto de auditoria, arquiva à parte resumos de execução com os dados sensíveis removidos.

Para exemplos práticos dos estados em plataformas reais, lê o artigo sobre estados de submissão e o guia mais antigo sobre acompanhar sem contar duas vezes; o vocabulário em si está definido em estado da listagem.