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。