更新、体检与恢复
根据安装范围更新正确的一份 Build。
只读检查更新
#先看哪些版本可用，再决定是否应用。
能帮你完成什么
检查公开稳定清单、比较当前和目标版本、查看兼容性及变更说明。项目安装还需要识别规则融合状态和入口是否修改。只读检查不会创建更新计划、替换组件或安装模块。
使用前
先确认当前使用用户插件还是项目内安装；检查最新公开清单需要网络。
怎么使用
- 在目标项目明确说“只检查，不更新”。
- 查看安装来源、候选版本、兼容性和阻断原因。
- 选定更新路径后再提出对应的更新请求。
试着这样对 Agent 说
只检查 Motux Build 更新，不安装。请报告当前来源、组件版本、可用版本和兼容性；如需要先处理项目规则或入口冲突，请说明。如何判断完成
- 明确的版本对比和是否可更新的判断。
- 没有因检查而修改项目或插件。
适用边界
- 没有网络时不能把缓存清单冒充最新版本。
更新或修复本机插件
#让共享 Codex 插件使用已验证的正式版本。
能帮你完成什么
用户级更新替换同一个 marketplace 的当前 Plugin 源，并由 Codex 重装同一 selector；新任务使用新缓存。修复针对准确的既有源和缓存，不迁移任何项目。项目中的最小选择不记录 Plugin 版本。
使用前
已安装 motux-build@motux，且明确要求用户级更新或修复。
怎么使用
- 请求比较公开 Plugin 版本和本机实际安装。
- 验证包后更新现有源；比较新旧 Hook，变化时需要重新审查。
- 确认列表中的 installed/enabled 版本，新开任务核验发现。
试着这样对 Agent 说
请更新本机用户级 Motux Build 插件到正式稳定版。校验包和现有安装源，保留同一 motux-build@motux 身份，完成后验证新版发现。如何判断完成
- 本机只有同一份配置身份指向当前正式 Plugin。
- 相同且完整版本为无需更新；Hook 不变时复用既有信任决定。
适用边界
- 项目内安装不随用户插件更新。
- 没有后台自动更新器或用户级全局版本回退入口；旧任务可能仍保留已加载版本。
一次完成合格的项目补丁更新
#所有固定条件满足时，用短指令完成更新。
能帮你完成什么
对于支持 safe update 的完整项目安装，“更新 Motux Build”授权一次稳定补丁尝试。Manager 核验组件完整性、最终兼容组合、规则和入口边界，先验证全部候选再应用；不满足任一门槛时保持零写入并说明原因。
使用前
完整 schema-2 项目安装，Manager 至少 0.1.25，受管理文件未改动，目标为允许的同一 major/minor 补丁，且没有迁移或未解决规则冲突。
怎么使用
- 先确认当前项目确实使用项目内 Build。
- 明确请求安全更新；Agent 通过固定 preflight 确定范围。
- 全部通过后更新被选组件，必要时先完成 Manager 交接，再验证并记录。
试着这样对 Agent 说
更新当前项目内的 Motux Build，按 safe update 固定策略尝试稳定补丁。若不满足条件，保持零写入并说明需要改走哪条流程。如何判断完成
- 成功时得到组件前后版本、验证和可追溯记录。
- 阻断时说明原因，并提供只读检查或普通更新计划入口。
适用边界
- 不包括主/次版本升级、布局迁移、桥接改写、业务代码、额外 Agent 或新产品。
- Manager 0.1.24 及更早版本需先走普通受控更新。
按组件计划更新
#处理需要明确选择和预览的项目更新。
能帮你完成什么
普通更新分为 check、plan 和 apply。计划列出组件、版本、文件范围、完整性、受影响规则、验证与回退；用户确认后才应用。Core 变化时按已采用版本进行增量规则复查。
使用前
项目内安装可被 Manager 识别；你知道想更新的组件或愿意先只读检查。
怎么使用
- 先检查，再生成组件明确的更新计划。
- 解决受影响的规则冲突和授权范围；必要时只更新可独立处理的 Manager 或 Brief。
- 确认具体计划后 apply，体检并维护对应更新记录。
试着这样对 Agent 说
请为当前项目生成普通 Motux 更新计划，分别列出 Manager、Core、Brief 的目标版本、影响文件、项目规则冲突、验证和回退。先不应用。如何判断完成
- 可审阅的更新计划与明确的确认对象。
- 业务文件、项目 overrides 和未选入口保持由各自流程维护。
适用边界
- 计划不是已经应用；不能跳过受管理文件被修改或 Core 规则冲突。
体检、修复判断与项目回退
#在出现异常时先定位，再选择恢复方式。
能帮你完成什么
doctor 检查命名空间、配置、锁、组件文件、产品入口和已记录桥接。它报告问题与修复计划，不能把读状态当作修复授权。项目更新回退优先撤销独立 Motux 更新提交；无 Git 时只按以前记录的已校验产物恢复。
使用前
尽量保留错误、当前文件和更新记录；不要先删 .motux 再尝试。
怎么使用
- 请求只读体检，区分完整性问题、入口问题和业务问题。
- 查看准确恢复范围；有本地修改时先决定如何保留。
- 明确确认修复或回退后执行，再复验组件与加载状态。
试着这样对 Agent 说
更新后 Agent 找不到 Build。请先运行只读体检，区分组件损坏与入口未加载；给出最小修复或回退方案，不要先删除安装目录。如何判断完成
- 明确问题归属以及需要重开任务、修复入口或回退的理由。
- 恢复后既核验文件，也核验当前 Agent 的入口。
适用边界
- Build 体检不是对业务系统、服务器或账户的全面健康检查。
- 插件修复、项目组件回退和独立模块回退是不同操作。
旧布局与早期 Motux Dev
#按实际历史版本选择专门的迁移路径。
能帮你完成什么
Manager 对可识别旧布局先生成迁移计划，而不是直接替换组件。更早的 Motux Dev 使用独立支持包，先核验完整版本指纹，再形成绑定目标的计划和恢复方案；普通安装与安全更新不自动进入它。
使用前
项目确实安装了可验证的旧版本，而不仅是出现名称类似的目录。
怎么使用
- 先只读识别现有安装，不复制新规则到旧目录。
- 根据结果使用普通旧布局迁移或官网“早期版本支持”说明。
- 审阅具体计划，单独确认后迁移，并核验新状态与保留的恢复材料。
试着这样对 Agent 说
这个项目可能使用早期 Motux Dev。请先只读识别，若普通 Manager 不支持，指向官网的独立支持流程，不自动迁移或删除旧内容。如何判断完成
- 明确是受支持旧布局、早期 Dev，还是未知/外来状态。
- 支持路径与普通更新清楚分开。
适用边界
- 名称相似不构成版本证明；未知 .motux 冲突不能强行升级。