# get_execution_flows

get_execution_flows scores the top entry points and traces each call graph breadth-first, showing how the codebase executes end to end. Opt-in tool.

Runtime call flow, not static structure. `get_execution_flows` scores
the codebase's entry points and traces each one's call graph breadth-first,
so the agent sees which functions run in sequence when the program
actually executes, and whether that flow crosses architectural
community boundaries along the way. The call edges and communities come from
the [dependency graph](https://docs.repowise.dev/intelligence/dependency-graph); the default tools
are on [MCP tools](https://docs.repowise.dev/mcp/overview).

## Off by default

Registered but not part of the default tool surface in any mode. Turn
it on per repo:

```yaml
# .repowise/config.yaml
mcp:
  tools: ["+get_execution_flows"]
```

or per launch with `repowise mcp --tools "+get_execution_flows"`. See
[Configuring the tool surface](https://docs.repowise.dev/cli/server#repowise-mcp) for the
full `+`/`-` delta syntax.

## When to call

- **Orienting in an unfamiliar system**: what actually happens when
  the program runs, beyond the static module map `get_overview` gives.
- **Tracing one entry point**: pass `entry_point` to walk a specific
  symbol's call chain instead of the top-scored ones.
- **Spotting layering violations**: `crosses_community` flags a flow
  that jumps between architectural clusters.

## Parameters

| Name | Type | Default | Description |
|---|---|---|---|
| `top_n` | number | `10` | Number of top-scored entry points to trace. |
| `max_depth` | number | `8` | Max trace depth per flow. |
| `entry_point` | string |  | Trace from a specific symbol instead, overriding top_n scoring. Takes a node id, a partial id such as service.py::AuthService, or a bare name such as App, resolved like get_symbol. |
| `repo` | string |  | Repository alias. "all" is not supported. |

## Returns

| Field | Meaning |
|---|---|
| `total_entry_points` | Number of flows traced |
| `flows` | One entry per entry point, sorted by `entry_point_score` descending |

Each `flows` entry:

| Field | Meaning |
|---|---|
| `entry_point` | Node id of the entry point |
| `entry_point_name` | Its short name |
| `entry_point_score` | Entry-point ranking score |
| `trace` | The BFS call path from this entry point |
| `trace_via` | *(when known)* Which resolution strategy produced each hop, aligned pairwise with `trace` |
| `depth` | How deep the trace went |
| `termination` | Why the trace stopped, one of a closed six-value vocabulary: `depth_limit`, `callees_truncated`, `cycle`, `confidence_filtered`, `excluded_target`, `no_callees`. Never just "ended": `no_callees` is deliberately distinct from a proven leaf, since a symbol whose calls failed to resolve looks identical to one that has none |
| `termination_detail` | Present when `termination` is `confidence_filtered`: which resolution origins were below the confidence floor and declined |
| `crosses_community` | `true` if the trace crosses an architectural community boundary |
| `communities_visited` | Which communities the trace passed through |

## Example

```python
get_execution_flows()
get_execution_flows(entry_point="src/cli/main.py::main", max_depth=4)
```

## Things worth knowing

- **Parameters are bounded.** `top_n` clamps to 1-50, `max_depth` to
  1-20, regardless of what's passed.
- **Excluded files never leak downstream.** Entry points in excluded
  paths are dropped up front, and excluded nodes reached later in a
  trace are filtered out of it too.
- **`entry_point` resolves like `get_symbol`.** An exact node id, a
  partial id or a bare name all work, ranked the same way as other tools.
  A name nothing matches errors immediately instead of falling back to
  top-N scoring, so a typo doesn't silently return the wrong flow.

> **Note**
>
> Follow up on any trace node with
> [`get_context`](https://docs.repowise.dev/mcp/get-context)`(include=["callers", "callees"])`
> for the detail this tool's `trace` doesn't carry: signatures, docs, and
> ownership.