Skip to content

Repo Triage: локальный анализ issue и Python-репозитория

Repo Triage — вторая, более реалистичная лаборатория курса. Если Taskboard знакомит с handoff (передачей задачи между этапами по контракту, неделя 2) и тестовым baseline, то Repo Triage показывает отдельный шаг перед делегированием: подготовку фактов о запросе и структуре существующего Python-репозитория.

Что делает инструмент

Запуск локальной CLI-утилиты строит Markdown-отчёт по двум входам: каталогу с issue и корню анализируемого репозитория.

Windows PowerShell

Из корня репозитория:

.\.venv\Scripts\python.exe -m pip install -e ".\labs\repo-triage[dev]"
.\.venv\Scripts\python.exe -m repo_triage --repo .\labs\repo-triage\sample-repo --issues .\labs\repo-triage\issues

macOS / Linux

Из корня репозитория:

./.venv/bin/python -m pip install -e "./labs/repo-triage[dev]"
./.venv/bin/python -m repo_triage --repo ./labs/repo-triage/sample-repo --issues ./labs/repo-triage/issues

Создайте .venv по инструкции в разделе учебные репозитории курса, если окружение ещё не настроено. После запуска отчёт появится в терминале; он содержит инвентарь и кандидатов по каждому issue.

Отчёт содержит инвентарь Python-файлов и определённых в них классов/функций, список Markdown-файлов, тип задачи и статус triage. Для bug/test/docs утилита ранжирует небольшой список файлов-кандидатов по ключевым словам из заголовка и типу задачи.

Rule

Это поверхностная эвристика, а не семантическое понимание связей между модулями. Её задача — сократить список кандидатов, а не заменить чтение кода.

Типы заданий:

Тип Цель практики
bug Сопоставить воспроизводимое поведение с production-кодом и regression test.
test Ограничить изменение тестами и проверить, что агент не расширил scope.
docs Найти документационные файлы и не менять код без необходимости.
ambiguous Зафиксировать неизвестные; остановить процесс со статусом needs_input.

Границы и безопасность

Утилита работает только локально, не требует API-ключей и внешних пакетов. Она читает .py и .md, разбирает Python AST для инвентаря символов, не запускает код проекта, shell-команды или содержимое issue и не изменяет исходные файлы анализируемого репозитория; --output сохраняет отчёт только по явно указанному пути. Ошибки синтаксиса Python-файлов отражаются в отчёте, а не скрываются.

Не передавайте в отчёт приватные issue, секреты или персональные данные: он содержит тексты задач и имена файлов. Проверяйте предложенные кандидаты вручную. Передавать контекст внешнему или локальному LLM следует только отдельным явно контролируемым шагом.

Упражнение в мультиагентном workflow

  1. Сохраните отчёт и сравните его с выводом read-only analyst, который использует только те же issue и файлы.
  2. Для bug-задачи попросите planner сформулировать критерии приёмки, после чего поручите analyst проверить подходящие код и тесты.
  3. Для test/docs-задач явно задайте implementer-у ограничение «только tests» или «только Markdown».
  4. Для ambiguous-задачи требуйте handoff needs_input с вопросами, не с планом реализации.
  5. Отметьте false positives/negatives keyword ranking и внесите наблюдения в сравнение single-agent и multi-agent из Taskboard.

Rule

Отчёт утилиты — это вход для аналитика, а не замена его работы. Передавайте в workflow вывод вместе с источником (path:line), иначе handoff снова станет непроверяемым.

Команды запуска, формат issue и тесты описаны в labs/repo-triage/README.md исходного репозитория.