Lenses
Every lens is the same scan, re-sliced. Switching a lens never re-runs anything — it regroups, filters, or re-sorts the one cold scan to answer a different question. Each is explained the same way: what it answers, why it's useful, and why it earns a place next to the others.
Product map
default · product → user flow → dev flowWhat it answersWhat does this product do, and which code implements each part?
Why it's usefulUse it for system orientation, planning discussions, and moving from a human product concept to the implementation underneath it.
Why this lensIt shows the complete product-to-code hierarchy. Metric columns are populated only from the worker sidecar and retain their evidence semantics.
User flows
user journeys → dev flowsWhat it answersWhich user journeys were reconstructed, and which dev flows implement them?
Why it's usefulUse it when a product or support conversation starts with a journey such as checkout, login, or password reset.
Why this lensIt groups implementation evidence in the language product teams use, without inventing a score.
Shared code
resolved overlapping spansWhat it answersWhich dev flows physically share resolved code spans, and where?
Why it's usefulUse it before changing shared implementation to inspect concrete overlap receipts and dependent flows.
Why this lensIt reports structural overlap counts and locations. It does not claim that a low count makes a refactor safe.
Full hierarchy
complete tree · unfilteredWhat it answersShow every product feature, dev feature, and flow in one tree.
Why it's usefulUse it for scan QA, finding a specific entity, or inspecting the complete structured output.
Why this lensIt keeps the full map visible without a metric-derived filter that could turn missing evidence into a safe state.