# Lite 与 Pro 的包边界

SlideStage Lite 是 `.stage` 运行时和共享包的来源。SlideStage Pro 是自托管团队平台。两者共享格式和播放能力，但代码边界必须保持清晰。

一句话原则：**Pro 消费 Lite 发布的包，Lite 不知道 Pro 存在。**

## 为什么需要边界

如果 Pro 直接引用 Lite 源码，或者在 Pro 中复制 Lite 的 loader/schema，会出现三个问题：

- `.stage` 格式漂移：同一份 deck 在 Lite 和 Pro 中校验结果不同。
- 下游补丁堆积：Pro 的临时修复无法自然回到 Lite。
- 版本分支扩散：`isPro`、`VITE_APP_EDITION` 这类判断会污染 Lite。

边界的目标是让 Lite 可以作为独立产品发布，同时让 Pro 稳定复用它。

## 允许的依赖方向

Pro 可以依赖这些已发布包：

- `@slidestage/core`
- `@slidestage/ui`
- `@slidestage/lite-preset`
- `@slidestage/brand`
- `@slidestage/spec`

这些依赖应通过 semver 从 npm registry 安装。

## 禁止的做法

Pro 不应提交：

- `file:../SlideStageLite/...`
- `link:../SlideStageLite/...`
- 从 Lite checkout 的深层相对 import。
- 在 Pro 中重新声明 `manifestSchema`。
- 在 Pro 中复制 `loadDeck` 或路径安全逻辑。
- `isPro` 或 `VITE_APP_EDITION` 这类 edition branching。

如果需要本地联调，可以使用临时 `pnpm link` 或 `yalc` 工作流，但不能把这些设置提交进仓库。

## Pro 如何扩展

Pro-only 行为应该放在 Pro 自己的包中，例如：

- `packages/pro-preset`
- `packages/pro-shared`
- `apps/api`
- `apps/web`

浏览器端功能通过插件或 preset 装配。服务端功能通过 API、数据库和存储层实现。

Lite 不应为了 Pro 加条件分支。需要共享的新能力，应先在 Lite/Core/Spec 中设计为通用扩展点，再由 Pro 消费新版本。

## `.stage` 契约归属

`.stage` 格式由 `@slidestage/spec` 定义。

这意味着：

- Manifest 字段变更先从 spec 开始。
- Loader 和路径安全逻辑通过 `@slidestage/core` 消费。
- Pack、Lite、Pro 都应对同一份 `.stage` 给出一致结果。

Pro 上传 pipeline 应使用 Lite/Core 的能力，而不是自己写一套 zip/manifest 规则。

## 品牌资产归属

品牌资产和产品 registry 由 `@slidestage/brand` 维护。

Pro 可以在构建时把品牌资产同步到自己的 public 目录，但同步结果应是生成物或忽略文件，不应复制一份新的品牌源文件。

## 什么时候改 Lite

如果 Pro 需要一个能力，而这个能力对 `.stage` 格式、播放器、converter 或共享 UI 也有意义，应优先在 Lite 侧提出。

例子：

- 新 manifest 可选字段。
- 新 trust capability。
- 新 loader error code。
- 新 converter source kind。
- 新可复用 viewer UI primitive。

改完 Lite 并发布包后，Pro 再通过 semver 升级使用。

## 检查清单

提交 Pro 改动前，确认：

- 没有 `file:` 或 `link:` 指向 Lite。
- 没有从 `../SlideStageLite` import。
- API 层没有 import React。
- Web 层没有 import Prisma、Hono 或 Node 文件系统模块。
- `.stage` 校验来自 `@slidestage/core` / `@slidestage/spec`。
- Pro-only 能力位于 Pro 包或 Pro apps。