積み残しを機械で数えてから、A-1 から順に潰した一日

朝いちで、積み残しをリストにしてくれと頼んだ。 心当たりはいくつかあったが、数までは覚えていない。 覚えていないから聞いている、という状態だった。

返ってきたのは、scripts/scan-carryover.mjs に計画書555本を走査させ、Google タスクと git の実状を突き合わせたリストだった。 実作業10件、期限を過ぎた Google タスク4件、未解決の issue 24件。 そのうえで、最優先が3つだと添えてあった。

• ローカルと origin が分岐していて、pull がブロックされる
• 昨日の作業53ファイル（うち未追跡44）が丸ごと未コミットのまま残っている
• 本番の /search が壊れたまま放置されている

読んでいて一度だけ苦笑した。 この棚卸しの2段目は、まだ手で読んでいる。 /carryover コマンド本体は Phase 3 が未実装で、そのこと自体がリストの一行として並んでいた。 積み残しを数える道具が積み残しの中にある。

番号のついた3つを、別々のセッションに配る

リストには A-1、A-2、A-3 と番号が振ってあった。 おかげで、どのセッションにどれを渡すかがそのまま決まった。 A-1（分岐の解消）と A-2（未コミットのコミット）は同じ git を触るので1つのセッションにまとめ、A-3（/search の廃止）は別のセッションに投げた。

A-3 側には、origin の未 pull 2コミットが今回触るファイルと衝突しないかを着手の前に確かめさせた。 中身は記事と SVG だけだった。 それなら pull を待つ理由がないので、実装を先に進めさせて並行で走らせた。

git の分岐をどちらに寄せるか（A-1 と A-2）

計画では A-1 から A-2 の順だったが、実際には逆になった。 先に53ファイルを全部コミットして手元をゼロにし、そのあとでマージに入っている。 未コミットを抱えたままマージすると、後から出た差分がマージ由来か作業ツリー由来かを切り分けられなくなる。

寄せ方は、実測を見てから決めた。 origin 側のほうが新しいファイルもあり、memo は origin が完了状態まで進んでいた。 一方で図解の SVG は、ローカルの改稿版が新しい。 そこで「分割でやってください」と返し、ファイル単位で新しいほうを採る方針にした。 バイナリは含めてしまってよい、と決めた。 差分の読めないものだけ分けて後回しにしても、困るのは後日の自分だった。

差分を比べる途中で CRLF の疑いが出たので、改行を無視して比較し直させた。 Windows と Mac の2台運用をしていると、これは毎回踏む。

コミットは /commit に分割させた。 nuxt.config.ts には GA4 タグとプリレンダーの重複除去が同居していたので、prerender の分だけを部分ステージして切り出させた。 新しく入ったテスト28件はその場で走らせ、全部通ることを確かめた。 学習ゲートはスキップと指示した。 棚卸しのコミットに、設計意図を問う設問を挟む理由がない。

途中で2つ取りこぼしが出た。 issue のコミットメッセージに件数を実測せずに書いていたので、数え直させた。 未追跡もまだ5本残っていた。 最初の git status の出力が途中で切れていた分で、これは自分では気づきようがない。

53ファイルは10コミットに収まり、未コミットはゼロになった。 そこで A-1 のマージに入った。 衝突は3件だけで、図解と memo は同一内容だったので自動で解決した。 残りはローカル版を採った。 ahead 11 の状態でプッシュし、分岐は消えた。

手元をゼロにしてから寄せた効き目は、マージの直後に出た。 1ファイルが書き換わっているのを検出したので出所を確認させたところ、並行して走っていた別プロセスが記事を編集中だった。 作業ツリーが空でなければ、この書き換わりは自分の取り残しと区別がつかなかった。 その1本には手を付けずに残した。

/search の廃止と、404 経由のダンプ取得（A-3）

こちらは前日に計画書を作り、判断4件に回答済みだった。 症状は単純で、本番の /search を開くたびにブラウザが 11.3MB の SQL ダンプを落としていた。

入れた変更は4つ。

1. /search を /blog/ へ 301 で流す
2. catch-all の 404 でクライアント側の DB を組ませない
3. 壊れた localStorage を掃除するプラグインを足す
4. ビルド生成物から SQL ダンプを外す

判断が要ったのは2番目だった。 404 でクライアント DB を組ませなくすると、ディレクトリ一覧ページが本番で 404 になる。 このページは今、8.3MB のダンプ取得と引き換えに描画されていて、修正とは両立しない。 そこで、このページが dist に1本も静的生成されておらず、トップからも /blog からもリンクが張られていないことを実測させた。 /takken/zei/ のようなフィールド一覧も同じだった。 誰も辿り着けないページのために全訪問者へ 8MB を配るのは割に合わないので、そのまま落とすことにした。 代わりに CLAUDE.md へ導線を1行足させた。

掃除プラグインは、壊れた状態をブラウザに仕込んでからリロードさせ、実機で効くところまで見た。 ダンプは dist/dump.pages.sql にもう1本、11.35MB の同じものが残っていたので、それも外した。

デプロイが止まった場所

ビルドは通ったのに、postgenerate が最後まで走らなかった。 原因は今日書きかけの記事だった。 公開記事から非公開記事2本へリンクしていたため、公開前の検査が exit 1 で止まっていた。 /search の変更とは関係がない。 リンクを外す、とその場で決めて先に進めた。

デプロイは約16分の見込みが 23.4分かかった。 本番で測ると、404 ページの転送量は 8,312KB から 558KB になり、ダンプへのリクエストは0件になった。

ただ、エッジのキャッシュに古いダンプが残っていた。 Cloudflare にはログイン済みだったので、そのままブラウザ操作で消させた。 サイト全体の Purge Everything ではなく、当該 URL だけの Custom Purge にした。 関係のないページまで巻き込んでキャッシュを捨てる理由がない。

これが効かなかった。 パージは送信され、ダイアログも正常に閉じたのに、2分待っても 200 で 11.3MB が返り続けた。 ?cb= を付けると 404 になるので、オリジンからは消えている。 cf-cache-status が DYNAMIC だったため、ゾーンのキャッシュではなく Pages 側のレイヤーが返している可能性が高い、という見立てになった。 放置しても約6日で失効する。 次のデプロイで消えるかを見ることにして、その日は追わなかった。

朝のリストが作れた理由

別の作業の途中で、進捗をドキュメントに残しておいてほしいと言った。 今日いちばん効いた一言は、たぶんこれだった。

A-3 でも、実装が終わった時点で計画書の状態ブロックと実装ログを更新させた。 デプロイ時間を調べたメモには、10:14 の実測を突き合わせて追記させた。 プリレンダーの対象は 9,810 から 7,729 ルートへ減り、差は 2,081 だった。 重複除去が効いているという裏が、これで取れた。

朝のリストが機械で作れたのは、前日までの計画書に状態ブロックが書いてあったからだった。 書いていなければ、555本の計画書を人間が読む羽目になっていた。 今日追記した分は、明日の朝のリストの材料になる。

最後に、A-3 側の変更をコミット4本に分けてプッシュした。 デプロイはそこで止めた。 _local-unpublished/ と raw ログは gitignore の対象なので、コミットには入っていない。

残ったもの

• エッジキャッシュの古いダンプ。次のデプロイで消えるかを確認する
• 別プロセスが編集中だった記事1本。手を付けずに残した
• /carryover コマンドの Phase 3。棚卸しの2段目は、まだ手作業のまま