From M3E Canvas to a Coding Brief

Once a M3E Canvas design has explicit screens, layout relationships, theme choices, and interaction targets, the next problem is translation. This chapter examines how the project turns that structured document into a readable prompt, what it can infer from geometry, and why the prompt remains editable. It then follows the optional AI and agent paths, where direct provider calls and whole-design drafts are constrained by JSON validation and author review. The useful judgment is not whether the output sounds detailed; it is whether each important sentence can be traced back to an authored fact or to a clearly bounded interpretation.

The compiler translates structure instead of dumping coordinates

The prompt generator starts from the same document that powers the canvas and preview. It takes the design, measured widths for content-sized parts, an optional single-screen filter, and a language. Before describing anything, it normalizes certain document cases, determines the implementation platform, expands hand-made groups into the regular runs they contain, assigns groups to their frames, and identifies which component kinds are actually in use.

That preparation prevents the prompt from being a raw serialization of editor internals. A list of numeric positions would preserve coordinates while asking the receiving tool to reconstruct their meaning. M3E Canvas instead turns geometry into reader-facing relationships: a part is near the top or bottom, a row runs from left to right, a group is inside a container, or one element partly overlaps another and is drawn in front. The compiler uses the bounds of groups and parts to build a containment tree, detects rows from shared vertical extents and side-by-side placement, and describes positions relative to a frame or a container.

This is a change of representation, not a lossless export of every pixel. A coordinate such as “left 64, top 312” is exact but not very informative to a coding tool. “In the middle, aligned right” is less exact but communicates the relationship that is more likely to matter when real content changes. The project uses the original geometry to derive that phrase, then relies on general guidance to let a downstream implementation adjust dimensions and spacing without destroying order, grouping, or intentional overlap.

The compiler treats connected runs as meaningful units. A horizontal run of buttons is described as a connected button group and kept on one line; a vertical run of list items is described in reading order. Several parts placed inside a box can be described as layered on top of the box, with the later layer in front. A free group is expanded into its hidden runs for description because it is a movement convenience, not necessarily a single visual component. This preserves the distinction established on the canvas: regular adjacency becomes a row or list, while a hand-made composition retains its internal relationship.

Consider one connected row with a primary “Save” button and an outlined “Cancel” button. The document contributes the labels, variants, member order, and axis. The layout compiler contributes the fact that the two belong on one line and should not be stacked or wrapped. The component-style section supplies the relevant Material 3 Expressive treatment for buttons. If the Save item has an action, that action appears in the behavior section; if it has a note explaining what is saved, the note adds product meaning that no rectangle can provide. One visual relationship has consequently become several sentences, each owned by a different source of information.

The same pattern handles details that would otherwise disappear. A card's image can be on top, fill a leading or trailing side, or occupy the background, and the prompt can describe that placement. A dropdown's options and initial value can be named. A navigation bar or rail can state its destinations and selected item.