桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 作为跨端Electron / Compose / Flutter / Tauri / macOS Native / JavaFX同步演进的开发者工具箱其 Compose 桌面分支通过以docs/diff/为载体的 DIFF 切片逐帧对齐 Electron 行为与界面。本文以 DIFF-562 切片文档 为骨架完整展开该切片在四个维度上的落地Vault MCP 双库notes jsonstdio 端到端授权验证、四类 F 工具F09 HTTP / F20 翻译 / F24 PDF / F25 硬件信息的 Presentation→Engine 引擎路径改造、Vault Git remote 产品 UI 接线与 Compose 帧 156 证据捕获以及验证执行链路。读完本文你将掌握该切片的测试矩阵、关键源码调用链、参数边界与回归验证命令。一、切片背景与不重复原则DIFF-562 是 MooTool Next Compose 分支 DIFF 流水线的连续切片。其前置 DIFF-561见 561 切片已完成 MCP stdio 的mootool_hash/mootool_diff/mootool_json_query/mootool_timestamp/mootool_uuid子进程往返、F03runFormat引擎可测化、更新下载流单测、env/net/vault 底栏守卫以及 Compose 帧 155 捕获。因此 DIFF-562 在开头就明确声明不重复 561 链本切片只在其基础上推进以下增量Vault MCP stdio 从单一库授权扩展到同一access.json同时授权 notes json 双库F 工具从“守卫可测化”走向完整引擎路径Presentation → EngineVault Git 产品 UI 的 remote 输入行接线与帧 156 证据 PNG六套 CSS 逐选择器皮肤、产品主窗 Tab/IME/TCC PNG、P7 三平台安装等 substantial 缺口仍列在 parity-gap 中目标未达成。这一“行为 / 验证 / 未做”三段式是每条 DIFF 切片的固定骨架便于在流水线中快速比对差异。二、Vault MCP stdio双库单授权端到端2.1 双库授权的核心场景DIFF-562 在 Vault MCP 上扩展的场景是AiIntegrationVaultMcpConnectionTest.subprocessSearchBothVaultKindsInOneAccessPolicy同一access.json同时授权 notes json子进程分别 search。也就是说此前DIFF-561 之前的阶段MCP 的 Vault 只读工具一次只面向单一 vault 类型本切片验证的是一个授权文件同时声明两个 vault 根目录时mootool_notes_search与mootool_json_documents_search在同一个 MCP 子进程内都能独立工作。2.2 access.json 授权文件格式授权文件路径由McpLaunchResolver.accessFile决定fun accessFile(directories: AppDirectories): Path directories.configRoot.resolve(ai-integration).resolve(access.json)即位于configRoot/ai-integration/access.json。其 JSON 结构为{version: 1, notes: /path/to/notes/vault, json: /path/to/json/vault}version授权文件版本号当前为 1notesMarkdown 笔记 vault 的绝对目录路径为null时禁用 notes 读取jsonJSON 文档 vault 的绝对目录路径为null时禁用 json 读取。双库授权即同时给出两个非空路径。测试用例中的构造方式见 AiIntegrationVaultMcpConnectionTest.kt为path.writeText( {version:1,notes:${notesRoot.toRealPath()},json:${jsonRoot.toRealPath()}} )随后通过desktopTestMcpLaunch(accessFile)得到启动命令与参数用StdioClientTransport拉起子进程 MCP 服务器。2.3 子进程启动与工具调用MCP 子进程的启动命令由McpLaunchResolver.clientLaunch构造fun clientLaunch(accessFile: Path): McpLaunch { val command ProcessHandle.current().info().command().orElse(javaBinary()) val args listOf(--mcp, --access-file, accessFile.absolutePathString()) return McpLaunch(command command, args args) }即复用当前 Java 进程的可执行文件追加--mcp --access-file path两个参数服务器端由McpBootstrap.run解析--access-fileparseAccessFile注册McpToolCatalog.registrations()中的全部工具并对 Vault 工具转发给VaultMcpToolsval result when { VaultMcpTools.isVaultTool(name) - VaultMcpTools.call(name, map, accessFile) else - MooToolMcpTools.call(name, map) }四个 Vault 只读工具名见 VaultMcpTools.kt工具名作用关键参数mootool_notes_search在 notes vault 内全文搜索query、limit、offsetmootool_notes_read读取 notes 文档指定区间path、offset、lengthmootool_json_documents_search在 json vault 内全文搜索query、limit、offsetmootool_json_documents_read读取 JSON 文档指定区间path、offset、length在双库场景中客户端在同一个 MCP client 连接上分别调用val notesSearch client.callTool( McpSchema.CallToolRequest.builder() .name(mootool_notes_search) .arguments(mapOf(query to dual, limit to 5, offset to 0)) .build(), ) val jsonSearch client.callTool( McpSchema.CallToolRequest.builder() .name(mootool_json_documents_search) .arguments(mapOf(query to 562, limit to 5, offset to 0)) .build(), )断言jsonSearch返回文本中包含data.json说明双库在同一授权策略下均可被搜索命中。2.4 参数边界严格校验而非静默钳制VaultMcpTools.searchArgs/readArgs对齐 ElectronvaultTools.ts的 Zod strict 边界越界直接抛错而不是静默截断见 VaultMcpTools.kt参数默认值允许范围query空串 列出全部最长 200 字符search.limit201..50search.offset00..2000read.path必填最长 1000 字符非空、相对路径read.offset00..2_000_000read.length20_0001..50_000配套的AiIntegrationVaultMcpConnectionTest提供了 20 个方法级别的端到端用例除双库搜索外还覆盖notes/json 各自 searchread、offset/length分页读取、search 的offset分页limit1, offset1命中第二篇、nextOffset续读拼接、listTools按授权动态暴露 Vault 读工具等。这为“MCP 工具参数边界”提供了可直接复用的回归样本。2.5 只读安全模型在只读工具的背后VaultMcpReadService见 VaultMcpReadService.kt实现了一系列安全约束授权根目录必须是真实绝对目录非绝对路径、符号链接别名、toRealPath() ! path、非目录都会抛出The granted vault moved. Grant access again in MooTool settings..gitignore 尊重读取 vault 根下的.gitignore普通文件、小于 100 KB、UTF-8 严格解码GitIgnoreMatcher判定被忽略的相对路径在 search 中跳过、在 read 中直接拒绝Gitignored documents are not exposed to AI禁止越界与符号链接resolveUnderRoot逐段解析并拒绝符号链接inside(root, realPath)保证文档必须位于授权根内搜索遍历深度上限 24、访问条目上限 4000、字节预算上限 10 MB单文档 2 MB 上限maxBytes 2_000_000L超过即拒绝类型白名单notes 仅NoteFrontmatter.noteExtensionsjson 仅.json扩展名。由此MCP 暴露给 AI 的数据面是“只读 授权 gitignore 过滤 路径受限”的受控子集。三、F 工具引擎路径Presentation → EngineDIFF-562 的第二大主题是把 F09/F20/F24/F25 四类工具从“仅守卫可测化”推进到真实调用链 Presentation → Engine使 UI 层、展示层与纯逻辑引擎解耦且全部可单测。3.1 F20 翻译TranslationWiringPresentation.runTranslateTranslationWiringPresentation见 TranslationWiringPresentation.kt封装了 F20 的完整入参构造与执行languagePairFromSettings把设置里的源/目标语言 wire 值交给TranslationEngine.normalizeLanguagePair规范化支持中英日韩等 29 个语言代码及别名、auto自动检测源语言与目标语言相同时强制源为autobuildInput生成TranslationInput(requestId, text, sourceLang, targetLang, preferredProvider, timeoutMs)其中 provider 由TranslationEngine.parseProvider解析bing不区分大小写否则 Google超时由clampTimeout限制在 1000..120000 msrunTranslate(input, proxy)最终调用TranslationEngine.translate默认使用HttpProxyConfig()即不走代理。在 TranslationScreen.kt 中主翻译与生词重译的调用链完全一致val input TranslationWiringPresentation.buildInput( requestId requestId, text text, sourceLangWire sourceLang, targetLangWire targetLang, providerWire settings.tools.translationProvider, timeoutWire settings.network.translationTimeoutMs, ) scope.launch(Dispatchers.IO) { val result TranslationWiringPresentation.runTranslate(input, proxy) // withContext(Main) 内按 requestId 判活后回写 session }TranslationEngine.translate的核心逻辑见 TranslationEngine.kt值得展开文本超过MAX_TEXT_UNITS50 000直接返回INVALID_REQUEST空文本直接成功返回按偏好 provider 构造顺序[preferred, alternate]若某 provider 处于冷却期providerCooldownMs默认 10 分钟则跳过它Google 路径按自然断句把长文本切成 ≤1800 字符的块splitTranslationText避开代理对/emoji 断裂以并发 3 的线程池mapPool并行翻译后拼接Bing 路径先抓取翻译页 HTML 解析IG:...与params_AbusePreventionHelper获取会话 token再调ttranslatev3全程以requestId为维度注册 OkHttp call、超时调度与 abort 原因支持cancel(requestId)结果携带provider与fallbackUsedUI 据此显示“主/备提供商”提示。DIFF-562 要求TranslationScreen主翻译与生词重译都走该 Presentation而TranslationWiringPresentationTest见 desktopTest/domain则对语言规范化、超时 clamp、各按钮 enabled 判定translateActionEnabled/copyResultActionEnabled/retranslateWordActionEnabled/clearHistoryActionEnabled等做纯函数断言。3.2 F09 HTTP 请求HttpRequestPresentation.runSendHttpRequestPresentation见 HttpRequestPresentation.kt承担 F09 发送/在途响应写入守卫shouldApplyResponse(activeRequestId, resultRequestId)只有当前在途requestId与结果一致才写回 UI对齐 Electron 丢弃过期响应canSend(urlTrimmed, sending)URL 非空且不在发送中sendActionEnabled与此一致stopSendActionEnabled(sending, requestId)须在途且已有 requestIdrunSend(draft, requestId, timeoutMs, proxy)真正调用HttpEngine.send(draft, requestId, timeoutMs, proxy)。在 HttpScreen.kt 中val result HttpRequestPresentation.runSend(draft, requestId, timeout, proxy) if (!HttpRequestPresentation.shouldApplyResponse(session.requestId, result.requestId)) returnwithContextHttpEngine.send见 HttpEngine.kt先prepare(draft)构造HttpPreparedRequest支持 GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS、URL 参数拼装、JSON/XML/HTML/JS 等 body 类型、multipart/form-data随后用 OkHttp 执行响应体最大 10 MB二进制内容按Content-Type解码并保留bodyBytes文本内容自动prettyJson美化。同 requestId 的新请求会先取消旧 callcalls[requestId]?.cancel()。失败按classify(error, call)映射为ABORTED / TIMEOUT / NETWORK / INVALID_REQUEST / RESPONSE_TOO_LARGE。3.3 F24 PDFPdfWiringPresentation.inspectFilePdfWiringPresentation见 PdfWiringPresentation.kt提供 PDF 导入 ingest 的完整守卫inspectFile(path)runCatching { PdfEngine.inspect(path) }包装为InspectOutcome.Success/FailurecanAddTask非 busy 且 Split/Merge 任务数未达PdfEngine.MAX_TASKS20canStartSplit非 busy 且选中数 0canStartMerge非 busy 且选中数 ≥ 2runSplit/runMerge分别调用PdfEngine.split(tasks, cancelled)与PdfEngine.merge(sources, output, cancelled)shouldToastJobFailure仅当PdfException.code ! cancelled时才弹失败 toast用户取消不算错误。PdfEngine.inspect见 PdfEngine.kt基于 Apache PDFBox 打开 PDF统计页数、表单域数AcroForm、书签数与签名域数hasSpecialObjects标记含特殊对象的文档。parsePageSelection支持1-5;8;10-12式页范围逗号/中文逗号自动转分号拆分规则支持 Odd/Even/Custom。DIFF-562 的要求是 PDF 导入 ingest 必须经 Presentation 调用PdfEngine.inspect使 PdfWiringPresentationTest.kt 可以脱离 UI 验证任务上限、合并条件与失败判定。3.4 F25 硬件信息HardwareWiringPresentation.runCollectHardwareWiringPresentation见 HardwareWiringPresentation.kt封装 F25 系统信息采集refreshEnabled(loading)加载中禁用刷新copyReportEnabled(loading, hasGroups)加载中或无分组时禁用复制报告runCollect(loadSampleMs 200)调用HardwareEngine.collect(loadSampleMs)CPU 负载采样默认 200 msshouldToastCollectFailureCancellationException不算失败。HardwareEngine见 HardwareEngine.kt基于 OSHI 采集 System / CPU / Memory / Storage / Network 五个 tab 的分组数据并提供敏感信息掩码mask如ab****cd、字节/时长/主频格式化工具。DIFF-561 已登记interfacesCommandEnabled顶栏命令扩展的守卫本切片继续把HardwareScreen刷新接线到HardwareWiringPresentation.runCollect由HardwareWiringPresentationTest验证。3.5 Presentation 层的统一价值把“引擎纯逻辑”与“Presentation 守卫/编排”分开后四个 F 工具的按钮 enabled 条件、错误 toast 判定、requestId 判活、任务上限等规则都可以用纯函数在 desktopTest/domain 下直接断言无需启动完整桌面 UI。这正是 DIFF 流水线“先可测、再接线”的推进节奏。四、Git / Vault 产品 UIremote 行与帧 1564.1mooGitVaultRemoteRow与VaultGitDialogDIFF-562 在 Vault Git 产品 UI 上接线的是mooGitVaultRemoteRow定义于 Controls.kt在VaultGitDialog中用于 remote 输入行见 VaultGitDialog.ktRow(modifier Modifier.mooGitVaultRemoteRow()) { Text(container.t(git.remote), ...) MooTextField(remote, { remote it }, placeholder container.t(git.remotePlaceholder), ...) val remoteTrimmed remote.trim() val remoteLabel if (remoteTrimmed.isNotEmpty()) container.t(git.saveRemote) else container.t(git.removeRemote) MooButton( remoteLabel, enabled GitVaultRemotePresentation.saveRemoteEnabled( busy busy, repository repository, draftRemoteTrimmed remoteTrimmed, statusRemote status.remote, ), onClick { val committed when (val outcome SettingsVaultGitNormalize.commitGitRemote(remote)) { GitRemoteCommitResult.Cleared - is GitRemoteCommitResult.Accepted - outcome.remote GitRemoteCommitResult.Rejected - { notifyVaultGitInvalidRemote(container); returnMooButton } } // 更新设置 vault.gitRemote 后 GitEngine.setRemote(root, committed) }, ) } if (GitVaultRemotePresentation.unsavedRemoteDraft(remote, status.remote)) { Text(container.t(git.remoteUnsavedHint), ...) }行为要点输入为空时按钮文案变为git.removeRemote清空 remote非空时为git.saveRemotesaveRemoteEnabled由 GitVaultRemotePresentation 判定!busy configureRemoteEnabled(repository, draftRemoteTrimmed, statusRemote)remote 草稿与已持久化 remote只读status.remote不一致时显示git.remoteUnsavedHint未保存提示由unsavedRemoteDraft判断提交 remote 后经GitEngine.setRemote(root, committed)落盘并重载状态、同步 remote 字段syncRemoteField。同时GitVaultRemotePresentation还定义了顶栏 fetch/push/pull 的启用条件fetch只要已持久化 remote 且非 busy 即可用pull/push额外要求非 merging 且未解决冲突数conflicts 0fetch 在冲突期间仍可用push/pull 禁用与 DIFF-516/520 的引擎侧拒绝行为一致。4.2 帧 156 证据捕获验证由GitVaultRemoteCaptureTest见 GitVaultRemoteCaptureTest.kt完成它在 640x120 的 Compose 桌面 UI 测试中渲染一个带mooGitVaultRemoteRow的行含git.remote标签、remote 草稿文本与“保存 remote”按钮通过FocusRequester聚焦保存按钮captureToImage()截图后断言焦点环色值0x316DC0像素数 ≥ 8从而以像素级方式验证保存按钮的 Tab 焦点可见性。输出帧为156-compose-git-vault-remote-save-tab-focus.png该 PNG 写入docs/evidence/2026-09-15-inspector-screencapture/windows/。文档明确标注其为非产品主窗证据——这是与“产品主窗 Vault Git/IME 手工 PNG”未做项的边界。五、验证链路与运行命令5.1 测试矩阵DIFF-562 的验证覆盖六个测试类测试类验证点AiIntegrationVaultMcpConnectionTestVault MCP stdio 端到端双库授权、search/read、offset/length 分页、listToolsTranslationWiringPresentationTestF20 翻译 Presentation语言对、超时 clamp、按钮守卫HttpRequestPresentationTestF09 HTTP PresentationrequestId 判活、canSend/stop、runSendPdfWiringPresentationTestF24 PDF Presentation任务上限、inspect/split/merge、toast 判定HardwareWiringPresentationTestF25 硬件 Presentationrefresh/copy 守卫、runCollectGitVaultRemoteCaptureTest帧 156 截图 焦点环像素断言5.2 证据恢复与回归命令两条命令按文档执行# 恢复证据 PNG托盘 / 调色板 / 图片工具屏幕录制 TCC 产品窗验收准备 ./scripts/prepare-tray-screencapture-evidence.sh该脚本见 prepare-tray-screencapture-evidence.sh把docs/evidence/2026-09-15-inspector-screencapture/windows/57-color.png恢复到docs/evidence/2026-09-17-tray-tcc-screencapture/reference/57-color-baseline.png并打印手工 TCC 权限验证步骤系统设置 → 隐私 → 屏幕录制权限开关对 MooTool 的影响。# 离线运行全部桌面测试要求 JDK 21 ./gradlew :composeApp:desktopTest --offline--offline表明该流水线在无网络环境下仍可完整回归依赖已由 Gradle 缓存提供。六、未做项与 parity-gap 边界DIFF-562 末尾明确列出未做项属于诚实透明的切片边界六套 CSS 逐选择器皮肤Compose 皮肤逐选择器对齐仍未推进产品主窗 Vault Git / IME 手工 PNG帧 156 是组件级截图非产品主窗P7 三平台安装 / 公证HTTP / 翻译 / PDF 其余 substantial UI本切片只推进了引擎路径与守卫接线总体目标未达成。这些未做项与“行为 / 验证”一起为后续切片如 563-579 系列的 F 工具引擎、Vault Git、CSS 皮肤切片提供了明确的接力点也说明 DIFF 流水线是一种增量推进、逐帧留痕、未做即声明的工程方法。七、小结DIFF-562 是 MooTool Next Compose 分支切片流水线中承上启下的一环它在 Vault MCP 上把单库授权扩展为 notes json 双库单授权端到端验证并借access.json授权、只读安全模型与严格参数边界把 AI 数据面收敛为受控子集在 F09/F20/F24/F25 四个工具上完成 Presentation → Engine 的引擎路径改造让按钮守卫、错误判定与核心逻辑全部可单测在 UI 侧接好mooGitVaultRemoteRow并产出帧 156 像素级证据最后以prepare-tray-screencapture-evidence.sh./gradlew :composeApp:desktopTest --offlineJDK 21作为可复现的验证闭环。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool NextComposeF20/F09/F24 呈现层对齐与 F19 会话恢复DIFF-546 实现解析与验证指南MooTool NextComposeF20/F09/F24 呈现层对齐与 F19 会话恢复DIFF 546 实现解析与验证指南 导读 本文以 MooT桌面应用开发工具MooTool Compose 桌面端 F04/F06 导入导出统一化与 Vault MCP 双库 read→search 链路解析DIFF-576MooTool Compose 桌面端 F04/F06 导入导出统一化与 Vault MCP 双库 read→search 链路解析DIFF 576 本文基桌面应用开发工具MooTool Compose F20/F24/F07 引擎接线、Vault Git Remote、列编辑语义与 MCP 工具集成实战指南MooTool Compose F20/F24/F07 引擎接线、Vault Git Remote、列编辑语义与 MCP 工具集成实战指南 导读 本文基于 Mo桌面应用开发工具上一篇python-sdk URI 模板与路径安全实战指南从 RFC 6570 操作符全集到 safe_join 防御体系下一篇解决python-react常见问题从渲染超时到跨域请求的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 作为跨端Electron / Compose / Flutter / Tauri / macOS Native / JavaFX同步演进的开发者工具箱其 Compose 桌面分支通过以docs/diff/为载体的 DIFF 切片逐帧对齐 Electron 行为与界面。本文以 DIFF-562 切片文档 为骨架完整展开该切片在四个维度上的落地Vault MCP 双库notes jsonstdio 端到端授权验证、四类 F 工具F09 HTTP / F20 翻译 / F24 PDF / F25 硬件信息的 Presentation→Engine 引擎路径改造、Vault Git remote 产品 UI 接线与 Compose 帧 156 证据捕获以及验证执行链路。读完本文你将掌握该切片的测试矩阵、关键源码调用链、参数边界与回归验证命令。一、切片背景与不重复原则DIFF-562 是 MooTool Next Compose 分支 DIFF 流水线的连续切片。其前置 DIFF-561见 561 切片已完成 MCP stdio 的mootool_hash/mootool_diff/mootool_json_query/mootool_timestamp/mootool_uuid子进程往返、F03runFormat引擎可测化、更新下载流单测、env/net/vault 底栏守卫以及 Compose 帧 155 捕获。因此 DIFF-562 在开头就明确声明不重复 561 链本切片只在其基础上推进以下增量Vault MCP stdio 从单一库授权扩展到同一access.json同时授权 notes json 双库F 工具从“守卫可测化”走向完整引擎路径Presentation → EngineVault Git 产品 UI 的 remote 输入行接线与帧 156 证据 PNG六套 CSS 逐选择器皮肤、产品主窗 Tab/IME/TCC PNG、P7 三平台安装等 substantial 缺口仍列在 parity-gap 中目标未达成。这一“行为 / 验证 / 未做”三段式是每条 DIFF 切片的固定骨架便于在流水线中快速比对差异。二、Vault MCP stdio双库单授权端到端2.1 双库授权的核心场景DIFF-562 在 Vault MCP 上扩展的场景是AiIntegrationVaultMcpConnectionTest.subprocessSearchBothVaultKindsInOneAccessPolicy同一access.json同时授权 notes json子进程分别 search。也就是说此前DIFF-561 之前的阶段MCP 的 Vault 只读工具一次只面向单一 vault 类型本切片验证的是一个授权文件同时声明两个 vault 根目录时mootool_notes_search与mootool_json_documents_search在同一个 MCP 子进程内都能独立工作。2.2 access.json 授权文件格式授权文件路径由McpLaunchResolver.accessFile决定fun accessFile(directories: AppDirectories): Path directories.configRoot.resolve(ai-integration).resolve(access.json)即位于configRoot/ai-integration/access.json。其 JSON 结构为{version: 1, notes: /path/to/notes/vault, json: /path/to/json/vault}version授权文件版本号当前为 1notesMarkdown 笔记 vault 的绝对目录路径为null时禁用 notes 读取jsonJSON 文档 vault 的绝对目录路径为null时禁用 json 读取。双库授权即同时给出两个非空路径。测试用例中的构造方式见 AiIntegrationVaultMcpConnectionTest.kt为path.writeText( {version:1,notes:${notesRoot.toRealPath()},json:${jsonRoot.toRealPath()}} )随后通过desktopTestMcpLaunch(accessFile)得到启动命令与参数用StdioClientTransport拉起子进程 MCP 服务器。2.3 子进程启动与工具调用MCP 子进程的启动命令由McpLaunchResolver.clientLaunch构造fun clientLaunch(accessFile: Path): McpLaunch { val command ProcessHandle.current().info().command().orElse(javaBinary()) val args listOf(--mcp, --access-file, accessFile.absolutePathString()) return McpLaunch(command command, args args) }即复用当前 Java 进程的可执行文件追加--mcp --access-file path两个参数服务器端由McpBootstrap.run解析--access-fileparseAccessFile注册McpToolCatalog.registrations()中的全部工具并对 Vault 工具转发给VaultMcpToolsval result when { VaultMcpTools.isVaultTool(name) - VaultMcpTools.call(name, map, accessFile) else - MooToolMcpTools.call(name, map) }四个 Vault 只读工具名见 VaultMcpTools.kt工具名作用关键参数mootool_notes_search在 notes vault 内全文搜索query、limit、offsetmootool_notes_read读取 notes 文档指定区间path、offset、lengthmootool_json_documents_search在 json vault 内全文搜索query、limit、offsetmootool_json_documents_read读取 JSON 文档指定区间path、offset、length在双库场景中客户端在同一个 MCP client 连接上分别调用val notesSearch client.callTool( McpSchema.CallToolRequest.builder() .name(mootool_notes_search) .arguments(mapOf(query to dual, limit to 5, offset to 0)) .build(), ) val jsonSearch client.callTool( McpSchema.CallToolRequest.builder() .name(mootool_json_documents_search) .arguments(mapOf(query to 562, limit to 5, offset to 0)) .build(), )断言jsonSearch返回文本中包含data.json说明双库在同一授权策略下均可被搜索命中。2.4 参数边界严格校验而非静默钳制VaultMcpTools.searchArgs/readArgs对齐 ElectronvaultTools.ts的 Zod strict 边界越界直接抛错而不是静默截断见 VaultMcpTools.kt参数默认值允许范围query空串 列出全部最长 200 字符search.limit201..50search.offset00..2000read.path必填最长 1000 字符非空、相对路径read.offset00..2_000_000read.length20_0001..50_000配套的AiIntegrationVaultMcpConnectionTest提供了 20 个方法级别的端到端用例除双库搜索外还覆盖notes/json 各自 searchread、offset/length分页读取、search 的offset分页limit1, offset1命中第二篇、nextOffset续读拼接、listTools按授权动态暴露 Vault 读工具等。这为“MCP 工具参数边界”提供了可直接复用的回归样本。2.5 只读安全模型在只读工具的背后VaultMcpReadService见 VaultMcpReadService.kt实现了一系列安全约束授权根目录必须是真实绝对目录非绝对路径、符号链接别名、toRealPath() ! path、非目录都会抛出The granted vault moved. Grant access again in MooTool settings..gitignore 尊重读取 vault 根下的.gitignore普通文件、小于 100 KB、UTF-8 严格解码GitIgnoreMatcher判定被忽略的相对路径在 search 中跳过、在 read 中直接拒绝Gitignored documents are not exposed to AI禁止越界与符号链接resolveUnderRoot逐段解析并拒绝符号链接inside(root, realPath)保证文档必须位于授权根内搜索遍历深度上限 24、访问条目上限 4000、字节预算上限 10 MB单文档 2 MB 上限maxBytes 2_000_000L超过即拒绝类型白名单notes 仅NoteFrontmatter.noteExtensionsjson 仅.json扩展名。由此MCP 暴露给 AI 的数据面是“只读 授权 gitignore 过滤 路径受限”的受控子集。三、F 工具引擎路径Presentation → EngineDIFF-562 的第二大主题是把 F09/F20/F24/F25 四类工具从“仅守卫可测化”推进到真实调用链 Presentation → Engine使 UI 层、展示层与纯逻辑引擎解耦且全部可单测。3.1 F20 翻译TranslationWiringPresentation.runTranslateTranslationWiringPresentation见 TranslationWiringPresentation.kt封装了 F20 的完整入参构造与执行languagePairFromSettings把设置里的源/目标语言 wire 值交给TranslationEngine.normalizeLanguagePair规范化支持中英日韩等 29 个语言代码及别名、auto自动检测源语言与目标语言相同时强制源为autobuildInput生成TranslationInput(requestId, text, sourceLang, targetLang, preferredProvider, timeoutMs)其中 provider 由TranslationEngine.parseProvider解析bing不区分大小写否则 Google超时由clampTimeout限制在 1000..120000 msrunTranslate(input, proxy)最终调用TranslationEngine.translate默认使用HttpProxyConfig()即不走代理。在 TranslationScreen.kt 中主翻译与生词重译的调用链完全一致val input TranslationWiringPresentation.buildInput( requestId requestId, text text, sourceLangWire sourceLang, targetLangWire targetLang, providerWire settings.tools.translationProvider, timeoutWire settings.network.translationTimeoutMs, ) scope.launch(Dispatchers.IO) { val result TranslationWiringPresentation.runTranslate(input, proxy) // withContext(Main) 内按 requestId 判活后回写 session }TranslationEngine.translate的核心逻辑见 TranslationEngine.kt值得展开文本超过MAX_TEXT_UNITS50 000直接返回INVALID_REQUEST空文本直接成功返回按偏好 provider 构造顺序[preferred, alternate]若某 provider 处于冷却期providerCooldownMs默认 10 分钟则跳过它Google 路径按自然断句把长文本切成 ≤1800 字符的块splitTranslationText避开代理对/emoji 断裂以并发 3 的线程池mapPool并行翻译后拼接Bing 路径先抓取翻译页 HTML 解析IG:...与params_AbusePreventionHelper获取会话 token再调ttranslatev3全程以requestId为维度注册 OkHttp call、超时调度与 abort 原因支持cancel(requestId)结果携带provider与fallbackUsedUI 据此显示“主/备提供商”提示。DIFF-562 要求TranslationScreen主翻译与生词重译都走该 Presentation而TranslationWiringPresentationTest见 desktopTest/domain则对语言规范化、超时 clamp、各按钮 enabled 判定translateActionEnabled/copyResultActionEnabled/retranslateWordActionEnabled/clearHistoryActionEnabled等做纯函数断言。3.2 F09 HTTP 请求HttpRequestPresentation.runSendHttpRequestPresentation见 HttpRequestPresentation.kt承担 F09 发送/在途响应写入守卫shouldApplyResponse(activeRequestId, resultRequestId)只有当前在途requestId与结果一致才写回 UI对齐 Electron 丢弃过期响应canSend(urlTrimmed, sending)URL 非空且不在发送中sendActionEnabled与此一致stopSendActionEnabled(sending, requestId)须在途且已有 requestIdrunSend(draft, requestId, timeoutMs, proxy)真正调用HttpEngine.send(draft, requestId, timeoutMs, proxy)。在 HttpScreen.kt 中val result HttpRequestPresentation.runSend(draft, requestId, timeout, proxy) if (!HttpRequestPresentation.shouldApplyResponse(session.requestId, result.requestId)) returnwithContextHttpEngine.send见 HttpEngine.kt先prepare(draft)构造HttpPreparedRequest支持 GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS、URL 参数拼装、JSON/XML/HTML/JS 等 body 类型、multipart/form-data随后用 OkHttp 执行响应体最大 10 MB二进制内容按Content-Type解码并保留bodyBytes文本内容自动prettyJson美化。同 requestId 的新请求会先取消旧 callcalls[requestId]?.cancel()。失败按classify(error, call)映射为ABORTED / TIMEOUT / NETWORK / INVALID_REQUEST / RESPONSE_TOO_LARGE。3.3 F24 PDFPdfWiringPresentation.inspectFilePdfWiringPresentation见 PdfWiringPresentation.kt提供 PDF 导入 ingest 的完整守卫inspectFile(path)runCatching { PdfEngine.inspect(path) }包装为InspectOutcome.Success/FailurecanAddTask非 busy 且 Split/Merge 任务数未达PdfEngine.MAX_TASKS20canStartSplit非 busy 且选中数 0canStartMerge非 busy 且选中数 ≥ 2runSplit/runMerge分别调用PdfEngine.split(tasks, cancelled)与PdfEngine.merge(sources, output, cancelled)shouldToastJobFailure仅当PdfException.code ! cancelled时才弹失败 toast用户取消不算错误。PdfEngine.inspect见 PdfEngine.kt基于 Apache PDFBox 打开 PDF统计页数、表单域数AcroForm、书签数与签名域数hasSpecialObjects标记含特殊对象的文档。parsePageSelection支持1-5;8;10-12式页范围逗号/中文逗号自动转分号拆分规则支持 Odd/Even/Custom。DIFF-562 的要求是 PDF 导入 ingest 必须经 Presentation 调用PdfEngine.inspect使 PdfWiringPresentationTest.kt 可以脱离 UI 验证任务上限、合并条件与失败判定。3.4 F25 硬件信息HardwareWiringPresentation.runCollectHardwareWiringPresentation见 HardwareWiringPresentation.kt封装 F25 系统信息采集refreshEnabled(loading)加载中禁用刷新copyReportEnabled(loading, hasGroups)加载中或无分组时禁用复制报告runCollect(loadSampleMs 200)调用HardwareEngine.collect(loadSampleMs)CPU 负载采样默认 200 msshouldToastCollectFailureCancellationException不算失败。HardwareEngine见 HardwareEngine.kt基于 OSHI 采集 System / CPU / Memory / Storage / Network 五个 tab 的分组数据并提供敏感信息掩码mask如ab****cd、字节/时长/主频格式化工具。DIFF-561 已登记interfacesCommandEnabled顶栏命令扩展的守卫本切片继续把HardwareScreen刷新接线到HardwareWiringPresentation.runCollect由HardwareWiringPresentationTest验证。3.5 Presentation 层的统一价值把“引擎纯逻辑”与“Presentation 守卫/编排”分开后四个 F 工具的按钮 enabled 条件、错误 toast 判定、requestId 判活、任务上限等规则都可以用纯函数在 desktopTest/domain 下直接断言无需启动完整桌面 UI。这正是 DIFF 流水线“先可测、再接线”的推进节奏。四、Git / Vault 产品 UIremote 行与帧 1564.1mooGitVaultRemoteRow与VaultGitDialogDIFF-562 在 Vault Git 产品 UI 上接线的是mooGitVaultRemoteRow定义于 Controls.kt在VaultGitDialog中用于 remote 输入行见 VaultGitDialog.ktRow(modifier Modifier.mooGitVaultRemoteRow()) { Text(container.t(git.remote), ...) MooTextField(remote, { remote it }, placeholder container.t(git.remotePlaceholder), ...) val remoteTrimmed remote.trim() val remoteLabel if (remoteTrimmed.isNotEmpty()) container.t(git.saveRemote) else container.t(git.removeRemote) MooButton( remoteLabel, enabled GitVaultRemotePresentation.saveRemoteEnabled( busy busy, repository repository, draftRemoteTrimmed remoteTrimmed, statusRemote status.remote, ), onClick { val committed when (val outcome SettingsVaultGitNormalize.commitGitRemote(remote)) { GitRemoteCommitResult.Cleared - is GitRemoteCommitResult.Accepted - outcome.remote GitRemoteCommitResult.Rejected - { notifyVaultGitInvalidRemote(container); returnMooButton } } // 更新设置 vault.gitRemote 后 GitEngine.setRemote(root, committed) }, ) } if (GitVaultRemotePresentation.unsavedRemoteDraft(remote, status.remote)) { Text(container.t(git.remoteUnsavedHint), ...) }行为要点输入为空时按钮文案变为git.removeRemote清空 remote非空时为git.saveRemotesaveRemoteEnabled由 GitVaultRemotePresentation 判定!busy configureRemoteEnabled(repository, draftRemoteTrimmed, statusRemote)remote 草稿与已持久化 remote只读status.remote不一致时显示git.remoteUnsavedHint未保存提示由unsavedRemoteDraft判断提交 remote 后经GitEngine.setRemote(root, committed)落盘并重载状态、同步 remote 字段syncRemoteField。同时GitVaultRemotePresentation还定义了顶栏 fetch/push/pull 的启用条件fetch只要已持久化 remote 且非 busy 即可用pull/push额外要求非 merging 且未解决冲突数conflicts 0fetch 在冲突期间仍可用push/pull 禁用与 DIFF-516/520 的引擎侧拒绝行为一致。4.2 帧 156 证据捕获验证由GitVaultRemoteCaptureTest见 GitVaultRemoteCaptureTest.kt完成它在 640x120 的 Compose 桌面 UI 测试中渲染一个带mooGitVaultRemoteRow的行含git.remote标签、remote 草稿文本与“保存 remote”按钮通过FocusRequester聚焦保存按钮captureToImage()截图后断言焦点环色值0x316DC0像素数 ≥ 8从而以像素级方式验证保存按钮的 Tab 焦点可见性。输出帧为156-compose-git-vault-remote-save-tab-focus.png该 PNG 写入docs/evidence/2026-09-15-inspector-screencapture/windows/。文档明确标注其为非产品主窗证据——这是与“产品主窗 Vault Git/IME 手工 PNG”未做项的边界。五、验证链路与运行命令5.1 测试矩阵DIFF-562 的验证覆盖六个测试类测试类验证点AiIntegrationVaultMcpConnectionTestVault MCP stdio 端到端双库授权、search/read、offset/length 分页、listToolsTranslationWiringPresentationTestF20 翻译 Presentation语言对、超时 clamp、按钮守卫HttpRequestPresentationTestF09 HTTP PresentationrequestId 判活、canSend/stop、runSendPdfWiringPresentationTestF24 PDF Presentation任务上限、inspect/split/merge、toast 判定HardwareWiringPresentationTestF25 硬件 Presentationrefresh/copy 守卫、runCollectGitVaultRemoteCaptureTest帧 156 截图 焦点环像素断言5.2 证据恢复与回归命令两条命令按文档执行# 恢复证据 PNG托盘 / 调色板 / 图片工具屏幕录制 TCC 产品窗验收准备 ./scripts/prepare-tray-screencapture-evidence.sh该脚本见 prepare-tray-screencapture-evidence.sh把docs/evidence/2026-09-15-inspector-screencapture/windows/57-color.png恢复到docs/evidence/2026-09-17-tray-tcc-screencapture/reference/57-color-baseline.png并打印手工 TCC 权限验证步骤系统设置 → 隐私 → 屏幕录制权限开关对 MooTool 的影响。# 离线运行全部桌面测试要求 JDK 21 ./gradlew :composeApp:desktopTest --offline--offline表明该流水线在无网络环境下仍可完整回归依赖已由 Gradle 缓存提供。六、未做项与 parity-gap 边界DIFF-562 末尾明确列出未做项属于诚实透明的切片边界六套 CSS 逐选择器皮肤Compose 皮肤逐选择器对齐仍未推进产品主窗 Vault Git / IME 手工 PNG帧 156 是组件级截图非产品主窗P7 三平台安装 / 公证HTTP / 翻译 / PDF 其余 substantial UI本切片只推进了引擎路径与守卫接线总体目标未达成。这些未做项与“行为 / 验证”一起为后续切片如 563-579 系列的 F 工具引擎、Vault Git、CSS 皮肤切片提供了明确的接力点也说明 DIFF 流水线是一种增量推进、逐帧留痕、未做即声明的工程方法。七、小结DIFF-562 是 MooTool Next Compose 分支切片流水线中承上启下的一环它在 Vault MCP 上把单库授权扩展为 notes json 双库单授权端到端验证并借access.json授权、只读安全模型与严格参数边界把 AI 数据面收敛为受控子集在 F09/F20/F24/F25 四个工具上完成 Presentation → Engine 的引擎路径改造让按钮守卫、错误判定与核心逻辑全部可单测在 UI 侧接好mooGitVaultRemoteRow并产出帧 156 像素级证据最后以prepare-tray-screencapture-evidence.sh./gradlew :composeApp:desktopTest --offlineJDK 21作为可复现的验证闭环。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool NextComposeF20/F09/F24 呈现层对齐与 F19 会话恢复DIFF-546 实现解析与验证指南MooTool NextComposeF20/F09/F24 呈现层对齐与 F19 会话恢复DIFF 546 实现解析与验证指南 导读 本文以 MooT桌面应用开发工具MooTool Compose 桌面端 F04/F06 导入导出统一化与 Vault MCP 双库 read→search 链路解析DIFF-576MooTool Compose 桌面端 F04/F06 导入导出统一化与 Vault MCP 双库 read→search 链路解析DIFF 576 本文基桌面应用开发工具MooTool Compose F20/F24/F07 引擎接线、Vault Git Remote、列编辑语义与 MCP 工具集成实战指南MooTool Compose F20/F24/F07 引擎接线、Vault Git Remote、列编辑语义与 MCP 工具集成实战指南 导读 本文基于 Mo桌面应用开发工具上一篇python-sdk URI 模板与路径安全实战指南从 RFC 6570 操作符全集到 safe_join 防御体系下一篇解决python-react常见问题从渲染超时到跨域请求的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
