81 lines
2.0 KiB
Markdown
81 lines
2.0 KiB
Markdown
# 下一个专项建议（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 挂”的情况
|
||
|
||
---
|
||
|
||
**建议人**：小虾 🦐
|