# Gitea 集成

对接已有的自建 Gitea 实例，作为所有被管理项目的统一 git 后端。接入包「增配档」的核心。

## 风筝线模型（炼境与 Gitea 的关系）

🪁 **风筝 = Gitea 本体**（git 存储 + CI 执行）：独立部署、独立运行，炼境**不托管其进程、不背运维**。
🧵 **线 = 炼境的掌控**（控制面）：炼境是**唯一持线人**——Gitea 连接/token 统一存炼境，建仓/关联/迁移/配置 lefthook&CI 的操控全经炼境，子项目对 Gitea 的动作都从它手里过。
👀 **关注风筝的动态 = 观测面**（飞轮燃料）：炼境持续感知每个子项目 ↔ Gitea 的连接动态（push 的 commit type/scope、PR、CI 三阶段、review、停滞项目）。

> 「线」≠ 松散 API 对接：炼境是**主动掌控者**而非被动客户端。风筝越多 → 线越多 → 动态越丰富 → 飞轮越强（契合核心愿景）。

## 其他边界

- 替代炼境现有 GitHub 能力：`github-auth` / `github-publish` 已冻结，`cicd.rs` 的 GitHub Actions 生成改造为 Gitea Actions
- 炼境自身仓库也迁 Gitea（发布产物仍走 OSS updater 不变）

## 参考实现

`enterprise-system` 已趟通完整链路，属「照搬」而非「从零探索」：
- Gitea origin（`git.yljt.info`）+ Gitee 镜像（备份）
- lefthook 强制 conventional commit + typecheck（pre-commit）
- Gitea Actions 三阶段 CI：静态检查 → 测试（DeepSeek-V3 自修）→ PR code review（DeepSeek）
- Gitea Actions 语法兼容 GitHub Actions，迁移成本低

> 详见 `E:/code-project/enterprise-system/docs/ai-context/git-workflow.md` 与 `AGENTS.md`。

## 任务卡（concept，待 /architect）

### 💭 Gitea API 对接（握线基础）
- status: concept
- complexity: L
- acceptance: TBD —— 建仓/关联、推送、读 CI 状态、读 PR review 结果

### 💭 观测面：Gitea webhook 接入（持线人感知动态）
- status: concept
- complexity: L
- files: src-tauri/src/mcp_server.rs（内嵌 HTTP server 加 webhook 端点）, src-tauri/src/commands/blueprint.rs
- acceptance: TBD —— 复用炼境内嵌 HTTP server 新增 Gitea webhook 接收端点；实时接住各子项目 push/PR/CI/review 事件 → 解析 conventional commit（对接 flywheel-intelligence 的 L0 解析层）→ 写飞轮快照 + 刷新连接动态；webhook 不可达时降级为定时轮询 Gitea API

### 💭 Gitea Actions workflow 生成
- status: concept
- complexity: M
- files: src-tauri/src/commands/cicd.rs（改造）
- acceptance: TBD —— 生成 Gitea Actions 三阶段 CI 模板（语法兼容 GitHub Actions）

### 💭 DeepSeek CI review 集成（可选插件）
- status: concept
- complexity: L
- acceptance: TBD —— 静态检查 + 测试自修 + PR review；作为复杂项目可选增配，不进基线档

### 💭 旧项目 GitHub → Gitea 迁移
- status: concept
- complexity: M
- acceptance: TBD —— remote 切换 + 推送，安全增量，不丢历史