DockTouchBar · 14 · 两个版本合成一个：一份源码、一个 App、一条发布线

先查事实：它们真的是两个产品吗

合并之前先看了分支的实际差别。vibecoding 比 main 多 34 个提交，而 main 只比 vibecoding 多 1 个文档提交，也就是说 Vibe 是纯净版的超集，没有真正的分叉。两者的差别集中在几处：App 名称和包标识符、更新渠道的标签前缀、打包脚本里的文件名，以及 Agent 功能本身。

所以不需要编译开关，也不需要拆成两个目标。把身份还原成 DockTouchBar，Agent 状态保留，设置里本来就有一个总开关，不想用的人关掉就行。一个 App、一份源码、一个下载。

怎么合：身份还原，功能保留，再逐个合 PR

做法是在新分支上先把 main 合进来，再把 Info.plist、更新器、打包脚本这些身份文件整个还原成 main 的版本；去掉原来那段检测到纯净版在运行就退出的互斥检查；图标用了 Vibe 的那个，右下角带一杯冒烟的像素咖啡。

然后依次合入三个外部 PR。构建回退的那个我顺手去掉了一处把错误输出丢掉的写法，否则第一次构建失败时看不到真正的原因；隐藏程序坞图标的那个和 Agent 设置有四处冲突，都是两边各加一项，保留两边即可；强制退出的那个没有冲突，我只确认了 Finder 被排除在外。

合入别人的翻译文件之后要查一件事：Swift 的字典字面量里有重复的 key，运行时会直接崩溃，编译却能过。所以合并多方翻译后专门扫了一遍重复 key。

踩到的坑：迁移代码放错了位置

老 Vibe 用户的数据在一个叫 DockTouchBarVibe 的目录里，已经配对的智能体的 hook 脚本也指向那里。为了不让他们重新配对，我加了一段迁移：启动时把旧目录搬到 DockTouchBar，在原位置留一个符号链接。

第一版把这段代码放在了启动监听之后。监听启动时会先建好新目录和 socket 文件，迁移里又有一行清理旧 socket 的代码，于是把刚建好的 socket 删掉了。现象很迷惑：进程明明在跑，配对脚本的自检却说 App 没运行。编译通过，自动测试也通过，是我在本机安装后跑自检才发现的。

修法有两处：迁移必须在建立监听之前执行；并且不要碰任何 socket 文件，旧 socket 本来就不需要迁移。复测时我把数据目录改回旧名字模拟老用户，再装新版，迁移完成、自检返回正常。这类问题提醒我：涉及启动顺序的改动，必须真的启动一次、走一遍外部入口，不能只看编译和单元测试。

让贡献可见：关于页和 README 里的致谢

这次合并的价值，很大一部分来自外部的人。隐藏程序坞图标、Option 强制退出、构建回退，还有此前一位贡献者改进的智能体配对诊断，都是他们写的；另外几位的 issue 促成了避让系统控件可以关闭。我把他们的 GitHub 账号和具体贡献写进了 README 的 Thanks 表，同时放进 App 的关于页，名单只在 AppInfo 里维护一处。

这也定下了今后的规则：只有 main 一条长期分支，所有 PR 都提到 main，旧的 vibecoding 分支改名为 archive/vibecoding，只读保留。

后来：1.25 补上了两条用户建议

合并后第一个回头处理的是 issue #2 里一位用户的两条建议：图标能不能靠右，因为打字时按 Esc 容易误碰最左边的图标；Dock 因按 Fn 让位之后，能不能过几秒自己回来。靠右做成了图标位置三选一（靠左、居中、靠右），旧的居中开关自动对应，老用户的设置不变。

自动恢复没有照字面做成“让位几秒后就回来”，因为用户真的按住 Fn 看功能键时，Dock 提前回来会盖住它们。我改成每隔几秒重读一次按键和截图任务的真实状态：确实结束了才恢复，Fn 还按着就不恢复；只在让位期间才开定时器，平时不轮询，空闲唤醒仍然是 0。

这里有一件没法自己验证的事：用户说按一下左 Command 就能恢复，我推断是松开 Fn 的事件没有送到全局监听，但无法在没有实体键盘操作的情况下复现，是用户实机测过才确认可用。

验证：做了什么，没做什么

做了的：release 构建通过；智能体配对的自检脚本全部通过；窗口居中和最大化的回归脚本里 Finder 和 Chrome 通过；本机用安装脚本装上后实际运行，数据迁移和自检正常。

没做的：Touch Bar 上的手感，包括隐藏程序坞图标、Option 强制退出、智能体动画，需要我在实体 Touch Bar 上自己试；Intel 机器仍然没有实机测过。