Сценарий 15 ищет записи журналов, проверки утверждений, точки трассировки, работу со стеком и подходящие места для точек останова. Он собирает сведения из исходников и графа для конкретного вопроса об ошибке. Отладку работающей программы проводите средствами приложения и инструментами наблюдения.
Когда применять
Начните с наблюдаемого симптома и ограниченного компонента. Сценарий помогает выяснить:
- где ошибка записывается или преобразуется;
- какие функции могут участвовать в наблюдаемом пути вызова;
- где поставить точку останова, чтобы различить две гипотезы;
- какие проверки утверждений или точки трассировки охватывают подозреваемую ветвь.
Приложите входные данные, вызывающие сбой, падающий тест, трассировку стека или наблюдение работающей программы. Не просите определить дефект по всему репозиторию без конкретного симптома.
Предварительные условия и область
Подготовьте окружение Python и локальную конфигурацию по руководству CLI и программному интерфейсу. Проверьте доступность сервисов графа и настройте LLM для ветвей workflow, которые её используют. Сохраните пример в файл Python в корне репозитория CodeGraph и запустите его из этого каталога в подготовленном окружении. Замените обозначения контекста на принятую область задачи и реальные ссылки на свидетельства.
Нужны принятая задача реализации и CPG исследуемой ревизии. Ограничьте file_paths предполагаемым компонентом. До приложения журналов или стека удалите секреты, учётные данные и клиентские данные.
Сценарий ищет код и графовые связи. Для запуска программы, подключения к процессу, просмотра переменных и воспроизведения временного или конкурентного поведения используйте отладчик приложения и инструменты наблюдения.
Запуск типизированного сценария
Задавайте одну задачу поиска за вызов. В примере ниже сценарий ищет места для точек останова; поиск журналирования выполните отдельным запросом.
from src.digital_employees.runtime.scenarios import (
RoleBoundScenarioInvocationRequest,
invoke_role_bound_scenario_request,
)
request = RoleBoundScenarioInvocationRequest(
query="Найди точки останова для проверки сбоя перехода импорта.",
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"])
Отдельной поддерживаемой публичной CLI-команды сценария 15 нет. Сохраняйте сотрудника, событие, задачу и ревизию из типизированного вызова.
Как сценарий выбирает места для проверки
Сначала сценарий пробует специализированный обработчик с готовым форматом ответа. Если запрос требует общего анализа, он определяет намерение: поиск журналирования, утверждений, трассировочных точек, функций работы со стеком или кандидатов для точек останова. Для намерения выбирается соответствующий поиск в CPG.
При поиске журналирования сценарий сопоставляет имена вызовов с шаблонами плагина языка или предметной области. Указанный уровень ошибки дополнительно фильтрует текст вызова. Каждая строка содержит имя вызванной функции, код выражения, строку, вызывающий метод и файл. Результаты упорядочены по файлу и строке, а их число ограничено конфигурацией анализа.
Для намерения breakpoint поиск сначала сопоставляет запрос с ключевыми словами подсистем из активного плагина. Затем строит запрос CPG по именам функций выбранной подсистемы или её префиксу. Если подсистема не выбрана, поиск использует общий набор функций и шаблонов точек останова этого плагина.
Каждый найденный метод содержит id, name, full_name, filename, signature и line_number. Откройте filename на строке line_number, сверьте сигнатуру и поставьте точку останова в отладчике. Запустите воспроизводитель ошибки и проверьте, с какими значениями программа входит в этот метод.
Например, при ошибке импорта найдите место, где исключение записывается в журнал, и откройте вызывающий метод. Затем поставьте точку останова перед этим вызовом и повторите исходный запрос с теми же входными данными. Сравнение значения исключения и выбранной ветви помогает проверить гипотезу о неверном переходе.
В общем пути результаты попадают в methods, имена функций — в retrieved_functions, а пояснение — в answer. Поля metadata.debug_intent, metadata.error_level и metadata.method_count показывают выбранный поиск, фильтр уровня и число найденных записей. Используйте эти сведения, чтобы уточнить следующий запрос.
Как читать результат
Используйте methods, retrieved_functions, evidence и answer для планирования следующего эксперимента. Проверьте каждое важное место в привязанной ревизии и свяжите его с наблюдаемым симптомом.
Результат показывает найденные конструкции исходного кода и их расположение. Сопоставьте их с трассировкой работающей программы на той же ревизии, чтобы определить фактически выполненную ветвь.
От гипотезы к исправлению
Преобразуйте ведущую гипотезу в целевой воспроизводитель или RED-тест. Внесите минимальное ограниченное изменение, повторите проверку и сохраните данные до и после. Для ревью ревизии используйте сценарий 09, для пробелов покрытия — сценарий 07.
Ошибки и восстановление
- Места не найдены: проверьте написание символа, ревизию, свежесть CPG, покрытие языка и область файлов.
- Получен fallback: пометьте его как гипотезу и восстановите недоступное свидетельство до изменения кода.
- Статические данные расходятся с наблюдением работающей программы: сравните ревизии и проверьте сгенерированный код, динамические вызовы и пути, зависящие от среды.
- Приложена трассировка с чувствительными данными: остановите распространение и следуйте утверждённой процедуре обращения с данными.