LaunchRepoCon el espacio de trabajo creado y el panel en marcha, la primera sesión real la dirige el agente. ONBOARDING.md le indica que hable tu idioma, avance fase por fase, rellene los archivos con tus respuestas y fuentes verificadas, y nunca pregunte dos veces algo que podría leer en un archivo existente. Si una sesión se interrumpe, onboarding.json y SESSION.md permiten al siguiente agente continuar desde la primera fase incompleta. Esto es lo que hace cada fase y lo que el agente tiene prohibido hacer.
Fases 1–2: orientación y un hogar privado
El agente empieza explicando el plan: entender el producto, conectar el navegador y el buzón de verificación, acordar cómo puede publicar fichas y badges en tu web, y conservar la configuración para futuras sesiones. Pide nombre, URL y carpeta de código local del primer producto, y los lee antes de preguntar nada más. También comprueba qué puede hacer realmente en esta sesión: un terminal a secas no es control del navegador, y el kit prohíbe atribuirse herramientas que la sesión no puede invocar.
La fase 2 da a tus datos un hogar privado. Si el agente sigue dentro del repositorio de entrega comprado, inicializa el espacio de trabajo independiente que crea el inicio en tres pasos y te ayuda a configurar tu propio remoto privado. Avisa sin rodeos de que los datos de acceso, si consientes en guardarlos, viven en ese repositorio privado —legibles por cualquiera con acceso, incluido a su historial— y nunca en el repositorio de entrega. Propietario, repositorio, comprobación de visibilidad y elección de credenciales van a workspace.json; con un gestor de secretos, solo se guardan referencias.
Fase 3: el briefing del producto y tu fecha de lanzamiento
El agente ejecuta scripts/new-product.py con un slug corto en minúsculas y rellena product.json —el archivo de contexto del producto que leen todos los playbooks— con tus respuestas: audiencia, problema, diferenciador, funciones reales, precio o prueba, fase de lanzamiento, capturas auténticas y logo. El copy resultante se te muestra para corregirlo. Dos reglas te protegen de fichas bochornosas: las capacidades nunca se derivan de un competidor, y las funciones planificadas nunca se describen como disponibles. Lo desconocido se queda vacío.
Esta fase también pregunta cuándo deberían salir los primeros lanzamientos y si hay una fecha antes de la cual nada puede publicarse, avisando claramente de que los directorios gratuitos ponen los envíos en cola de revisión y la publicación puede tardar semanas, no días. Tu respuesta se convierte en earliest_launch_date en product.json, la fecha mínima de lanzamiento que record.py hace cumplir más adelante.
identity.json recoge después el nombre público, el correo de contacto, el apodo y los datos de la organización que autorizas, y mantiene el correo privado de tu cuenta separado del contacto público. Antes de que nada de esto llegue a una ficha, el agente ejecuta el breve briefing de representación.
Fase 4: Chrome y el buzón
Siguiendo la guía de conexión con Chrome, el agente te guía por la página de depuración remota de Chrome y los permisos de macOS necesarios, y después hace una prueba de humo visible en una página pública. Tú mismo inicias sesión en tu buzón web en el navegador conectado; el agente confirma que es la cuenta prevista sin copiar mensajes. Los correos de verificación completan registros y fichas, así que el alcance del acceso al buzón queda registrado en authorizations.json. Reenviar códigos a mano es una alternativa soportada, registrada como relevo humano y no como acceso automatizado.
Fase 5: permisos, acordados una vez por producto
El agente pregunta dónde vive el código de la web del producto, cómo se despliega, qué rama es producción y cuál es la URL canónica. Y luego la pregunta que más fricción ahorra: ¿puede añadir un badge de directorio oficial al pie de esa web, hacer commit, push y redesplegar? Alcance, respuesta, fecha y repositorio y rama permitidos van a authorizations.json. Un «no» no bloquea los directorios que no necesitan badge. El mismo archivo registra si se autorizan registros gratuitos, envíos finales gratuitos y acciones concretas sobre los correos de verificación. El gasto se queda en cero, y un permiso para un producto nunca se extiende a otro.
Fases 6–7: un resultado real y un espacio de trabajo reanudable
Hecha la configuración, el agente ejecuta doctor.py, que separa lo que falta por configurar de los permisos que rechazaste a propósito. Elige de tres a cinco playbooks relevantes, explica el encaje y empieza con una vía gratuita accesible: buscar una ficha existente, verificar el destino, preparar copy exacto, confirmar que no se cobra nada, enviar dentro del permiso concedido, registrar el resultado real. Un buen primer resultado suele ser una revisión enviada, no una página publicada; ver la guía para registrar resultados.
Para cerrar, el agente actualiza onboarding.json solo con comprobaciones observadas de verdad, escribe evidencia no sensible y pasos abiertos en SESSION.md, apunta las fechas de seguimiento en FOLLOW-UP.md y resume qué está hecho, pendiente, esperándote y qué sigue. Antes de cada push corre una comprobación de privacidad de git. La prueba de una buena primera sesión: el siguiente agente puede continuar sin volver a registrar nada ni pedir dos veces los permisos permanentes. La página de cómo funciona muestra dónde encaja esto en el flujo completo.