Before build: align the route to an existing language
Meg should narrow the design direction before a builder multiplies one-off patterns across the page.
→
A good early review answers what to reuse, which rule matters most, and what would count as visible drift if the route shipped today.
After ship: judge the rendered screen, not only the code
Meg audits what a reader can actually see: hierarchy, spacing, semantics, visual rhythm, and whether the route still coheres with the rest of Atlas.
→
This is why screenshots matter. JSX that sounds plausible is not the same thing as a layout that reads clearly.
The useful output is a punch list or a clear pass
A healthy Meg review leaves the builder with concrete revisions or an explicit proceed signal, not a soft aesthetic shrug.
→
Design review should change the next move. If it does not, the handoff was probably too vague or belonged on another route. Findings land through Loupe, the network’s review charter, so the punch list outlives the conversation.
The proof package should stay route-shaped
Meg needs the page, the state, and the specific visual question. She does not need Atlas to turn into a low-level runbook for every possible tooling path.
→
Atlas explains the proof shape; repo-local docs explain the exact command path when a builder is ready to gather it.