Building a type from other types

Most object types in a real application are slices of an entity or of another object: a create input, a patch input where every field is optional, a public view, a list summary, a v2 response that adds a field. Instead of writing each field out (title: Todo.title), a type's body can copy fields from other types. The body keeps its ordinary Output { } form. Four kinds of line build it. They are read from top to bottom, and each changes the result of the lines above it:

type TodoView = Output {    pick: [Todo.id, Todo.title, Todo.status, Todo.due_at]}type TodoDetail = Output {    include: [Todo]    omit: [Todo.deleted_at]    owner_email: User.email}type PatchTodo = Input {    pick: [Todo.title, Todo.due_at]    optional: all}type OrderView = Output {    include: [Order]    lines: List<OrderLineView>  // replaces Order.lines with a view of each line}type TodoReminder = Object {    pick: [Todo.id, Todo.title, Todo.due_at]    owner_email: User.email    days_overdue: DayCount}

Rules:

• Top to bottom. The same kind of line may appear more than once, and the formatter keeps the order written, because order matters here.
• Fields keep their declared order. Copied fields stand where their include or pick line is, an include's in the order its type declares them and a pick's in the order listed; a written field that replaces a copied one takes its place. Values, hover and the manifest (each field's order) follow it.
• Lists are always in brackets, even with one entry: include: [Todo].
• omit removes only what is there. Omitting a field that is not present at that point is an error, which catches typos and fields since removed.
• Written fields win. A field you write replaces any field of the same name above it, visibly; otherwise it is added.
• Copied fields never silently replace copied fields. An include or pick that would replace a field brought in by an earlier include or pick is an error: resolve it with omit or by writing the field. Copied fields are not visible in the declaration, so a clash there would change a type unseen when a source type gains a field.
• No include on an Input. Taking every field of User would accept any field added to User later, so a client could set a field it was never meant to (the mass-assignment bug). Inputs pick or write their fields. Generated fields such as id and created_at can never appear in an Input.
• optional makes the listed fields, or all, optional, only on an Input.
• Copied fields follow their source. Renaming Todo.title renames it in every type that copies it, and its validation rules come with it.
• No type includes itself. An include that leads back to its own type, directly or through another, is type.copy_cycle.
• Every built type has a name; there are no inline types in signatures. Hover in your editor shows the final fields and where each came from (title ← Todo.title, lines ← written, replaces Order.lines).
• Outputs may include. A field added to Todo later reaches TodoDetail, and the committed API record shows the addition in review (HTTP). Fields that policy hides from clients stay hidden when the app runs (Field restrictions).
• include, pick, omit and optional are reserved and cannot be field names.