2. How a span becomes a report🔗

The public API makes profiling look like one function call:

span "source.analyze" (analyzeSource source)

That small boundary is intentional. The application already knows that this action is source analysis; the profiler should preserve that fact without asking the caller to manage clocks, thread stacks, or report files. Internally, the span passes through four distinct stages:

reserve its place in the event tree
sample time and Lean heartbeats around the action
complete and retain an event
analyze all retained events when the session ends

Keeping these stages separate is what lets the same capture handle nested calls, worker threads, asynchronous runtimes, and repeated measurements without changing the basic span API.

1. 2.1. The session owns the capture
2. 2.2. Reservation establishes the event tree
3. 2.3. The timed interval has a precise boundary
4. 2.4. Hooks define when asynchronous work is finished
5. 2.5. Analysis computes inclusive and self time
6. 2.6. Repeated spans become summary rows
7. 2.7. What LeanProfiler does not infer