LaunchRepoCom o espaço de trabalho criado e o painel a correr, a primeira sessão a sério é conduzida pelo agente. O ONBOARDING.md diz-lhe para falar a tua língua, tratar uma fase de cada vez, preencher ficheiros a partir das tuas respostas e de fontes verificadas, e nunca perguntar duas vezes o que podia ler de um ficheiro. Se uma sessão se interromper, o onboarding.json e o SESSION.md deixam o agente seguinte continuar a partir da primeira fase incompleta. Eis o que faz cada fase — e o que o agente é instruído a não fazer.
Fases 1–2: orientação e uma casa privada
O agente começa por explicar o plano: entender o produto, ligar o browser e a caixa de correio de verificação, acordar como pode publicar listagens e badges no site, e preservar a configuração para sessões futuras. Pede nome, URL e pasta de código local do primeiro produto e lê-os antes de perguntar mais. Verifica também o que consegue realmente fazer nesta sessão — um terminal sozinho não é controlo do browser, e o kit proíbe alegar ter ferramentas que a sessão não consegue invocar.
A fase 2 dá aos teus dados uma casa privada. Se o agente ainda estiver no repositório de entrega comprado, inicializa o espaço de trabalho independente que o arranque em três passos cria e ajuda-te a configurar o teu remoto privado. Diz claramente que dados de login guardados, se consentires, vivem nesse repositório privado — legíveis por quem tiver acesso, incluindo ao histórico — e nunca no repositório de entrega. Dono, repositório, verificação de visibilidade e escolha de credenciais vão para o workspace.json; com um gestor de segredos, só se guardam referências.
Fase 3: o briefing do produto e a tua data de lançamento
O agente corre scripts/new-product.py com um slug curto em minúsculas e preenche o product.json — o ficheiro de contexto do produto que todos os playbooks leem — a partir das tuas respostas: público, problema, diferenciador, funcionalidades reais, preço ou trial, fase de lançamento, capturas de ecrã genuínas e logótipo. O texto resultante é-te mostrado para correções. Duas regras protegem-te de listagens embaraçosas: capacidades nunca são derivadas de um concorrente, e funcionalidades planeadas nunca são descritas como disponíveis. O que não se sabe fica vazio.
Esta fase pergunta também quando devem os primeiros lançamentos ficar online e se há uma data antes da qual nada pode ser publicado — com o aviso claro de que os diretórios gratuitos põem as submissões em fila de revisão e publicar pode levar semanas, não dias. A tua resposta torna-se earliest_launch_date no product.json, a data mínima de lançamento que o record.py impõe mais tarde.
O identity.json capta depois nome público, e-mail de contacto, alcunha e factos da organização que autorizas, mantendo o e-mail privado da conta separado do endereço de contacto público. Antes de isto chegar a uma listagem, o agente faz o curto briefing de representação.
Fase 4: o Chrome e a caixa de correio
Seguindo o guia de ligação ao Chrome, o agente guia-te pela página de depuração remota do Chrome e pelas permissões do macOS que surjam, e faz uma verificação rápida visível numa página pública. És tu que inicias sessão na caixa de correio web no browser ligado; o agente confirma que é a conta pretendida sem copiar mensagens. Os e-mails de verificação concluem registos e listagens, por isso o âmbito do acesso à caixa de correio fica registado em authorizations.json. Reencaminhar códigos à mão é um recurso suportado, registado como passagem para humano e não como acesso automatizado.
Fase 5: permissões, acordadas uma vez por produto
O agente pergunta onde vive o código do site do produto, como faz deploy, qual o branch de produção e qual o URL canónico. Depois, a pergunta que mais fricção poupa: pode adicionar um badge de diretório oficial ao rodapé desse produto, fazer commit, push e novo deploy? Âmbito, resposta, data e o repositório e branch permitidos vão para o authorizations.json. Um «não» não bloqueia os diretórios que não precisam de badge. O mesmo ficheiro regista se registos gratuitos, submissões finais gratuitas e ações específicas em e-mails de verificação estão autorizados. A despesa fica a zero, e uma autorização para um produto nunca se estende a outro.
Fases 6–7: um resultado real e um espaço de trabalho retomável
Com a configuração feita, o agente corre o doctor.py, separando configuração em falta de permissões recusadas de propósito. Escolhe três a cinco playbooks relevantes, explica o encaixe e começa por uma via gratuita acessível: procurar uma listagem existente, verificar o destino, preparar texto exato, confirmar que nada é cobrado, submeter dentro da autorização, registar o resultado real. Um bom primeiro resultado é muitas vezes uma revisão submetida e não uma página live — vê o guia de registo de resultados.
Para fechar, o agente atualiza o onboarding.json apenas com verificações que observou de facto, escreve evidência não sensível e passos em aberto no SESSION.md, põe as datas de acompanhamento no FOLLOW-UP.md e resume o que está feito, pendente, à tua espera e a seguir. Uma verificação de privacidade do git corre antes de cada push. O teste de uma boa primeira sessão: o agente seguinte consegue continuar sem registar nada de novo nem pedir permissões permanentes duas vezes. A página como funciona mostra onde isto entra no fluxo completo.