Registrar resultados: estados, evidencia y record.py

Cada intento en un directorio termina con un comando. scripts/record.py escribe una única fila actual por plataforma en submissions.json, dentro de la carpeta del producto, y rechaza las filas que el kit considera sin probar o inseguras. Esa negativa es todo el sentido: el tracker es lo que impide que «enviamos a 40 directorios» signifique «rellenamos 40 formularios y cruzamos los dedos». Esta guía cubre los estados, la evidencia que necesita cada uno, los flags del comando y qué puede ir y qué no en una nota. Es un resumen de RUNBOOK.md y de las comprobaciones del propio script, no un sustituto.

El comando

El ejemplo del runbook, desde el directorio del kit y con una carpeta privada de proyecto ya creada:

En Windows, usa py -3 en lugar de python3 en los comandos siguientes (o python si ejecuta Python 3.10 o superior). Guarda tu espacio de trabajo en una carpeta local privada fuera de OneDrive y otras carpetas sincronizadas. En PowerShell, escribe los ejemplos de shell multilínea en una sola línea y elimina los caracteres \ al final de cada línea.

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"

Dos argumentos posicionales (id de plataforma, estado) y dos opciones obligatorias (--note, --next-action). Los flags opcionales son --public-url, --confirmed-public, --launch-date y --replace. El id de plataforma debe ser un slug en minúsculas, el estado debe ser uno de los once de abajo, y el tracker termina con una explicación siempre que no se cumpla una regla. El formulario de registro del panel local llama a la misma función con las mismas reglas.

Los once estados y su evidencia mínima

La tabla del runbook, en resumen:

Estado	Qué tienes que haber observado
draft	Trabajo preparado; envío final no confirmado.
prepared_needs_human	Una acción concreta del propietario o un desafío (CAPTCHA, 2FA) bloquea el trabajo preparado.
submitted_pending_review	La plataforma recibió explícitamente el envío; la moderación sigue abierta.
queued	La plataforma confirma una posición en cola o un estado de lista de espera.
scheduled	La plataforma confirma una fecha de lanzamiento igual o posterior a la fecha mínima; la aprobación pendiente se queda en la nota.
live	Ficha pública verificada, sin etiqueta de pendiente; URL pública y --confirmed-public obligatorios.
already_listed	Ficha pública ya existente verificada; mismos requisitos que live.
blocked	Elegibilidad, capacidad de la cuenta o un dato obligatorio que falta impiden avanzar.
deferred_paid	La vía utilizable exige pago; no se compró nada.
not_a_fit	El producto no cumple los criterios de audiencia o de ficha.
unavailable	La vía o la plataforma no se pueden usar ahora mismo; anota el problema.

Las distinciones que más importan son borrador vs. enviado y pendiente vs. publicada. Una pantalla de agradecimiento no convierte una ficha en publicada. Una página a la que puedes acceder puede seguir pendiente de aprobación. Una casilla marcada de «distribuir también a nuestro socio» no significa que una segunda plataforma haya recibido nada. El resultado de cada plataforma se mantiene independiente para que los totales nunca se inflen.

Las reglas que aplica el script

• Los estados públicos necesitan prueba. live y already_listed exigen --public-url con una URL HTTPS revisada —sin query string, sin fragmento, sin rutas de cuenta, panel o login— y --confirmed-public, tu declaración de que has mirado la página.
• Programado necesita fecha. --launch-date YYYY-MM-DD es obligatorio y no puede ser anterior a earliest_launch_date en product.json; la guía sobre la fecha mínima de lanzamiento explica por qué.
• Las notas se mantienen limpias. Las notas y las siguientes acciones no pueden contener enlaces, direcciones de correo, pares tipo password= ni prefijos de token conocidos. El archivo del tracker está pensado para compartirse; la evidencia con URLs de cuenta va en almacenamiento privado.
• Una fila por plataforma. Si la plataforma ya tiene fila, el comando falla salvo que pases --replace, y solo después de inspeccionar tanto la fila existente como la plataforma. Reemplazar es intencionado, nunca un efecto secundario.
• Sin symlinks, escrituras atómicas, un archivo de bloqueo. Detalles aburridos, pero son la razón de que dos agentes escribiendo a la vez no corrompan el tracker.

Reanudar sin duplicados

Al empezar la siguiente sesión, lee el tracker antes de tocar ningún formulario. Prioriza los relevos humanos y los lanzamientos programados que toca verificar, y después los envíos pendientes cuya ventana de revisión declarada ya pasó. Si una plataforma no indica plazos de revisión, acuerda una fecha de seguimiento con el propietario en lugar de inventarla. Y nunca reenvíes para adelantar en una cola: recomprueba el registro existente. El tracker guarda el estado actual, no el historial; si necesitas una pista de auditoría, archiva aparte resúmenes de ejecución con los datos sensibles eliminados.

Para ejemplos de los estados en plataformas reales, lee el artículo sobre los estados de envío y la guía anterior sobre registrar sin contar dos veces; el vocabulario en sí está definido en estado de la ficha.