Build a job form without hardcoding its inputs

If you put a Rendobar job behind a form, you already know the awkward part. GET /jobs/types/{type}/schema told you every parameter a job accepts, with types and defaults and options, and then said nothing at all about the media the job actually reads, which is half of what a job needs to run. So the parameters rendered as proper fields and the media became a textarea where someone types JSON by hand.

The schema now describes the inputs too.

{
  "type": "caption.burn",
  "fields": [ /* parameters, unchanged */ ],
  "inputs": {
    "fields": [
      {
        "key": "source", "name": "source", "label": "Source Video",
        "type": "string", "required": true,
        "url": true, "multiple": false
      }
    ],
    "variadic": false
  }
}

Each entry is an ordinary field plus the two flags an input needs. url says the value is a media URL rather than free text, so you can render a file picker or validate a link. multiple says it takes a list.

variadic is the one worth reading twice. It says the job type accepts any filename as an input key rather than a fixed set, which is how ffmpeg and ffprobe work. Their inputs become files in a working directory and the command itself decides what they are called, so no fixed list could ever describe them. A form that respects the flag offers a key-value editor for those two types and named fields for the other seven.

The field is optional and additive. A client written before today keeps working untouched, and one that reads it can stop guessing.

Every live job type carries it now, so a single generic form covers all nine rather than nine hand-written ones. The endpoint itself arrived with public job discovery, which is where to start if you have not read a schema off it before.