Web UI

Workflow tab

The end-to-end pipeline in four numbered steps, driving exactly the same code as the CLI.

Project and configOpening a project reports its source count, build system and instrumented binaries; the preview shows what the current config selects.

1. Project — browse the filesystem (directories badged make/cmake) and open one. You get the source count, the detected build system, and any instrumented binaries already present.
2. trace.config — an editor with save, a selection preview (N sources: X instrumented, Y excluded), and a call-subtree helper: type a function name and optional depth to resolve its subtree through the static call graph and append the matching include-func line.
3. Build & run — one-click instrumented build (make instrument or the CMake flow) with the full log captured, then run the binary with TRACE_ENABLE=1, a TRACE_MAX cap and a timeout.
4. Report — the analyzer result as a sortable table: calls, inclusive, self and max time, with the summary line turning green on unmatched_exits=0.

The reportClick any column header to re-sort. Rows arrive ordered by self time, so the hot leaves are on top.

Config Builder tab

A visual editor for trace.config — no pattern syntax to memorize.

Files on the left, functions on the rightBoth panes filter live; the symbols: badge names the backend that produced the scan.

1. Pick a folder and scan. The builder enumerates every source file and the functions defined in them. It uses ctags when available — a symbols: badge next to the Scan button tells you which backend served the scan: system ctags, the bundled static copy (auto-downloaded on first scan), or the built-in regex fallback.
2. Searchable checkbox panes — one for files, one for functions. Filter either list and tick what you care about.
3. Per-function actions — for each selected function choose include-subtree (expands through the static call graph, like include-func) or exclude.
4. Preview — writes the generated config, then dry-runs the selection against it: how many sources would be instrumented versus excluded with your current choices. (The write is required — the dry run reads the saved file.)
5. Apply — writes trace.config into the project, ready for the next instrumented build.

Both buttons ask before overwriting an existing config whose content differs.

Symbol enumeration

The builder needs to know what functions a project defines. In order of preference:

• Universal Ctags on PATH — accurate parsing, with static detection.
• The bundled static ctags — downloaded on first scan into ~/.callsight/bin and checksum-verified. Run it ahead of time with callsight provision, or inspect what would be used with the same command.
• The regex fallback — the same heuristic parser that backs include-func. Always available, no dependency.

Notes

• Everything the UI does goes through the same functions as the CLI. There are no behavior differences between driving it from the browser and from a shell.
• CMake is fetched ephemerally through uvx when the host has none, so a CMake project works without installing CMake system-wide.
• The UI's dependencies (FastAPI, uvicorn) live in the ui extra; the core package stays stdlib-only.