# 下一个专项建议（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 挂”的情况

---

**建议人**：小虾 🦐