# Audit 全量优化路线

## 本次完成

- **更新结果可信**：以第一方 `pluginManager` 的 `application`、`changed`、`error` 和 `incompatible` 为准。兼容性拒绝会记录为 `failed`，不再伪装成「本轮未变化」；同版本重新物化会显示已重新安装并要求重启确认。
- **更新状态可解释**：批量结果继续落盘，单行轮询结果保留管理器错误码、应用阶段和同版本重装标记；批量可在重启后恢复，单行 token 目前只在当前宿主进程内有效。
- **翻译结果可扫描**：`zh.meta.title` 显示在插件名称列，原包名保留在下方；`zh.meta.description` 显示在「优化」列，并以当前落盘状态为准。
- **失败动作可执行**：`incompatible-version`、超时、旧宿主接口等错误都提供下一步动作，不再只显示红色状态。
- **启动兼容性可诊断**：兼容性拒绝不再只保留一个错误码；主表保留原始诊断、运行时版本和 peer 范围，并在行内提示“宿主已跳过：版本不兼容”。

## 当前边界

`一键更新` 仍然由 DSH 第一方管理器执行。它会拒绝与当前 DSH 运行时不兼容的最新版本，并恢复 profile 文件；audit 负责准确呈现拒绝原因，不绕过管理器强装。

截图中的 `@wenaixi/dsh-ponytail@4.9.0-dsh.5` 就属于这一类：它声明 `@deepseek-ai/dsh-skill@^0.1.1-rc.2`，而当前宿主是 `0.2.0-rc.1`。audit 可以在宿主恢复后把这个拒绝原因和处理建议送到表格；它不能在宿主启动前拦截第一方加载器，也不会替代 `dsh plugin allow-version` 绕过安全检查。

2026-09-29 只读核验 npm 元数据时，以下最新版本声明了与当前运行时不一致的兼容范围：

- `dsh-context@0.59.2` 声明 `dshReleases` 为 `0.1.5-rc.1` / `0.1.7-rc.2`。
- `dsh-doublecheck@0.9.17` 的 `engines.dsh` 上限为 `<0.2.0`。

因此当前 DSH `0.2.0-rc.1` 下，点击更新可能被第一方管理器拒绝；正确结果是失败并给出兼容性建议，而不是显示成功或长期锁定「未变化」。上述元数据只作诊断证据，实际安装仍以管理器的兼容性检查为准。

## 下一阶段

### P1：更新前预检

在 `/updates` 中增加只读的 `compatibilityHint`，优先显示「可更新」「最新但不兼容」「无法比对」三种状态。预检只能提示，最终仍由 `pluginManager.installBundle()` 判定。

验收：对最新版本超出当前 DSH 兼容范围的包，表格不再把它计入「一键更新」数量；用户仍可展开详情查看版本和兼容范围。

### P1：翻译工作流分层

把「待生成文案」和「已有文案待落盘」拆成两个可点击 KPI；翻译完成后自动刷新插件页元数据，并保留用户覆盖层的来源、生成时间和回滚入口。

验收：生成、应用、还原三种动作都能在名称列和优化列立即看到结果，重启后结果不回退到英文。

### P2：历史与诊断

增加按插件查看的最近 10 次动作记录，记录 `from/to`、管理器错误码、是否要求重启、日志路径和恢复建议；默认只显示最近一次，避免把设置页变成日志墙。

验收：用户能从单行详情回答「这次为什么没更新」「文件有没有被恢复」「下一步该做什么」三个问题。

### P2：多 profile 与安全边界

把 profile 选择、只读 bundle、宿主管理 bundle 和本地依赖的边界显式放进筛选器；更新锁从单一批次扩展为 profile 级互斥键。

验收：多个 profile 同时存在时，任何一次更新都只影响目标 profile，且不会出现跨 profile 的假状态。

## 暂缓

- 不自建包管理器、不绕过第一方兼容性检查。
- 不把市场搜索、守护进程和冲突修复混进 audit 主流程；这些能力继续复用生态插件或第一方功能。