Композитные рабочие процессы

Руководство по архитектуре и использованию композиции и оркестрации сценариев.

Содержание¶

Обзор
Архитектура
S18 как оркестратор
S19 как оркестратор
Компоненты композиции
Конфигурация
Конечные точки API
Команды CLI
Аудит качества кода
Валидация пользовательских историй
Синхронизация документации по интерфейсам
Лучшие практики

Обзор¶

Композитные рабочие процессы позволяют сценариям действовать как оркестраторы, вызывающие несколько подсценариев для комплексного анализа. Это обеспечивает сложный многогранный анализ кода без необходимости запускать сценарии по отдельности.

Ключевые преимущества¶

Комплексный анализ: Объединение проверок безопасности, производительности и качества
Дедупликация: Автоматическое объединение и дедупликация находок
Разрешение конфликтов: Разрешение противоречивых рекомендаций
Оценка приоритетов: Ранжирование находок по комбинированным метрикам
Единая точка входа: Одна команда для полного анализа

Архитектура¶

┌─────────────────────────────────────────────────────────────────────────────┐
│                    АРХИТЕКТУРА КОМПОЗИТНОГО РАБОЧЕГО ПРОЦЕССА                │
│                                                                              │
│  Запрос пользователя: "Оптимизировать src/"                                  │
│        │                                                                     │
│        ▼                                                                     │
│  ┌────────────────────────────────────────────────────────────────────────┐ │
│  │                    ОРКЕСТРАТОР (S18 или S19)                            │ │
│  │                                                                          │ │
│  │  ┌─────────────────────────────────────────────────────────────────┐   │ │
│  │  │                   ВЫЗЫВАТЕЛЬ СЦЕНАРИЕВ                           │   │ │
│  │  │                                                                   │   │ │
│  │  │  Параллельное выполнение:                                         │   │ │
│  │  │  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐                    │   │ │
│  │  │  │ S02 │  │ S05 │  │ S06 │  │ S11 │  │ S12 │                    │   │ │
│  │  │  │Безоп│  │Рефак│  │Произ│  │Архит│  │Долг │                    │   │ │
│  │  │  └──┬──┘  └──┬──┘  └──┬──┘  └──┬──┘  └──┬──┘                    │   │ │
│  │  │     │        │       │        │        │                         │   │ │
│  │  │     └────────┴───────┴────────┴────────┘                         │   │ │
│  │  │                      │                                            │   │ │
│  │  │              Результаты подсценариев                              │   │ │
│  │  └──────────────────────┼───────────────────────────────────────────┘   │ │
│  │                         │                                                │ │
│  │  ┌──────────────────────▼───────────────────────────────────────────┐   │ │
│  │  │                ОБЪЕДИНИТЕЛЬ РЕЗУЛЬТАТОВ                           │   │ │
│  │  │                                                                   │   │ │
│  │  │  Стратегия: union | intersection | weighted | consensus          │   │ │
│  │  │  - Дедупликация (порог схожести: 0.8)                             │   │ │
│  │  │  - Отслеживание источников                                        │   │ │
│  │  │  - Сохранение метаданных                                          │   │ │
│  │  └──────────────────────┼───────────────────────────────────────────┘   │ │
│  │                         │                                                │ │
│  │  ┌──────────────────────▼───────────────────────────────────────────┐   │ │
│  │  │                 РАЗРЕШИТЕЛЬ КОНФЛИКТОВ                            │   │ │
│  │  │                                                                   │   │ │
│  │  │  Режим: priority_based | security_first | interactive            │   │ │
│  │  │  - Обнаружение противоречивых рекомендаций                        │   │ │
│  │  │  - Применение правил разрешения                                   │   │ │
│  │  │  - Логирование решений                                            │   │ │
│  │  └──────────────────────┼───────────────────────────────────────────┘   │ │
│  │                         │                                                │ │
│  │  ┌──────────────────────▼───────────────────────────────────────────┐   │ │
│  │  │                КАЛЬКУЛЯТОР ПРИОРИТЕТОВ                            │   │ │
│  │  │                                                                   │   │ │
│  │  │  Алгоритм: weighted_sum | risk_based | custom                     │   │ │
│  │  │  Веса: серьёзность(0.3) × влияние(0.25) × roi(0.2)                │   │ │
│  │  │        × уверенность(0.15) × консенсус(0.1)                       │   │ │
│  │  └──────────────────────┼───────────────────────────────────────────┘   │ │
│  │                         │                                                │ │
│  └─────────────────────────┼────────────────────────────────────────────────┘ │
│                            │                                                  │
│                            ▼                                                  │
│                  УНИФИЦИРОВАННЫЕ НАХОДКИ                                      │
│                  (отсортированы по приоритету)                                │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

S18 как оркестратор¶

Сценарий 18 (Оптимизация кода) оркестрирует несколько сценариев анализа для комплексного улучшения кода:

Подсценарии¶

Сценарий	Название	Вес	Вклад
S02	Аудит безопасности	1.5	Уязвимости безопасности
S05	Рефакторинг	1.0	Запахи кода, мёртвый код
S06	Производительность	1.2	Узкие места производительности
S11	Архитектура	1.1	Нарушения архитектуры
S12	Технический долг	0.9	Элементы технического долга

Поток выполнения¶

Запрос оптимизации S18
        │
        ├─→ S02: Анализ безопасности
        ├─→ S05: Анализ рефакторинга
        ├─→ S06: Анализ производительности
        ├─→ S11: Анализ архитектуры
        └─→ S12: Анализ технического долга
                │
                ▼
        Объединение находок (взвешенное)
                │
                ▼
        Разрешение конфликтов
                │
                ▼
        Расчёт приоритетов
                │
                ▼
        Унифицированный отчёт об оптимизации

Пример использования¶

# CLI
python -m src.cli composition run "Оптимизировать src/core/" -o s18

# MCP
/select 18
> Проанализировать src/core/ для комплексной оптимизации

Вывод¶

╭─────────────── Результаты композитной оптимизации ──────────╮
│                                                                │
│  Вызванные подсценарии: S02, S05, S06, S11, S12                │
│  Находок до объединения: 87                                    │
│  Находок после объединения: 52                                 │
│  Удалено дубликатов: 35                                        │
│  Разрешено конфликтов: 3                                       │
│  Время выполнения: 4.2с                                        │
│                                                                │
│  Топ находок:                                                  │
│                                                                │
│  1. [Критическое] Уязвимость SQL-инъекции                      │
│     Источник: S02 (Безопасность)                               │
│     Оценка приоритета: 0.95                                    │
│                                                                │
│  2. [Высокое] Узкое место производительности в цикле           │
│     Источник: S06 (Производительность)                         │
│     Оценка приоритета: 0.87                                    │
│                                                                │
│  3. [Высокое] Нарушение слоя архитектуры                       │
│     Источник: S11 (Архитектура)                                │
│     Оценка приоритета: 0.82                                    │
│                                                                │
╰────────────────────────────────────────────────────────────────╯

S19 как оркестратор¶

Сценарий 19 (Проверка стандартов) оркестрирует проверку соответствия с правилами на основе документов:

Подсценарии¶

Сценарий	Название	Роль	Вклад
S08	Соответствие	Обязательный	Правила соответствия стандартам, сопоставление шаблонов
S17	Редактирование файлов	Опциональный	Применение исправлений на основе AST
S18	Оптимизация кода	Опциональный	Рекомендации по оптимизации исправлений

S08 всегда вызывается как основной механизм проверки соответствия. S17 и S18 интегрируются опционально — S17 для применения исправлений, S18 для оптимизации предложенных изменений.

Обогащение документами¶

Документ стандартов
        │
        ▼
    Извлечение правил
        │
        ├─→ S08: Анализ соответствия (обязательный)
        │         │
        │         ▼
        │   Найденные нарушения
        │         │
        │         ▼
        ├─→ S17: Применение исправлений (опциональный)
        │         │
        │         ▼
        └─→ S18: Оптимизация исправлений (опциональный)
                  │
                  ▼
        Нарушения со ссылками

Пример использования¶

# CLI
python -m src.cli composition run "Проверить на соответствие стандартам OWASP" -o s19

# С пользовательским документом стандартов
python -m src.cli composition run "Проверить по company_standards.yaml" -o s19

Аудит качества кода¶

Аудит — самый масштабный композитный рабочий процесс. Запускает 9 подсценариев по 12 измерениям качества кода с многоуровневой фильтрацией ложных срабатываний.

Подсценарии¶

Сценарий	Название	Вклад
S02	Аудит безопасности	Уязвимости, анализ потоков данных
S03	Документация	Качество комментариев и документации
S05	Рефакторинг	Запахи кода, мёртвый код
S06	Производительность	Узкие места производительности
S07	Покрытие тестами	Тестируемость и пробелы в покрытии
S08	Соответствие	Стандарты кодирования, 152-ФЗ, ГОСТ
S11	Архитектура	Модульность, циклические зависимости
S12	Технический долг	Накопленный долг, ROI рефакторинга
S16	Точки входа	Поверхность атаки, внешние входы

12 измерений качества¶

#	Измерение	Источники
1	Читаемость и стандарты кодирования	S05
2	Модульность и повторное использование	S11
3	Избыточный и трудноподдерживаемый код	S05, S12
4	Масштабируемость	S06, S11
5	Производительность на больших объёмах данных	S06
6	Архитектура для масштабирования	S11
7	Уязвимости безопасности	S02, S08
8	SQL-инъекции, XSS и утечки данных	S02, S16
9	Поддерживаемость	S12, S05
10	Покрытие тестами и тестируемость	S07
11	Сложность и зависимости	S11, S12
12	Документация и комментарии	S03

Поток выполнения¶

Запрос аудита
        │
        ▼
  AuditRunner.run()
        │
        ▼
  AuditRunner._collect_metrics()
        │
        ├─→ S02: Безопасность
        ├─→ S03: Документация
        ├─→ S05: Рефакторинг
        ├─→ S06: Производительность
        ├─→ S07: Тесты
        ├─→ S08: Соответствие
        ├─→ S11: Архитектура
        ├─→ S12: Тех. долг
        └─→ S16: Точки входа
                │
                ▼
        Фильтрация ложных срабатываний (V25-V30)
                │
                ▼
        Подсчёт мёртвого кода
                │
                ▼
        Объединение + дедупликация
                │
                ▼
        Отчёт по 12 измерениям

Фильтрация ложных срабатываний мёртвого кода¶

Многоуровневая система фильтрации (V25–V30) последовательно снижает FP-rate:

Версия	Фильтр	Описание
V25	`is_test`	Исключение тестовых методов
V26	Достижимость на уровне классов	Методы, вызываемые через экземпляр класса
V26b	Наследование	Базовые классы с живыми подклассами
V27	`is_nested`	Исключение вложенных функций
V28	Полностью мёртвые модули	Модули, где все методы мёртвые
V29	Низкая жизнеспособность	Модули ≥5 методов, <40% живых
V30	Живой компаньон файла	Функции FILE-уровня в файлах с живым кодом

Пример использования¶

# CLI
python -m src.cli audit --db data/projects/codegraph.duckdb --language ru

# С автоисправлениями
python -m src.cli audit --db data/projects/codegraph.duckdb --autofix

# JSON-формат для CI/CD
python -m src.cli audit --db data/projects/codegraph.duckdb --format json --output report.json

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

composition:
  orchestrators:
    audit:
      sub_scenarios:
        - scenario_02
        - scenario_03
        - scenario_05
        - scenario_06
        - scenario_07
        - scenario_08
        - scenario_11
        - scenario_12
        - scenario_16
      parallel_execution: true
      timeout_seconds: 600
      max_findings_per_scenario: 50
      deduplicate_paths: true

Валидация пользовательских историй¶

Валидация проверяет, что каждая выполненная пользовательская история из USER_STORIES.md доступна хотя бы через один интерфейс.

Проверяемые интерфейсы¶

Интерфейс	Путь в CPG	Описание
CLI	`src/cli/`	Команды CLI
REST API	`src/api/routers/`	REST-эндпоинты
MCP	`src/mcp/`	Инструменты MCP-сервера
ACP	`src/acp/`	Агентный протокол
gRPC	`src/services/gocpg/grpc_transport.py`	gRPC-транспорт Go CPG

Типы доказательств¶

Символ	Тип	Уверенность	Описание
`+`	dedicated	≥0.8	Специализированный эндпоинт
`~`	passthrough	≤0.5	Общий шлюз (напр. /chat)
`*`	scenario_map	0.7	Из маппинга сценарий→интерфейс
`-`	not found	—	Не найден

Пример использования¶

# Базовый запуск
python -m src.cli dogfood validate-stories --db data/projects/codegraph.duckdb

# С Go CPG
python -m src.cli dogfood validate-stories \
    --db data/projects/codegraph.duckdb \
    --go-db data/projects/gocpg.duckdb \
    --output report.md

Синхронизация документации по интерфейсам¶

Синхронизация документации — композитный рабочий процесс, который сканирует 6 интерфейсов на предмет расхождений документации. Запускает 5-фазный пайплайн для обнаружения сущностей кода, парсинга существующей документации, выявления несоответствий и генерации отчёта покрытия.

Проверяемые интерфейсы¶

Интерфейс	Путь к коду	Путь к документации
REST API	`src/api/routers/`	`docs/api/{lang}/REST_API.md`
CLI	`src/cli/`, `src/api/cli.py`	`docs/guides/{lang}/CLI_GUIDE.md`
MCP	`src/mcp/`	`docs/api/{lang}/MCP_TOOLS.md`
ACP	`src/acp/`	`docs/api/{lang}/ACP_INTEGRATION.md`
gRPC	`src/services/gocpg/grpc_transport.py`	`docs/api/{lang}/GRPC_API.md`
WebSocket	`src/api/websocket/routes.py`, `src/api/routers/dashboard_ws.py`	`docs/api/{lang}/WEBSOCKET_API.md`

5-фазный пайплайн¶

Обнаружение         Парсинг документов   Генерация            Детекция дрифта      Отчёт
     │                    │                    │                    │                  │
     ▼                    ▼                    ▼                    ▼                  ▼
  Сканирование       Парсинг markdown     Генерация            Сопоставление       Markdown/JSON
  сущностей кода     задокументированных  недостающих          код↔документация     Покрытие %
  по интерфейсам     сущностей            заглушек (опц.)      Мультистратегия     по интерфейсам

Категории дрифта¶

Категория	Описание
`UNDOCUMENTED`	Сущность есть в коде, но отсутствует в документации
`STALE`	Документация описывает сущность, которой нет в коде
`OUTDATED`	Обе существуют, но параметры/сигнатуры расходятся
`COVERED`	Корректно задокументировано

Стратегии сопоставления¶

Детектор дрифта использует мультистратегийный пайплайн (фаза 4):

Точное совпадение — прямое сравнение имён (уверенность: 1.0)
С учётом маршрутов — удаление префиксов маршрутов /api/v1 (уверенность: 0.95)
Нормализация регистра — эквивалентность snake_case ↔ kebab-case (уверенность: 0.95)
Нечёткое совпадение — подобие Жаккара по токенам имени (уверенность: коэффициент подобия)

Шаблоны исключения (регулярные выражения) позволяют фильтровать сущности. Конфигурация:

composition:
  orchestrators:
    interface_docs_sync:
      drift_detection:
        route_prefix_strip: ["/api/v1", "/api/v2", "/api"]
        exclude_patterns: ["^internal_", "^_"]
        case_normalize: true
        fuzzy_threshold: 0.6
        min_coverage_warning: 0.8

Пример использования¶

# Полный отчёт
python -m src.cli docs-sync --db data/projects/codegraph.duckdb

# CI-режим (код выхода 1, если покрытие ниже порога)
python -m src.cli docs-sync --check --format json

# Фильтрация по интерфейсам
python -m src.cli docs-sync --interfaces rest_api,cli --language ru

# REST API
curl -X POST /api/v1/documentation/sync -d '{"interfaces": ["rest_api", "cli"]}'

# MCP-инструмент
codegraph_docs_sync(interfaces="rest_api,cli", output_format="json")

Интеграция с CI¶

GitHub Actions .github/workflows/docs-sync.yml запускается на PR, затрагивающих код интерфейсов или документацию. Публикует прикреплённый комментарий к PR с метриками покрытия и загружает отчёт как артефакт.

Компоненты композиции¶

ScenarioInvoker¶

Вызывает подсценарии с параллельным или последовательным выполнением:

from src.workflow.composition import ScenarioInvoker

invoker = ScenarioInvoker()

# Параллельное выполнение (по умолчанию)
results = invoker.invoke_parallel(
    scenarios=["scenario_02", "scenario_06", "scenario_11"],
    state=state,
    timeout=30.0,
)

# Последовательное выполнение
results = invoker.invoke_sequential(
    scenarios=["scenario_02", "scenario_06"],
    state=state,
)

ResultMerger¶

Объединяет находки с настраиваемыми стратегиями:

from src.workflow.composition import ResultMerger, MergeStrategy

merger = ResultMerger()

# Объединение со стратегией union (включить все)
result = merger.merge(
    scenario_results={"s02": findings_s02, "s06": findings_s06},
    strategy=MergeStrategy.UNION,
)

# Объединение со взвешенной стратегией
result = merger.merge(
    scenario_results=all_findings,
    strategy=MergeStrategy.WEIGHTED,
)

Стратегии объединения¶

Стратегия	Описание	Вариант использования
`union`	Включить все находки	Комплексный анализ
`intersection`	Только находки из 2+ сценариев	Только высокая уверенность
`weighted`	Взвешивать по приоритету сценария	Приоритизированный анализ
`consensus`	Находки с согласием	Консервативный подход

ConflictResolver¶

Разрешает противоречивые рекомендации:

from src.workflow.composition import ConflictResolver

resolver = ConflictResolver()

# Разрешение конфликтов
resolved_findings, resolution_log = resolver.resolve_conflicts(
    findings=unified_findings,
    mode="priority_based",
)

Типы конфликтов¶

Тип	Описание	Разрешение
Одно место	Несколько находок для одного кода	Оставить с высшим приоритетом
Противоречие	Противоречивые рекомендации	Применить правила разрешения
Перекрытие	Частично перекрывающиеся находки	Объединить или выбрать

PriorityCalculator¶

Вычисляет комбинированные оценки приоритетов:

from src.workflow.composition import PriorityCalculator

calculator = PriorityCalculator()

# Вычислить и отсортировать по приоритету
prioritized = calculator.sort_by_priority(findings)

# Получить разбивку приоритета
breakdown = calculator.get_priority_breakdown(finding)

Веса приоритетов¶

Фактор	Вес	Описание
`severity`	0.30	Уровень серьёзности находки
`impact`	0.25	Оценка потенциального влияния
`roi`	0.20	Возврат инвестиций
`confidence`	0.15	Уверенность обнаружения
`consensus`	0.10	Согласие между сценариями

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

Настройка композиции в config.yaml:

composition:
  enabled: true

  orchestrators:
    scenario_18:
      sub_scenarios:
        - scenario_02  # Безопасность
        - scenario_05  # Рефакторинг
        - scenario_06  # Производительность
        - scenario_11  # Архитектура
        - scenario_12  # Технический долг
      parallel_execution: true
      timeout_seconds: 60
      enabled: true

    scenario_19:
      sub_scenarios:
        - scenario_08  # Соответствие (обязательный)
      optional_sub_scenarios:
        - scenario_17  # Редактирование файлов (опциональный)
        - scenario_18  # Оптимизация кода (опциональный)
      parallel_execution: false
      timeout_seconds: 30
      enabled: true

  merging:
    strategy: weighted  # union, intersection, weighted, consensus
    deduplication_threshold: 0.8
    max_findings: 100
    preserve_sources: true

  priority:
    algorithm: weighted_sum  # weighted_sum, risk_based, custom
    weights:
      severity: 0.30
      impact: 0.25
      roi: 0.20
      confidence: 0.15
      consensus: 0.10

  conflicts:
    resolution_mode: priority_based  # priority_based, security_first, interactive
    security_priority_boost: 1.5
    compliance_priority_boost: 1.3
    log_resolutions: true

Конечные точки API¶

POST /api/v1/composition/query¶

Выполнить композитный рабочий процесс:

POST /api/v1/composition/query
Content-Type: application/json
Authorization: Bearer <token>

{
  "query": "Оптимизировать src/core/",
  "orchestrator": "scenario_18",
  "context": {
    "language": "ru",
    "file_paths": ["src/core/"]
  },
  "parallel": true,
  "merge_strategy": "weighted"
}

Ответ:

{
  "session_id": "sess_abc123",
  "answer": "Найдено 52 возможности для оптимизации...",
  "unified_findings": [],
  "priority_scores": {},
  "sub_scenario_results": {},
  "conflicts_resolved": 3,
  "execution_time_ms": 4234.5,
  "metadata": {}
}

POST /api/v1/composition/apply¶

Применить ожидающую правку из сессии:

POST /api/v1/composition/apply
Content-Type: application/json
Authorization: Bearer <token>

{
  "session_id": "sess_abc123",
  "finding_id": "find_xyz789",
  "preview": true
}

GET /api/v1/composition/conflicts/{session_id}¶

Получить информацию о конфликтах для сессии:

GET /api/v1/composition/conflicts/sess_abc123
Authorization: Bearer <token>

GET /api/v1/composition/session/{session_id}¶

Получить полное состояние сессии:

GET /api/v1/composition/session/sess_abc123
Authorization: Bearer <token>

DELETE /api/v1/composition/session/{session_id}¶

Удалить сессию и её состояние:

DELETE /api/v1/composition/session/sess_abc123
Authorization: Bearer <token>

GET /api/v1/composition/config¶

Получить конфигурацию композиции:

GET /api/v1/composition/config
Authorization: Bearer <token>

GET /api/v1/composition/scenarios¶

Список доступных сценариев для композиции:

GET /api/v1/composition/scenarios
Authorization: Bearer <token>

Команды CLI¶

# Запустить композитный рабочий процесс
python -m src.cli composition run "<запрос>" -o s18|s19

# Запустить с конкретными подсценариями
python -m src.cli composition run "Анализировать src/" -o s18 -s scenario_02 -s scenario_06

# Запустить со стратегией объединения
python -m src.cli composition run "Оптимизировать код" -o s18 --merge-strategy weighted

# Применить ожидающую правку
python -m src.cli composition apply <finding_id> -s <session_id>

# Предпросмотр правки перед применением
python -m src.cli composition apply <finding_id> -s <session_id> --preview

# Просмотреть конфликты
python -m src.cli composition conflicts -s <session_id>

# Просмотреть конфигурацию
python -m src.cli composition config

# Список доступных сценариев
python -m src.cli composition scenarios

Лучшие практики¶

1. Выбор правильного оркестратора¶

Аудит для комплексного анализа: Полная проверка по 12 измерениям качества (9 подсценариев, 600с таймаут)
S18 для оптимизации: Когда нужны улучшения производительности, безопасности и качества (5 подсценариев)
S19 для соответствия: Когда нужна проверка стандартов со ссылками (S08 обязательный + опциональные S17/S18)
Синхронизация документации для покрытия документации: Когда нужно найти незадокументированные эндпоинты и устаревшую документацию (6 интерфейсов, 120с таймаут)

2. Настройка стратегии объединения¶

# Для комплексного анализа (включить всё)
merging:
  strategy: union

# Только для находок с высокой уверенностью
merging:
  strategy: intersection

# Для приоритизированного анализа
merging:
  strategy: weighted

3. Обработка конфликтов¶

Включите логирование конфликтов для понимания решений по разрешению:

conflicts:
  log_resolutions: true

4. Оптимизация производительности¶

Для больших кодовых баз используйте параллельное выполнение с таймаутом:

orchestrators:
  scenario_18:
    parallel_execution: true
    timeout_seconds: 120

5. Настройка весов приоритетов¶

Настройте веса в соответствии с приоритетами вашей команды:

priority:
  weights:
    severity: 0.40  # Приоритет серьёзности
    impact: 0.20
    roi: 0.20
    confidence: 0.10
    consensus: 0.10

Операции жизненного цикла проектов¶

Помимо композитных рабочих процессов анализа, CodeGraph предоставляет управление жизненным циклом проектов через все интерфейсы:

Доступные операции¶

Операция	CLI	MCP	REST API
Список проектов	`projects list`	`codegraph_project_list`	`GET /api/v1/projects`
Переключение	`projects activate <name>`	`codegraph_project_switch`	`POST /api/v1/projects/{id}/activate`
Переименование	`projects rename <old> <new>`	`codegraph_project_rename`	`PUT /api/v1/projects/{id}`
Удаление	`projects delete <name>`	`codegraph_project_delete`	`DELETE /api/v1/projects/{id}`

Очистка данных при удалении¶

Удаление может опционально удалить связанные данные:

Файлы DuckDB — CLI --delete-files, API неявно через реестр импорта
Коллекции ChromaDB — CLI --delete-collections, API ?delete_collections=true, MCP delete_data=true
Запрос подтверждения — CLI требует --yes / -y для пропуска интерактивного подтверждения при удалении данных

Разрешения RBAC¶

Операция	Требуемая роль
Список / Переключение	`GroupRole.VIEWER`
Переименование / Обновление	`GroupRole.EDITOR`
Удаление	`GroupRole.ADMIN`
Удаление с данными	`GroupRole.ADMIN`

Содержание¶

Обзор¶

Ключевые преимущества¶

Архитектура¶

S18 как оркестратор¶

Подсценарии¶

Поток выполнения¶

Пример использования¶

Вывод¶

S19 как оркестратор¶

Подсценарии¶

Обогащение документами¶

Пример использования¶

Аудит качества кода¶

Подсценарии¶

12 измерений качества¶

Поток выполнения¶

Фильтрация ложных срабатываний мёртвого кода¶

Пример использования¶

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

Валидация пользовательских историй¶

Проверяемые интерфейсы¶

Типы доказательств¶

Пример использования¶

Синхронизация документации по интерфейсам¶

Проверяемые интерфейсы¶

5-фазный пайплайн¶

Категории дрифта¶

Стратегии сопоставления¶

Пример использования¶

Интеграция с CI¶

Компоненты композиции¶

ScenarioInvoker¶

ResultMerger¶

Стратегии объединения¶

ConflictResolver¶

Типы конфликтов¶

PriorityCalculator¶

Веса приоритетов¶

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

Конечные точки API¶

POST /api/v1/composition/query¶

POST /api/v1/composition/apply¶

GET /api/v1/composition/conflicts/{session_id}¶

GET /api/v1/composition/session/{session_id}¶

DELETE /api/v1/composition/session/{session_id}¶

GET /api/v1/composition/config¶

GET /api/v1/composition/scenarios¶

Команды CLI¶

Лучшие практики¶

1. Выбор правильного оркестратора¶

2. Настройка стратегии объединения¶

3. Обработка конфликтов¶

4. Оптимизация производительности¶

5. Настройка весов приоритетов¶

Операции жизненного цикла проектов¶

Доступные операции¶

Очистка данных при удалении¶

Разрешения RBAC¶

Связанная документация¶