# SaaS 新项目落点与启动方式（第一版）

本文档定义新 SaaS 项目的物理落点、仓库边界和启动方式。

---

## 1. 目标

新 SaaS 项目必须做到：

- 与旧桌面版彻底隔离
- 有单独仓库边界或至少单独根目录边界
- 可以独立开发、测试、部署
- 不会把旧实现混进新主线

---

## 2. 推荐落点策略

### 2.1 推荐方案：独立仓库 + 独立目录

最稳妥方案是：

- 新 SaaS 使用独立 Git 仓库
- 新项目有独立顶层目录
- 旧桌面版继续保留在当前仓库中作为参考样本

### 2.2 推荐目录命名

如果在当前机器上先做本地启动，可以使用：

- `F:\openclaw-saas\`：新项目总目录
- `F:\openclaw-saas\docs\`
- `F:\openclaw-saas\apps\web\`
- `F:\openclaw-saas\apps\api\`
- `F:\openclaw-saas\apps\worker\`
- `F:\openclaw-saas\packages\domain\`
- `F:\openclaw-saas\packages\application\`
- `F:\openclaw-saas\packages\ports\`
- `F:\openclaw-saas\packages\adapters\`

### 2.3 推荐仓库命名

建议仓库名保持清楚：

- `xiaoxia-saas`
- 或 `xiaoxia-autocut-saas`

原则：

- 名字要能一眼看出是新主线
- 不要和旧桌面版仓库名字混淆

---

## 3. 为什么推荐独立仓库

### 好处

- 物理隔离最彻底
- 不会把旧桌面版文件误加进来
- CI/CD、依赖、部署都可以单独设计
- 后续多人协作更清楚
- 更符合正规 SaaS 项目的工程实践

### 风险

- 初期需要重新搭仓库和流水线
- 需要重新整理文档和工程规范

这个成本是值得的，因为它换来的是长期稳定性。

---

## 4. 启动方式

### 4.1 启动前先做的事

1. 确认产品边界
2. 确认一期 MVP
3. 确认技术栈
4. 确认目录结构
5. 确认 AI 工具清单
6. 确认协作制度

### 4.2 启动时要先建的东西

- 新仓库
- docs 总目录
- domain/application/ports/adapters 基础包
- web/api/worker 三个应用入口
- CI/CD 初版
- 测试目录

### 4.3 启动时不先做的东西

- 不先做复杂权限
- 不先做支付
- 不先做多租户高级方案
- 不先做复杂发布市场

---

## 5. 与旧桌面版的关系

- 旧桌面版继续保留在当前仓库中
- 旧桌面版不再继续作为未来主线开发
- 新 SaaS 只参考旧桌面版的业务规则和经验
- 新 SaaS 不依赖旧桌面版的安装链路和 Tkinter 结构

---

## 6. 当前建议结论

### 最佳启动方案

- 独立仓库
- 独立目录
- 独立 CI/CD
- 独立文档
- 独立发布链路

这样新项目才能真正从混乱旧代码中脱离出来。