能力门控 - AI-native Laboratory Language

能力门控是 FSP 服务的放行判断。它回答的不是“文档上写没写支持”，而是“这台设备在这一次请求中能不能安全执行”。

四层检查

检查层	要回答的问题	信息来源
硬件能力	设备是否具有加液、加热、搬运等所需机构？	设备型号、硬件清单和已核对的设备定义
代码实现	目标设备是否绑定了这份动作契约？	绑定表和程序注册结果
部署就绪	连接、标定、限位、权限和现场验收是否完成？	部署配置、标定记录和验收记录
当前可执行	设备是否在线、空闲，对象和资源是否可用，状态是否足够新？	执行前现场读数、资源锁和权限检查

四层都通过才能进入适配器。任何一层失败都应返回具体原因，且设备命令下发次数必须为零。

静态能力不等于当前可用

情况	应怎样处理
硬件不支持	拒绝，不自动更换设备
宣称支持，但没有对应代码	报告实现缺失，不标记为已实现
已实现，但配置或验收未完成	保留能力说明，标明未就绪的原因
设备或容器被占用	拒绝或按公布的规则排队
状态不知道或已过期	重新观测，在此之前不执行
结果仍在核实	保留必要占用，阻止可能冲突的新动作

可供程序读取的能力描述

{
  "device_id": "device-01",
  "definition_revision": "12",
  "operations": [{
    "operation_id": "add_liquid",
    "contract_version": "1",
    "implemented": true,
    "ready": false,
    "readiness_reason": "现场体积核验尚未完成",
    "limits": [{
      "parameter": "volume_mL",
      "minimum": 0.05,
      "maximum": 0.8,
      "unit": "mL",
      "source": "deployment_policy"
    }]
  }]
}

implemented 只表示代码存在并经过相应检查；ready 表示配置和验收已满足要求。这两个字段都不表示设备当前空闲。给规划程序或 AI 使用的工具 Schema、Function Skill 和说明文档，应从同一份动作契约和已检查的设备定义生成。静态说明不能绕过执行前门控。门控流程伪代码见适配器：能力门控，可运行实现见 GitCode 示例源码。