0.69.0

Lists can be filled or appended to, absent members sent as null, and ess generate types writes body types.
13 added, 3 changed, 29 fixed.

Changed

• From format: ess/31 a sets: entry may store the empty list [] in a required List<…> field, so a view publishing the field can be filled; generated Rust and Go store an empty list.
• From format: ess/31 an input of List type may carry an example:, a list of element values (structs included), which synthesis sends at the plain instance where no guard reads into the list; below ess/31 it keeps its type_mismatch, its hint naming ess/31.
• The specify guide has a page for tagged unions (guides/specify/unions.md): a kind: union declaration with tag:, variants: and a unit variant that ess specify validate accepts, why a union is always tagged, the wire shape of each variant rendered from the JSON Schema ess generate --kind schema writes for it, and when to choose a union over a struct of optional fields.
• An ess-http/1 route binding a command to delete may declare request: {encoding: query}, as an adopter asked, so a deleting command takes its unmapped input from the query string and reads no body. The OpenAPI projection writes each unmapped field as an in: query parameter under its wire name with no requestBody, and the generated Rust and Go servers read it from the query string, refusing an unknown key unless the route says unknown: ignore. ess-http/1 and ess-http-ir/1 stay at their versions; query on post, put or patch is still refused as ESS-HTTP-020, which now names get and delete.
• The views guide says how a view parameter is named on the wire, after an adopter asked: its flat wire: names the query parameter in the OpenAPI document and in the generated Rust and Go servers, which refuse the model name as an unknown key, and a view field's flat wire: names it in each row. A view field refuses the nested naming: {wire} spelling as an unknown field. A test now holds both generated servers to these names.
• An ess-http/1 outcome may answer one field of the command's response bare, as an adopter asked: body: response.<field> writes that field's value alone, a JSON string where the field is a String. The field must be declared and not Optional, on a returns: true outcome without error; anything else is ESS-HTTP-024. The OpenAPI document describes the body as the field's schema under {command}.{outcome}.Response, and the generated Rust and Go servers write the same bytes.
• An ess-http/1 command route may carry errors:, one answer for every outcome with error that outcomes: does not list, as an adopter asked, so a binding states an external: refusal's status once instead of per outcome and the derived 502 is replaced. It is held to every check a listed outcome is, once per outcome it covers, reported at routes[i].errors; on a view or on a route with no unlisted error outcome it is ESS-HTTP-022. A binding using neither form compiles to the bytes it did, and both servers and the OpenAPI document follow errors as they follow a listed outcome.
• 38 more in the changelog.

Every change: CHANGELOG.md § 0.69.0