Launch inputs are checked in one fixed order and answered once

A caller gets one problem to fix at a time, in the order that makes the next attempt useful: what you sent that does not exist, then what you did not send, then what is wrong with what you sent.

What it means

A launch can be wrong in more than one way at once, and the three stages are ordered so a caller is never told about a problem fixing the first one would have made moot. A key that is not a declared input name is checked before whether a required input is missing, which is checked before the values themselves — and the check stops the moment a stage fails. A caller who both misspelled an input's name and left a required one out only hears about the misspelling: the missing-required message would be about a state the caller has not actually reached yet, since fixing the typo might supply it.

Every message, at whichever stage it stops, ends the same way: it names the inputs the workflow accepts, or says it accepts none. And "required" has two sources, not one — a manifest entry can say so directly, or the input's name can simply appear in the published contract's top-level required list. Either is enough on its own, so a manifest written before that contract was last rebuilt is still enforced through the newer source.

Example

The workflow declares one input, message, required.

{ "mesage": "typo" }

{}

The first refusal reports only the unknown key and the inputs the workflow accepts; it says nothing about message being missing, even though it is. The second, sent once the typo is gone, is the first point at which the missing-required stage gets to speak.