Una ejecución de lanzamiento de principio a fin

El runbook del kit describe un lanzamiento como un bucle repetible, no como un evento único: construir un briefing veraz, elegir un lote pequeño, trabajar una plataforma cada vez, registrar lo observado y reanudar la próxima vez sin rehacer nada. Esta guía sigue una ejecución a través de ese bucle. Da por hechas las guías de configuración: el espacio de trabajo existe, el navegador está conectado y el onboarding ha registrado tus permisos. El flujo completo, producto → agente → directorios → tracker, está dibujado en la página de cómo funciona.

1. Parte de un briefing veraz

Toda ejecución empieza en product.json y copy.md: nombre, URL canónica, audiencia, funciones verificadas, un resumen de precios y una fecha de revisión. El runbook es estricto con las pequeñas mentiras que se cuelan: una prueba limitada por créditos es una prueba aunque empezar sea gratis; un dato obligatorio que no conoces se registra como desconocido, no se adivina; las capturas son de la interfaz real, redimensionadas desde los originales y revisadas en calidad; no se reutilizan cifras de clientes ni testimonios de nadie más. Prepara un logo cuadrado y una descripción corta y otra larga a partir de esos hechos. El agente nunca deriva capacidades de un competidor.

2. Elige de tres a cinco plataformas

El índice de playbooks permite al agente elegir por audiencia y requisitos previos. Empieza con tres a cinco, no cincuenta. Los playbooks condicionales —un directorio de IA que exige una capacidad de IA real, un directorio de empresas que quiere datos de empresa autorizados por el propietario— son orientación útil incluida en el kit, no una promesa de que todo producto consigue un hueco gratis. Para cada plataforma elegida, el agente lee el playbook completo antes de navegar, revisa la fila existente del tracker, busca en el directorio el nombre y el dominio del producto e inspecciona la cuenta con sesión iniciada. Una ficha existente que es tuya se reclama o se edita, no se duplica; un intento anterior poco claro se resuelve antes de empezar otro. El artículo sobre el lanzamiento con presupuesto cero muestra cómo fue un lote así en plataformas reales.

3. Una plataforma cada vez

Los seis pasos del runbook para cada plataforma:

1. Vuelve a comprobar el formulario vigente, el precio, la elegibilidad, el límite de cuenta y el consentimiento requerido.
2. Prepara solo copy verificado y recursos auténticos; valida cada campo importado.
3. Vuelve a abrir los campos guardados o previsualiza el borrador para confirmar que persistió.
4. Inspecciona el total final y cualquier extra opcional. Con la política por defecto, detente ante cualquier pago obligatorio. Si se exige un badge, revisa la autorización registrada para la web, usa el marcado oficial y verifica la página pública desplegada antes de atestiguarlo.
5. Envía dentro de la autorización del propietario; inspecciona el panel resultante y la etiqueta de moderación; guarda un resumen no sensible.
6. Registra el resultado y la siguiente acción de inmediato, y pasa a la siguiente.

«De inmediato» hace mucho trabajo en el paso 6. El kit trata un envío a un directorio como inacabado hasta que su resultado está en el tracker, porque un agente que registra diez resultados al final de una sesión recordará mal al menos uno.

4. Elige los estados a partir de la evidencia

El estado sale de lo que se observó, no de lo que se intentó. Una pantalla de agradecimiento no es live. Una página accesible con la etiqueta Pending approval es submitted_pending_review. Un hueco confirmado con la aprobación pendiente es scheduled, con la salvedad en la nota y un --launch-date igual o posterior a la fecha mínima. Un pago obligatorio es deferred_paid y no se compra nada. La tabla completa, el comando y las reglas de las notas están en la guía para registrar resultados.

5. Reanuda, no repitas

La siguiente sesión empieza leyendo el tracker. Primero los relevos humanos y los lanzamientos programados que toca verificar, después los envíos pendientes cuya ventana de revisión ya pasó. No se inventa ningún SLA de plataforma; si un directorio no indica plazos, se acuerda contigo una fecha de seguimiento. Reenviar para adelantar en una cola está prohibido: se recomprueba el registro existente. Los proyectos reales y la evidencia del navegador se quedan en privado; con varios agentes, cada uno tiene su propio perfil de navegador y su asignación de plataformas, y el tracker solo coordina las escrituras locales.

Cómo es una primera ejecución realista

De tres a cinco plataformas, una sesión de agente y un tracker que dice algo así: un submitted_pending_review, un scheduled con la aprobación pendiente, un prepared_needs_human esperando a que resuelvas un CAPTCHA, un deferred_paid. Posiblemente cero live el primer día: las vías gratuitas publican según el calendario del directorio, semanas después, que es justo la razón de que exista la fecha mínima. Eso no es una ejecución fallida; es la cola vista desde dentro. Para una versión narrada con un agente concreto, mira el recorrido con Claude Code o la página de Codex.