Onboarding Map
A reading guide for your repository, written from your repository. Fourteen sections take a new engineer from “what is this system” to “here is how you make your first change” — and each one says where its claims came from, so nothing an AI guessed can pass as a measured fact.
How it is built
The guide is generated from the Intent Map, the dependency graph and the findings of the other scans. It is not a separate analysis of your code — it is a reading of the analyses you have already run, which is why it regenerates in seconds once the Intent Map exists.
The tab
Sections that have nothing to show collapse themselves, and the rail on the right lists only the ones that rendered.
The guide sections
Orientation
- Coverage — a banner when fewer files were summarised than indexed, naming the gap. It disappears entirely on a complete scan.
- Architecture Overview — what the system is, in prose, with the technologies detected in it.
- Repository at a Glance — files, directories, entry points, technologies, and the estimated hours for the core path.
- Runtime Flow — how a request moves through the system, derived from static analysis rather than from traces.
The map
- Repository Tour — what each top-level directory is for, and the key files inside it.
- Complexity by Area — where the coupling is concentrated, so you know which parts will fight back.
- Key Entry Points — every API route, page, layout, middleware, webhook, cron job and CLI script, with its coupling and why it matters.
- Watch Out For — the gotchas: the places where the obvious reading of the code is the wrong one.
- High Risk Areas — the debt already found by the other scans — dead code, zombies, unused dependencies and assets, orphan tables, secrets — each linking to the tab that found it.
The path
- Suggested Learning Path — numbered steps, each with the files to read, an hours estimate, and why the step matters. Ordered by dependency, not by file name.
- Learning Path by Role — the same repository read differently for a frontend, backend or full-stack starting point.
- Change Recipes — how to do the five common changes in this codebase: add an endpoint, add a database column, add a background job, add a feature flag, add a webhook. Each step cites the evidence behind it, and recipes this repository has no surface for are named as not applicable rather than faked.
- Next Recommended Analyses — which scans have not run yet, so the gaps in the guide are visible.
Provenance badges
Every section carries a badge naming where its content came from and how far it can be trusted:
Verified— derived from code: the AST, the import graph, static analysis. High trust.Provided— taken from your repository configuration or documentation. High trust.Estimated— a statistical heuristic, such as the hours on a learning step. Medium trust.Inference— an AI interpretation. A starting point, not a fact. Low trust.
The Architecture Overview is the one low-trust header on the page, and it wears the badge rather than being dressed up as fact. Each badge also names the concrete sources behind its section and the limits of what those sources cover.
Observed level in the taxonomy, reserved for real runtime traces. Nothing in Mapnostics uses it today, because nothing in Mapnostics watches your code run. The Runtime Flow section is static analysis and is badged Verified, not Observed.What it will not guess
The last section of the guide is a deliberate boundary. Business context, revenue flows, team ownership and escalation paths are decisions people made, not facts in the code. Mapnostics names them as out of scope rather than leaving a gap that reads like a missing feature — or worse, filling it with a confident guess.