dev-manager-tauri/.blueprint/modules/gitea-integration.md

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 切换 + 推送，安全增量，不丢历史