Subscribe to change, the event textinput actually emits Three examples subscribed to submit. textinput emits one event, change; submit is only a code comment (textinput.go:122), never a wire name. They passed the executable example checker because sub accepts any word and never validates it against the type -- the one class of error that checker cannot catch, and the reason it is worth fixing in the protocol. Also drops the describe line counts from two pages. Those move as types are added, and the shape of the output is the part that stays true.
Say what the missing-separator error actually is It was described as failing oddly. It does not: the second new lands where a property name belongs, so the parser reads it as one and the type rejects it by that name. The message is exact, and knowing why is what lets a reader recognise it as a missing separator.
Add the Protocol Overview page The anchor for the protocol section: the eight verbs plus the bare surfacing statement, how correlation keys work, and what a reply carries. Documents two things that only show up by trying them. Keys last for the whole connection, not the request, which is what makes the build-then-drive patterns work at all. And a dotted path names every level -- w.pn.q, never w.q -- so a container built without a correlation key puts everything beneath it out of reach for good.