---
name: zuix-optimize
description: "审计独立 ZUI 扩展项目的整库质量或编排多库、跨领域优化；仅审计时只读，要求优化或修复时完成规划后直接实施。单独的文档、调试页或 i18n 任务使用对应技能。"
---

# ZUI 扩展库优化

## 解析上下文、范围与模式

1. 按 [共享工作流](../zuix-standards/references/workflow.md) 解析本次所需上下文、读取适用规则并检查所有权；已有且未变化的发现直接复用。读取 [references/audit.md](references/audit.md) 中本次审计涉及的维度，涉及宿主时再读 extension-library 规范。
2. 将用户范围解析为单库、明确包列表或 `extensionRoot` 当前发现的全部扩展包；用真实路径和 package 标识区分目标，不硬编码数量。WIP/notReady 在只读盘点中保留并标记，是否实施由用户请求范围决定。
3. 宿主内置库只作为规范或必要参考，默认不属于修改范围。跨扩展项目或宿主源码优化需要用户明确授权并分别解析所有权。
4. 只要求审计、检查或报告时全过程只读，输出发现和建议。要求优化、完善或修复时，连续完成审计、统一规划、实施与验证，不等待计划确认。
5. 只读审计仅运行不会写入任一仓库、生成目录或缓存的检查，不运行 build、docs 同步、开发服务器、lint `--fix` 或会刷新 build/dist/docs/cache/lockfile 的命令。用户明确要求带构建的只读审计时，优先隔离；无法隔离则先说明副作用并取得许可。实施任务按共享工作流完成必要验证。

`zuiRoot` 或 `extsName` 未唯一解析时仍可完成扩展侧审计，不猜测宿主命令、资源路径或验收结论。需要联合验证才能确认的问题标为 `risk`。

## 盘点与审计

1. 使用扩展 standards 的盘点脚本盘点 `extensionRoot` 全部或指定目标。脚本信号只能筛选，不能替代源码判断。
2. 对单库或当前计划批次中的每个目标，按审计范围追踪相关 package、入口、类型、实现、样式、i18n、正式文档和调试页；全领域审计覆盖这些维度，窄领域审计只展开相关部分。必要时参考相近的扩展实现，再按证据需要补充宿主实现。
3. 大范围任务先依据全部 package 元数据、依赖图、宿主发现结果和现有验证状态浅层分组，再深读本批目标。浅审不能宣称源码缺陷，也不要在整体优先级形成前随机修改第一个库。
4. 按发现领域读取对应技能中影响本次判断或计划的部分；实施时复用已有发现：
   - 规范与 package/宿主契约：`../zuix-standards/SKILL.md`
   - UI 组件：`../zuix-component/SKILL.md`
   - helper/store/utils：`../zuix-helper/SKILL.md`
   - 正式文档：`../zuix-doc/SKILL.md`
   - 调试页：`../zuix-dev/SKILL.md`
   - 国际化：`../zuix-i18n/SKILL.md`
   - 单库跨领域/package 契约：`../zuix-lib/SKILL.md`
5. 按 audit reference 检查扩展源码质量、package 与宿主契约、公开 API、调试、i18n 和规范一致性。每项记录证据、影响、置信状态、严重度、建议、owner skill、文件所有权层和验证方式。
6. 不把风格偏好包装成缺陷。无法从源码、复现或只读结果确认的问题标为 `risk`，加入验证/修复计划，不进行猜测性修改。宿主契约本身的问题单独报告，不把宿主修复偷渡进扩展优化范围。

## 统一优化计划

按共享工作流基于审计结果形成优化计划后直接实施；计划仅展开本次相关决策：

- 四层上下文、目标库清单与真实命名字段、排除项、工作区基线和相似实现；
- 按库列出的 confirmed defect、risk、文档/调试/i18n/package/宿主缺口及优先级；
- 每项优化的目标、非目标、公开 API/兼容性/宿主影响和验收场景；
- owner skill、`targetLibRoot`/`extensionRoot` 内精确文件边界、依赖顺序和跨库影响；
- JSDoc、正式文档、调试页、i18n、public 资源和 package 元数据的纳入范围；
- 扩展侧验证、宿主联合验证、基线失败、批次顺序和剩余假设；
- 按用户请求明确任务范围，列出本次允许修改的库、问题、领域与所有权边界。

单库或少量库形成完整计划后直接实施。全库或大范围先形成路线图，再按可独立验收的批次深审、细化计划、实施和验证，范围内的后续批次不逐批请求批准。

批次选择、优先级调整、任务范围和必要澄清遵循共享工作流。用户只要求审计时不修改文件；实施时始终服从当前协作模式。

## 编排实施

宿主命令的执行位置、生成物与缓存写入统一遵循 [共享工作流](../zuix-standards/references/workflow.md) 的验证隔离与批准规则；下文 `zuiRoot` 表示宿主契约来源，不表示可直接写入原工作区。

1. 当前模式允许编辑时检查 `gitRoot` 状态，按共享工作流复用或刷新受影响的上下文，只实施任务范围。
2. 单库跨领域可用 `$zuix-lib` 作为执行器；窄领域直接用相应技能。把任务范围和已明确决定传给子技能，范围内直接实施；真正超出用户请求或存在无法合理判断的重大歧义时，按共享工作流澄清受影响部分，继续其余工作。
3. 先处理共享基础/helper，再处理依赖它们的组件，随后处理 i18n、正式文档和调试页。互不依赖的包可并行，但每库保持独立验收记录。
4. 仅在真实 `targetLibRoot` 和任务所需的 `extensionRoot` 文件内修改。依赖与 lockfile 按扩展项目策略在 `extensionRoot` 处理；不修改宿主源码、依赖、lockfile 或注册；宿主生成物和缓存写入遵循共享工作流的验证隔离与批准规则。
5. 只修复证据充分且位于任务范围内的问题。新发现记录证据后按依赖和风险纳入适当批次；不顺手扩张。保留合理局部结构与 API，避免无关格式化、重命名、迁移和公共契约破坏。
6. 每完成一个库按共享工作流验证并修复范围内问题，更新账本；批次结束后仅补充尚未覆盖且已获授权的组合构建、文档或浏览器验证，不重复有效检查。宿主上下文、执行位置及服务管理遵循共享规则。

## 交付

- 按库汇报 defect、质量、API/JSDoc、package/宿主契约、正式文档、调试和 i18n 变化。
- 分开记录扩展侧通过、宿主侧通过、基线阻断、未执行与未验证项。
- 对比可验证行为，不用文件数代替质量结果。
- 不手工编辑宿主生成目录代替修改源文件；验证产物和服务管理遵循共享工作流，不自动提交、推送或发布。