LaunchRepoEspace de travail créé et tableau de bord lancé, la première vraie session est menée par l’agent. ONBOARDING.md lui demande de parler votre langue, d’avancer une phase à la fois, de remplir les fichiers à partir de vos réponses et de sources vérifiées, et de ne jamais redemander ce qu’un fichier existant contient déjà. Si une session s’interrompt, onboarding.json et SESSION.md permettent à l’agent suivant de reprendre à la première phase incomplète. Voici chaque phase — et ce que l’agent ne doit pas faire.
Phases 1–2 : orientation et un espace privé
L’agent expose d’abord le plan : comprendre le produit, connecter le navigateur et la boîte mail de vérification, convenir de la façon dont il peut publier fiches et badges de site, et préserver la configuration pour les sessions futures. Il demande le nom, l’URL et le dossier de code local du premier produit, et les lit avant toute autre question. Il vérifie aussi ce qu’il peut réellement faire dans cette session — un terminal seul ne contrôle pas le navigateur, et le kit interdit de revendiquer des outils que la session ne peut pas appeler.
La phase 2 donne à vos données un espace privé. Si l’agent est encore dans le dépôt de livraison acheté, il initialise l’espace de travail indépendant du démarrage en trois étapes et vous aide à configurer votre propre remote privé. Il dit clairement que les identifiants stockés, si vous y consentez, vivent dans ce dépôt privé — lisibles par quiconque y a accès, y compris à son historique — et jamais dans le dépôt de livraison. Propriétaire, dépôt, contrôle de visibilité et choix d’identifiants vont dans workspace.json ; avec un gestionnaire de secrets, seules des références sont enregistrées.
Phase 3 : le brief produit et votre date de lancement
L’agent exécute scripts/new-product.py avec un slug court en minuscules et remplit product.json — le fichier de contexte produit que lit chaque playbook — à partir de vos réponses : audience, problème, différenciateur, fonctionnalités réelles, tarifs ou essai, stade de lancement, vraies captures d’écran et logo. Le texte obtenu vous est soumis pour corrections. Deux règles vous protègent des fiches embarrassantes : aucune capacité déduite d’un concurrent, aucune fonctionnalité prévue décrite comme disponible. Les inconnues restent vides.
Cette phase demande aussi quand les premiers lancements doivent être en ligne et s’il existe une date avant laquelle rien ne doit paraître — en avertissant clairement que les annuaires gratuits mettent les soumissions en file de modération et que publier peut prendre des semaines, pas des jours. Votre réponse devient earliest_launch_date dans product.json, la date de lancement au plus tôt que record.py fera respecter ensuite.
identity.json recueille ensuite le nom public, l’e-mail de contact, le pseudonyme et les faits d’organisation que vous autorisez, en séparant l’e-mail privé de votre compte de l’adresse de contact publique. Avant que tout cela n’atteigne une fiche, l’agent mène le court briefing de représentation.
Phase 4 : Chrome et la boîte mail
Avec le guide de connexion à Chrome, l’agent vous accompagne sur la page de débogage à distance de Chrome et les éventuelles permissions macOS, puis fait un test de fumée visible sur une page publique. Vous vous connectez vous-même à votre messagerie web dans ce navigateur ; l’agent confirme qu’il s’agit du bon compte sans copier de messages. Les e-mails de vérification finalisent inscriptions et fiches ; le périmètre d’accès à la boîte mail est donc consigné dans authorizations.json. Transmettre les codes à la main reste un repli accepté, enregistré comme relais humain plutôt que comme accès automatisé.
Phase 5 : les permissions, convenues une fois par produit
L’agent demande où vit le code du site du produit, comment il se déploie, quelle branche est en production et quelle est l’URL canonique. Puis la question qui évite le plus de friction ensuite : peut-il ajouter un badge d’annuaire officiel au pied de page de ce produit, commiter, pousser et redéployer ? Périmètre, réponse, date, dépôt et branche autorisés vont dans authorizations.json. Un « non » ne bloque pas les annuaires qui n’exigent aucun badge. Le même fichier consigne si inscriptions gratuites, soumissions finales gratuites et certaines actions sur les e-mails de vérification sont autorisées. Les dépenses restent à zéro, et une autorisation pour un produit ne s’étend jamais à un autre.
Phases 6–7 : un vrai résultat, puis un espace de travail reprenable
Configuration terminée, l’agent exécute doctor.py, en distinguant configuration manquante et permissions délibérément refusées. Il choisit trois à cinq playbooks pertinents, justifie le choix et commence par une voie gratuite accessible : chercher une fiche existante, vérifier la destination, préparer un texte exact, confirmer que rien n’est facturé, soumettre dans le cadre autorisé, enregistrer le résultat réel. Un bon premier résultat est souvent une soumission en modération, pas une page en ligne — voir le guide d’enregistrement des résultats.
Pour clore, l’agent met à jour onboarding.json avec les seules vérifications réellement observées, écrit les preuves non sensibles et les étapes ouvertes dans SESSION.md, place les dates de relance dans FOLLOW-UP.md, et résume ce qui est fait, en attente, à votre charge et à venir. Un contrôle de confidentialité git s’exécute avant chaque push. Le test d’une bonne première session : l’agent suivant continue sans rien réenregistrer ni redemander les permissions permanentes. La page comment ça marche montre où cela se situe dans le flux global.