插件市场安装任意插件时持续提示状态已变化，无法完成安装

[cindy-issue]

提交人: 灰語
客户端版本: 0.1.69

---

现象

在插件市场尝试安装插件时，安装操作持续失败。界面将该操作判定为账号、插件或客户端版本的状态已变化，并要求确认最新状态后重试，导致插件无法安装。

复现步骤

1. 打开插件市场。
2. 选择任意插件并执行安装。
3. 观察安装结果。

期望行为

点击安装后应正常开始并完成插件安装；不应在未发生用户可见状态变更时要求通过重启或重新打开客户端来恢复安装。

实际行为

安装未完成，界面反复显示状态已变化、请确认最新状态后重试的提示。

复现频率

当前会话中每次尝试均可复现，且不限于某一个特定插件。

已尝试

• 刷新插件市场：问题仍然存在。
• 重新打开客户端、重新登录：用户尚未尝试。

脱敏诊断摘要

用户已同意公开必要的截图证据。截图显示安装操作连续出现相同的通用状态变化错误提示；不含账号、路径、令牌或其他个人信息。

版本区域: CN
OS: win32 x64 (10.0.26200)
Harness: Codex
Model ID: gpt-5.6-terra
界面语言: zh-CN

[dash-s-cindy]

判断：插件市场已经具备公共及自定义来源的安装能力，当前需要处理的是安装事务在前置状态校验失败后，将不同原因统一呈现为“账号、插件或版本已发生变化”，从而让用户无法完成安装。该现象具有明显用户影响，但现有证据还不足以确认具体是哪一个状态发生了变化，因此建议先按可观测性和最小复现推进，而不是放宽或删除安全校验。

行动：

1. 在 Windows、Cindy 0.1.69 上保留一次失败的完整时间点，记录 IPC 错误码、插件 ID、release ID，以及 Main 日志中对应的原始错误；确认是否始终为 PRECONDITION_FAILED。
2. 用同一会话分别测试公共插件和自定义市场插件，并区分市场详情页安装、推荐卡片直接安装、首装和更新。若只有某一路径失败，优先检查该路径传递的快照字段；若所有路径和来源都失败，再检查会话 owner/generation 或全局市场服务状态。
3. 若命中 PRECONDITION_FAILED，按实际分支分类处理：
   • The active account changed during the Plugin operation：检查登录/本地云模式切换或 session generation 是否在 IPC 等待期间被误推进；
   • Plugin release changed after selection：检查目录与详情接口是否返回不一致的 release；
   • Plugin approval state changed during the update：检查 approval token 是否在用户确认前后被不必要地重建或刷新；
   • 若是自定义市场，则检查二次发现、来源 revision 和 expectedReleaseId 是否在稳定来源未变化时发生漂移。
4. 根据日志补充最窄的回归测试，覆盖“状态确实变化时拒绝”和“状态未变化时允许安装”两组边界；同时验证刷新市场不会制造新的快照代际。只有确认是误判后，才调整比较字段或重试策略。

代码定位与现状：

• apps/desktop/src/renderer/features/plugin/lib/pluginMarketErrorKey.ts 将 PRECONDITION_FAILED 映射到 settings.ghosts.market.errors.stateChanged。
• apps/desktop/src/renderer/i18n/locales/zh-CN/common.json:4468 的文案为“操作期间账号、插件或版本已发生变化，请确认最新状态后重试。”这解释了截图中的通用提示，但不能单独证明账号真的变化。
• apps/desktop/src/main/plugin-market/service.ts 的 requireSameMarketOwner() 校验 mode、dataOwnerId 和 generation；安装流程还会重新获取目录和详情，并比较 expectedReleaseId。同文件还在约 1403、1827、1935 行附近校验已安装插件的 approval token 是否变化。
• apps/desktop/src/main/plugin-market/registerIpc.ts 会保留稳定 IPC 错误码；非稳定内部异常才统一转为 INTERNAL。因此应先取得实际 code，而不是从中文文案反推原因。

历史证据：

• PR #2871（已合并）：直接改动插件市场安装/更新确认流程，使用用户确认时的 expectedManifest 贯穿下载、安装和复核，并补充了安装期间状态与并发边界。它与本 Issue 共用核心安装状态模型，是最有价值的实现背景；但记录中没有证明 0.1.69 的“任意插件持续失败”已解决。
• PR #1978（未合并，后关闭）：处理的是 manifest 不兼容被错误映射为通用错误，后续逻辑已在 main 的 service.detail() 中直接返回稳定错误码。它与本 Issue 的“状态已变化”提示不是同一故障，不建议作为当前修复依据。

风险与边界：

• 目前没有证据表明应移除账号、发布版本或 approval 状态保护；这些校验用于避免用户确认的内容在安装期间被替换。
• 也没有证据证明重启或重新登录是可靠修复。它们最多可作为一次诊断对照，不能作为产品层 workaround。
• 如果确认是稳定状态被错误识别为变化，推荐修复比较逻辑、快照代际或错误分类，并保留真实变化时的拒绝行为；修复不应把所有 PRECONDITION_FAILED 自动重试或静默放行。

验证方案：补充 service 层针对稳定 owner、稳定 release、稳定 approval token 的首装/更新回归；覆盖账号切换、release 变化、approval 变化、详情与列表不一致、网络重试和自定义来源 revision 变化。再在 Windows 0.1.69 上完成公共/自定义来源的首装与更新手工验证，并确认成功后账本状态、已安装列表和运行时能力一致。

[GaoWeiLiuXD]

麻烦尝试重启后重试下，如果本地有其他本地开发的 cindy 实例正在运行，请先关闭后然后重启 cindy 重试

[fico-hub]

认领:排查插件安装「状态已变化」必现的判定链路(批准状态/指纹比对)。注:该面属插件基座,若修复需改批准状态语义会按仓规走白名单确认门或转结论回贴。

[fico-hub]

释放认领:维护者已给出排查方向(多实例占用→重启复测),球在提报人侧;且该面属插件基座(安装事务/前置校验),任何语义修复都需走白名单确认门。避免重复投入,待提报人复测结果出来后如仍需仓内修复再跟进。

[KingSystemHaiGo]

补充线索（待验证）：用户发现本机系统时间当时比实际时间快约 5 分钟。插件市场的状态/请求校验可能因此误判账号、插件或版本状态已变化，并持续提示重试。建议排查时检查客户端时钟偏差及时间同步状态。