MRGI EVOLVE / WORKFLOW FIELD GUIDE
Assess a small reporting-tool migration
Make an acceptance decision from explicit behavioral evidence rather than a visual resemblance alone.
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
Define authorization
- Start with
- A fictional reporting workflow owned by the team.
- Work through
- State which files, commands, and outputs are in scope.
- Result
- A bounded assessment plan.
- 02
Capture expectations
- Start with
- A known sample import and expected report result.
- Work through
- Record the values and behavior that must be preserved.
- Result
- A versioned acceptance fixture.
- 03
Compare a candidate
- Start with
- A matching or regressed synthetic output.
- Work through
- Evaluate the fields and report the differences.
- Result
- A reproducible comparison result.
- 04
Review the decision
- Start with
- The results and known test gaps.
- Work through
- Resolve regressions and document accepted differences before migration.
- Result
- An explicit acceptance record with limits.
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 |
|---|---|---|
| Authorized source / behavior records | Assessment inputs | Access and execution scope must be explicitly constrained. |
| Expected / observed fixtures | Regression comparison | Fixtures need meaningful coverage and controlled versions. |
| Patch proposals / evidence | Engineering handoff | Human review and project tests remain required before deployment. |
A deliberate cross-app boundary
Receive approved Interface specifications, preserve test evidence in Evidence, and communicate the decision 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.
- The demo runs no external commands or inspected application code.
- Matching JSON fixtures do not prove complete application equivalence.
- Sandbox design and live agent integrations require independent security validation.
Development status
The source foundation is imported. The MRGI modernization workflow is exploratory; sandbox guarantees and end-to-end equivalence testing are not yet validated.
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.
Can this migrate an arbitrary app automatically?
That is not a supported claim. The proposed workflow depends on authorization, compatible inputs, acceptance coverage, and reviewed engineering changes.
What does a passing comparison establish?
Only that the selected sample outputs matched under the implemented comparison. Uncovered behaviors remain unknown.
Open-source foundation
Inspection engines, an evidence ledger, rebuild loops, CLI/MCP, and optional external agents exist in Craft Anything. Authorized, measured modernization is the proposed product direction. Read the credits and foundation mapping.
Keep exploring Evolve.
Return to the product breakdown or try the local interactive example.