/store-module-architecture

name: store-module-architecture
description: 处理 BK-CI 研发商店中的插件、模板、镜像等组件发布、审核、安装、统计和扩展点机制时使用。当用户提到商店组件上架、插件发布、模板分发、安装升级或市场能力时优先使用。

Store 模块架构

适用场景

• 发布或管理插件、模板、镜像等商店组件
• 处理审核、上架、下架、安装和升级
• 理解商店中的组件类型、状态流转和统计逻辑
• 处理商店扩展点、分类标签、成员和评论等能力

不适用场景

• 只是单个插件执行逻辑，不涉及商店生命周期
• 只是模板模块内部逻辑，不涉及商店分发
• 只是镜像运行或制品归档，不涉及商店管理

快速指导

1. 先判断问题属于哪条主线：

• 商店基础与组件类型：看 `reference/1-store-foundation.md`
• 发布、安装、审核与扩展：看 `reference/2-release-install-extension.md`

2. `Store` 的重点不是组件“怎么执行”，而是组件“怎么进入市场、被审核、被安装和被统计”。 3. 插件、模板、镜像三类组件共享商店心智，但生命周期细节不同，不要强行一套处理。 4. 如果问题已经落到模板实例或插件执行本身，接下来切到对应模块 skill。

高信号规则

• `Store` 负责组件生命周期与分发，不负责具体执行引擎
• 组件状态流转通常比单次业务动作更关键
• 商店能力常常叠加分类、标签、成员、评论、统计和审核
• 安装和升级问题要同时看来源组件版本与目标项目落地状态

关键陷阱

• 把插件、模板、镜像完全当成同一种组件处理
• 只看发布流程，不看审核和下架回收链路
• 商店安装成功就默认目标项目已经完全可用
• 只排查组件元数据，不排查安装后的资源同步

延伸阅读

• 商店基础：`reference/1-store-foundation.md`
• 发布与安装：`reference/2-release-install-extension.md`
• 涉及模板分发时：再看 `pipeline-template-module`
• 涉及插件执行时：再看 `pipeline-plugin-development`