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
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
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Find logging and breakpoint candidates around 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)
There is no separate supported public Scenario 15 CLI command. Keep the role, event, task, and revision evidence carried by the typed request.
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 is not a runtime trace. It is a static call-path view; confirm production execution with runtime traces, and inspect the deployed revision when a function is absent from the graph.
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.
Keep operational command results separate from product acceptance and governed task closure.
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.
Source contract
This guide is bound to:
src/workflow/scenarios/debugging/workflow.py— intent routing, CPG results, evidence, and fallback;src/workflow/scenarios/debugging_handlers/workflow.py— specialized debugging handlers;src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py— typed routing;src/digital_employees/runtime/scenarios/employee_scenario_invocation.py— developer ownership and required event.