Release v0.3.0 · Xsxdot/handoff

0.3.0 正式版。 这一版的主线是桌面端：Windows 与 macOS 各有一份原生薄壳，
把控制台、首次配置、以及本机 agentd/CLI 的版本同步收进一个双击就能用的入口。
从 v0.2.3 升级无需改配置。

桌面端（Windows .exe / macOS .dmg）。 托盘常驻，双击进控制台，首次运行
带三步配置向导。macOS 版已签名并公证。
桌面端启动时会把本机的 agentd/CLI 同步到与自己同版。 此前只有第一次运行会
释出内嵌的 CLI，之后换一份新的桌面端不会带动它——纯桌面端用户的 agentd 会一直
停在旧版且收不到任何信号。本机有活跃任务时自动跳过本次同步，不打断在跑的活。
托盘「有新版 vX.Y.Z 可下载」，点击打开 release 页面；与 CLI 侧共用同一份
24 小时缓存。
托盘「升级执行机…」：打开一个面板跑 handoff upgrade --now，逐行显示巡检表。
proxy 配置项：给 handoff 自身出网配代理，支持 http / https / socks5 /
socks5h。作用于更新链路与 agentd 的 git clone/fetch；不作用于协调者↔agentd
链路与 executor（后者仍走 env 段）。空值时行为不变（沿用 HTTPS_PROXY 等环境变量）。
handoff upgrade --push：强制由本机下载并推送二进制。

handoff upgrade --now 默认改为让执行机自己下载：协调者只下发 tag 与 sha256。
一次多机升级的跨机流量从每台 20MB 降到几十字节。对端 agentd 过旧时自动降级为
推送，无需干预。
/api/update 新增 mode 查询参数（pull / push）。省略时行为与此前一字不变。
/api/status 的 update 段新增 pull（能力位）与 pull_state（自拉进度与失败原文）。
macOS 薄壳的资产从 .zip 换成 .dmg。

macOS 桌面端打开控制台停在「需要登录」。 会话 cookie 是 SameSite=Strict，
而薄壳加载控制台走的是程序发起的顶层导航、没有同站发起方，WebKit 会把这类
cookie 扣下不发——症状是 ticket 兑换成功、紧跟的跳转却报「无凭据」。已降为 Lax：
只对顶层 GET 导航放行，写操作走 POST/DELETE，跨站一样带不上。Chromium
（Chrome / Windows 的 WebView2）不受影响，所以这个问题只在 macOS 出现。
版本比较认预发布号了（v0.3.0-rc8 < v0.3.0-rc11 < v0.3.0）。此前本仓库发的
每一个 rc 对比较器都是不可比的，后果是 rc 构建上的同步与更新提示一律失效。
.app 的版本号不再写死成 0.1.0，改为随 tag 注入。
go install 装出来的二进制不再自称 unknown，改为回落到模块版本。此前
upgrade --check 会陷入「劝你升级 → 升完仍是 unknown → 继续劝」的死循环。
Windows：双击薄壳进程在约 1 秒后无声消失；service status 长期误报「已安装但
未运行」；spawn 子进程时闪控制台窗口。
macOS：.app 图标发灰、字形偏小、带投影。

agentd 的版本被你手上这份安装包钉住。 桌面端只把本机同步到与自己同版，要升到
更新的版本得换安装包——托盘的「有新版可下载」就是这个提醒。
已装 CLI 的版本号不是 vX.Y.Z 形态时同步不触发（例如自行 go build 的开发
构建）。这是刻意的保守行为：判不出新旧就不覆盖你手上的东西。

Navigation Menu