外包源码到手、合并进主仓或能运行，是否就等于完成交付验收？

吕箐翎律师的判断是：外包源码到手后，最容易被混在一起的不是技术动作本身，而是它们各自想回答的问题。收到一个压缩包或取得仓库访问权限，能否说明对方交付了合同约定的全部成果；把一个版本合并进主仓，能否说明企业可以自由使用或继续修改；构建通过、局部测试或形成一份验收记录，能否说明约定的验收范围已经闭合——这些都不能只凭其中一个动作回答。

接收，先确认实际拿到了什么

“已收包”首先是接收事实。应当能够对应到接收包、仓库、分支、标签、提交、构建产物或交付包中的具体识别信息，以及取得的时间和路径。这样才能回答：眼前拿到的究竟是哪一份资料、哪个版本，而不是只留下“源码已给”的概括说法。

但接收事实不自行补足合同范围。技术合同中，成果内容、范围和要求、履行方式、验收标准以及成果归属等约定，本来就可能分别存在。合同、需求、变更和验收约定中写的是哪些成果、格式、环境和整改安排，仍须与实际接收的对象逐项比对。一个压缩包、一项仓库权限或一封交付邮件，不能单独说明合同项下的全部成果已经到位。

合并，说明的是特定版本进入了哪里

合并进主仓可用来核对某一分支、标签、提交或制品在特定时点进入了既有代码库这一动作。它常常是后续构建、测试或维护的前提，但不等于合并前后的代码范围已经与合同约定一一相同，也不说明主仓权限当然覆盖任意修改、再交付或向第三方提供。

因此，合并前后应保留能够识别版本和动作的记录，并把它与接收时取得的对象、约定交付范围分别对应。发现版本、组件或材料之间存在空缺时，现阶段能确认的只是哪个对象、版本或时点尚待核对；不能直接把空缺写成外包方已经违约、存在侵权，或项目必然无法继续。

验收回答的是约定范围内的履行和使用事实

一次构建通过、局部测试、部署后可以使用，或已经付款，都可能是重要记录，却各自只覆盖实际发生的范围。验收需要回到约定的成果、环境、标准和整改安排，再核对实际测试、验收与使用记录所指向的对象和版本。没有把这些材料对齐时，“可运行”不能自动扩展为“全部验收完成”。

反过来，一份验收单也应先看它明确覆盖了哪些成果、版本、时点和事项。它不能当然解决接收时是否包含全部约定资料、合并的是否为同一版本，或后续使用是否超出了既有授权的问题。

交付记录之外，还要单独留出授权链问题

即使接收、合并和验收的记录能够相互对应，开发主体及授权链仍是另一组事实。对于拟接收、合并或使用的具体版本，应分别核对开发主体、委托或许可关系、第三方组件及其授权材料。软件著作权登记、付款凭证或单一压缩包都不能单独替代这部分核对。

准备接收或验收时，可以把现有材料按四个问题暂时分开：合同原本要求什么；实际收到和合并的是哪个对象、版本与时点；测试、验收和使用记录覆盖到哪里；开发与授权材料对应到哪里。某一栏材料不足时，结论应停在相应事实尚待补齐，而不宜先把“收到源码”“已经合并”或“能够运行”概括成项目已经完成交付验收。