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. This catalogue lists them by tab.
Overview tab
| Section | Answers the question |
|---|---|
| Summary | What is this software, who is it for and what does it do? |
| Architecture (narrative) | How is it put together, and why that way? |
| Modules | Which parts does the project consist of, what does each one do, and where does it start? |
| API Surface | Which endpoints or entry points does it offer to the outside? (Only present when the project has any — a library or command-line tool may have none.) |
| Tech Stack | Which languages, frameworks and libraries does it use — taken from the project's own files? |
Architecture tab — the C4 diagrams
The C4 model describes software at four zoom levels, like a map that goes from country to street:
| Level | Diagram | Answers the question |
|---|---|---|
| L1 | System context | Who uses the system, and which outside systems does it talk to? |
| L2 | Containers | Which deployable pieces (applications, services, databases) 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, and how are they related? |
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 — see Architecture.
Governance tab
| Artefact | Answers the question |
|---|---|
| Inception canvas | Why does this system exist — business case, functions, quality goals, stakeholders and constraints? |
| Communication canvas | How do we pitch the architecture — requirements, solution building blocks, interfaces, risks and key decisions? |
| Architecture decision records (ADRs) | Which important decisions were taken, why, and with which consequences? |
| Configuration records | How is the software versioned and released? Produced from the repository history where available. |
Codebase tab
When codebase analysis is included, every source file gets an explanation, and so do the classes and functions inside it. This is the place to answer "what does this file actually do?" without reading it line by line.
Topic sections on request
Some topics are written only when the project's owner asks for them, from the Coverage tab: Building, Deployment, Data Model, Configuration, Security, Error Handling, Testing and Glossary. Each is written only from what the repository contains, and appears in the Overview once ready.
Coverage tab
For the project's owner only. Compares the documentation with a checklist of what good developer documentation covers, shows which files and modules are documented and why the others are not, and lists what is worth adding next. See Coverage.
Quality tab
Where enabled for your account, the Quality tab holds 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. See Quality.
How trustworthy is generated content?
dev-doc writes from evidence it finds in your code and project files, and labels content that needs a human eye. Still, treat every section as a first draft for review: read it, correct it with Edit, then Approve it. See Review, edit & approve.