ZUI 组件开发

准备

按 共享工作流 定位目标、检查所有权并复用已有发现。组件实现读取 组件规范 的相关部分；运行时加载外部资源再读 external-library 规范，涉及包元数据再读 library 规范，其他领域按需路由。

阅读本次判断所需的目标源码；架构或公开契约尚不清楚时再检查相似实现。仅修改目标库，除非批准范围明确包含跨库依赖。

理解与设计

1. 从现有代码、请求及已确认决定推断用途、场景、目标用户和约束。合理沿用既有约定并说明；同一术语仍有无法可靠消除、会实质改变组件身份、包角色、架构或公开契约的歧义时，提出 1–3 个最少必要问题，暂缓依赖该答案的设计，不以假设代替高影响选择。其他只读调查可继续。
2. 只询问无法从仓库发现且会改变设计的信息，通常包括：
   • 需要支持的 HTML/CSS、Preact、vanilla 构造器、zui-create 或 toggle 消费方式；
   • 受控或非受控状态、事件、命令式方法、异步和错误行为；
   • 视觉变体、响应式、键盘、焦点、ARIA 与国际化要求。
3. 提问时说明已确认的背景及问题影响；答案明确后继续相关设计。澄清与实施批准的关系遵循共享工作流。
4. 分别判断包角色和实现架构。不要因为包类型是 component 就默认使用 Preact，也不要因使用 Preact 就改变包角色。
5. 定义最小公开 API、状态或数据流、DOM 生命周期与清理策略。仅暴露真实需要的入口。

确认门禁

尚无适用批准时，在任何文件修改前按共享工作流给出可直接实施的拟实施计划；以下仅展开本次相关决策：

• 类型判断：包角色、组件架构及必要参考依据；
• 目标、非目标和验收场景；
• 公开 API：消费方式、options/props、事件、方法、类型及兼容性；
• 实现方式：渲染、状态/数据流、生命周期、清理、无障碍和 i18n；
• 外部资源（若有）：LibLoader 所有权、注册名、资源/check/依赖、加载时机、失败重试、开发资源与销毁竞态；
• 文件集、入口导出、依赖和 contributes 影响；
• 正式文档与调试页是否纳入；
• 验证方式、边界场景和仍存在的假设。

尚无适用批准时，等待用户明确确认后再实施。批准复用、修订回复、增量范围与等待期间的推进遵循共享工作流，始终服从当前协作模式。

实施

1. 获得确认且当前模式允许编辑后，重新检查工作区状态并按批准计划实施。
2. 使用 Preact 而不是 React，并遵循状态与副作用规范：禁止 hooks，响应式状态推荐 signals，按生命周期清理 effect。跨库导入使用 @zui/<name>；显式维护局部和库入口导出。
3. 运行时外部依赖统一通过库内单例 LibLoader<T> 按需加载，并落实加载失败、重试、异步销毁竞态和第三方实例清理；不要在组件内直接调用 $.getLib、注入资源标签或维护第二份模块缓存。
4. 按 布局与样式规范 优先组合 @zui/utilities 辅助类，只有无法快捷实现时才补充最少自定义 CSS；落实语义标签、键盘、焦点和 ARIA。
5. 仅在批准范围内调用或遵循 $zui-i18n、$zui-doc、$zui-dev；不要借机修改其他领域。
6. 按共享工作流验证本次改动、修复范围内问题并复跑受影响检查；组件验收项目按本次涉及的行为选择。
7. 汇报实现文件、公开 API、验证结果和未验证风险，不自动提交。