ZUI 库开发
分析
- 按 共享工作流 完成所需发现并复用已有上下文;读取 库规范 的相关部分。
- 判断目标是新库还是已有库,并检查工作区状态。已有库保持合理的局部目录与 API 风格,不顺带迁移无关代码。
- 从目标和必要参考识别本次涉及的包角色、贡献与消费方式;需要定位或筛选时使用盘点脚本。仅询问无法发现且会改变本次设计或验收的信息。
- 根据请求选择需要的领域,规划时读取影响本次决策的技能和参考部分;实施时沿用这些发现:
- UI 组件:
../zui-component/SKILL.md - helper/store/utils:
../zui-helper/SKILL.md - 国际化:
../zui-i18n/SKILL.md - 正式文档:
../zui-doc/SKILL.md - 调试页:
../zui-dev/SKILL.md
- UI 组件:
一次集成计划
尚无适用批准时,完成本次必要的发现与设计,不修改文件。按共享工作流输出一份拟实施集成计划;以下仅展开本次相关决策:
- 新库/已有库判断、包角色、相似库及理由;
- package 名称、版本、入口、依赖、
zui.type、displayName、准确contributes和可选导出; - 组件与 helper 的类型、公开 API、状态/数据流、生命周期及文件集;
- i18n 的语言、命名空间/静态映射和加载路径;
- 正式文档类别、调试页场景和资源;
- 依赖顺序、跨库影响、非目标、验收场景、验证命令和假设;
- 明确标记的“拟实施范围”,列出目标库、公开 API、允许修改的领域与文件边界。
尚无适用批准时,等待用户对整份计划明确确认后再实施。批准复用、修订回复与增量范围遵循共享工作流,始终服从当前协作模式。
编排实施
- 确认且当前模式允许编辑后,重新检查工作区状态。
- 新库先创建最小准确骨架:
@zui/<kebab-name>、0.0.1、package.json、src/main.ts、files、正确元数据,以及实际需要的tsconfig.json。已有库只调整批准范围内的骨架或元数据。 - 按实际依赖顺序遵循选中的领域技能,传递已有发现和已批准范围;子流程按共享工作流复用上下文及批准。
- 目标、公开 API、包角色或文件边界需要超出批准范围时,按共享工作流暂停受影响部分,更新增量计划并再次确认;继续范围内不受影响的工作,不让子技能自行扩大范围。
- 检查所有入口真实存在、内部依赖分类正确、文档和调试示例与 API 一致。
- 按共享工作流合并所需验证、复用有效结果,修复本次引入且位于范围内的问题并复跑受影响检查;范围外问题单独报告。
- 汇报已完成范围、关键 API、验证结果和剩余风险,不自动提交。