Loading
Preparing the page
Public context is loading before any interactive tool code.
Preparing the page
Public context is loading before any interactive tool code.
Validate module IDs, layers and directed dependencies locally, flag dependency cycles, and export editable Mermaid without uploading a repository.
Your checked result will appear here.
Module tiles pass through an identifier and edge gate before becoming a layered dependency map. A dangling target stops the result; a cycle remains visible for review.
The tool works from facts you supply. It does not infer imports, execution order, network calls or runtime reachability.
Use one stable lowercase ID for references and a separate human-readable label for the visible node.
Each module points to the modules in its depends_on list; the generated comment repeats that rule.
Unknown targets, duplicate IDs, self-links and oversized graphs stop with a specific error.
Strongly connected groups receive a visible Mermaid class and a review comment without being called a defect.
The tested fixture groups interface, service and data modules. Two terminal modules have no further declared dependency, and no cycle is present.
{
"direction": "LR",
"modules": [
{ "id": "web", "label": "Storefront", "layer": "Interface",
"depends_on": ["catalog", "checkout"] },
{ "id": "catalog", "label": "Catalog service", "layer": "Services",
"depends_on": ["database"] },
{ "id": "checkout", "label": "Checkout service", "layer": "Services",
"depends_on": ["payments"] },
{ "id": "database", "label": "Product database", "layer": "Data",
"depends_on": [] },
{ "id": "payments", "label": "Payment adapter", "layer": "Data",
"depends_on": [] }
]
}flowchart LR
subgraph layer1["Interface"]
m1["Storefront"]
end
subgraph layer2["Services"]
m2["Catalog service"]
m3["Checkout service"]
end
m1 --> m2
m1 --> m3
m2 --> m4
m3 --> m5Observed: 5 modules · 4 dependencies · 3 layers · 2 leaves · 0 cycles
web depends_on missing-serviceThe target is absent from the module list, so no Mermaid is emitted.
A useful diagram makes the evidence boundary obvious. The manifest can document intended dependency structure while real source and runtime checks remain separate.
Visible labels and layers come directly from module records; generated node IDs cannot inject Mermaid syntax.
Every arrow is produced from one validated depends_on entry, with duplicates removed.
A strongly connected component proves a cycle in this manifest, not whether production execution traverses it.
Imports, conditional paths, reflection, service calls and runtime traces are not inspected by this local version.
The generated text uses documented flowchart directions, subgraphs, nodes, arrows, comments and one optional cycle class.
Use LR or RL for wide architecture maps and TB or BT when vertical reading suits the document.
Layer names create subgraphs; omit a layer when grouping would imply a boundary that does not exist.
Paste the exported .mmd text into a Mermaid-compatible environment and inspect the rendered result.
Confirm module and edge declarations against the real repository before publishing or changing architecture.
The tool validates only the JSON you can see. It cannot prove that the implementation matches the map.