max / quasi

0.55.0: a screen can ask for a mount of its own Ruled by Max 2026-08-22 (goingson 3fb2526a), picking (b) of three: grow the vocabulary rather than let a host script or a menu item own the second window. WHAT WAS MISSING. Frame { verbs, status } landed in 0.54 and says what a mount puts around a screen, which is the whole of how goingson's compose differs between its two windows. Nothing said how anything asks for the second mount. Act had by_host, replacing, saving and awaiting, and no word for elsewhere, so the only ways left were a host script reaching around the description to a control the description already owns, or a menu item the description cannot see. Action::elsewhere is the same family as saves and replaces: all three say where the answer lands, and this one says it lands somewhere that is not here. Not a Destination, which says where the call goes -- the two are independent, and one address being the main window's compose screen and the compose window's is the point of Frame. DELIBERATELY NOT "A WINDOW". A mount is whatever a renderer puts a screen up in, and the three already differ: webview a second document, which the host opens immediate a viewport of its own terminal nothing; the call is performed where it stands The terminal's answer is the interesting one and it is not a gap. A second mount there would be a split or a tab, both of which are that renderer's furniture rather than the description's, so a screen asking for one would be asking for a layout. It navigates instead, which is the honest degradation Renderer exists to allow, and it gets a test rather than a silence: the failure mode next door is by_host's, a control that is drawn, is reachable and does nothing when pressed. THE WEBVIEW EMITS data-mount AND NO TRANSPORT, the shape by_host already has: no verb, no trigger, no href, since every one of those would put the answer in the mount the control is already in. data-mount and not data-sends, because a host that conflated them would post where it should open. No wait mark either -- putting up a mount is not a call that resolves, and a spinner on it reads as a hang. STEP::MOUNT CARRIES A REQUEST, not an address, so quasi-immediate needs no transport crate to build a URL and the new viewport asks for its screen the way the first one did. Built before the payload is absorbed: what a control collected belongs to the call it was collected for, and feeding a going-up mount a half-filled form would be this renderer inventing a screen state nobody described. Distinct from Step::Open, which is somewhere outside the app entirely. Five tests, one per renderer answer plus the two that would be silent if wrong: the carried view riding along (else the window opens on the wrong list), and an ordinary call untouched by the member existing. 0.55.0 rather than 0.54.1: a field on Action and a variant on Step are both breaking to cargo at 0.x. Consumers forward-fixed in the same pass.