diff --git a/docs/下一个专项建议-2026-06-19.md b/docs/下一个专项建议-2026-06-19.md
deleted file mode 100644
index 8d20096d1..000000000
--- a/docs/下一个专项建议-2026-06-19.md
+++ /dev/null
@@ -1,80 +0,0 @@
-# 下一个专项建议（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 挂”的情况
-
----
-
-**建议人**：小虾 🦐