Documentation article
System architecture
Understand how parser, IR, traversal, generator, and diagnostics layers stay separated inside one pipeline.
The architecture matters because this project is trying to be more than a one-off converter. The docs need to show how parsers, Shape IR, traversal, generators, and diagnostics fit together as one pipeline.
A useful architecture page should make extension work feel understandable before it feels exhaustive.
The pipeline starts with a source-specific parser, normalizes into Shape IR, moves through shared traversal behavior, and then hands control to a target-specific generator.
Diagnostics should stay close to each stage instead of being bolted on afterward. That is how the system can explain both success and partial support honestly.
These boundaries are what keep new route work reviewable instead of turning every feature into a whole-stack rewrite.
The important detail is not the arrows themselves. It is that each handoff is explicit enough for tests, docs, and extension work to describe independently.
High-level pipeline view
Source schema
-> parser
-> Shape IR
-> traversal helpers
-> generator
-> output + diagnostics