Your workflow in focus
Architecture diagrams from code: document dependencies with traceable sources
Start with one module’s source files, review components and connections, and hand over an editable architecture diagram.
Discuss a Diagramora code workflowWho this workflow is for
For development, architecture and technical teams explaining a code sample for reviews or onboarding.
The everyday challenge
When joining a module, teams often lack an up-to-date picture of its dependencies. A generated draft becomes useful when the team can trace relevant connections to their sources and identify unsupported assumptions. Diagramora supports this reviewable transition from a code sample to an editable model.
A concrete workflow example
Fictional example: an order module in architecture review
Three TypeScript files are supplied for a module dependency view. The team distinguishes established imports from information requiring additional sources.
| Relationship | Source | Assessment |
|---|---|---|
| OrderController → OrderService | Import in controller | Established in the sample |
| OrderService → OrderRepository | Import in service | Established in the sample |
| OrderRepository → production database | Deployment configuration missing | Assumption; review separately |
Fictional module names, not customer architecture. Imports describe source-code relationships. They establish neither the complete runtime path nor current production configuration.
How the workflow takes shape
Choose scope and view
Select a focused module and the view needed, such as module dependencies. Establish which files may be processed in Codex.
Create a draft with provenance
Use Codex with the Diagramora plugin and local MCP server. Request source provenance and explicit identification of unsupported assumptions.
Review and supplement connections
Compare nodes and connections with the files. Add external systems only with further evidence and lock reviewed positions.
Hand over the editable model
Save canonical Diagramora JSON. Check fidelity of the chosen export format and review later code changes as a proposed semantic diff.
What we need to get started
- A focused sample of supported source files and a specific diagram question.
- Codex with the enabled Diagramora plugin and local MCP server for the plugin workflow.
- Approved access and appropriate Codex data-processing settings; an accountable person reviews sources and assumptions.
What to know before you start
- A code sample does not automatically describe the entire runtime architecture. Runtime status and additional architecture information must be separately established or maintained.
- The local editor uses deterministic local drafts by default. LLM-assisted code analysis runs through Codex Chat and MCP, subject to Codex data-processing settings.
- An optional editor AI endpoint requires explicit setup and confirmation per request. Foreign formats can lose information; complete BPMN, UML and C4 rule sets are planned.
Common questions about this workflow
Can I edit the draft afterwards?
Yes. Nodes, ports, connections and labels can be edited. Keep Diagramora JSON as the editable source.
Is AI analysis also entirely local?
Distinguish the local editor and MCP tools from LLM analysis. Analysis through Codex follows its data-processing settings; review those for your sources.
Is a repository enough for a complete production view?
Not automatically. Deployment, external services and runtime behaviour may be outside the analysed sample and require deliberate additions and review.
Can I also create a data model from SQL?
Yes. SQL DDL containing CREATE TABLE and REFERENCES can be imported into Diagramora as an editable ER diagram. Review tables, keys and relationships against the definitions. SQL is never executed and no production database is queried. You can use the editor for this local import.
Make the next step concrete
Bring your current workflow and a typical example. Together, we clarify which data, systems and responsibilities matter for getting started.
Discuss a Diagramora code workflow