工程项目经常会卡在一个外部条件上：授权素材还没拿到，第三方接口仍在审核，关键 SDK 尚未安装，或者真正的运行环境不在当前机器上。
最危险的处理有两种。一种是完全停工，把所有问题都推迟到依赖到位之后；另一种是用模拟结果填满报告，让项目看起来已经完成。
在 Freedom G 多人对战原型中，正式的 Unreal / Lyra 工程尚未到位。我选择了第三条路：明确承认阻塞，同时把不依赖最终运行环境的工程工作做实。
先把“完成”定义成证据
“战斗系统完成”是一个模糊句子。更可执行的定义是：专用服务器启动；两个客户端进入同一场比赛；攻击、格挡、闪避和能量技能在服务端正确结算；结果成功写入后端；排行榜可以读回；每一步都有来自真实运行日志的证据。
当最终证据被提前定义，团队会清楚哪些工作现在可以完成，哪些必须等待真实环境。它也阻止临时样例被误当成端到端结果。
把外部依赖变成明确的前置检查
依赖缺失不应该在构建到一半时才以神秘错误出现。项目增加了前置检查和结构化状态：
OK：条件真实存在且已经验证；BLOCKED：需要外部动作，但已有恢复说明；MISSING：项目自身应该具备的文件或契约缺失；FAIL：已经执行，但结果不符合要求。
这几个状态看似简单，却能把“做不了”拆成完全不同的后续动作。外部阻塞不等于内部失败，内部缺失也不能用“环境问题”掩盖。
在等待期间，可以完成什么
即使最终引擎不在，仍然可以推进大量高价值工作：
- 定义模块边界、数据结构和接口契约；
- 完成独立后端并用真实请求验证登录、匹配、结算和防重放；
- 为未来要创建的资产建立清单和校验器；
- 编写安全导入、构建、启动、停止和部署脚本；
- 为真实运行日志定义证据标记和收集规则；
- 把每个阻塞点写成下一位执行者可继续的恢复步骤。
这些工作不会替代最终端到端测试，但会显著缩短依赖到位后的集成路径。
Smoke 只能证明门禁会工作
项目允许用临时日志做只读 Smoke 检查，验证解析、脱敏和完整度规则是否正确。但 Smoke 结果被放在独立位置，不会写入正式证据目录，也不能让最终完成门禁通过。
这是一个重要边界：模拟数据可以测试测量工具，不能证明被测系统已经运行。许多“AI 辅助完成”的假象，就发生在这两种证据被混在一起的时候。
可恢复交接也是工程成果
一个好的阻塞状态应该包含：缺什么、已经做了什么、为什么不能继续、依赖到位后运行哪条命令、预期看到什么、失败时看哪里。
当这些信息齐全，项目虽然没有完成，却不是一堆无法使用的半成品。它处于一个诚实、可接手、可验证的中间状态。
工程成熟度不只体现在顺利时跑得多快，也体现在条件不完整时，能否继续创造真实价值，同时不把“准备好了”说成“已经完成”。