 wuguanganandClaude Opus 5
|
fe3febbfd2
|
feat: Stop 拦截注入 —— 收工时拿清单逼它逐条报证据
Stop 从「非阻塞、输出被忽略」改成阻塞式，有待验收项时输出
{"decision":"block","reason":<清单>} 让 Claude 不停下来，先逐条核对。
下一轮的 lastAssistantMessage 里的自查 JSON 被收回来，把 open 推到 claimed。
Stop 的超时阶梯和审批那条**完全分开**，方向也相反：
3s HookCoordinator / 5s hubctl / 10s settings.json，超时一律 = 不拦。
审批超时 = 拒绝（安全刹车）；这里超时 = 放行。写反的话 Hub 一出问题
所有会话就再也收不了工，比"少提醒一次验收"严重得多。实测 hook 本身
6-11ms，Hub 在不在都一样。
查出来三个真问题，都不是靠读代码发现的：
1. 服务端从不给 stop 回写应答。我改了 hubctl 让它等，却没动
HubSocketServer 里写死的 guard kind == .preToolUse —— 拦截一次都没生效
过，而且不报错、不超时、10ms 就返回，表现得和"清单里没有待办"
一模一样。端到端测了三轮才找到。修法不是补一个 if，是加
Kind.expectsDecision 让两边共用同一个判断。
这和上次「grep activeScreen() 漏了一个调用点」是同一类错误：
改了协议的一端，假设另一端会跟上。
2. SIGPIPE 会杀掉 Hub。服务端开始给 stop 回写之后，遇到不等应答就关连接
的客户端（旧版 hubctl、被 Ctrl-C 的 hook），那次 write 直接终止进程 ——
不是报错，是进程没了。测试崩在 signal 13 上才暴露。
先加了 per-socket 的 SO_NOSIGPIPE（看起来更讲究），结果没生效，
照样崩；改成进程级 signal(SIGPIPE, SIG_IGN) 才好。
更讲究的写法如果不生效，就只是更讲究的 bug。
3. stop 事件不能去重。缓存决策只有在决策是事件的纯函数时才成立，
而 stop 的结论取决于会变的上膛状态：同样内容的两条 stop，
一条在用户说话前、一条在之后，结论截然相反。实测被这个坑到过。
4. {"done":1} 被判成做完了。JSONSerialization 把数字 1 桥接成 NSNumber，
as? Bool 对它成立 —— 模型只要把 done 写成数字就能绕过"含糊按没做算"。
改用 CFBooleanGetTypeID 严格判定。
端到端实测（真实 hubctl 二进制）：未上膛不拦、上膛后拦下 13 条要点、
连着两次收工都放行、Hub 存活、自查回答（带散文和围栏）正确回收成
claimed 且 hasProof 仍为 false。
346 个测试。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-07 18:10:35 +08:00 |
|
|
|
b6d90cac2b
|
feat: 重写为原生 Swift 灵动岛，修掉通知跳转与主窗口数据链路 (#4)
删掉 Tauri 版（app/），全部重写为 SwiftUI + SwiftPM（HubKit/，8.2k 行源码 +
2k 行测试，131 个测试）。核心动机是旧版"点通知跳不到对应终端"——
根因是身份链路全程用会漂移的字符串：项目名 → tmux 窗口名 → pane_title →
AppleScript 子串匹配。实测 9 个 tmux 窗口只有 2 个能和 projects.yaml 对上，
其中一个窗口名是 `2.1.173`（tmux automatic-rename 把它改成了 claude 的版本号）。
主要变化
- 会话状态直接读 ~/.claude/sessions/<PID>.json（Claude Code 自己维护的权威源），
不再用 spinner 字符猜 busy；死进程的残留 json 用 kill(pid,0) 过滤
- 跳转改用 iTerm jobPid + 进程祖先链求交，全程只有整数 PID 和 UUID；
bg 会话不在任何终端里，单独用稳定 job 名兜底。实测 9/9 绑定成功
- hook 从 bash 换成 Swift 的 hubctl，走 Unix socket；Hook 没运行时立即放行
- 高风险操作在岛上审批，六重防误点；拒绝是超时和异常的默认值
- 主窗口：会话 / 项目 / 用量 / 审批日志 / 设置
修掉的真实缺陷（详见 HubKit/NOTES.md）
- 超时阶梯是反的：ApprovalCoordinator 和 hubctl 读超时都是 60s，同时到期时
hubctl 按 fail-open 放行了一条已被服务端判定拒绝的 git push --force origin main。
改成 60/65/75/90 严格递增，并区分「连不上」（放行）与「连上但没应答」（拒绝）
- 点击全部被吞：app 是 .accessory + panel 是 .nonactivatingPanel，
NSHostingView.acceptsFirstMouse 默认 false，每次点击都算 first mouse 被丢弃
- hitTest 假设 NSHostingView 恒为 flipped，而 isFlipped 是 final 的可读写属性
- 形态切换靠替换 rootView，导致动画不可能发生且 @State 每次归零
- 全局 leftMouseDown 监听会收到点在自己身上的点击，展开态一点就收起
- hook 进程死后审批卡不消失，且会挡住后面的请求（按 clientPid 扫描清理）
- app 读的 projects.yaml 不是脚本维护的那份，且那份被写坏成
`projects: []` + 117 条内容，解析器静默返回 0 —— 三个页面因此全空
- 用量对 945MB/341 个 jsonl 整份读进内存，跑不完；改流式 + 增量缓存后
7 天首扫 3.6s、命中缓存 0.22s、全量 4s
- 辅助二进制放 Contents/MacOS/ 且共用 bundle id 会被 exec 瞬间 SIGKILL
- 同一 bundle id 对应多个 .app 让存活判断和 TCC 授权互相打架
刻意的取舍
- 放弃 Liquid Glass 做岛的基底：它会跟着背景亮度双向补偿，而刘海恒为纯黑，
两者物理上互斥。改用固定 86% 暗色基底 + 背景模糊 + 边缘高光
- 用 SwiftPM + 打包脚本而不是 .xcodeproj：手写 xcodeproj 的 XML 无法 review，
且 SwiftPM 保住了 swift test
Co-authored-by: wuguangan <anjaihd0206@gmail.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-07-29 19:20:12 +08:00 |
|