builder: app install with v-lanes not yet drafted correctly (design lane: wrong modifier keys, a broken sealed door, no manifest; a channel with a route-less return edge)

[mmeyerlein]

Context

Ruling 2026-09-05 (apps rim, M-1): the installer is the builder — an app installation is a build wish, the builder reads /colony/graph and drafts the edges that are missing; meclaw app install will only place that wish. The night of 2026-09-05 was the first real test, on a fresh colony grown from the shipped meclaw-os@1.8.4 (builder@1.7.3), two design-lane wishes with auto_submit, composer = the configured MODEL_BUILDER. Both wishes named the template README that documents the exact edges (templates/voice/README.md § Wiring it into a member; templates/member/README.md § Installing an app), and the corpus carried both.

What happened

Wish 1 — a voice channel (2 edges). Draft 1 refused edge_schema (add_edges[].modifier must be an object on both edges); the repair round produced draft 2, which committed (8 rounds, 1 repair, 0.22 $). But the committed edges were wrong in two ways nobody was told about:

• the return edge ./channels -> ./channels/voice had no route guard (has(context.channel_node) && context.channel_node == 'voice' only) — it would have fired for the channel's own turn/partial/error transiting the container and sent every utterance back into the cell as in_speak (the assistant would have spoken the person's words);
• the ingress promotion wrote session_id: hop.session_id without the has(...) ? … : '' guard the README prescribes — a modifier that fails to evaluate skips the edge, so an emission without a session (an error) would silently not fire it.

Both were replaced by hand with remove_edges + add_edges in one mutation. A third line the README could not know (the member's firewall allowlists user_id) had to be added by hand too.

Wish 2 — the app install (1 node, 11 edges, 4 of them v-lanes with a lane field). Three drafts, none usable (9 rounds, 2 repairs, 0.58 $):

1. edge_schema: modifier with unknown keys set and delete (the vocabulary is set_context, delete_context, set_hop, delete_hop, restore_ttl; the grammar in the briefing names it);
2. a draft that passed the schema and broke the tools hive's door — post-state refusal hive_contract on <gen>/tools ("declares it accepts tool_call … no door") — i.e. the composer redrew or removed an edge inside a sealed level instead of only adding the eleven;
3. no_manifest_in_answer ("the answer carried no balanced json object").

The hand manifest (the README's, names substituted) committed first time.

What this says

• For a two-edge channel the design lane is at the edge of what it can do, and the repair loop cannot see a semantically wrong guard: the door only refuses what the schema and the post-state checks catch. A route-less return edge is legal and wrong.
• For an eleven-edge install with v-lanes it is not there yet: the modifier vocabulary was missed twice, a sealed hive was touched, and the answer form failed.
• The corpus had the exact recipe in prose, and the wish quoted its section — retrieval did not turn it into the manifest. Two routes forward: a recipe (fast lane) for install app <name> for <assistant> on <screen> rendered from app.json (the ruling's meclaw app install is exactly that wish), so no model is asked for what is a template; and/or a composer that is handed the README's manifest block verbatim as a pattern with a substitution task rather than a description.

Measured on

e20 (mm-os-e20), 0.31.0 + apps rim, builder@1.7.3, member@1.6.2, assistant@2.5.1, voice@1.0.0, app voice2vision@0.1.0 registered through the front. Mutation log entries: 1× edge_schema, 1× committed (wish 1); 1× edge_schema, 1× failed (hive_contract), no third draft (wish 2); hand manifest committed.

[mmeyerlein]

Measured again on a fresh colony (three cases, all on the same seam): (1) a build wish carries no node parameters that are not spelled out in the wish text, so a channel hive came up with template defaults (port, empty caller table) and could only be repaired by rebuilding the tree — remove_nodes/move_nodes/swap_nodes all refuse a hive that has no registry row of its own; (2) override_params applies at instantiation only, and a runtime params update does not persist across a process restart; (3) the display's page route lives only in the pages table (runtime state), so the two ops settings a web-proxied colony needs are re-applied by a recipe step after every rebuild. All three want the installer to own node parameters and durable ops state.