HGJ UI 组件库

问题背景

在海管家前端项目里，模板里大量出现 el-* 标签，包名是 @hgj/element-plus，CSS 变量前缀为 --hep-*。组件注册名仍是 ElXxx，表面与 Element Plus 很像，但API、默认值和行为已经分叉。若模型仍按开源 Element Plus 文档或记忆写属性与事件，很容易出现「能编译、跑起来却不对」的隐性 bug。

技能如何约束编码

本技能把 LLM 当成组件库的「合规编译器」，核心规则有四条：

• 强制触发：任务涉及任何 el- 前缀或 @hgj/element-plus 时，必须遵循本文档。
• 严禁外参：标准组件 API 不得套用开源版记忆；文档未列出的属性要去查 node_modules/@hgj/element-plus/es/components/**/index.d.ts。
• 标记语义：🔧 独有属性、⚠️ 默认值/行为不同、🔄 用法模式不同（例如属性回调替代事件）。
• 九款高危组件：el-x-table、el-tabs-pro、DialogWrapper（openDialog）、CardContainer 系列、el-highlight-input、el-text-ellipsis、el-notice、NasFile、el-number-flow —— API 与库内标准组件差异大，必须读独立 reference，不能凭名猜。

文档还按业务场景做了速查（表单页、列表/表格、弹窗抽屉、布局、页签、看板、通知），并索引 Basic / Form / Data / Navigation 等标准组件表，便于在对话里快速对齐「该用哪张子文档」。

适用边界

• 仅适用于海管家内部私有 registry 下的 @hgj/element-plus 技术栈，不是通用开源 Element Plus 教程。
• NasFile 等能力依赖 ElConfigProvider 传入的 nas.env，环境未配置时不应假设可用。
• 主题、国际化、Nuxt、手动导入等完整工程配置在 references/setup.md，本技能正文以「写对组件 API」为主，不替代项目脚手架决策。