# 基础设施保留 / 废弃 / 重建清单（第一版）

本文档定义新 SaaS 项目启动时，哪些基础设施继续保留，哪些只保留经验不保留实现，哪些必须全新重建。

---

## 1. 分类原则

基础设施分为三类：

1. **保留**：直接作为新项目资产继续使用
2. **废弃实现，仅保留经验**：旧实现不进入新主线，但经验可复用
3. **必须重建**：新 SaaS 需要重新搭建

---

## 2. 保留清单

### 2.1 代码仓库

- **保留项**：Gitea
- **原因**：已经是稳定的代码真相源，具备提交、历史、协作、推送能力
- **新项目做法**：新 SaaS 使用新的独立仓库或独立主目录，不与旧桌面版混线

### 2.2 CI/CD 思路和经验

- **保留项**：自动检查、测试、构建、发布的工程理念
- **原因**：这是正规软件必须保留的工程资产
- **新项目做法**：重建适合 Web/SaaS 的流水线

### 2.3 巡检机器人思路

- **保留项**：巡检、告警、状态监控思路
- **原因**：线上系统比桌面工具更需要健康巡检
- **新项目做法**：转为 SaaS 服务、任务、队列、磁盘、worker 的巡检

### 2.4 服务器与开发环境

- **保留项**：Windows 开发机、Ubuntu 服务器
- **原因**：开发和部署基础已有
- **新项目做法**：重新按 SaaS 需要规划开发/测试/生产用途

---

## 3. 旧实现废弃，但经验保留

### 3.1 Tkinter 桌面 UI 工程结构

- **旧实现**：Tkinter 主窗口 + 单体 GUI 文件
- **处理方式**：废弃为新主线实现
- **保留经验**：哪些业务交互复杂、哪些模块最容易耦合

### 3.2 安装版同步 / 发布脚本

- **旧实现**：`deploy_to_installed.py`、安装版同步链
- **处理方式**：不带入新 SaaS 主线
- **保留经验**：发布必须有清单、运行时文件必须明确登记

### 3.3 桌面版更新体系

- **旧实现**：本地补丁、manifest、rollback
- **处理方式**：不直接复用
- **保留经验**：版本状态、回滚、失败恢复、补丁安全校验思路

### 3.4 临时修复脚本文化

- **旧实现**：一批为临时问题而生的脚本
- **处理方式**：明确不继承到新主线
- **保留经验**：哪些问题容易高频复发，需要产品级能力解决

---

## 4. 必须重建的基础设施

### 4.1 新项目仓库结构

必须重建：

- 新仓库目录结构
- 前后端分层结构
- 文档结构
- 基础模块布局

### 4.2 Web/SaaS CI/CD 流水线

必须重建：

- 前端构建
- 后端测试
- 镜像/部署包构建
- 测试环境部署
- 正式环境部署
- 回滚流程

### 4.3 鉴权体系

必须重建：

- 用户认证
- 会话管理
- 权限控制
- 团队/工作区边界（如果需要）

### 4.4 存储体系

必须重建：

- 对象存储 / 素材存储方案
- 数据库存储方案
- 结果文件管理方案
- 清理和归档策略

### 4.5 任务体系

必须重建：

- 任务队列
- 异步生成任务
- 重试机制
- 状态追踪
- worker 管理

### 4.6 观测性体系

必须重建：

- 日志
- 指标
- 告警
- 错误追踪
- 健康检查

### 4.7 配置与密钥管理

必须重建：

- 环境变量规范
- 密钥注入方式
- 不同环境配置管理
- 敏感信息隔离

---

## 5. 项目推进器要不要

### 结论

要，但先轻量，不要一开始就搞太重。

### 轻量方案即可支撑初期

- 需求清单
- 里程碑
- issue / 任务列表
- 发布记录
- 架构文档

### 暂时不需要的重型能力

- 复杂流程引擎
- 重度项目管理系统
- 过度自动化的工单流转

---

## 6. 巡检机器人要不要

### 结论

要保留，而且未来价值更大。

### 在新 SaaS 中的职责

巡检机器人未来可以检查：

- API 服务是否在线
- 队列是否堆积
- worker 是否离线
- 生成失败率是否异常
- 存储空间是否异常
- 数据库连接是否异常
- 定时任务是否失效

### 定位

- 它是运维和健康检查系统的一部分
- 不是业务开发主流程的一部分

---

## 7. CI/CD 要不要

### 结论

必须保留，而且必须升级。

### 新 SaaS 项目里必须具备的能力

- 代码检查
- 自动测试
- 构建
- 测试环境部署
- 正式环境部署
- 回滚

### 原则

- 新项目不能没有 CI/CD
- 但 CI/CD 流程必须服务于 SaaS，不是延用桌面版套路

---

## 8. 当前建议的基础设施策略

### 立即保留

- Gitea
- 现有 CI/CD 思路
- 巡检机器人思路
- 服务器资源

### 立即停止依赖旧实现

- 桌面版发布链
- 安装同步链
- Tkinter 工程结构
- 临时修复脚本文化

### 接下来优先重建

1. 新项目仓库结构
2. SaaS CI/CD
3. 鉴权体系
4. 存储体系
5. 任务体系
6. 观测性体系

---

## 9. 当前阶段结论

新 SaaS 项目不是从零开始，因为我们有：

- 仓库
- CI/CD 经验
- 巡检经验
- 服务器
- 业务规则
- 稳定性治理经验

但新 SaaS 也不能“沿用旧系统实现”，因为：

- 桌面架构不适合作为未来主线
- 发布方式完全不同
- 任务模型完全不同
- 存储模型完全不同
- 用户和权限模型未来也会不同

所以正确策略是：

- **保留资产**
- **废弃旧实现**
- **重建 SaaS 所需基础设施**