図解カタログをB案でmasterへ統合した日。カテゴリA11型と、消えていた原典の顛末
朝の積み残しは、11項目のうち5番目で止まっていた計画書だった。 「85%で寝るパレート図」という、自分がどこかに書き残したはずのメモが手がかりになる。 過去に描いたその図を探し出し、習熟の逓減を今の図解に接続できるかを判断する。 それが今日の最初の仕事だった。
「85%」という思い込みが検索を空振りさせる
リポジトリの中を検索させると、パレート図はすぐに2つ見つかった。 ただし、どちらも探し物ではない。 一つは海外のタイムマネジメント本にある80/20、もう一つは投資の累積効果を示した図だった。 記憶にある「85%」とは違う。
リポジトリの中で見つからないなら、Gitの履歴とセッションログに検索範囲を広げさせた。 やり取りの途中で、API Error: Connection refused が二度続けて出た。 「これなんでなん？」とそのまま聞き返した。 ネットワーク層が一時的に切れていただけで、探索の中身とは無関係だった。 すぐに復帰したので、探索を再開させた。
Fドライブに展開済みのバックアップフォルダが残っていたのを思い出し、古いセッションログの検索先に加えさせた。
USBメモリからの全文検索は、検索ツール1回あたり20秒という上限を超える見込みだったので、バックグラウンドで走らせておいた。
自分が当時眺めていた /svg-gallery のスライド番号（#slide1=678 と =991）も手がかりにして、ギャラリーの並び順を洗わせた。
別プロジェクト側にBefore/Afterらしき候補も見つかったが、これも違った。
たどれる経路をすべて潰したところで、いったん結論を出した。 図の実体は存在しない。 計画書にそう書いて、判断が必要な地点として一度立ち止まった。
原典は、数値もリポジトリも違う場所にあった
figure-02として自分で描き直す方針に切り替え、既存図の設計とSVGのルールを確認しにいった。
svg-diagram スキルの追加リファレンスを読み込んだところで、探していた原典がようやく姿を見せた。
覚えていた「85%」は、実際には80%だった。 そして図は、このリポジトリの外にあった。 記憶の数値でいくらグレップしても一致しないのは当然で、リポジトリの外にある以上、リポジトリの中をいくら掘っても出てくるはずがなかった。 数値の思い込みと置き場所の思い込みが重なって、二重に的を外していたことになる。
原典のファイルには手を入れず、そのまま保存した。
この原典自体が努力の限界効用逓減をテーマにした図だったので、習熟の逓減を接続するかという判断は、この一枚を土台に据えることでそのまま答えが出た。
描き直しは別工程として、svg-diagramの規律に載せたfigure-02で改めて起こす。
計画書の「図は存在しない」という結論を訂正し、次のセッションへの引き継ぎドキュメントも作らせた。
潰した経路（リポジトリ、セッションログ、別プロジェクト、note、Artifact）は無駄ではなく、「ここには無い」という確認の記録として残る。
前日に決めていたB案、まだmasterには無かった
原典探しに区切りをつけたところで、もう一つの持ち越しに移った。
図解60型カタログでは、SVGにフレーム（タイトル、リード、区切り線、出典）を持たせるか、Vue側に持たせるかを、前日に複数案で比較させていた。
トークンを1つ変えたときに触るファイル数は、SVG側に持たせるA案で28、Vue側に持たせるB案で1になる。
27系SVGは記事から一度も参照されていないことも実測済みで、B案唯一の弱点（SVG単体で開くとタイトルが出ない）を、今のところ誰も使っていないことになる。
推奨はB案で決まっていたが、実装はローカルのworktree（../mdx-cat-b、ブランチexp/frame-b）に置いたままで、masterには1行も入っていなかった。
ローカルにしか無い11型を、先に逃がす
worktreeの中には、カテゴリAの11型ぶんの実装が積み上がっていた。
そのうち2コミットはoriginにも上がっていない。
ディスク障害でも、worktreeの誤削除でも、git worktree pruneの一発でも消える場所に、まとまった作業が置かれたままになっている。
一番先にやったのは、この状態を解消することだった。
git push origin exp/frame-bは、他の作業状況と無関係にいつでも実行できる。
実際、他のことを考えるより先にこれだけ済ませておいた。
masterでは並行して別セッションが動いていて、同じブランチに触れていた。
HEADのハッシュが数分おきに変わり続けていたが、これはcommit --amendによるものなので、ハッシュの比較だけでは作業が終わったかを判定できない。
向こうが終わっているかを直接尋ね、「ファイルを修正している感じではないので進めて大丈夫」という返事をもらってから、マージの作業に入らせた。
マージの詰まりどころ
作業を止めてから改めて測り直すと、対象は想定していた4ファイルではなく6ファイルになっていた。
git merge-baseでfrom-bとmasterの分岐点を出し、frame-b側が実際に変更したファイル一覧と、作業ツリーに残っている未コミットファイルの一覧を突き合わせて、衝突候補だけを機械的に絞り込ませた。
このリポジトリのpre-commitフックは学習ゲートを兼ねているが、マージの自動コミットには効かない設定になっている（pre-merge-commitが用意されていないため）。
そのままマージを確定させず、--no-commitでいったん止めてから、明示的にgit commitを打つ形にした。
マージ自体はgit merge-treeの時点で衝突なしと確認済みだったので、手作業の解消は要らなかった。
ただし、口頭で伝えていた説明のうち2点が誤りだった。
一つは「方向を誤るとmasterの既存ドキュメントが3本消える」という懸念で、git diffの出力をそのまま読んだ誤読だと分かった。
通常のマージでは起きない。
もう一つは、ある未追跡ファイルを「3つ目の版で73行の差分がある」と見ていたことで、実際は共有のベースコミットとバイト単位で一致していた。
未追跡ファイルをgit diffにかけると全行が差分として出てしまうため、67行のファイルが73行の差分に見えていた。
マージを終えて/diagram-catalogを確認しにいくと、最初の一回だけ10秒のタイムアウトでリクエストが切れた。
ポート3000はlistenしているのに応答が返らない。
一瞬マージ由来の不具合を疑ったが、Chrome DevTools MCPで60秒の猶予を与えて開き直すと、14.4秒で普通に表示された。
続けて詳細ページへ遷移すると1.3秒で返り、コンソールにもエラーは出ていなかった。
マージ直後の再コンパイルが長引いていただけで、直すべき不具合ではなかった。
最終的なマージコミットは24ファイル、2,279行の追加と943行の削除になった。
フレームを担うSlideFrame.vueとsvgBody.ts、意味グリッドのslideChromeGrid.tsが新規に加わり、テストも2本増えている。
残ったもの
- 「85%」ではなく「80%」が正しい数値で、図はこのリポジトリの外にあったと分かった
- 原典を保存し、描き直しはfigure-02として次工程に回した
- フレーム分離のB案とカテゴリA11型が、worktreeからmasterへ移った
- カテゴリB以降49型の展開は、まだ手つかずのまま残っている
記憶にある数値をそのまま検索条件にすると、数値が一つ違うだけで的が外れ続ける。 今日はそれを実地で確認した1日だった。 ローカルの作業も、pushするまでは存在しないのと同じ扱いにしたほうがいい。