diff --git a/tasks/014-full-package.md b/tasks/014-full-package.md
index bf89a44..af7e77d 100644
--- a/tasks/014-full-package.md
+++ b/tasks/014-full-package.md
@@ -64,19 +64,41 @@ SHA256SUMS.txt
 
 ## 实测记录（v0.2.0 发布时）
 
+按文档 §5.7 硬性要求 4「若用 A 方案，先在发布文档里记录实测上限」记录。
+
 | 上传体积 | 结果 | 说明 |
 |--|--|--|
 | 14 MB | 通过（HTTP 201） | 分卷时代的对照 |
 | 30.5 MB / 40 MB | **HTTP 413** | IIS 默认 `maxAllowedContentLength` 未放开 |
-| **38,245,661 B（本整包）** | 请求体被**完整接收**（115 s），但 **Gitea 返回 HTTP 500** | IIS 上限已放开，瓶颈转移到 Gitea 侧 |
+| **38,245,661 B（本整包）** | 请求体被**完整接收**（115 s），随后 **Gitea 返回 HTTP 500** | IIS 上限已放开，瓶颈转移到 Gitea 侧 |
 
-放开 IIS 之后同接口的边界测量：914 KB 与 16,372,427 B 通过；
-16,400,000 B 及以上失败；**在若干次大包失败之后，连 100 KB 都会在 0.3 秒内 500** ——
-更像**上传临时目录 / 数据盘写满**（Gitea 先写 `data/tmp`），而不是体积上限。
+IIS 放开之后的隔离测试（同一 Release 资产上传接口）：
 
-→ 结论：**只放开 IIS 不足以放行 38 MB 整包**，还需要
-①清理/扩容 Gitea 数据盘（尤其 `data/tmp`）②`app.ini` 的 `[attachment] MAX_SIZE`。
-详见 `opendance-web/deploy/proxy/README.md` 第九节。
+| 上传体积 | 结果 |
+|--|--|
+| 914 KB / 927 KB（web tar.gz） | 通过 |
+| 16,372,427 B（android zip） | 通过 |
+| 37 MB（本整包） | HTTP 500 |
+| 24 / 21 / 18 / 16.5 / 16.4 MB | HTTP 500 |
+| **100 KB / 1 KB** | **HTTP 500，0.14~0.3 秒** |
+
+结论（与最初"体积上限"的猜测不同）：
+
+1. **与体积无关**：1 KB 也失败，而且是**瞬间**失败（不是读完请求体才判断），
+   所以不是 `MAX_SIZE` 这类体积限制；
+2. **与仓库无关**：三个仓库的 Release 资产上传接口同样失败；
+3. **其他写入通道正常**：创建 Release、PATCH Release 说明（纯 JSON）都成功；
+4. **间歇性**：全部失败期间仍有 927 KB 的附件成功上传过一次。
+
+→ 最可能是 **Gitea 宿主机磁盘（或上传临时目录所在分区/tmpfs）几乎写满**：
+Gitea 先把请求体写进数据目录的临时目录再落库，空间不足时返回 500 而不是 413。
+运维需按 `opendance-web/deploy/proxy/README.md` 第九节：
+①`df -h` 查数据盘 / `/tmp` / `data/tmp` ②看 Gitea 日志里这次 500 的真实错误
+③清理临时文件与旧附件释放空间 ④把 `[attachment] MAX_SIZE` 设为 256 并重启。
+
+> 说明：本仓库 v0.1.0 的 `.part0/1/2` 分卷已被确认是交付缺陷（用户无法直接解压），
+> 本仓库的打包脚本**不会**再生成分卷；整包与 `SHA256SUMS` 已就绪，
+> 等上述空间问题解除后立即上传。
 
 ## 上传前检查清单