Process-detection budget (`maxProcesses`/`maxBranching`/`maxTraceDepth`) is hard-coded — no config or env to opt into fuller flow coverage on large repos

Summary

Execution-flow (process) detection silently down-samples on large repositories, and its budget is compiled-in with no way to raise it. On a large monorepo the analyzer warns that only a small fraction of candidate entry points are ranked into flows ([processes] N flows reported, but whole flows are MISSING: … entry point(s) never ranked in), yet there is no CLI flag, env var, or config key to increase the process budget or disable the capping.

This makes the (correct and useful) entryPointCandidatesDropped warning un-actionable: the user can see flows are being sampled away, but cannot opt into more complete coverage.

Background

Flow detection caps are defined in gitnexus/src/core/ingestion/process-processor.ts:

• maxTraceDepth = 10 (max steps per trace)
• maxBranching = 4 (max branches followed per node)
• maxProcesses = 75 (interface default), but the pipeline sets it dynamically:

computeDynamicMaxProcesses(symbolCount) // max(20, round(symbolCount / 10))

gitnexus/src/core/ingestion/pipeline-phases/processes.ts:38-40

So the per-repo flow cap scales with symbol count (symbols/10), but all three deep-traversal caps (maxBranching, maxTraceDepth, per-entry trace budget) are fixed constants with no override surface. Adding up, a repo whose entry-point candidate list exceeds ~200 already drops candidates (processes.ts:584, ENTRY_POINT_CANDIDATE_LIMIT), independent of the other budgets.

The phase already surfaces this honestly — ProcessTruncationStats distinguishes "whole flows dropped at maxProcesses" from "traces cut at maxTraceDepth", and pipeline-phases/processes.ts routes only the whole-flow-missing counters to warn. The gap is that the operator cannot mitigate it.

Why it matters

process data is not decorative — it powers several read paths:

• query() returns ranked execution flows for a concept (not just symbol matches).
• detect_changes() maps a diff onto symbols and reports affected processes.
• impact() reports affected_processes (flows that would break, and at which step).
• context(symbol) shows which flows a symbol participates in.

When the budget drops whole flows, an edit's blast radius over flows is under-reported. impact() correctly marks this as budget-exhausted (risk: UNKNOWN, and its resource riskScale names the exhausted budget) rather than claiming no effect — that part is right. But today the only remedy is to throw more RAM at the machine, because the budget itself cannot be raised.

Request

Expose the flow-detection budget via configuration so large repositories can opt into fuller coverage, e.g.:

• env vars such as GITNEXUS_MAX_PROCESSES, GITNEXUS_MAX_PROCESS_BRANCHING, GITNEXUS_MAX_PROCESS_TRACE_DEPTH, or
• entries in the .gitnexusrc config added by analyze --process-budget <...>, or
• an "also include a fuller flow set" flag.

Because the caps exist to bound memory/time on very large graphs (the dynamic symbols/10 cap and the per-entry trace budget are the anti-OOM guardrail), defaults should stay as-is and the config should be a raise/down only from an explicit operator choice — with the existing truncation warnings reflecting the chosen budget.

I am not certain which surface (env vs .gitnexusrc vs a flag) best fits GitNexus's existing config conventions — happy for the maintainers to pick. The core ask is simply an override path for the process budget today.

Suggested implementation pointers

• Defaults: gitnexus/src/core/ingestion/process-processor.ts — DEFAULT_CONFIG (maxBranching, maxTraceDepth, minSteps).
• Dynamic cap: gitnexus/src/core/ingestion/pipeline-phases/processes.ts — computeDynamicMaxProcesses (symbols/10), and where it is applied (processProcesses(…, { maxProcesses: dynamicMaxProcesses, minSteps: 3 })).
• Entry-point candidate limit: process-processor.ts — ENTRY_POINT_CANDIDATE_LIMIT (~200) and the entryPointCandidatesDropped accounting.
• Most other ProcessDetectionConfig fields are already threaded through; only maxProcesses is overridden at the call site today, so wiring a user-supplied override there mirrors existing structure.

Alternatively, if full coverage is considered undesirable for any graph (not just resource-constrained ones), a docs note explaining "the flow list is a sample by design" at the user-facing surface would at least make the limitation discoverable without introspection.