Comparing changes

只改 CHANGELOG.md / main/Cargo.toml / Cargo.lock 的发布 PR 此前仍要跑 macOS / Linux / Windows 三平台全量测试（Windows job 约 25 分钟），而改动里没有任何代码，这些测试没有意义。 - ci.yml 新增 classify job：PR 场景下用 script/release_pr.py 判定是否只包含发布改动，是则跳过 test 与 windows-rdp-probe，改为就地校验发布元数据 - script/release_pr.py：分类规则为「改动文件全部属于发布白名单」且「Cargo.toml / Cargo.lock 的差异只有 version = "..." 行」；命中后校验 main/Cargo.toml 与 Cargo.lock 中 main 包版本一致，且该版本的双语 changelog 条目完整（更新内容/修复与优化 + What's New/Fixes and Improvements，含 CNB 镜像行）；无法算出 diff 时回退到全量测试 - ci-gate 仍是唯一必需状态检查，分类或校验失败都会拦住合并 - .github/RELEASE.md 记录该快速通道 - windows_rdp_host 契约测试钉住 classify/needs/if 结构与脚本白名单验证： - python3 -m unittest discover -s script/tests -p "test_release_pr.py" — 16 passed - cargo test -p windows_rdp_host --test contract — 40 passed - ruby -ryaml 解析 ci.yml，核对 classify/test/windows-rdp-probe/ci-gate 的 needs 与 if 表达式 - rustfmt --edition 2024 --check crates/windows_rdp_host/tests/contract.rs

ci: 发布 PR 只跑发布元数据校验，跳过全平台测试

`NSApplication::activate()` 是 macOS 14 才引入的选择器（Apple《AppKit Release Notes for macOS 14》：`activate(ignoringOtherApps:)` 在 14 废弃，同时新增 `activate`），而 `Info.plist` 声明的最低支持版本是 macOS 12.0。旧系统上该选择器不存在，消息转发失败（`doesNotRecognizeSelector:`）→ `std::terminate` → SIGABRT。 - 崩溃报告：x86_64 / macOS 12.7.6（MacBookPro11,4）/ navop 0.18.3；未捕获 ObjC 异常 `EXC_CRASH (SIGABRT)`，帧序 `__exceptionPreprocess` → `objc_exception_throw` → `___forwarding___` → `_CF_forwarding_prep_0` - 必现路径：SSH 终端窗口最小化到托盘后恢复主窗口 - 修复：`activate_app` 用 `respondsToSelector(sel!(activate))` 运行时按系统版本分派，命中走 `activate()`，否则回退 `activateIgnoringOtherApps:`；回退收进 `activate_legacy` 并 `#[allow(deprecated)]`，两条路径各自都在原生支持的系统上 - 新增源码级守卫测试：禁止调用方绕过 helper 直接调新选择器，也禁止删掉旧系统回退 - 影响面仅 `main/src/window_visibility.rs`；gpui 的 `activate_window()` 只做 `makeKeyAndOrderFront:`，无同类越线

Windows 单实例此前有三层叠加缺陷，任何一层单独存在都足以让「双击两次」得到两个 GUI： 1. 占用判定用错了错误码。claim_or_forward 按 io::ErrorKind::AddrInUse 判断「名称已被占用」，但 interprocess 首次建实例带 FILE_FLAG_FIRST_PIPE_INSTANCE，名称冲突时 OS 返回 ERROR_ACCESS_DENIED(5)，Rust std 把它映射为 PermissionDenied；而全 crate 唯一的 AddrInUse 处理在 Unix UDS 路径上。于是这个分支在 Windows 上永远不会命中，转发逻辑一次都没有被执行过。 2. 转发链路在 Windows 上不可用。接收端与发送端都调用 interprocess 的 set_recv_timeout / set_send_timeout，而它在 Windows 命名管道上恒返回 ErrorKind::Unsupported （"named pipes do not support I/O timeouts"）。这是被第 1 条挡住的潜伏缺陷，第 1 条一修就会立刻暴露出来。 3. 启动门禁把「建不了单实例」解释成「可以再开一个」：main.rs 只有转发成功才 return， Err 分支只记一条 warn 就继续初始化 GUI。本次按 tokio 命名管道重写 IPC 层，并收紧启动门禁与 ACK 语义： - 互斥只由 ServerOptions::first_pipe_instance(true) 提供，且只给首个实例；服务循环补建的实例一律不带该标志，否则会把自己也挡在门外。 - 占用与连接错误全部按原始 Win32 错误码分类：ERROR_ACCESS_DENIED(5) 表示名称已被占用；客户端可重试码为 2/5/231（231 在 std 里落到 Uncategorized，按 kind 判会漏掉）。 - 所有 I/O 用 tokio::time::timeout 加时间边界，每条连接独立 task：一个半开连接不会拖住后续启动请求。接受循环先补建下一个实例、再移交当前连接，名称不会出现无主窗口；循环异常退出时保持名称被占用并停驻（fail-closed）——宁可让后续启动转发失败后明确报错退出，也不允许第二个 GUI 进来。 - ACK 收紧为「启动请求已入队」：入队失败回 [0]，不再假成功。 - 门禁区分「转发失败」与「监听失败」并给出各自的提示文案，Err 一律提示后 exit(1)。 release 是 windows_subsystem = "windows"、没有控制台，用户看不到 eprintln，提示走 MessageBoxW。 - 顺带修掉一个空转断言：windows_single_instance_gate_precedes_application_creation 里 assert!(!source.contains("continuing startup")) 的字面量本身就在 include_str! 的范围内，会自己满足自己。现在断言只看 production_source()（截掉测试模块的生产代码），并补上 exit(1) 与提示函数的断言。依赖侧：main 不再使用 interprocess，从 main 的依赖表中摘除（工作区声明保留，因为 extension-driver 与 extension-host 仍在使用，Cargo.lock 相应少一行）。tokio 增加 io-util / net 两个 feature，二者已由 public_mcp、sftp 启用，不引入重编。验证： - cargo test --offline：9 passed。测试放在一个独立 crate 里，用 #[path] 直接引用 main/src/windows_single_instance.rs 本体（不是副本），依赖按 Cargo.lock 精确版本锁定。其中 5 个是真实 Windows 命名管道传输测试：转发成功且主实例确实收到请求、入队失败时 ACK 必须为拒绝、半个请求超时断开且不阻塞后续请求、4 线程并发抢占只有 1 个取得主实例资格、不同配置目录各自独立。 - cargo clippy --offline --all-targets -- -D warnings：0 warning。 - rustfmt --edition 2024：windows_single_instance.rs 无格式差异，main.rs 新增片段无差异。 - 原始故障的真机探针复现：第 2 次 create_sync 返回 PermissionDenied(raw 5)、 kind() == AddrInUse 命中为 false、set_recv_timeout 返回 Unsupported。 - 未验证：main crate 本体的编译，以及真机双击验收（第二次启动只唤起已有窗口）。原因：依赖图含 git 依赖 quickjs-jit，其 rev 需联网获取，而本地构建缓存被清空后正在做全量编译，尚未跑完；托管 CI 在 Windows 平台会编译 main 本体，可作为该缺口的补充验证。

fix(tray): 托盘恢复主窗口按系统版本选择激活选择器，修复 macOS 13 及更早系统崩溃

解决与 PR #228（feat(tray): 关闭按钮询问「最小化到托盘 / 退出应用」，并修复 Windows 重复启动）的冲突，让本 PR 重新可合。 - main/src/windows_single_instance.rs：采用 PR 侧重写（SingleInstanceError 枚举、 worker + 决策通道、Claim/ForwardAttempt、create_pipe_instance）。main 侧 bd34cc4 新增的 instance_name_taken 语义已由 PR 的 is_name_in_use（Windows 专用，认 ERROR_ACCESS_DENIED=5）与 is_connect_retryable（认 2/231/5）覆盖；其被自动合并保留在非冲突区的定义一并删除，否则留下 3 个 dead_code 警告 - Cargo.lock：按合并后的 Cargo.toml 由 cargo 同步（保留 main 侧新增依赖，去掉 PR 已移除的 interprocess） - main/src/main.rs、main/Cargo.toml：自动合并无冲突验证：cargo check -p main --all-targets（0 警告）、cargo test -p main --bin navop （634 passed, 0 failed）。Windows 侧属 CI 覆盖范围（本机无 MSVC 工具链，跨编译在 libz-sys 处止步）。

…orwarding fix(single-instance): 修复 Windows 重复启动会开出第二个窗口

- CHANGELOG.md：新增 v0.18.4 双语条目（macOS 托盘恢复窗口崩溃、Windows 重复启动） - main/Cargo.toml、Cargo.lock：版本 0.18.3 -> 0.18.4

chore(release): 发布 v0.18.4（macOS 托盘恢复崩溃 + Windows 重复启动）

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Sep 19, 2026

This comparison is taking too long to generate.

Uh oh!