`pipeline_setup_v3` это YAML-driven test harness для проверки agent pipeline на уровне сценариев, а не unit-тестов.

Как он работает:
- Берёт один YAML-файл или директорию с YAML-кейсами.
- Каждый кейс описывает:
  - `id`
  - `query`
  - `runner`
  - `mode`
  - `input`
  - `expected`
- Если в `input` нет готового `rag_session_id`, harness сам получает его:
  - либо берёт из `input.rag_session_id`
  - либо индексирует `input.repo_path` в RAG и кеширует полученную сессию для одинакового `(repo_path, project_id)`

Какие режимы кейсов есть:
- `router_only`
  Проверяется только роутинг, без retrieval и без LLM.
- `router_rag`
  Проверяется роутинг плюс retrieval, но без полной генерации ответа.
- `full_chain`
  Проверяется полный pipeline: router → retrieval → downstream pipeline/LLM → final answer.

Как устроен execution flow:
1. Loader читает YAML и превращает каждый кейс в `V3Case`.
2. Runner для каждого кейса резолвит `rag_session_id`.
3. `AgentRuntimeAdapter` исполняет кейс в зависимости от `mode`.
4. Возвращаются два объекта:
   - `actual`
   - `details`
5. Validator сравнивает `actual/details` с `expected`.
6. Writer сохраняет:
   - JSON с машинными результатами
   - Markdown с человекочитаемой диагностикой
   - итоговый `summary.md` по всему прогону

Что обычно лежит в `actual`:
- `intent`
- `sub_intent`
- `graph_id`
- `conversation_mode`
- `rag_count`
- `answer_mode`
- `llm_answer`
- `path_scope`
- `doc_scope`
- `entity_candidates`
- `symbol_candidates`
- `layers`
- `filters`

Что лежит в `details`:
- `router_result`
- `retrieval_request`
- `retrieval_result`
- `rag_rows`
- `diagnostics`
- `llm_request`
- `pipeline_steps`
- иногда `validation`, `token_usage`, `runtime_trace`

Что умеют expectations:
- `expected.router`
  Проверяет `intent`, `sub_intent`, `graph_id`, `conversation_mode`
- `expected.retrieval`
  Проверяет:
  - пустой/непустой retrieval
  - минимум строк
  - наличие нужных слоёв
  - path/doc scope
  - symbol/entity candidates
  - фильтры
- `expected.llm`
  Проверяет:
  - есть ли ответ
  - содержит ли ответ обязательные фразы
  - не содержит ли запрещённые фразы
  - `answer_mode`
- `expected.pipeline`
  Проверяет в основном итоговый `answer_mode`

Что важно при формулировке нового test case для ChatGPT:
- кейс должен описывать не “как реализовать код”, а “какой пользовательский сценарий проверяем”
- у кейса должны быть:
  - понятный `query`
  - корректный `mode`
  - вход: `rag_session_id` или `repo_path`
  - минимально достаточные `expected`
- не надо переописывать весь output, лучше проверять только ключевые инварианты

Хороший шаблон задания для ChatGPT:
1. Укажи, для какого suite нужен кейс.
2. Укажи `mode`: `router_only`, `router_rag` или `full_chain`.
3. Дай пользовательский `query`.
4. Опиши, что именно должно проверяться:
   - роутинг
   - retrieval layers/scope
   - answer mode
   - ключевые фразы в ответе
5. Попроси вернуть YAML-фрагмент в формате `pipeline_setup_v3`.

Пример формулировки для ChatGPT:
“Сформируй YAML test case для `pipeline_setup_v3` в режиме `full_chain`. Нужно проверить, что запрос `Объясни по документации как работает /health` маршрутизируется в docs-intent, retrieval использует docs layers, retrieval непустой, а ответ содержит `/health` и не содержит фраз про отсутствие данных.”

Если хочешь, я могу сразу подготовить тебе готовый prompt для ChatGPT, который будет генерировать новые кейсы в нужном формате.