参数：调用方该填什么

参数是什么，有哪些类型

上一节写的 confirm-order 只有一个订单参数。这一节专讲参数：它是 Action 与外面所有调用方（表单、工作流步骤、智能体）之间的接口。规则和提交条件都靠参数名取值，参数设计得好不好，直接决定 Action 好不好用。同一个 Action 的调用方各不相同：表单前的人、工作流的一步、智能体，它们传的是同一组参数，过的是同一套校验。

有一条数字要记住：一个 Action 一次最多改 10,000 个对象。对象集或对象列表命中的对象超过 10,000 个，整个请求会被拒绝，而不是只处理前面一部分。

用限制把错误挡在入口

限制直接写在参数上：数值用 min、max，文本用 maxLength，对象要写 objectType。要复用「取值只能是这几个」之类的规则，就引用值类型（valueType），它的约束（enum、range、length、regex 等）在写入时用同一套校验。校验结果逐个参数返回，--validate-only 能看出是哪一个不合格。

下面是示例工厂的 release-work-order：把一张计划中的工单下达到一条产线。提交条件留到第 4 节。

{
  "kind": "actionType",
  "apiName": "release-work-order",
  "title": "下达工单",
  "schema": {
    "parameters": [
      { "name": "workOrder", "type": "object", "objectType": "workOrder", "title": "工单", "required": true },
      { "name": "line", "type": "object", "objectType": "productionLine", "title": "产线", "required": true },
      { "name": "startAt", "type": "timestamp", "title": "计划开工时间", "required": true }
    ],
    "rules": [
      {
        "type": "modifyObject",
        "objectType": "workOrder",
        "object": "$workOrder",
        "values": { "status": "released", "lineCode": "$line.lineCode", "startAt": "$startAt" }
      }
    ],
    "actionLog": true
  }
}

注意 line 是对象参数，规则用 $line.lineCode 取它的属性。调用方从产线里选一条，而不是手敲编码。

值类型让一条约束只写一次：severity 的取值由 defectSeverity 约束，登记缺陷的 Action、缺陷对象的属性，以及以后别的用到它的地方，用的是同一份约束。

必填、可选，与不该让人填的值

required: true 的参数缺了就是不合格，返回里会指名是哪一个。可选参数没传时，规则不会去动对应的属性。report-output 就靠这一点：这一班没有报废，就不传 scrapQty，属性保持原值，不会被写成 0。

[
  { "name": "workOrder", "type": "object", "objectType": "workOrder", "title": "工单", "required": true },
  { "name": "goodQty", "type": "integer", "title": "累计合格数", "required": true, "min": 0 },
  { "name": "scrapQty", "type": "integer", "title": "累计报废数", "min": 0 }
]

上面是 report-output 的 parameters 数组，它的规则是一条 modifyObject：把 goodQty、scrapQty 写进工单，并把 status 写成 running。有些值根本不该由调用方填：执行人、当前时间、新对象的主键。这些直接在规则里写 $user、$userName、$now、$uuid：调用方改不了，也不会出现在表单上。create-purchase-order 就这样处理：poNo 用 $uuid，起草人 ownerId 用 $user。

通用做法里有、AIDC 里还没有的