xiaoxia-saas/docs/下一个专项建议-2026-06-19.md

下一个专项建议（2026-06-19）

建议结论

下一个最该开的专项：CI/CD 稳定性修复专项

原因不是它最有趣，而是它当前最影响整体工程推进效率。

---

为什么优先做这个

1. 它已经成为当前最明确的交付阻塞点

• 提交 e5d5ae4 对应 ci-cd.yml #239 已确认失败
• 失败点在 Code Quality Check
• 这意味着“本地验证通过”还不能稳定转化为“远端门禁通过”

2. 它是所有后续专项的放大器

如果 CI/CD 不稳定：

• 后续前端、后端、生成链、文档治理都会重复被卡
• 质量门禁会名义存在、实际失效
• 团队会更容易回到“先做再说”的旧路径

3. 它符合当前规则约束

老大已经明确：

• 本轮只记录问题，不顺手修改 CI/CD
• 下次需要单独规划、单独执行

所以把它作为下一个专项，本身就是对当前规则的严格执行。

---

专项目标

把当前 CI/CD 从“曾经跑通过，但不稳定”收口到：

• 质量检查工具链稳定可执行
• .gitea / .github 工作流保持一致
• feature 分支提交能稳定得到可信结果
• CI 成为真正可依赖的交付门禁

---

专项边界

本专项只处理：

• CI 工作流执行链
• 开发依赖工具链安装与调用方式
• 容器/venv/依赖入口一致性
• 与 CI 直接相关的文档与验证脚本

本专项不处理：

• Phase 7 业务功能扩展
• 真实生成逻辑深化
• 前端新页面开发
• 非 CI 主线的历史代码债

---

建议执行顺序

1. 复盘 #239 失败点与可复现条件
2. 核查 requirements-dev.txt / workflow / 质量工具调用方式
3. 形成专项修复方案文档
4. 在独立分支完成修复
5. 用 feature 分支提交做验证
6. 更新进度文档与专项清单

---

成功标准

• Code Quality Check 稳定通过
• Run Tests 稳定通过
• Build Summary 按规则触发
• 同类提交不再重复出现“本地过、CI 挂”的情况

---

建议人：小虾 🦐