到了 2026 年 10 月中旬，我手头自己长线维护的几款主力工具——硬件监控**「观澜」（guanlan.igng.net）、AI 账单与额度监控「计然」**（jiran.igng.net）、待办工具 TaskDock（taskdock.igng.net）、OpenCode 移动端 Lagoon（lagoon.igng.net）以及鸿枢——都已经迭代得有模有样了。为了让它们各自有个体面的门面，也为了统一它们的客户端更新机制，我在 10 月中下旬做了一次大刀阔斧的工程化收口。

5 个独立官网上线，两周后全数并回主仓库

10 月 13 日那天，我一口气新建了 5 个独立的 *-website 仓库，按每款软件的性格专门设计了完全不同的主题官网并部署到 Cloudflare Pages：

  • 观澜做成了硬核的“数字观测站”风格；
  • 计然以中国古计时器“刻漏（点滴有数）”为主题，还专门做了中文字体子集化压缩；
  • TaskDock 主打干脆利落的“任务归位”；
  • Lagoon 则设计成深海质感的“一次下潜”。

好看是真好看，但维护了不到两周我就发现了一个蠢问题：我这几款软件几乎每天都在发新版，每次主仓库打完 Release，我还得专门切到对应的 *-website 仓库去改官网上的版本号和下载链接，稍微忘一次两边就对不上了。

于是在 2026 年 10 月 25 日 当天，我果断把这 5 个官网的代码全部迁入各自产品主仓库的 website/ 目录下，配置成随主仓 Release 自动触发构建与发布，并把那 5 个独立官网仓库全部归档设为只读（Archived）。源码和官网同处一仓，发版即同步，彻底治好了版本号漂移。

统一 updates.json 静态更新源与双通道切换

紧接着在第二天（10 月 26 日），我又把所有软件的客户端检查更新链路统一了一遍：在每个产品主仓库里建立专门的 GitHub updates 分支，由 CI 发版时自动生成并提交 updates/updates.json 静态更新索引，同时支持**稳定版（stable）与预览版（preview）**双通道切换。

现在不管是观澜、计然还是 TaskDock、Lagoon，客户端检查更新时直接拉取静态 raw 源并配合 ETag 缓存比对，再也不需要依赖自建中枢的更新接口，也彻底避开了直接调 GitHub Releases API 时动不动就撞上的每小时 60 次匿名限流。