[1lck]

第二轮【搜索与可见性】车道，对应 #1662 的 WS-03、WS-04。

WS-03 Quick Open 名称匹配与评分（完成，两端接好、旧实现已删）

• 新增 Core API workspace.rankNames（rust/lithe-core/src/project/name_ranking.rs）：纯函数，输入候选名（{name, path?}）、查询和显式上下文（openPaths、按最近到最远排序的 recentPaths），输出 matches: [{index, degree, tier, nameMatchRanges}]。与 workspace.searchEverywhere 共用同一个匹配器，所以 DH 能命中 DeviceHandler.java；名称没命中时用路径做更弱的匹配；排序依次是分数、open/recent/other 分层、最近访问顺序、IDEA 文件名顺序、请求顺序；每层独立限量；超限输入报 invalid_request 而不是截断。Fixture：shared/fixtures/search/rank-names-v1.json。
• Windows：
  • Quick Open 的文件结果改成异步：同一请求只发一次，查询变化后丢弃过期结果，加载期间保留旧列表不清空。remote/wsl 根目录的候选名仍由平台获取，打分统一交给 rankNames（这是第一轮撤出 WS-03 的原因）。
  • 删除 quick-open/utils/fuzzy-search.ts、use-file-search.ts 里的 fuzzyScore 兜底和 fffSearchFiles 的子串匹配；fffSearchFiles 现在是“列清单 + rankNames”。
  • 符号搜索（@）和文件导航侧栏的 fuzzy 模式原先也用这份本地评分，一并改走 rankNames（新的 useRankedNames hook）。
• macOS：删除 SearchRelevance.swift 的兼容打分，SearchEverywhereView 只用 Core 返回的 matchingDegree；原来 5 个测 Swift 本地打分的测试删除，同等行为改由 Rust fixture 测试覆盖。
• 同步更新 rust-core-api.md、功能矩阵 search-quick-open。

WS-04 隐藏路径规则（部分完成，其余撤出）

• 已做：Windows 的内容搜索（workspace.searchEverywhere）、文件清单（workspace.snapshot）、本地历史（history.entries/history.record/项目时间线）请求现在带上设置里的隐藏规则（hiddenPathRules()：目录名 -> hiddenDirectoryNames，带通配符或分隔符的目录项 -> 目录 glob，文件模式原样传），用户设置值不变，解释权在 Core（Core 自带的 node_modules、target 等内置规则一并生效）。
• 撤出：统一默认列表、project::visibility 批量分类、“仅文件树隐藏 / 搜索历史也排除”的区分，以及删除 Swift FileVisibilityRules.swift 和 Windows default-settings.ts 里的默认列表。原因：
  1. Windows 文件树在渲染路径里同步用 ignore 库判断（file-explorer-tree.tsx 的 isUserHidden），改成 Core 批量分类要把它变成异步预分类，而这个文件正是 fix(workspace): 完善忽略目录排除提示与树状态 #1658/fix(git): 跳过忽略或排除目录内的普通子仓库 #1659 大面积修改的地方，冲突和闪烁风险高；
  2. Swift FileVisibilityRules 在 watcher、快照构建、tree loader 等 20 多处同步调用 isHidden，其默认列表所在模块 LitheCoreContracts 不依赖 Rust bridge，没有同步取 Core 默认值的通道；
  3. 按“一次切干净”的规则，不合入没有调用方的 Core 分类 API。需要先决定同步取默认值的通道（例如生成常量）并等 fix(workspace): 完善忽略目录排除提示与树状态 #1658/fix(git): 跳过忽略或排除目录内的普通子仓库 #1659 合并后再做。

重叠的 open PR

#1658、#1659 与本 PR 没有直接重叠的文件（它们改 file-explorer-tree.tsx、files.rs、indexing.rs、protocol/command.rs、dispatcher.rs、rust-core-api.md；我只在 command.rs、dispatcher.rs、rust-core-api.md 做了追加式的一行级改动，可能出现邻近行的文本冲突）。WS-04 的文件树部分正是为避开它们而撤出。

验证

• cargo test -p lithe-core --lib rank_names：通过。
• Windows：bun run typecheck 通过；quick-open、file-search、file-explorer-selection、settings/lib 下相关测试逐文件通过；rank-names.test.ts 用真实 Core 动态库（LITHE_CORE_TEST_LIBRARY）跑 fixture 全部通过。
• 脚本：verify-rust-core-comments、verify-shared-contracts、verify-service-boundaries、verify-windows-boundaries、verify-platform-feature-matrix、两个 i18n 检查均通过（本次没有新增界面文案）。
• 未执行/待补：见评论中的 macOS 测试结果（SearchEverywhereBehavior 过滤，机器负载高编译很慢）；verify-core.sh 同样在排队；Windows 真机验证由主会话在 lithe-dev 上做。

风险

• Windows Quick Open 每次输入会把整份候选名发给 Core（stateless），超大仓库的 IPC 体积是个观察点。
• 旧 Swift 的“浅层文件优先”只在没有 Core 分数时生效，而 Core 一直都返回分数，所以实际行为不变。
• 隐藏规则现在会进入 Windows 的搜索/历史：设置里已有的 .idea、.hg 等默认项会被排除出搜索结果和 Quick Open 清单。

Refs #1662

🤖 Generated with Claude Code

[1lck]

本地集成验证（#1662 第二轮）

本 PR 与 #1765、#1768、#1767、#1766、#1769 一起，在本地集成分支 feat/issue-1662-r2-integration（基于 preview c1c7015）上验证。结果如下：

Rust

• cargo test -p lithe-core：2130 个测试通过。
• cargo test -p lithe-agent-host -- --test-threads=2：270 个测试通过。
• cargo fmt --check -p lithe-core 通过。
• cargo check --bin lithe-windows 在 macOS 上只有 2 个已知的 std::os::windows 错误，没有新增。

校验脚本
以下脚本全部通过：rust-core-comments、verify-core、shared-contracts、service-boundaries、windows-boundaries、platform-feature-matrix、两个 i18n 检查、runtime-bundle-immutability。

macOS

• swift build --build-tests 通过。
• test-macos.sh 跑了相关的 701 个测试，没有本次引入的失败：
  • cancellingSaveAllDuringRemoteDrainDoesNotWrite 在 preview 上同样失败，是既有问题。
  • 另外 3 个失败是高负载下的时序抖动，单独重跑能通过。

Windows 前端（在 Mac 上用 bun 跑）

• bun run typecheck 通过。
• 逐文件跑了 259 个测试文件，只有 3 个失败（git-status-display-order、matcher 的 IME 用例、agent-hooks-settings），在 preview 上同样失败，都是既有问题。

未执行
Windows 真机上的编译和测试没跑，因为 lithe-dev 服务器暂时连不上。

验证通过后用 --admin squash 合并，没有触发云端 macOS/Windows CI。