Lenses

What it answersWhat does this product actually do, and how healthy is each part? The top-down tree — product features, the user flows under them, and the dev flows that implement each — with every node scored on health, impact, coverage and churn.

Why it's usefulThe orientation view. Hand it to a new hire, a stakeholder, or an AI agent and they read the whole system top-down in one screen, sorted by impact so the load-bearing features sit up top.

Why this lensIt's the only lens that shows the full product → code mapping in one hierarchy. Every other lens is this same cold scan re-sliced by a single concern — start here, then switch to answer a sharper question.

What it answersThe product framed as the journeys a user takes — each user flow rolled up from the code, linking the dev flows that implement it.

Why it's usefulBridges PM language and code. “Onboarding is flaky” becomes the exact dev flows behind onboarding, each with its own health and coverage, so a behavioral complaint maps to specific code in one click.

Why this lensGroups by user-facing journey instead of code structure. Reach for it when the conversation is about what a feature does, not which files it lives in — the framing a product team already thinks in.

What it answersIf I change this, what else breaks? Dev flows ranked by how many other flows physically share their code — the same file and line range. Open any row to see exactly which flows, and where.

Why it's usefulThe top rows are the shared chokepoints — a repository, an error helper, an auth guard — that many flows depend on. A row is tagged RISK when its code is widely shared AND under 50% covered: a change there ripples far and tests won't catch the fallout. This is the lens a tech lead opens before approving a refactor of shared infrastructure.

Why this lensThe engine's reach number tells you a flow sits in many features — that it's connected. This lens tells you which lines are physically tangled, with the dependent flows named — the difference between “important” and “a change here is dangerous.” Flows that are referenced broadly but share no lines drop to an Isolated tail, so the ranked top is only genuine entanglement, and every ranked row opens to show its evidence.

What it answersWhich features are the most dangerous to change? The full feature tree sorted by impact (blast radius) descending — the most wired-in code first.

Why it's usefulWhere triage starts. High impact means a change ripples across the product; read it alongside the coverage column and you've found exactly what needs mandatory senior review and a CODEOWNERS rule.

Why this lensSame tree as Product map, reordered purely by blast radius. It strips away product grouping so the riskiest-to-change code floats to the top regardless of which area it lives in — surfacing risk that a per-feature view buries.

What it answersWhere is the codebase both fragile and load-bearing? Every feature plotted as a dot — X is code health, Y is impact. The top-left box (impact ≥ 70, health < 55) is the danger zone.

Why it's usefulOne glance shows the shape of the whole portfolio. Dots in the top-left are in firefighting AND wired into everything — refactor those first. It's the chart that justifies a stabilization sprint to leadership without a spreadsheet.

Why this lensThe only lens that shows two dimensions at once. A list sorted by impact hides health, and a list sorted by health hides impact; the scatter exposes the dangerous intersection that neither single-column sort can.

What it answersWhat is shipping untested? Only the features under 65% coverage, weakest first.

Why it's usefulThe test-debt worklist, already prioritized. Features below 40% correlate with markedly higher post-deploy incident rates — this is the queue to burn down before they bite, and the one to write tests for before any refactor.

Why this lensFilters the scan to a single question and orders by severity, so you're acting on a ranked backlog instead of eyeballing a coverage column across hundreds of rows.

What it answersWhere is velocity bleeding right now? Only the features in firefighting mode — health under 55, meaning recent commits are mostly bug fixes rather than new work.

Why it's usefulThese features are eating sprint capacity on fixes instead of shipping. The lens names them, worst first, so a recurring-pain conversation has evidence behind it and the stabilization candidates are obvious.

Why this lensHealth blends bug-fix ratio, churn and regression recency into one cut. This lens isolates the actively-bleeding tail so structural pain is visible on its own, not averaged away among healthy features.

What it answersShow me everything. The entire scan — product feature → dev feature → dev flow — sorted by impact, with nothing filtered out.

Why it's usefulThe reference view for when you need the whole map, not a curated slice: auditing a scan end-to-end, hunting a specific flow, or exporting the complete structure.

Why this lensNo filter and no special grouping — the raw structured output every other lens draws from. Reach for it when a filtered lens hid the exact row you were looking for.