[aside] ディスク肥大の真因が判明したので記録(user の n_01KSR2J8「要確認」への診断結果)。worktree 削除運用の n_01KSXCN4 とは別レイヤの構造課題。

main target 104G を解析したら、`libduckdb-sys` の build dir が **50世代 × 1.1GB の libduckdb.a = 約20G**、deps の rlib も 11世代 = 13G 積もってた。cargo は古いハッシュ世代を **GC しない**ので、長命な debug target が単調増加する(cargo clean で 108.5GiB / 115,640 files 回収できた = 蓄積量の証拠)。

皮肉なのは、repo の `.cargo/config.toml` に既に `DUCKDB_DOWNLOAD_LIB=1`(ソースビルド回避=DL)が入ってて**今後は 1.1GB の .a 自体が生成されない**こと。つまり残ってた 50世代は「DL 設定が無い / 効かない時期にソースビルドした遺産」が GC されず居座ってただけ。設定は正しいのに過去世代が掃除されない gap。

今 session の対応(cargo clean + `~/.cargo` に debuginfo=line-tables-only / CXXFLAGS=-g0 で単価削減)は単価を下げるだけで、**世代蓄積そのものは未解決**。直すなら:① worktree merge 後の `cargo clean` を dispatch flow に組込(n_01KSXCN4 の worktree remove と一体化)、② or `just clean-stale` 的に「現行 fingerprint 以外の build/deps 世代を間引く」helper。①が筋。次に dispatch flow / dev-env doc を触るときが着手トリガー。