Сценарий 10: Межрепозиторный анализ

Архитектор анализирует зависимости, дубликаты и возможности консолидации между несколькими репозиториями с помощью CPG-агентов и графовых методов.

Содержание¶

• Быстрый старт
• Как это работает
• Двухфазная архитектура
• Определение намерений
• Фаза handler’ов
• 3 handler’а
• Базовые методы CrossRepoHandler
• Форматтеры отчётов
• Фаза LLM
• 3 агента
• Интеграция CallGraphAnalyzer
• Графовые инсайты
• Модели данных
• Конфигурация
• Использование CLI
• Примеры запросов
• Связанные сценарии

Быстрый старт¶

# Выберите сценарий межрепозиторного анализа
/select 10

Как это работает¶

Двухфазная архитектура¶

S10 использует стандартную двухфазную архитектуру: фаза 1 на основе handler’ов и фаза 2 с LLM fallback:

Запрос -> CrossRepoIntentDetector.detect()
  |
  Фаза 1: integrate_handlers(state)
    -> HandlerRegistry("cross_repo") -> подбор handler'а по intent
    -> handler.handle() -> CrossRepoReportFormatter -> ответ
    |
    handled=True  -> возврат форматированного результата (без LLM)
    handled=False -> Фаза 2
  |
  Фаза 2: cross_repo_workflow() [LLM fallback]
    -> 3 агента (RepositoryIndexer, CrossRepoAnalyzer, DependencyMapper)
    -> CallGraphAnalyzer (графовые инсайты)
    -> PromptRegistry -> LLMInterface.generate() -> ответ

cross_repo_workflow() в cross_repo.py сначала вызывает integrate_handlers(state). Если handler сработал (handled=True), результат возвращается без LLM. Иначе выполняется полный LLM-workflow с 3 агентами и графовым анализом.

Определение намерений¶

CrossRepoIntentDetector(IntentDetector) в cross_repo_handlers/intent_detector.py определяет 6 intent’ов, отсортированных по приоритету:

Fallback: general_cross_repo (confidence=0.5), когда ни один паттерн не совпал.

Сопоставление ключевых слов через keyword_match_morphological() для поддержки русской морфологии. Доменные ключевые слова хуков загружаются динамически через _get_domain_hook_keywords() из активного доменного плагина.

Фаза handler’ов¶

3 handler’а¶

cross_repo_handlers/workflow.py регистрирует 3 handler’а в HandlerRegistry("cross_repo"):

Все handler’ы наследуют CrossRepoHandler(BaseHandler).

Базовые методы CrossRepoHandler¶

CrossRepoHandler в cross_repo_handlers/handlers/base.py предоставляет 4 общих метода CPG-запросов:

ExtensionDependenciesHandler дополнительно использует get_extension_dependency_patterns_from_plugin() и build_sql_like_clause() из _plugin_helpers для загрузки доменных паттернов API расширений (доменно-независимый подход).

Форматтеры отчётов¶

CrossRepoReportFormatter(CrossRepoFormatter) в cross_repo_handlers/formatters/cross_repo_report.py предоставляет 2 форматтера:

CrossRepoFormatter(BaseFormatter) предоставляет вспомогательные методы: format_file_list(), format_consolidation_badge(), format_similarity_badge(). Все форматтеры поддерживают локализацию EN/RU.

Фаза LLM¶

3 агента¶

Когда ни один handler не сработал, cross_repo_workflow() выполняет полный LLM-конвейер с 3 агентами из src/cross_repo/cross_repo_agents.py:

Конвейер: 1. RepositoryIndexer обнаруживает и индексирует репозитории из workspace_path 2. CrossRepoAnalyzer находит дубликаты и возможности консолидации 3. DependencyMapper картирует зависимости, обнаруживает циклы, генерирует отчёт 4. Список доказательств строится из дубликатов, возможностей и зависимостей высокого риска 5. PromptRegistry.get_agent_prompt("cross_repo_analyzer", ...) формирует промпт 6. LLMInterface().generate() генерирует финальный ответ

Интеграция CallGraphAnalyzer¶

После завершения 3 агентов CallGraphAnalyzer(cpg) из src/analysis выполняет графовый анализ:

• Общие методы: Для каждого дубликата анализирует вызывающие/вызываемые/влияние через find_all_callers(), find_all_callees(), analyze_impact(). Вычисляет consolidation_score = (callers + callees) * instances.
• Межрепозиторные вызовы: Для зависимостей с source_method находит вызываемые методы для обнаружения tight coupling. Помечает зависимости с высокой связанностью для приоритета декаплинга.
• Паттерны консолидации: Группирует методы по сигнатуре графа вызовов (набор вызываемых). Методы с идентичными паттернами вызовов — кандидаты на консолидацию.

Графовые инсайты¶

Графовый анализ формирует 3 категории инсайтов в state["metadata"]["graph_insights"]:

Модели данных¶

Ключевые dataclass’ы из src/cross_repo/repo_patterns.py:

Перечисления: DependencyType (import, function_call, type_reference, …), RiskLevel (critical, high, medium, low).

Конфигурация¶

S10 является доменно-независимым. Все доменные данные загружаются из плагинов:

• _get_api_keywords() — маппинг API-ключевых слов на функции из domain.get_api_keywords()
• _get_domain_hook_keywords() — ключевые слова хуков из domain.get_intent_keywords("CROSS_REPO")
• get_extension_dependency_patterns_from_plugin() — паттерны зависимостей расширений

Конфигурация проектов в config.yaml → projects:

projects:
  registry:
    postgres:
      db_path: data/projects/postgres.duckdb
      language: c
      domain: postgres
    extension1:
      db_path: data/projects/extension1.duckdb
      language: c
      domain: postgres

Использование CLI¶

# Анализ межрепозиторных зависимостей
python -m src.cli query "Find cross-repository dependencies"

# Обнаружение дубликатов
python -m src.cli query "Find duplicate code across repositories"

# Анализ консолидации
python -m src.cli query "Show consolidation opportunities"

# Анализ зависимостей расширений
python -m src.cli query "Which extensions depend on memory allocation functions?"

# Анализ использования хуков
python -m src.cli query "Find all hook usage patterns"

# Проверка согласованности
python -m src.cli query "Check naming consistency across codebase"

Примеры запросов¶

• “Find cross-repository dependencies”
• “Find duplicate code across repositories”
• “Show consolidation opportunities”
• “Which extensions use [function_name]?”
• “Find all hook usage patterns”
• “Check naming consistency across the codebase”
• “What would break if [function] changes?”
• “Show high-risk dependencies”
• “Find functions used by extensions”

Связанные сценарии¶

• Архитектура — Анализ внутренней архитектуры (S11)
• Рефакторинг — Обнаружение запахов кода и мёртвого кода (S05)
• Массовый рефакторинг — Крупномасштабные изменения (S13)
• Аудит безопасности — Сканирование уязвимостей (S02)

S10 vs S11: S10 (межрепозиторный анализ) фокусируется на мультирепозиторном анализе — дубликаты между репозиториями, межрепозиторные зависимости, возможности консолидации и анализ графа вызовов между репозиториями. S11 (архитектура) фокусируется на внутренней архитектуре одного проекта — анализ слоёв, метрики связности/сцепления, циклические зависимости внутри одной кодовой базы.