Scenario 15 locates logging, assertions, trace points, stack helpers, breakpoint candidates, and other source constructs related to one debugging question. It produces static debugging evidence for a developer; live runtime inspection uses the application’s debugger and observability tools.
When to use it
Start with an observed symptom and a bounded component. Useful questions include:
- where an error is logged or converted;
- which functions participate in an observed call path;
- where to place a breakpoint to distinguish two hypotheses;
- which assertions or trace points cover the suspected branch.
Attach the failing input, test, stack trace, or runtime observation as a source reference. Do not ask the scenario to infer a defect from the whole repository without a symptom.
Prerequisites and scope
Prepare the Python environment and local configuration using the CLI guide and programmatic guide. Confirm that the required graph services are accessible and configure the LLM for workflow branches that use it. Save the example as a Python file in the CodeGraph repository root and run it from that directory in the prepared environment. Replace all context placeholders with the accepted task scope and actual evidence references.
Use an accepted implementation task and a CPG that matches the investigated revision. Limit file_paths to the suspected component. Remove secrets, credentials, and customer data from stack traces or logs before attaching them.
The scenario searches code and graph relations. Use the application’s debugger and observability tools to execute the program, attach to a process, inspect live variables, and reproduce timing and concurrency behavior.
Run the typed scenario
Use one search objective per call. The example below asks for breakpoint locations; run logging discovery as a separate query.
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Find breakpoint candidates for investigating the failed import transition.",
employee_id="codegraph_developer",
scenario_id="scenario_15",
event_type="implementation_start",
context={
"project_key": "codegraph",
"namespace": "default",
"task_id": "<task-id>",
"source_refs": ["<failure-evidence-ref>", "<revision-ref>"],
"file_paths": ["<bounded-source-path>"],
},
)
result = invoke_role_bound_scenario_request(request)
if result.get("error"):
raise RuntimeError(result["error"])
if not result.get("scenario_id") or not result.get("answer"):
raise RuntimeError("Scenario returned no scenario identity or answer")
print(result["answer"])
There is no separate supported public Scenario 15 CLI command. Keep the role, event, task, and revision evidence carried by the typed request.
How the scenario selects inspection locations
The scenario first tries a specialized handler with a prepared answer format. For a general analysis, it identifies the intent: logging, assertions, trace points, stack helpers, or breakpoint candidates. It then selects the corresponding CPG finder.
For logging, the finder matches call names against patterns from the language or domain plugin. A specified error level also filters the call expression. Each row contains the called function, expression text, line, caller method, and file. Results are ordered by file and line and bounded by the analysis configuration.
For the breakpoint intent, the finder first matches the query against subsystem keywords from the active plugin. It then builds a CPG query using the selected subsystem’s function names or prefix. When no subsystem is selected, the finder uses the plugin’s general breakpoint functions and name patterns.
Each matching method contains id, name, full_name, filename, signature, and line_number. Open filename at line_number, check the signature, and set a breakpoint in the debugger. Run the failure reproducer and inspect the values when execution enters that method.
For example, when an import fails, locate the call that logs the exception and open its caller. Set a breakpoint before that call and repeat the original request with the same inputs. Compare the exception value and selected branch to test the suspected transition failure.
On the general path, results populate methods, function names populate retrieved_functions, and the explanation appears in answer. The fields metadata.debug_intent, metadata.error_level, and metadata.method_count identify the search, level filter, and number of records. Use them to refine the next query.
Read the result
Use methods, retrieved_functions, evidence, and answer to plan the next experiment. Verify every important location in the bound revision and connect it to the observed symptom.
The result identifies source constructs and their locations. Compare them with a runtime trace from the same revision to determine which branch executed.
From hypothesis to fix
Convert the leading hypothesis into a focused reproducer or RED test. Make the smallest bounded change, rerun the reproducer, and record the before/after evidence. Use Scenario 09 for revision review and Scenario 07 for coverage gaps.
Failure and recovery
- No locations found: verify symbol spelling, revision, CPG freshness, language coverage, and file scope.
- Fallback answer: mark it as a hypothesis and restore the missing CPG or LLM evidence before acting.
- Static and runtime evidence conflict: prefer the observed revision-bound runtime evidence and investigate generated, dynamic, or environment-specific paths.
- Sensitive trace attached: stop distribution and follow the approved data-handling procedure.