Сценарий 15 находит логирование, assertions, trace points, помощники стека, кандидаты для breakpoint и другие конструкции, связанные с одним вопросом об ошибке. Он даёт разработчику static debugging evidence; живую отладку проводят отдельным инструментом.
Когда применять
Начните с наблюдаемого симптома и ограниченного компонента. Сценарий помогает выяснить:
- где ошибка записывается или преобразуется;
- какие функции могут участвовать в наблюдаемом пути вызова;
- где поставить breakpoint, чтобы различить две гипотезы;
- какие assertions или trace points охватывают подозреваемую ветвь.
Приложите падающий вход, тест, stack trace или runtime-наблюдение. Не просите определить дефект по всему репозиторию без конкретного симптома.
Предварительные условия и область
Нужны принятая задача реализации и CPG исследуемой ревизии. Ограничьте file_paths предполагаемым компонентом. До приложения журналов или стека удалите секреты, учётные данные и клиентские данные.
Сценарий ищет код и графовые связи. Он не запускает программу, не подключается к процессу, не читает живые переменные и не воспроизводит временное или конкурентное поведение.
Запуск типизированного сценария
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Найди логирование и кандидаты для breakpoint вокруг сбоя перехода импорта.",
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)
Отдельной поддерживаемой публичной CLI-команды сценария 15 нет. Сохраняйте сотрудника, событие, задачу и ревизию из типизированного вызова.
Как читать результат
Используйте methods, retrieved_functions, evidence и answer для планирования следующего эксперимента. Проверьте каждое важное место в привязанной ревизии и свяжите его с наблюдаемым симптомом.
Результат не является трассировкой времени выполнения. Он описывает статический путь вызова; факт выполнения в production проверяется runtime-наблюдением, а динамические пути дополняют анализ исходников.
От гипотезы к исправлению
Преобразуйте ведущую гипотезу в целевой воспроизводитель или RED-тест. Внесите минимальное ограниченное изменение, повторите проверку и сохраните данные до и после. Для ревью ревизии используйте сценарий 09, для пробелов покрытия — сценарий 07.
Результаты операционных команд не подменяют продуктовую приёмку и управляемое закрытие задачи.
Ошибки и восстановление
- Места не найдены: проверьте написание символа, ревизию, свежесть CPG, покрытие языка и область файлов.
- Получен fallback: пометьте его как гипотезу и восстановите недоступное свидетельство до изменения кода.
- Статические данные расходятся с runtime: приоритет у наблюдения, привязанного к ревизии; проверьте generated, dynamic и environment-specific пути.
- Приложен чувствительный trace: остановите распространение и следуйте утверждённой процедуре обращения с данными.
Контракт с исходным кодом
Статья привязана к следующим источникам:
src/workflow/scenarios/debugging/workflow.py— intent, CPG-результаты, evidence и fallback;src/workflow/scenarios/debugging_handlers/workflow.py— специализированные handlers;src/digital_employees/runtime/scenarios/role_bound_scenario_invoker.py— типизированная маршрутизация;src/digital_employees/runtime/scenarios/employee_scenario_invocation.py— владелец-разработчик и обязательное событие.