post-launch
La vigilancia. Se ejecuta en el momento en que DNS se ha movido, y luego una vez al día durante treinta días. Reporta; nunca bloquea, nunca corrige, nunca anuncia nada.
La única regla
Los bloqueadores se leen primero y se anuncian al final. Nada sobre un lanzamiento se anuncia — sin correo electrónico, sin publicación, sin llamada al cliente — hasta que este informe regrese limpio. Un anuncio es el único paso de un lanzamiento que no se puede revertir, y los dos bloqueadores aquí son exactamente los dos estados en los que el lanzamiento no ha ocurrido realmente: un certificado que nadie puede pasar, y un noindex que le dice a los motores de búsqueda que olviden el sitio. Ambos se ven bien en un navegador en el que ya has iniciado sesión.
Si alguien te pide que anuncies mientras un bloqueador está presente, di claramente cuál es el bloqueador y qué cuesta, y no lo suavices.
Solo lectura
La habilidad es de solo lectura. Obtiene el sitio en vivo, el host de staging, el host anterior y las URLs en el mapa de redirecciones, y pregunta a cuatro resolvedores de DNS públicos hacia dónde apunta el dominio. Escribe exactamente dos cosas, ambas son registro del propio operador: el paquete de informe, y watch.json dentro de él. Nunca edita un sitio, envía un formulario, cambia una configuración, llama a una API de proveedor o toca DNS.
Tres reglas siguen, y las reafirmas cuando reportas:
- Evidencia para cada hallazgo. Una URL, un estado, un encabezado, una respuesta DNS, una línea CSV.
- Una omisión no es un aprobado. Cada entrada que no proporcionaste se convierte en una línea nombrada en No cubierto.
No cubiertonunca es un aprobado. Repites esa sección al humano textualmente.
Los dos modos
| Modo | Cuándo | Qué responde |
|---|---|---|
--mode cutover | en el momento en que DNS se ha movido, y después de cualquier corrección | si el lanzamiento realmente ocurrió |
--mode watch | una vez al día, días 1–30 | qué vence hoy, y si algo se ha desviado |
Ejecuta cutover primero, corrige lo que encuentre, ejecútalo de nuevo hasta que esté limpio, luego anuncia. Inicia la vigilancia el mismo día.
1. Reúne las entradas
Cada entrada que omitas se convierte en una verificación que no puede ejecutarse. Pide cada una; no adivines.
- La URL de producción. Obligatoria.
baseline.json— del paquetepre-launch, o de una ejecución delaunch-auditcontra staging antes del cambio. Esto es contra lo que se mide "si algo cambió". Sin él, cuatro verificaciones no tienen nada con qué comparar y una quinta retrocede a--expect-analytics. Todas lo dicen.redirects.csv— del paquetelaunch-auditconstruido con--old-url. Cada fila se vuelve a solicitar en la URL con la que fue escrita.- La URL del sitio antiguo, si uno está siendo reemplazado.
- La URL de staging, para que la ejecución pueda confirmar que la copia de staging ahora está sellada.
- El ID de medición de analíticas, para cuando no hay línea base.
- Los registros DNS que se suponía debían estar en su lugar, como valores
apex=ywww=.
Si no tienes la línea base o el mapa de redirecciones, dilo antes de ejecutar en lugar de después: provienen de las dos fases anteriores, y después del cambio ninguno puede recrearse.
2. Ejecuta la verificación de cambio
Ejecuta el script; nunca leas su fuente, y nunca reimplementes lo que hace.
node scripts/post-launch.mjs --mode cutover --url <URL de producción> \
--baseline <ruta a baseline.json> --redirects <ruta a redirects.csv> \
--old-url <URL del sitio antiguo> --staging-url <URL de staging> \
--expect-analytics <ID de medición> --expect-dns apex=<ip>,www=<host> --out <directorio>
La ruta es relativa al directorio propio de esta habilidad — ejecuta el comando desde allí. El paquete se escribe bajo el directorio de trabajo actual: sin --out aterriza en ./website-launch/<host>-post-launch-<fecha>/, que con el comando de arriba significa dentro del directorio propio de esta habilidad. Escribe el paquete donde sea que esté el trabajo con --out.
Otras banderas: --dev-host <host> (repetible), --browser auto|on|off, --out <directorio>, --config <ruta>, --json, --help.
Códigos de salida: 0 siempre, por muy malo que sea el cambio. 2 para un error de uso o una falla de E/S. Salir con 0 nunca significa "el lanzamiento está bien" — esto reporta, no bloquea. Lee el informe.
3. Lee el informe en este orden
references/reading-the-report.md tiene la estructura del paquete. references/cutover-day.md explica por qué el día se ejecuta en el orden que lo hace — léelo antes de empezar a arreglar cosas fuera de orden.
- Los bloqueadores. Impresos en negrita, primero, sea cual sea el paso del día del que provengan. Arregla estos antes que cualquier otra cosa y antes de que a nadie se le diga que el sitio está en vivo.
- Los hallazgos altos. Desviación de redirecciones, una página faltante, un endpoint de formulario muerto, una copia de staging en vivo, el host anterior aún sirviendo — cada uno de estos es algo que está perdiendo tráfico o consultas ahora mismo. Son el trabajo de hoy, no de esta semana.
- La diferencia de línea base.
references/baseline-diff.mddice qué campos se espera que se muevan en un lanzamiento y cuáles nunca. No reportes toda la diferencia como daño; reporta las partes que nadie pidió. - Medio e información. Léelos. Di lo que son. No los arregles hoy.
- No cubierto, textualmente. Cada línea, sin editar, incluyendo las dos cosas que ningún rastreo puede ver.
Luego, vuelve a ejecutar, y sigue ejecutando hasta que los bloqueadores desaparezcan.
4. Trabaja los seis elementos humanos
Se imprimen al final de cada ejecución y no son opcionales:
enviar el sitemap (Search Console y Bing) · solicitar indexación para las páginas principales
confirmar la nueva propiedad de Search Console · verificar analíticas en tiempo real
mantener el host anterior activo y redirigiendo · anunciar solo después de que esto esté limpio
Nunca marques uno como hecho en nombre de alguien más. "El endpoint devolvió 200" no es "una persona recibió el envío de prueba", y "la etiqueta está en el HTML" no es "una visita apareció en tiempo real".
5. Ejecuta la vigilancia, a diario
node scripts/post-launch.mjs --mode watch --url <URL de producción> --day <n>
Imprime qué está vencido, qué vence hoy y qué viene en los próximos siete días, luego vuelve a ejecutar la parte automatizada y registra la ejecución. references/thirty-day-watch.md tiene el cronograma completo, qué mirar en Search Console y analíticas cada día, y cómo se ve "saludable" para que una caída normal posterior al lanzamiento no se reporte como un desastre.
Deja --day fuera y cuenta desde la primera ejecución. Un día que la vigilancia nunca ejecutó permanece vencido para las tareas automatizadas hasta que una ejecución lo cubra; una tarea humana permanece vencida hasta que un humano la resuelva, porque nada que haga un script es evidencia de que alguien abrió Search Console.
6. Día 30
Dos cosas, y ninguna está automatizada:
- La retrospectiva. Qué retrocedió, qué omitió el mapa de redirecciones, y qué agregar a la compuerta
pre-launchpara que el próximo lanzamiento no lo repita. Escríbelo. - La decisión del host anterior. El host anterior puede ser descomisionado solo una vez que Search Console no muestre rastreo de URLs antiguas y las redirecciones hayan estado en su lugar durante al menos treinta días. Hasta que ambas sean ciertas, sigue pagando por ello. Apagarlo temprano tira todos los enlaces que el sitio antiguo ganó.
7. Presenta el resultado
Lidera con la decisión, no con un conteo.
- El veredicto. "El cambio tiene un bloqueador" o "El cambio está limpio." Una oración.
- Qué lo bloquea, con la corrección nombrada.
- Qué está sangrando, agrupado por causa: los hallazgos altos, en lenguaje sencillo.
- Qué cambió contra la línea base que nadie pidió.
- No cubierto, textualmente.
- Los elementos humanos, con qué está hecho y qué no.
- Si el lanzamiento puede ser anunciado. Dilo explícitamente, de una forma u otra.
Las dos verificaciones que nunca se ejecutan
- Copia vs. documentos fuente. Nada compara las palabras en las páginas en vivo contra la copia aprobada. Una persona tiene que leer ambas.
- Páginas vs. alcance acordado. Nada sabe qué páginas se suponía que debían existir. Una página que nunca se construyó es invisible aquí.
Referencias
| Archivo | Cubre |
|---|---|
references/cutover-day.md | El script del día ordenado, y por qué cada paso está donde está |
references/thirty-day-watch.md | El cronograma, qué leer en Search Console y analíticas, cómo se ve saludable, la regla del host anterior |
references/baseline-diff.md | Cada campo de diferencia, qué cambios se esperan en un lanzamiento y cuáles no |
references/reading-the-report.md | El paquete, las severidades, los IDs, cómo triage |
Dónde se ubica esto
pre-launch controla el repositorio antes del despliegue y bloquea. launch-audit rastrea una URL de staging o en vivo y reporta. post-launch es este: el cambio y los treinta días posteriores. Ejecútalos en ese orden — la línea base y el mapa de redirecciones que esta habilidad necesita solo pueden ser creados por los dos primeros, y solo mientras el sitio antiguo aún esté en pie.