PR #3626 需要维护者确认：插件基座 library 新增 reveal/saveAs

[MagicLizi]

这条 PR 给 cindy.library 新增了 reveal / saveAs 两个操作，改动落在插件基座路径：

• apps/desktop/src/main/cindy-brain/librarySlot.ts
• apps/desktop/src/main/cindy-brain/index.ts
• apps/desktop/src/shared/ghost.ts

需要维护者确认的点：

1. 插件基座：这两个 op 会作用到全部已装插件可调用的 library 协议。请按 docs/dev-rules/plugin-security-and-authoring.md 第 5 节核对存量兼容——用户升级后什么都不做时，已装 / 已批准 / 已启用的插件是否照旧可用；新 op 是否只是加能力、旧插件不调用就无行为变化。
2. 作品库持久化：reveal / saveAs 是否遵守 docs/dev-rules/plugin-library-storage.md（主进程对话框、不把 webview File System Access 放开、另存为取消时库内文件仍在）。
3. 产品：feat 新增「在文件夹中显示 / 系统另存为」是给插件用的能力，Cindy 主界面本身没有新页面，但插件可以弹出系统对话框。

确认方式：直接在 PR 上 Approve。需要修改就 Request Changes，作者改完后重新 Approve 即放行。

---

关联 PR:#3626(作者 @PraiseZhu);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：reveal / saveAs 能为插件作品库提供“在文件夹中显示”和“系统另存为”的实际用户价值，采用 Electron 主进程文件管理器/保存对话框、而不是向 WebView 放开 File System Access，也符合当前 Library 的产品与安全边界。基于当前最新审查证据，PR #3626 目前不应直接 Approve，应先 Request Changes，修复账号切换与系统对话框异步等待之间的 owner 隔离问题。

已确认的实现边界

PR #3626 的目标是为 cindy.library 增加两个协议操作：

• reveal：将库内已有文件交给系统文件管理器显示；
• saveAs：通过主进程系统另存为对话框选择目标路径，再复制库内文件；
• 不向插件 WebView 开放 File System Access；
• 取消另存为时不删除、不移动库内源文件；
• 旧插件不调用新增操作时，既有 Library 操作应继续工作。

这些方向与 docs/dev-rules/plugin-library-storage.md 的要求一致：插件只能持有不透明 handle 与相对路径，绝对路径由 Host 解析；库根按 owner 与 plugin 隔离；不可用状态不能伪装为空库；取消或失败不能破坏原位置文件。

当前快照 64a20d1ab651c95bcf7bdce230a8e9612dac870e 的既有 librarySlot.ts 已体现以下基线：

• checkEligibility() 统一检查插件已安装、已启用并声明 library；
• Library session 捕获 ownerScopeKey，每次请求比较当前 owner；
• owner 变化时销毁旧 vault/SQL session，再按新 owner 重新解析 binding 与根目录；
• resolvePanelFilePath() 与普通 Library 读取共用库内文件解析；
• index.ts 在账号边界处理中会 disposeAll()，避免新 owner 继续使用旧 Library session；
• 现有 librarySlot.test.ts 覆盖了“切号后旧 session 作废、写入落新根、旧 owner 数据不串入新 owner”。

这说明基础 owner 隔离方向已经存在，但它不能自动证明一个等待系统对话框的新增异步流程安全：对话框返回前后必须重新确认有效 session，不能只依赖调用开始时已经解析出的绝对路径。

需要阻断合并的问题

PR #3626 的 PR 讨论中，Greptile 安全审查给出了具体的竞态链：

1. saveAs 在打开系统对话框前解析出旧 owner 的库文件绝对路径；
2. 系统对话框等待期间用户切换账号，旧 vault/session 失效；
3. 对话框返回后实现直接使用先前保存的绝对路径调用 copyFile；
4. 旧 owner 的文件仍然存在，因此文件可能被导出到用户选择的外部路径。

这不是只由“缺少某段保护代码”推导出的抽象风险，而是与当前 Library 规则直接冲突的可操作时序：plugin-library-storage.md 第 3 条要求 owner scope 每请求复核，并明确要求切换时不得继续使用上一 owner 的库。

PR 当前公开描述的自动测试结果为 librarySlot.test.ts 9 项通过，覆盖 reveal 成功/文件缺失，以及 saveAs 取消/复制流程；但从列出的覆盖范围看，没有“对话框打开期间切换 owner”的测试。当前快照中的既有测试也只覆盖切号后写入与读取，不覆盖系统对话框等待期间的异步 continuation。因此，现有测试不足以支持放行。

此外，当前快照是 PR #3626 尚未合入的 main 工作区；源码中的既有 librarySlot.ts 没有 reveal/saveAs 实现引用，不能把 PR 描述中的“9 tests PASS”误认为已落到主干或已完成发布验证。应以 PR 最新提交修复后的实际 diff、CI 与联调结果重新确认。

建议行动

请在 PR #3626 上 Request Changes，要求至少完成以下内容：

1. 对话框返回后重新验证 owner/session

   • 打开对话框前记录稳定 owner scope 或 session generation；
   • 对话框返回后再次确认当前 owner 未变化、边界不在进行中、Library session 仍有效；
   • 任一条件不满足时返回结构化失败，不执行复制；
   • 不要把旧的绝对源路径作为跨 owner 等待后的授权依据。

2. 从当前有效 Library session 重新解析源文件

   • 复制前使用当前 session/vault 按相对路径重新解析并复核文件存在性、普通文件属性和库根 containment；
   • 不把旧 session 已解析的绝对路径直接带过账号边界；
   • reveal 同样应使用库内解析结果，不能接受插件提供的任意绝对路径。

3. 补充回归测试
   至少覆盖：

   • saveAs 打开对话框期间切换 owner，返回后不复制旧 owner 文件；
   • 对话框返回前 session 被 dispose，复制被拒绝；
   • owner 未变化时正常复制；
   • 用户取消对话框时返回取消结果，库内源文件仍存在；
   • reveal 对库内存在文件成功，对缺失文件返回稳定错误；
   • 相对路径越界、symlink/非普通文件和 binding 不可用时不触碰外部路径；
   • 旧插件不调用新增 op 时既有 open/read/write/db 行为保持不变。

4. 更新验证说明

   • PR 描述应明确写出 owner 切换竞态的测试入口与结果；
   • 至少完成 macOS 与 Windows 的系统对话框联调，确认正常保存、取消、文件名建议和目标路径复制行为；
   • 若实现修改了作者可见的 Library 管子协议或作者手册，应同步 FORGE_GUIDE 对应章节，并在 PR 中说明同步位置；
   • 运行规则规定的最小门槛：

     pnpm --filter desktop exec vitest run src/main/cindy-brain/__tests__/library
     pnpm --filter desktop typecheck

修复完成并确认上述测试后，再由维护者 Approve。当前不建议通过新增能力价值来豁免异步 owner 边界审查，也不建议仅以“旧插件不调用则无行为变化”作为合并依据；这只能说明协议扩展的兼容性方向，不能覆盖新增 saveAs 的数据归属安全。

相关记录

• PR #3626：当前待审变更，新增 cindy.library 的 reveal/saveAs，并关联配套插件 PR；当前尚未合入主干。
• PR #1080：已合入后又因存量兼容问题整体回滚的插件批准 receipt 改造。其留下的正式规则要求：插件基座改动必须显式审查存量插件兼容，且 owner 隔离、生命周期和升级无感不能只靠新安装测试证明。该记录直接支持本次需要维护者门控、并要求补充真实异步边界测试的判断。

[MagicLizi]

维护者确认已通过,讨论结束,PR 恢复正常推进。关联 PR:#3626(https://github.com/makecindy/cindy/pull/3626)。本 issue 由 review-pr 流程自动关闭。