Getting Started
What your documentation contains
A completed run produces a set of documents, each written to answer one question a newcomer to the project would ask.
Overview tab
| Section | Answers |
|---|---|
| Summary | What is this software, who is it for and what does it do? |
| Architecture | How is it put together, and why that way? |
| Modules | Which parts does it consist of, what does each do, and where does it start? |
| API Surface | Which endpoints or entry points does it offer? (Only when there are any.) |
| Tech Stack | Which languages, frameworks and libraries — from the project’s own files? |
Architecture tab — the C4 model
| Level | Diagram | Answers |
|---|---|---|
| L1 | System context | Who uses the system, and which outside systems does it talk to? |
| L2 | Containers | Which deployable pieces make up the system? |
| L3 | Components | Inside the main container: which components exist and how do they depend on each other? |
| L4 | Code | Which classes and interfaces implement a component? |
Tests, examples and benchmarks are shown apart from the product, so the diagrams describe what is actually delivered. Very large diagrams open as a grouped overview you can drill into.
Governance tab
| Artefact | Answers |
|---|---|
| Inception canvas | Why does this system exist — business case, functions, quality goals, stakeholders, constraints? |
| Communication canvas | How do we pitch the architecture — requirements, building blocks, interfaces, risks, key decisions? |
| Architecture decision records | Which important decisions were taken, why, and with which consequences? |
| Configuration records | How is the software versioned and released? |
Codebase tab
With codebase analysis included, every source file gets an explanation, and so do its classes and functions.
Quality tab
Where enabled, requirements-to-code traceability and verification evidence. Facts that cannot be read from code — requirements, test results, contract details — are reported as missing until you upload them.
How trustworthy is generated content?
Dev-Doc writes from evidence it finds in your code and labels content that needs a human eye. Still, treat every section as a first draft: read it, correct it, then approve it.