MRGI INTERFACE / WORKFLOW FIELD GUIDE
Handoff a reusable project card
Make a component’s intended states and acceptance evidence clear before it enters an application.
01 / FROM INPUT TO HANDOFF
Follow the decisions.
This walkthrough describes the intended MRGI product behavior. The browser demo illustrates a small part of the workflow; it does not run the complete application.
- 01
Specify the states
- Start with
- Default, focused, and compact component variants.
- Work through
- Define expected text, tokens, interaction, and responsive behavior.
- Result
- An approved component specification.
- 02
Prepare implementation
- Start with
- The specification and an authorized project.
- Work through
- Generate or write a component within the project’s constraints.
- Result
- A reviewable implementation candidate.
- 03
Collect evidence
- Start with
- The candidate rendered in agreed states.
- Work through
- Run selected accessibility and visual checks; document manual review.
- Result
- Findings tied to the implementation revision.
- 04
Accept the handoff
- Start with
- The component and its findings.
- Work through
- Resolve blockers and state known limitations.
- Result
- A tested handoff with an explicit acceptance decision.
02 / INPUTS & INTERCHANGE
What travels with the work.
These are foundation formats and intended handoff contracts. Support and fidelity must be confirmed for each released build.
| Artifact | Role | Review consideration |
|---|---|---|
| Design frames / variants | Specification inputs | A picture alone cannot capture all interaction semantics. |
| Token packages | Line handoff | Map design values to implementation tokens deliberately. |
| Components / test evidence | Engineering output | Framework support and test environments must be defined per adapter. |
A deliberate cross-app boundary
Use Line design tokens, pass approved specifications to Evolve, and explain the release decisions in Present.
The intended handoff should identify the selected resource, its version, the destination, and the user’s authorization. A linked application should not inherit unrestricted file access.
Explore the connected applications ↗03 / BOUNDARIES & READINESS
Know what this example establishes.
- Passing a color-contrast check does not establish WCAG conformance.
- No production component generator runs in this page.
- Visual regression is sensitive to rendering environment and font changes.
Development status
The source foundation is imported. Generation adapters, accessibility checks, visual regressions, and the pictured interface are planned.
Before a production release
Validate real-file behavior and platform support, implement the stated authorization and review rules, and document the tested acceptance scope. The interactive website is a product demonstration, not a release candidate for the application.
04 / PRODUCT QUESTIONS
The details that matter.
What does the contrast number mean?
It compares the relative luminance of two opaque sRGB colors. Normal text generally needs at least 4.5:1 under WCAG AA; other criteria and exceptions still apply.
Will generated code be deployment-ready?
Generation is a proposed starting point. Project integration, behavior, accessibility, and regression checks remain necessary before release.
Open-source foundation
Frames, variants, variables, prototypes, Dev Mode, code, and collaboration modules exist in FigCraft. The MRGI proposal centers on traceable, tested handoff workflows. Read the credits and foundation mapping.
Keep exploring Interface.
Return to the product breakdown or try the local interactive example.