用途：为开发者提供 Saleor 电商平台与 Configurator 业务逻辑的领域知识，适用于实现新实体类型或功能、理解实体识别模式（slug 与 name）、处理部署流水线阶段、排查配置同步问题、理解业务规则与约束。
主要能力：解释 Configurator 这一“commerce as code”声明式配置管理 CLI 的核心概念，包括以 git 中的 YAML 作为店铺状态唯一真相来源、可版本控制与可复现的部署、声明式优于命令式管理。
实体识别规则：每个实体只有一种识别策略。基于 slug 的实体包括 Categories（如 electronics）、Channels（default-channel）、Collections（summer-sale）、Menus（main-navigation）、Products（iphone-15-pro）、Warehouses（us-east-warehouse）；基于 name 的实体包括 ProductTypes、PageTypes、TaxClasses、ShippingZones、Attributes；Singleton 实体为 Shop，无标识符。
部署流水线顺序（存在依赖）：1 校验、2 商店设置、3 产品类型、4 页面类型、5 属性、6 分类、7 集合、8 仓库、9 配送区域、10 产品、11 税务配置、12 渠道、13 菜单、14 自定义数据模型；产品创建依赖对应 ProductType 先存在。
使用方式：常用命令为 pnpm dev introspect（下载远程配置到本地 YAML）、pnpm dev deploy（将本地 YAML 应用到远程 Saleor）、pnpm dev diff（比较本地与远程配置）、pnpm dev start（交互式首次设置）。
配置 schema 顶层键：shop、channels、taxClasses、productTypes、pageTypes、attributes、categories、collections、warehouses、shippingZones、products、menus、models。批量操作默认按 50 项分块，GraphQL 客户端对 HTTP 429 自动指数退避，最多重试 5 次。
差异比较维度：存在性、字段相等性、子结构相等性；结果为 create、update、delete、unchanged，每种实体有专用比较器，按 slug 或 name 匹配。
限制与注意：需使用正确的识别策略；创建实体须遵守流水线依赖顺序；批量操作需分块；限流由 urql 重试机制处理。具体实现细节参考相关参考文档与源码路径，资料未提供价格与收费信息。