ZUI 库优化

确定范围与模式

1. 按 共享工作流 定位仓库并复用已有上下文。
2. 读取 references/audit.md 中本次审计涉及的维度。
3. 将用户范围解析为：
   • 单库：一个 lib/<name> 或 @zui/<name>；
   • 多库：明确名称列表；
   • 全库：当前 lib/*/package.json 实际发现的全部内置库。不要沿用硬编码数量；exts/ 仅在用户明确纳入时处理。
4. 检查 git status，记录用户已有改动和可用验证基线。明确“全库”默认在只读盘点中包含 WIP/notReady 内置库并单独标记；是否实施这些库的优化由批准范围决定。目标名称或是否包含扩展库仍不明确时，先提出最少必要问题。
5. 区分请求模式：
   • 只要求审计、检查或报告时保持只读，输出发现和修复建议；
   • 要求优化、完善或修复时，先只读审计，再进入统一计划确认门禁。
6. 确认前只运行不会写入仓库、生成目录或缓存的检查。不要运行 pnpm build、文档同步、开发服务器、lint --fix 或其他会刷新 build/、dist/、docs/_、cache 的命令；把它们列入批准后的验证。用户明确要求带构建验证的只读审计时，优先使用仓库外临时输出，否则先说明副作用并取得许可。

盘点与审计

1. 运行 ../zui-standards/scripts/inspect-zui-lib.mjs 盘点全部或指定目标。多库可逐库使用 --lib；脚本信号不能代替源码判断。
2. 对单库或当前待计划批次中的每个目标，按审计范围追踪相关 package、入口、类型、实现、样式、i18n、正式文档和调试页；全领域审计覆盖这些维度，窄领域审计只展开相关部分。必要时选择角色、架构或消费方式相近的成熟实现。
3. 大范围任务先依据全体 package 元数据、盘点信号、依赖和现有验证状态做浅层分组，再深读本批目标。浅层盘点不能宣称已确认源码缺陷；不要在尚未形成整体优先级时随机修改第一个库。
4. 按发现类型读取对应领域技能中影响本次判断或计划的部分；实施时复用已有发现：
   • 规范与包角色：../zui-standards/SKILL.md
   • UI 组件实现：../zui-component/SKILL.md
   • helper/store/utils：../zui-helper/SKILL.md
   • 正式文档：../zui-doc/SKILL.md
   • 调试页：../zui-dev/SKILL.md
   • 国际化：../zui-i18n/SKILL.md
   • 单库跨领域或 package 契约：../zui-lib/SKILL.md
5. 按 audit reference 检查代码质量、缺陷、公开 API 文档、调试示例、i18n 和规范一致性。每项发现都记录证据、影响、置信状态、严重度、建议处理和负责技能。
6. 不把风格偏好包装成缺陷。无法从源码、复现或构建结果确认的问题标为风险并制定验证/修复计划，不进行猜测性修复。

统一确认门禁

尚无适用批准时，在任何文件修改或生成产物前按共享工作流输出拟实施优化计划；以下仅展开本次相关决策：

• 目标库清单、范围排除项、工作区基线和相似库；
• 按库列出的已确认缺陷、风险、文档/示例/i18n/规范缺口及优先级；
• 每项优化的目标、非目标、公开 API/兼容性影响和验收场景；
• 选用的兄弟技能、文件边界、依赖顺序和跨库影响；
• 源码 JSDoc、正式文档、调试页及 i18n 的纳入范围；
• 每库验证命令、基线失败、批次顺序和剩余假设；
• 明确标记的“拟实施范围”，精确列出本次允许修改的库、问题和领域。

单库或少量库若能一次形成决策完整计划，只等待一次明确确认。全库或大范围默认先给出只读路线图，并提交第一个可独立验收批次的完整计划；每个后续批次在深审后再确认，除非用户已明确批准其中每项具体修改。不要让一次笼统的“优化全部”授权未知改动。

尚无适用批准时，请求用户明确确认后再实施；批准状态、包含批次选择或优先级调整的授权回复及等待期间的推进方式遵循共享工作流。用户只要求审计时不请求实施确认，也不修改文件。始终服从当前协作模式。

编排实施

1. 确认且当前模式允许编辑后，重新检查工作区，只实施已批准范围。
2. 对单库跨领域优化可调用 $zui-lib 作为该库执行器；窄领域直接调用相应技能。不要让 $zui-lib 与直接子技能重复处理同一项。
3. 将“由 zui-optimize 记录的用户已批准精确范围”传给子技能；范围内跳过子技能的重复确认。目标、公开 API、兼容性、跨库影响或文件边界需要超出批准范围时，按共享工作流仅暂停受影响部分，并返回本技能提出增量计划及确认。
4. 先处理共享基础和 helper，再处理依赖它们的组件，然后依次处理 i18n、正式文档和调试页。互不依赖的库按批次并行或顺序执行，但不得混淆各库验收结果。
5. 只修复证据充分且已批准的问题。实施中发现的新问题若不在范围内，记录到下一批；不要顺手扩张。
6. 保留已有库合理的局部目录与 API 风格，避免无关格式化、重命名、迁移和公共契约破坏。
7. 每完成一个库按共享工作流验证并修复范围内问题，更新进度账本；批次结束后仅补充尚未覆盖的组合构建、文档或浏览器验证，不重复有效检查。

交付

• 按库汇报已修复缺陷、质量改进、API/JSDoc、正式文档、调试示例和 i18n 变化。
• 区分通过、被基线阻断、未验证和移入后续批次的事项。
• 对比优化前后的可验证行为，不用文件数量代替质量结果。
• 不手工修改 docs/_ 代替文档源；验证产物及服务管理遵循共享工作流，不自动提交、推送或发布。