diff --git a/rfcs/0014-online-packaging-repo.md b/rfcs/0014-online-packaging-repo.md
new file mode 100644
index 0000000..9971d4b
--- /dev/null
+++ b/rfcs/0014-online-packaging-repo.md
@@ -0,0 +1,69 @@
+# 联网构建仓库提案
+
+- 提案发起时间：2025-06-05
+- 提案拉取请求：https://github.com/deepin-community/rfcs/pull/14
+
+## 概要
+
+在 commercial 仓库推送无法满足离线构建条件，需要在线构建的软件包。
+
+## 动机
+
+当前 Deepin 的软件包构建体系主要基于离线环境，这在大多数情况下能够保证安全性和稳定性。然而，由于社区人力有限，Rust 等生态的软件包（crate）又更新频繁，依赖关系复杂，Deepin 官方仓库中的 librust 库往往更新滞后，导致开发者经常遇到依赖无法满足的情况。
+
+在实际开发中，许多软件包需要及时获取最新的依赖才能正常构建。现有的离线构建机制无法灵活应对这类需求，导致软件包更新周期过长，影响用户体验。因此，我们需要在保证安全性的前提下，为部分软件包引入更灵活的构建机制。
+
+
+## 详细设计
+
+本提案建议为特定类别的软件包启用联网构建机制。这些软件包将不通过传统的 Open Build System (OBS) 进行构建，而是使用 GitHub Actions 等现代 CI/CD 工具完成构建流程。构建过程中允许从官方源（如 crates.io）下载必要的源代码依赖，但必须严格遵守安全规范。
+
+构建完成后，生成的二进制包将被推送到专门的 commercial 仓库，与主仓库隔离。这种设计既满足了部分软件包的构建需求，又不会影响主仓库的稳定性和安全性。该方案特别适合那些依赖更新频繁、但自身稳定性要求较高的终端用户应用程序。
+
+### 构建可复现性保障
+
+所有联网构建必须确保完全可复现。例如 Rust 项目必须提供完整的 `cargo.lock` 文件锁定依赖版本。构建系统需要记录所有下载的依赖及其校验信息，确保后续构建能够还原完全相同的环境。
+
+例如，对于 Rust 应用，我们强制要求构建脚本中必须使用 `cargo fetch --locked` `cargo build --frozen` ，禁止构建过程中更新锁文件。
+
+### 严格的下载限制
+
+禁止下载以下内容：
+
+- 预编译的二进制文件
+- 运行时依赖
+- 仅本项目使用，可放置于离线打包仓库内的资源
+- 未明确在仓库内记录哈希值并在构建时验证的资源
+
+### 软件包准入标准
+
+适用联网构建的软件包必须满足以下条件：
+
+- 必须是面向终端用户的独立应用程序
+- 不得作为其他软件包的构建依赖或运行时依赖
+
+不适用该机制的软件包包括：
+
+- 系统基础组件
+- 共享库
+- 任何可能被其他软件包依赖的组件
+
+### 预期效益
+
+实施该方案后，我们预期将获得以下改进：
+
+1. 显著提升 Rust 等现代语言软件包的更新速度
+2. 降低开发者维护软件包的负担
+3. 为用户提供更丰富、更新的应用程序选择
+
+该方案将在严格控制风险的前提下，为 deepin 生态系统带来更大的灵活性，更好地满足开发者和用户的需求。
+
+## 可能存在的问题
+
+在不耗费大量人力进行全面审计的前提下。我们实际上无法确保包管理器在安装依赖过程中的行为。如 Rust 平台的 `build.rs`，npm平台的 `postinstall` 等自定义脚本可能会运行各种预期外的命令。
+
+我们尽力保证参照其他发行版的打包行为，在代码审阅的过程中发现并修正不符合本规范的行为，但无力确保仓库内的所有软件包都完全在我们的控制之下。
+
+## 替代方案
+
+使用自动化设施自动打包一个 Rust 应用的所有 librust 依赖至仓库，但可能会导致仓库体积失控和潜在更复杂的依赖冲突。