Фикс состояния

2026-03-12 16:55:23 +03:00
parent 417b8b6f72
commit 6ba0a18ac9
1445 changed files with 620025 additions and 885 deletions
--- a/tests/pipeline_setup_v2/README.md
+++ b/tests/pipeline_setup_v2/README.md
@@ -0,0 +1,118 @@
+# pipeline_setup_v2
+
+Новый общий harness для двух семейств прогонов:
+
+- `code_qa_eval` — synthetic/golden проверки
+- `runtime` — router_only / router_rag / full_chain
+
+## Идея
+
+Один runner:
+
+- читает все `*.yaml` из папки с кейсами
+- для кейса принимает либо `repo_path`, либо `rag_session_id`
+- при `repo_path` сам индексирует репозиторий и получает `rag_session_id`
+- запускает выбранный runner/mode
+- проверяет ожидания
+- пишет per-case артефакты и `summary.md`
+
+## Структура
+
+- `run.py` — верхнеуровневый entrypoint
+- `llm_prompts.yaml` — общий каталог LLM-промтов для `full_chain`
+- `cases/` — папки с YAML-наборами кейсов
+- `core/` — общий harness: модели, loader, validator, session provider, artifact writer, orchestration
+- `runtime/` — конкретные исполнители для `runtime` и `code_qa_eval`
+- `test_results/` — артефакты прогонов
+
+## Запуск
+
+```bash
+PYTHONPATH=. python -m tests.pipeline_setup_v2.run \
+  --cases-dir tests/pipeline_setup_v2/cases/suite_01_synthetic \
+  --run-name suite_01_smoke
+```
+
+```bash
+PYTHONPATH=. python -m tests.pipeline_setup_v2.run \
+  --cases-dir tests/pipeline_setup_v2/cases/suite_02_pipeline \
+  --run-name suite_02_smoke
+```
+
+## Индексация RAG
+
+Если вы хотите получить `rag_session_id` заранее и подставлять его в кейсы, можно отдельно запустить индексатор:
+
+```bash
+PYTHONPATH=. python -m tests.pipeline_setup.suite_02_pipeline.cli.index_repo \
+  --repo-path /absolute/path/to/repo \
+  [--project-id my-project]
+```
+
+На выходе индексатор печатает:
+
+```bash
+rag_session_id=<uuid>
+```
+
+После этого `rag_session_id` можно использовать в описании кейса:
+
+```yaml
+cases:
+  - id: explain-existing-session
+    runner: runtime
+    mode: router_rag
+    query: "Как работает OrderService?"
+    input:
+      rag_session_id: "<uuid>"
+```
+
+Если в кейсе вместо `rag_session_id` указан `repo_path`, то `pipeline_setup_v2` сам выполнит индексацию перед прогоном.
+
+## Формат кейсов
+
+Runner читает несколько YAML-файлов из одной папки.
+
+Поддерживаемые поля:
+
+- `defaults.runner`: `runtime` или `code_qa_eval`
+- `defaults.mode`: `router_only`, `router_rag`, `full_chain`
+- `defaults.input.repo_path`
+- `defaults.input.project_id`
+- `defaults.input.rag_session_id`
+
+На уровне кейса:
+
+- `id`
+- `query`
+- `runner`
+- `mode`
+- `input`
+- `expected.router.*`
+- `expected.retrieval.*`
+- `expected.llm.*`
+- `expected.pipeline.answer_mode`
+
+## LLM Промпты
+
+Общий каталог промтов для `full_chain` находится в:
+
+- `tests/pipeline_setup_v2/llm_prompts.yaml`
+
+Выбор шаблона идёт в таком порядке:
+
+- `intent + sub_intent`
+- fallback на `intent`
+- fallback на `default`
+
+## Артефакты
+
+Результаты пишутся в:
+
+- `tests/pipeline_setup_v2/test_results/<run_name>/<timestamp>/`
+
+Там создаются:
+
+- `*.json` по каждому кейсу
+- `*.md` по каждому кейсу
+- `summary.md`
--- a/tests/pipeline_setup_v2/init.py
+++ b/tests/pipeline_setup_v2/init.py
@@ -0,0 +1 @@
+"""Unified pipeline test harness for synthetic eval and runtime integration runs."""
--- a/tests/pipeline_setup_v2/cases/suite_01_synthetic/code_qa_eval.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_01_synthetic/code_qa_eval.yaml
@@ -0,0 +1,80 @@
+defaults:
+  runner: code_qa_eval
+  mode: router_rag
+  input:
+    repo_path: "../../../pipeline_setup/suite_01_synthetic/fixtures/code_qa_repo"
+    project_id: code_qa_repo
+
+cases:
+  - id: open_file_main_positive
+    query: "Открой файл main.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+      retrieval:
+        path_scope_contains: ["main.py"]
+      pipeline:
+        answer_mode: normal
+
+  - id: open_file_api_positive
+    query: "Покажи src/order_app/api/orders.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+      retrieval:
+        path_scope_contains: ["src/order_app/api/orders.py"]
+      pipeline:
+        answer_mode: normal
+
+  - id: explain_order_positive
+    query: "Объясни класс Order"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+      retrieval:
+        symbol_candidates_contain: ["Order"]
+      pipeline:
+        answer_mode: normal
+
+  - id: explain_order_service_positive
+    query: "Как работает OrderService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+      retrieval:
+        symbol_candidates_contain: ["OrderService"]
+      pipeline:
+        answer_mode: normal
+
+  - id: find_tests_positive
+    query: "Где тесты для OrderService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+      retrieval:
+        symbol_candidates_contain: ["OrderService"]
+      pipeline:
+        answer_mode: normal
+
+  - id: find_entrypoints_positive
+    query: "Какие точки входа в приложение?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+      pipeline:
+        answer_mode: normal
+
+  - id: general_qa_positive
+    query: "Что делает этот проект?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: GENERAL_QA
+      pipeline:
+        answer_mode: normal
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
@@ -0,0 +1,96 @@
+defaults:
+  runner: runtime
+  mode: full_chain
+  input:
+    rag_session_id: "7d11da21-faa0-4cea-aede-aeabe069164c"
+
+cases:
+  - id: plba-fullchain-explain-runtime-manager
+    query: "Объясни как работает класс RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-http-control-channel
+    query: "Объясни класс HttpControlChannel"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["HttpControlChannel"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-control-plane-service
+    query: "Объясни класс ControlPlaneService"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["ControlPlaneService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-trace-service
+    query: "Как работает TraceService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["TraceService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-create-runtime
+    query: "Объясни функцию create_runtime"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["create_runtime"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-workflow-engine
+    query: "Объясни класс WorkflowEngine"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["WorkflowEngine"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_subintents.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_subintents.yaml
@@ -0,0 +1,110 @@
+defaults:
+  runner: runtime
+  mode: full_chain
+  input:
+    rag_session_id: "7d11da21-faa0-4cea-aede-aeabe069164c"
+
+cases:
+  - id: plba-fullchain-open-file-runtime
+    query: "Открой файл src/app_runtime/core/runtime.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/core/runtime.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-runtime-manager
+    query: "Объясни как работает класс RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-find-tests-runtime-manager
+    query: "Где тесты для RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-find-entrypoints
+    query: "Найди точки входа в коде"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        layers_include: ["C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-trace-flow-runtime-manager
+    query: "Покажи поток выполнения RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: TRACE_FLOW
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C2_DEPENDENCY_GRAPH", "C3_ENTRYPOINTS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-architecture-control-plane
+    query: "Какие компоненты участвуют в RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: ARCHITECTURE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        layers_include: ["C4_SEMANTIC_ROLES", "C2_DEPENDENCY_GRAPH", "C3_ENTRYPOINTS"]
+      llm:
+        non_empty: true
+
+  - id: plba-fullchain-explain-local-runtime-manager
+    query: "Почему в файле src/app_runtime/core/runtime.py класс RuntimeManager устроен так?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN_LOCAL
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/core/runtime.py"]
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS", "C2_DEPENDENCY_GRAPH"]
+      llm:
+        non_empty: true
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_subintents_v2.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_subintents_v2.yaml
@@ -0,0 +1,305 @@
+defaults:
+  runner: runtime
+  mode: full_chain
+  input:
+    rag_session_id: "7d11da21-faa0-4cea-aede-aeabe069164c"
+
+cases:
+  # OPEN_FILE
+  - id: plba-v2-open-file-runtime
+    query: "Открой файл src/app_runtime/core/runtime.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/core/runtime.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-open-file-public-api
+    query: "Открой файл src/plba/__init__.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/plba/__init__.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        excludes: ["из различных подпакетов", "ответ основан исключительно"]
+
+  # EXPLAIN
+  - id: plba-v2-explain-runtime-manager
+    query: "Объясни как работает класс RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS", "C2_DEPENDENCY_GRAPH"]
+      llm:
+        non_empty: true
+        excludes: ["ряд аргументов", "основные службы"]
+
+  - id: plba-v2-explain-trace-service
+    query: "Объясни как работает класс TraceService"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["TraceService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS", "C2_DEPENDENCY_GRAPH"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-explain-create-runtime
+    query: "Что делает функция create_runtime?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["create_runtime"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-explain-local-http-channel
+    query: "Почему в файле src/app_runtime/control/http_channel.py класс HttpControlChannel устроен так?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN_LOCAL
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/control/http_channel.py"]
+        symbol_candidates_contain: ["HttpControlChannel"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS", "C2_DEPENDENCY_GRAPH"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  # FIND_TESTS
+  - id: plba-v2-find-tests-runtime-manager
+    query: "Где тесты для RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-find-tests-trace-service
+    query: "Где тесты для TraceService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["TraceService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-find-tests-create-runtime
+    query: "Где тесты для create_runtime?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["create_runtime"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-find-tests-workflow-runtime-factory-negative
+    query: "Где тесты для WorkflowRuntimeFactory?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        direct_symbol_test_hits_max: 0
+        symbol_candidates_contain: ["WorkflowRuntimeFactory"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+
+  # FIND_ENTRYPOINTS
+  - id: plba-v2-find-entrypoints-control-plane
+    query: "Найди точки входа HTTP control plane"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        layers_include: ["C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-find-entrypoints-health-endpoint
+    query: "Где health endpoint?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        layers_include: ["C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        contains_all: ["GET /health"]
+        excludes: ["нет явных неподтвержденных кандидатов", "кандидаты на health-endpoint"]
+
+  # TRACE_FLOW
+  - id: plba-v2-trace-flow-runtime-start
+    query: "Покажи поток выполнения при запуске RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: TRACE_FLOW
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C2_DEPENDENCY_GRAPH", "C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-trace-flow-health-endpoint
+    query: "Покажи как проходит запрос /health в HttpControlAppFactory"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: TRACE_FLOW
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["HttpControlAppFactory"]
+        layers_include: ["C2_DEPENDENCY_GRAPH", "C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  # ARCHITECTURE
+  - id: plba-v2-architecture-runtime-manager
+    query: "Какие компоненты участвуют в RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: ARCHITECTURE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C4_SEMANTIC_ROLES", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  - id: plba-v2-architecture-control-plane
+    query: "Какие компоненты участвуют в ControlPlaneService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: ARCHITECTURE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["ControlPlaneService"]
+        layers_include: ["C4_SEMANTIC_ROLES", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        answer_mode: answered
+
+  # NEGATIVE / NOT FOUND
+  - id: plba-v2-explain-nonexistent-symbol
+    query: "Объясни класс RuntimeFactoryManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: false
+        symbol_candidates_contain: ["RuntimeFactoryManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        contains_all: ["не найдена"]
+        excludes: ["исходя из названия", "вероятно этот класс", "возможное предназначение"]
+      pipeline:
+        answer_mode: degraded
+
+  - id: plba-v2-open-file-nonexistent
+    query: "Открой файл src/app_runtime/core/missing_runtime.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: false
+        path_scope_contains: ["src/app_runtime/core/missing_runtime.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+      llm:
+        non_empty: true
+        contains_all: ["Файл src/app_runtime/core/missing_runtime.py не найден."]
+      pipeline:
+        answer_mode: not_found
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_smoke.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_smoke.yaml
@@ -0,0 +1,17 @@
+defaults:
+  runner: runtime
+  mode: full_chain
+  input:
+    repo_path: "../../../pipeline_setup/suite_01_synthetic/fixtures/code_qa_repo"
+    project_id: code_qa_repo_full_chain
+
+cases:
+  - id: full_chain_explain_order_service
+    query: "Как работает OrderService?"
+    expected:
+      router:
+        intent: CODE_QA
+      retrieval:
+        non_empty: true
+      llm:
+        non_empty: true
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_only_plba_code_retrieval.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_only_plba_code_retrieval.yaml
@@ -0,0 +1,123 @@
+defaults:
+  runner: runtime
+  mode: router_only
+  input:
+    repo_path: "/Users/alex/Dev_projects_v2/apps/plba"
+    rag_session_id: "7d11da21-faa0-4cea-aede-aeabe069164c"
+    project_id: plba
+
+cases:
+  - id: plba-open-runtime-manager-file
+    query: "Открой файл src/app_runtime/core/runtime.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+
+  - id: plba-open-http-control-channel-file
+    query: "Покажи файл src/app_runtime/control/http_channel.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+
+  - id: plba-explain-runtime-manager
+    query: "Объясни как работает класс RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["RuntimeManager"]
+
+  - id: plba-explain-http-control-channel
+    query: "Объясни класс HttpControlChannel"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["HttpControlChannel"]
+
+  - id: plba-explain-trace-service
+    query: "Как работает TraceService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["TraceService"]
+
+  - id: plba-find-tests-runtime-manager
+    query: "Где тесты для RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["RuntimeManager"]
+
+  - id: plba-find-tests-http-control-channel
+    query: "Найди тесты для HttpControlChannel"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["HttpControlChannel"]
+
+  - id: plba-find-entrypoints-create-runtime
+    query: "Найди точки входа в коде"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+
+  - id: plba-find-entrypoints-bootstrap
+    query: "Объясни функцию create_runtime"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["create_runtime"]
+
+  - id: plba-general-qa-runtime
+    query: "Объясни модуль runtime"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["runtime"]
+
+  - id: plba-general-qa-control-plane
+    query: "Объясни код control plane"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        symbol_candidates_contain: ["control", "plane"]
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_only_smoke.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_only_smoke.yaml
@@ -0,0 +1,16 @@
+defaults:
+  runner: runtime
+  mode: router_only
+
+cases:
+  - id: router_only_open_fixture_main
+    query: "Открой файл main.py"
+    expected:
+      router:
+        intent: CODE_QA
+
+  - id: router_only_docs_question
+    query: "Что сказано в README?"
+    expected:
+      router:
+        intent: DOCS_QA
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_rag_plba_code_retrieval.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_rag_plba_code_retrieval.yaml
@@ -0,0 +1,148 @@
+defaults:
+  runner: runtime
+  mode: router_rag
+  input:
+    rag_session_id: "7d11da21-faa0-4cea-aede-aeabe069164c"
+
+cases:
+  - id: plba-rag-open-runtime-manager-file
+    query: "Открой файл src/app_runtime/core/runtime.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/core/runtime.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-open-http-control-channel-file
+    query: "Покажи файл src/app_runtime/control/http_channel.py"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: OPEN_FILE
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        path_scope_contains: ["src/app_runtime/control/http_channel.py"]
+        layers_include: ["C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-runtime-manager
+    query: "Объясни как работает класс RuntimeManager"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-http-control-channel
+    query: "Объясни класс HttpControlChannel"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["HttpControlChannel"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-trace-service
+    query: "Как работает TraceService?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["TraceService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-find-tests-runtime-manager
+    query: "Где тесты для RuntimeManager?"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["RuntimeManager"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-find-tests-http-control-channel
+    query: "Найди тесты для HttpControlChannel"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_TESTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["HttpControlChannel"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C2_DEPENDENCY_GRAPH", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-find-entrypoints
+    query: "Найди точки входа в коде"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: FIND_ENTRYPOINTS
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        layers_include: ["C3_ENTRYPOINTS", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-create-runtime
+    query: "Объясни функцию create_runtime"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["create_runtime"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-control-plane-service
+    query: "Объясни класс ControlPlaneService"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["ControlPlaneService"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
+
+  - id: plba-rag-explain-workflow-engine
+    query: "Объясни класс WorkflowEngine"
+    expected:
+      router:
+        intent: CODE_QA
+        sub_intent: EXPLAIN
+        graph_id: CodeQAGraph
+        conversation_mode: START
+      retrieval:
+        non_empty: true
+        symbol_candidates_contain: ["WorkflowEngine"]
+        layers_include: ["C1_SYMBOL_CATALOG", "C0_SOURCE_CHUNKS"]
--- a/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_rag_smoke.yaml
+++ b/tests/pipeline_setup_v2/cases/suite_02_pipeline/router_rag_smoke.yaml
@@ -0,0 +1,23 @@
+defaults:
+  runner: runtime
+  mode: router_rag
+  input:
+    repo_path: "../../../pipeline_setup/suite_01_synthetic/fixtures/code_qa_repo"
+    project_id: code_qa_repo_runtime
+
+cases:
+  - id: router_rag_open_fixture_main
+    query: "Открой файл main.py"
+    expected:
+      router:
+        intent: CODE_QA
+      retrieval:
+        non_empty: true
+
+  - id: router_rag_explain_order
+    query: "Объясни класс Order"
+    expected:
+      router:
+        intent: CODE_QA
+      retrieval:
+        non_empty: true
--- a/tests/pipeline_setup_v2/core/init.py
+++ b/tests/pipeline_setup_v2/core/init.py
@@ -0,0 +1 @@
+"""Core contracts and orchestration for pipeline_setup_v2."""
--- a/tests/pipeline_setup_v2/core/artifacts.py
+++ b/tests/pipeline_setup_v2/core/artifacts.py
@@ -0,0 +1,144 @@
+from __future__ import annotations
+
+import json
+from datetime import datetime
+from pathlib import Path
+
+from tests.pipeline_setup_v2.core.models import V2CaseResult
+
+
+class ArtifactWriter:
+    def __init__(self, root: Path, run_name: str, started_at: datetime) -> None:
+        stamp = started_at.strftime("%Y%m%d_%H%M%S")
+        self.run_dir = root / run_name / stamp
+        self.run_dir.mkdir(parents=True, exist_ok=True)
+
+    def write_case(self, result: V2CaseResult) -> None:
+        stem = f"{result.case.source_file.stem}_{result.case.case_id}"
+        (self.run_dir / f"{stem}.json").write_text(
+            json.dumps(
+                {
+                    "case_id": result.case.case_id,
+                    "source_file": result.case.source_file.as_posix(),
+                    "runner": result.case.runner,
+                    "mode": result.case.mode,
+                    "actual": result.actual,
+                    "passed": result.passed,
+                    "mismatches": result.mismatches,
+                    "details": result.details,
+                },
+                ensure_ascii=False,
+                indent=2,
+            ),
+            encoding="utf-8",
+        )
+        lines = [
+            f"# {result.case.case_id}",
+            "",
+            f"- source_file: {result.case.source_file.as_posix()}",
+            f"- runner: {result.case.runner}",
+            f"- mode: {result.case.mode}",
+            f"- passed: {result.passed}",
+            "",
+            "## Query",
+            result.case.query,
+            "",
+            "## Actual",
+            json.dumps(result.actual, ensure_ascii=False, indent=2),
+            "",
+            "## Mismatches",
+            *([f"- {item}" for item in result.mismatches] or ["- none"]),
+        ]
+        (self.run_dir / f"{stem}.md").write_text("\n".join(lines), encoding="utf-8")
+
+    def write_summary(self, results: list[V2CaseResult]) -> Path:
+        path = self.run_dir / "summary.md"
+        path.write_text(SummaryComposer().compose(results), encoding="utf-8")
+        return path
+
+
+class SummaryComposer:
+    def compose(self, results: list[V2CaseResult]) -> str:
+        passed = sum(1 for item in results if item.passed)
+        lines = [
+            "# pipeline_setup_v2 summary",
+            "",
+            f"Passed: {passed}/{len(results)}",
+            "",
+            "| File | Case | Query | Expected sub-intent | Intent | Actual sub-intent | RAG layers | Pass |",
+            "|------|------|-------|---------------------|--------|-------------------|------------|------|",
+        ]
+        lines.extend(self._result_rows(results))
+        lines.extend(self._failure_section(results))
+        lines.extend(self._llm_section(results))
+        return "\n".join(lines)
+
+    def _result_rows(self, results: list[V2CaseResult]) -> list[str]:
+        rows: list[str] = []
+        for item in results:
+            actual = item.actual
+            rows.append(
+                f"| {item.case.source_file.name} | {item.case.case_id} | {self._table_text(item.case.query)} | "
+                f"{item.case.expectations.router.sub_intent or '—'} | {actual.get('intent') or '—'} | "
+                f"{actual.get('sub_intent') or '—'} | {self._rag_layers_text(item)} | {'✓' if item.passed else '✗'} |"
+            )
+        return rows
+
+    def _failure_section(self, results: list[V2CaseResult]) -> list[str]:
+        failures = [item for item in results if not item.passed]
+        if not failures:
+            return []
+        lines = ["", "## Failures"]
+        for item in failures:
+            lines.append(f"- **{item.case.case_id}**: {'; '.join(item.mismatches)}")
+        return lines
+
+    def _llm_section(self, results: list[V2CaseResult]) -> list[str]:
+        llm_results = [item for item in results if str(item.actual.get("llm_answer") or "").strip()]
+        if not llm_results:
+            return []
+        lines = ["", "## LLM Answers"]
+        for item in llm_results:
+            lines.append(f"- **{item.case.case_id}**")
+            lines.append(f"  Query: {self._table_text(item.case.query, limit=400)}")
+            lines.extend(self._quote_block(self._snippet(str(item.actual.get("llm_answer") or ""))))
+        return lines
+
+    def _snippet(self, text: str, limit: int = 880) -> str:
+        compact = " ".join(text.split())
+        if len(compact) <= limit:
+            return compact
+        return compact[: limit - 1].rstrip() + "…"
+
+    def _table_text(self, text: str, limit: int = 140) -> str:
+        compact = " ".join(text.split()).replace("|", "\\|")
+        if len(compact) <= limit:
+            return compact
+        return compact[: limit - 1].rstrip() + "…"
+
+    def _quote_block(self, text: str) -> list[str]:
+        quoted = text.strip()
+        if not quoted:
+            return ["  > —"]
+        return [f"  > {self._escape_markdown(line)}" for line in quoted.splitlines()]
+
+    def _escape_markdown(self, text: str) -> str:
+        escaped = text
+        for char in ("\\", "`", "*", "_", "{", "}", "[", "]", "(", ")", "#", "+", "-", "!", "|"):
+            escaped = escaped.replace(char, f"\\{char}")
+        return escaped
+
+    def _rag_layers_text(self, item: V2CaseResult) -> str:
+        rows = list(item.details.get("rag_rows") or [])
+        if not rows:
+            return "—"
+        counts: dict[str, int] = {}
+        for row in rows:
+            layer = str(row.get("layer") or "").strip()
+            if not layer:
+                continue
+            counts[layer] = counts.get(layer, 0) + 1
+        if not counts:
+            return "—"
+        parts = [f"{layer}:{counts[layer]}" for layer in sorted(counts)]
+        return self._table_text(", ".join(parts), limit=120)
--- a/tests/pipeline_setup_v2/core/case_loader.py
+++ b/tests/pipeline_setup_v2/core/case_loader.py
@@ -0,0 +1,106 @@
+from __future__ import annotations
+
+from pathlib import Path
+
+import yaml
+
+from tests.pipeline_setup_v2.core.models import (
+    CaseExpectations,
+    CaseInput,
+    LlmExpectation,
+    PipelineExpectation,
+    RetrievalExpectation,
+    RouterExpectation,
+    V2Case,
+)
+
+
+class CaseDirectoryLoader:
+    def load(self, cases_dir: Path) -> list[V2Case]:
+        if cases_dir.is_file():
+            return self._load_file(cases_dir)
+        files = sorted(path for path in cases_dir.rglob("*.yaml") if path.is_file())
+        if not files:
+            raise ValueError(f"No YAML case files found in: {cases_dir}")
+        cases: list[V2Case] = []
+        for path in files:
+            cases.extend(self._load_file(path))
+        return cases
+
+    def _load_file(self, path: Path) -> list[V2Case]:
+        payload = yaml.safe_load(path.read_text(encoding="utf-8")) or {}
+        if not isinstance(payload, dict):
+            raise ValueError(f"Invalid case file {path}: expected mapping")
+        defaults = payload.get("defaults") or {}
+        items = payload.get("cases") or []
+        if not isinstance(items, list):
+            raise ValueError(f"Invalid case file {path}: `cases` must be a list")
+        return [self._to_case(path, raw, defaults) for raw in items]
+
+    def _to_case(self, path: Path, raw: object, defaults: dict) -> V2Case:
+        if not isinstance(raw, dict):
+            raise ValueError(f"Invalid case in {path}: expected object")
+        merged_input = {**dict(defaults.get("input") or {}), **dict(raw.get("input") or {})}
+        runner = str(raw.get("runner") or defaults.get("runner") or "runtime").strip()
+        mode = str(raw.get("mode") or defaults.get("mode") or "").strip()
+        case_id = str(raw.get("id") or "").strip()
+        query = str(raw.get("query") or "").strip()
+        if not case_id or not query or not runner or not mode:
+            raise ValueError(f"Invalid case in {path}: `id`, `query`, `runner`, `mode` are required")
+        expected = dict(raw.get("expected") or {})
+        return V2Case(
+            case_id=case_id,
+            runner=runner,  # type: ignore[arg-type]
+            mode=mode,  # type: ignore[arg-type]
+            query=query,
+            source_file=path,
+            input=self._to_input(path.parent, merged_input),
+            expectations=self._to_expectations(expected),
+            notes=str(raw.get("notes") or ""),
+            tags=tuple(str(item).strip() for item in raw.get("tags", []) if str(item).strip()),
+        )
+
+    def _to_input(self, base_dir: Path, raw: dict) -> CaseInput:
+        repo_path_raw = str(raw.get("repo_path") or "").strip()
+        repo_path = None
+        if repo_path_raw:
+            repo_path = Path(repo_path_raw).expanduser()
+            if not repo_path.is_absolute():
+                repo_path = (base_dir / repo_path).resolve()
+        return CaseInput(
+            repo_path=repo_path,
+            project_id=str(raw.get("project_id") or "").strip() or None,
+            rag_session_id=str(raw.get("rag_session_id") or "").strip() or None,
+        )
+
+    def _to_expectations(self, raw: dict) -> CaseExpectations:
+        router = dict(raw.get("router") or {})
+        retrieval = dict(raw.get("retrieval") or {})
+        llm = dict(raw.get("llm") or {})
+        pipeline = dict(raw.get("pipeline") or {})
+        return CaseExpectations(
+            router=RouterExpectation(
+                intent=str(router.get("intent") or "").strip() or None,
+                sub_intent=str(router.get("sub_intent") or "").strip() or None,
+                graph_id=str(router.get("graph_id") or "").strip() or None,
+                conversation_mode=str(router.get("conversation_mode") or "").strip() or None,
+            ),
+            retrieval=RetrievalExpectation(
+                non_empty=retrieval.get("non_empty"),
+                min_rows=int(retrieval["min_rows"]) if retrieval.get("min_rows") is not None else None,
+                direct_symbol_test_hits_max=(
+                    int(retrieval["direct_symbol_test_hits_max"])
+                    if retrieval.get("direct_symbol_test_hits_max") is not None
+                    else None
+                ),
+                path_scope_contains=tuple(str(item) for item in retrieval.get("path_scope_contains") or []),
+                symbol_candidates_contain=tuple(str(item) for item in retrieval.get("symbol_candidates_contain") or []),
+                layers_include=tuple(str(item) for item in retrieval.get("layers_include") or []),
+            ),
+            llm=LlmExpectation(
+                non_empty=llm.get("non_empty"),
+                contains_all=tuple(str(item) for item in llm.get("contains_all") or []),
+                excludes=tuple(str(item) for item in llm.get("excludes") or []),
+            ),
+            pipeline=PipelineExpectation(answer_mode=str(pipeline.get("answer_mode") or "").strip() or None),
+        )
--- a/tests/pipeline_setup_v2/core/models.py
+++ b/tests/pipeline_setup_v2/core/models.py
@@ -0,0 +1,82 @@
+from __future__ import annotations
+
+from dataclasses import dataclass, field
+from pathlib import Path
+from typing import Literal
+
+
+RunnerKind = Literal["runtime", "code_qa_eval"]
+ModeKind = Literal["router_only", "router_rag", "full_chain"]
+
+
+@dataclass(slots=True, frozen=True)
+class CaseInput:
+    repo_path: Path | None = None
+    project_id: str | None = None
+    rag_session_id: str | None = None
+
+
+@dataclass(slots=True, frozen=True)
+class RouterExpectation:
+    intent: str | None = None
+    sub_intent: str | None = None
+    graph_id: str | None = None
+    conversation_mode: str | None = None
+
+
+@dataclass(slots=True, frozen=True)
+class RetrievalExpectation:
+    non_empty: bool | None = None
+    min_rows: int | None = None
+    direct_symbol_test_hits_max: int | None = None
+    path_scope_contains: tuple[str, ...] = ()
+    symbol_candidates_contain: tuple[str, ...] = ()
+    layers_include: tuple[str, ...] = ()
+
+
+@dataclass(slots=True, frozen=True)
+class LlmExpectation:
+    non_empty: bool | None = None
+    contains_all: tuple[str, ...] = ()
+    excludes: tuple[str, ...] = ()
+
+
+@dataclass(slots=True, frozen=True)
+class PipelineExpectation:
+    answer_mode: str | None = None
+
+
+@dataclass(slots=True, frozen=True)
+class CaseExpectations:
+    router: RouterExpectation = RouterExpectation()
+    retrieval: RetrievalExpectation = RetrievalExpectation()
+    llm: LlmExpectation = LlmExpectation()
+    pipeline: PipelineExpectation = PipelineExpectation()
+
+
+@dataclass(slots=True, frozen=True)
+class V2Case:
+    case_id: str
+    runner: RunnerKind
+    mode: ModeKind
+    query: str
+    source_file: Path
+    input: CaseInput = CaseInput()
+    expectations: CaseExpectations = CaseExpectations()
+    notes: str = ""
+    tags: tuple[str, ...] = ()
+
+
+@dataclass(slots=True, frozen=True)
+class ExecutionPayload:
+    actual: dict
+    details: dict
+
+
+@dataclass(slots=True)
+class V2CaseResult:
+    case: V2Case
+    actual: dict
+    details: dict
+    passed: bool
+    mismatches: list[str] = field(default_factory=list)
--- a/tests/pipeline_setup_v2/core/runner.py
+++ b/tests/pipeline_setup_v2/core/runner.py
@@ -0,0 +1,62 @@
+from __future__ import annotations
+
+from datetime import datetime
+from pathlib import Path
+
+from tests.pipeline_setup_v2.core.artifacts import ArtifactWriter
+from tests.pipeline_setup_v2.core.case_loader import CaseDirectoryLoader
+from tests.pipeline_setup_v2.core.models import V2CaseResult
+from tests.pipeline_setup_v2.core.session_provider import RagSessionProvider
+from tests.pipeline_setup_v2.core.validators import CaseValidator
+
+
+class V2Runner:
+    def __init__(self, cases_dir: Path, results_dir: Path, run_name: str) -> None:
+        self._cases_dir = cases_dir
+        self._validator = CaseValidator()
+        self._sessions = RagSessionProvider()
+        self._runtime = None
+        self._code_qa = None
+        self._writer = ArtifactWriter(results_dir, run_name=run_name, started_at=datetime.now())
+
+    @property
+    def run_dir(self) -> Path:
+        return self._writer.run_dir
+
+    def run(self) -> tuple[list[V2CaseResult], Path]:
+        results: list[V2CaseResult] = []
+        for case in CaseDirectoryLoader().load(self._cases_dir):
+            rag_session_id = self._sessions.resolve(case.input)
+            payload = self._execute(case, rag_session_id)
+            mismatches = self._validator.validate(case, payload.actual, payload.details)
+            result = V2CaseResult(
+                case=case,
+                actual=payload.actual,
+                details=payload.details,
+                passed=not mismatches,
+                mismatches=mismatches,
+            )
+            self._writer.write_case(result)
+            results.append(result)
+        return results, self._writer.write_summary(results)
+
+    def _execute(self, case, rag_session_id):
+        if case.runner == "runtime":
+            return self._runtime_adapter().execute(case, rag_session_id)
+        if case.runner == "code_qa_eval":
+            return self._code_qa_adapter().execute(case, rag_session_id)
+        raise ValueError(f"Unsupported runner: {case.runner}")
+
+    def _runtime_adapter(self):
+        if self._runtime is None:
+            from tests.pipeline_setup_v2.runtime.runtime_adapter import RuntimeAdapter
+
+            self._runtime = RuntimeAdapter()
+        return self._runtime
+
+    def _code_qa_adapter(self):
+        if self._code_qa is None:
+            from tests.pipeline_setup_v2.runtime.code_qa_eval_adapter import CodeQaEvalAdapter
+
+            self._code_qa = CodeQaEvalAdapter()
+        return self._code_qa
--- a/tests/pipeline_setup_v2/core/session_provider.py
+++ b/tests/pipeline_setup_v2/core/session_provider.py
@@ -0,0 +1,32 @@
+from __future__ import annotations
+
+from pathlib import Path
+
+from tests.pipeline_setup_v2.core.models import CaseInput
+
+
+class RagSessionProvider:
+    def __init__(self) -> None:
+        self._repository = None
+        self._cache: dict[tuple[Path, str | None], str] = {}
+
+    def resolve(self, case_input: CaseInput) -> str | None:
+        if case_input.rag_session_id:
+            return case_input.rag_session_id
+        if not case_input.repo_path:
+            return None
+        key = (case_input.repo_path, case_input.project_id)
+        if key not in self._cache:
+            self._cache[key] = self._build_indexer().index_repo(
+                case_input.repo_path,
+                project_id=case_input.project_id,
+            )
+        return self._cache[key]
+
+    def _build_indexer(self):
+        from app.modules.rag.persistence.repository import RagRepository
+        from tests.pipeline_setup.utils.rag_indexer import RagSessionIndexer
+
+        if self._repository is None:
+            self._repository = RagRepository()
+        return RagSessionIndexer(self._repository)
--- a/tests/pipeline_setup_v2/core/test_validators.py
+++ b/tests/pipeline_setup_v2/core/test_validators.py
@@ -0,0 +1,110 @@
+from __future__ import annotations
+
+from pathlib import Path
+
+from tests.pipeline_setup_v2.core.models import CaseExpectations, LlmExpectation, RetrievalExpectation, RouterExpectation, V2Case
+from tests.pipeline_setup_v2.core.validators import CaseValidator
+
+
+def test_direct_symbol_test_hits_allows_related_context_when_symbol_not_in_rows() -> None:
+    case = V2Case(
+        case_id="negative-find-tests",
+        runner="runtime",
+        mode="full_chain",
+        query="Где тесты для WorkflowRuntimeFactory?",
+        source_file=Path("cases.yaml"),
+        expectations=CaseExpectations(
+            router=RouterExpectation(intent="CODE_QA", sub_intent="FIND_TESTS"),
+            retrieval=RetrievalExpectation(
+                direct_symbol_test_hits_max=0,
+                symbol_candidates_contain=("WorkflowRuntimeFactory",),
+            ),
+        ),
+    )
+    actual = {
+        "intent": "CODE_QA",
+        "sub_intent": "FIND_TESTS",
+        "rag_count": 2,
+        "symbol_candidates": ("WorkflowRuntimeFactory",),
+        "layers": ("C2_DEPENDENCY_GRAPH",),
+    }
+    details = {
+        "rag_rows": [
+            {
+                "path": "tests/test_business_control_actions.py",
+                "title": "test_worker_wakes_up_with_configured_interval:dataflow_slice",
+                "content": "ScenarioWorker.name",
+                "metadata": {"is_test": True, "src_qname": "test_worker_wakes_up_with_configured_interval"},
+            }
+        ]
+    }
+
+    mismatches = CaseValidator().validate(case, actual, details)
+
+    assert mismatches == []
+
+
+def test_direct_symbol_test_hits_flags_direct_matches_in_test_rows() -> None:
+    case = V2Case(
+        case_id="negative-find-tests",
+        runner="runtime",
+        mode="full_chain",
+        query="Где тесты для WorkflowRuntimeFactory?",
+        source_file=Path("cases.yaml"),
+        expectations=CaseExpectations(
+            router=RouterExpectation(intent="CODE_QA", sub_intent="FIND_TESTS"),
+            retrieval=RetrievalExpectation(
+                direct_symbol_test_hits_max=0,
+                symbol_candidates_contain=("WorkflowRuntimeFactory",),
+            ),
+        ),
+    )
+    actual = {
+        "intent": "CODE_QA",
+        "sub_intent": "FIND_TESTS",
+        "rag_count": 1,
+        "symbol_candidates": ("WorkflowRuntimeFactory",),
+        "layers": ("C0_SOURCE_CHUNKS",),
+    }
+    details = {
+        "rag_rows": [
+            {
+                "path": "tests/test_workflow_runtime_factory.py",
+                "title": "test_workflow_runtime_factory_builds_runtime",
+                "content": "WorkflowRuntimeFactory builds runtime",
+                "metadata": {"is_test": True, "src_qname": "test_workflow_runtime_factory_builds_runtime"},
+            }
+        ]
+    }
+
+    mismatches = CaseValidator().validate(case, actual, details)
+
+    assert mismatches == ["retrieval: expected direct symbol-linked test hits <= 0, got 1"]
+
+
+def test_llm_contains_and_excludes_checks() -> None:
+    case = V2Case(
+        case_id="llm-quality",
+        runner="runtime",
+        mode="full_chain",
+        query="Где health endpoint?",
+        source_file=Path("cases.yaml"),
+        expectations=CaseExpectations(
+            router=RouterExpectation(intent="CODE_QA", sub_intent="FIND_ENTRYPOINTS"),
+            llm=LlmExpectation(
+                non_empty=True,
+                contains_all=("GET /health",),
+                excludes=("нет явных неподтвержденных кандидатов",),
+            ),
+        ),
+    )
+    actual = {
+        "intent": "CODE_QA",
+        "sub_intent": "FIND_ENTRYPOINTS",
+        "rag_count": 3,
+        "llm_answer": "GET /health объявлен в HttpControlAppFactory.",
+    }
+
+    mismatches = CaseValidator().validate(case, actual, {})
+
+    assert mismatches == []
--- a/tests/pipeline_setup_v2/core/validators.py
+++ b/tests/pipeline_setup_v2/core/validators.py
@@ -0,0 +1,101 @@
+from __future__ import annotations
+
+from tests.pipeline_setup_v2.core.models import V2Case
+
+
+class CaseValidator:
+    def validate(self, case: V2Case, actual: dict, details: dict | None = None) -> list[str]:
+        mismatches: list[str] = []
+        self._check(case.expectations.router.intent, actual.get("intent"), "intent", mismatches)
+        self._check(case.expectations.router.sub_intent, actual.get("sub_intent"), "sub_intent", mismatches)
+        self._check(case.expectations.router.graph_id, actual.get("graph_id"), "graph_id", mismatches)
+        self._check(case.expectations.router.conversation_mode, actual.get("conversation_mode"), "conversation_mode", mismatches)
+        self._check(case.expectations.pipeline.answer_mode, actual.get("answer_mode"), "answer_mode", mismatches)
+        self._check_retrieval(case, actual, details or {}, mismatches)
+        self._check_llm(case, actual, mismatches)
+        return mismatches
+
+    def _check(self, expected, actual, label: str, mismatches: list[str]) -> None:
+        if expected is not None and expected != actual:
+            mismatches.append(f"{label}: expected {expected}, got {actual}")
+
+    def _check_retrieval(self, case: V2Case, actual: dict, details: dict, mismatches: list[str]) -> None:
+        rag_count = int(actual.get("rag_count") or 0)
+        retrieval = case.expectations.retrieval
+        if retrieval.non_empty is True and rag_count == 0:
+            mismatches.append("retrieval: expected non-empty rag, got 0 rows")
+        if retrieval.non_empty is False and rag_count != 0:
+            mismatches.append(f"retrieval: expected empty rag, got {rag_count} rows")
+        if retrieval.min_rows is not None and rag_count < retrieval.min_rows:
+            mismatches.append(f"retrieval: expected at least {retrieval.min_rows} rows, got {rag_count}")
+        if retrieval.direct_symbol_test_hits_max is not None:
+            direct_hits = self._direct_symbol_test_hits(case, details)
+            if direct_hits > retrieval.direct_symbol_test_hits_max:
+                mismatches.append(
+                    f"retrieval: expected direct symbol-linked test hits <= {retrieval.direct_symbol_test_hits_max}, got {direct_hits}"
+                )
+        for path in retrieval.path_scope_contains:
+            if not any(path in item for item in actual.get("path_scope") or ()):
+                mismatches.append(f"path_scope should contain '{path}', got {list(actual.get('path_scope') or ())}")
+        for symbol in retrieval.symbol_candidates_contain:
+            if symbol not in (actual.get("symbol_candidates") or ()):
+                mismatches.append(f"symbol_candidates should contain '{symbol}', got {list(actual.get('symbol_candidates') or ())}")
+        for layer in retrieval.layers_include:
+            if layer not in (actual.get("layers") or ()):
+                mismatches.append(f"layers should include '{layer}', got {list(actual.get('layers') or ())}")
+
+    def _check_llm(self, case: V2Case, actual: dict, mismatches: list[str]) -> None:
+        llm = case.expectations.llm
+        expected = llm.non_empty
+        answer = str(actual.get("llm_answer") or "").strip()
+        if expected is None:
+            has_answer = bool(answer)
+        else:
+            has_answer = bool(answer)
+        if expected and not has_answer:
+            mismatches.append("llm: expected non-empty answer")
+        if not expected and has_answer:
+            mismatches.append("llm: expected empty answer")
+        lowered = answer.lower()
+        for value in llm.contains_all:
+            if value.lower() not in lowered:
+                mismatches.append(f"llm: expected answer to contain '{value}'")
+        for value in llm.excludes:
+            if value.lower() in lowered:
+                mismatches.append(f"llm: expected answer to exclude '{value}'")
+
+    def _direct_symbol_test_hits(self, case: V2Case, details: dict) -> int:
+        symbols = tuple(
+            symbol.strip().lower()
+            for symbol in case.expectations.retrieval.symbol_candidates_contain
+            if symbol.strip()
+        )
+        if not symbols:
+            return 0
+        hits = 0
+        for row in details.get("rag_rows") or []:
+            if not self._is_test_row(row):
+                continue
+            haystacks = self._row_search_texts(row)
+            if any(symbol in text for symbol in symbols for text in haystacks):
+                hits += 1
+        return hits
+
+    def _is_test_row(self, row: dict) -> bool:
+        path = str(row.get("path") or "").lower()
+        metadata = dict(row.get("metadata") or {})
+        if bool(metadata.get("is_test")):
+            return True
+        return "/tests/" in f"/{path}" or path.startswith("tests/") or "/test_" in path or path.endswith("_test.py")
+
+    def _row_search_texts(self, row: dict) -> tuple[str, ...]:
+        metadata = dict(row.get("metadata") or {})
+        values = [
+            str(row.get("title") or ""),
+            str(row.get("content") or ""),
+            str(metadata.get("qname") or ""),
+            str(metadata.get("symbol_name") or ""),
+            str(metadata.get("src_qname") or ""),
+            str(metadata.get("dst_ref") or ""),
+        ]
+        return tuple(value.lower() for value in values if value)
--- a/tests/pipeline_setup_v2/llm_prompts.yaml
+++ b/tests/pipeline_setup_v2/llm_prompts.yaml
@@ -0,0 +1,147 @@
+default:
+  template_id: "intent_default_v2"
+  system_prompt: "Ты технический ассистент по коду и документации, который отвечает только по извлечённому контексту."
+  task_prompt: |
+    Отвечай кратко, точно и без выдумок.
+    Используй только факты, которые подтверждаются контекстом RAG.
+    Если данных недостаточно, прямо скажи, чего именно не хватает.
+    Не компенсируй нехватку контекста общими рассуждениями.
+
+intents:
+  CODE_QA:
+    template_id: "intent_code_qa_v5"
+    system_prompt: "Ты senior Python-инженер, который объясняет код только по извлечённым фрагментам из RAG."
+    task_prompt: |
+      Отвечай только по коду и структуре проекта, которые есть в контексте.
+      Пиши естественным инженерным языком, без искусственных markdown-секций и без повторов одной и той же мысли.
+      Если ответ можно дать в 1-3 фразах, не раздувай его.
+      Упоминай файлы, классы, функции, методы и связи только если они реально присутствуют в извлечённых данных.
+      Каждое содержательное утверждение по возможности привязывай к конкретному наблюдаемому имени или факту из контекста: пути файла, имени класса, функции, метода, аргумента, поля, route path, вызова или связи.
+      Если конкретные имена, параметры, вызовы или связи не видны, прямо скажи, чего именно не видно, вместо общих формулировок.
+      Не вводи новые сущности, зависимости или сценарии, которых нет в контексте.
+      Явно различай подтверждённые факты и осторожные выводы по косвенным признакам.
+      Если данных мало, честно скажи об этом вместо общего обзора.
+      Не используй жирные заголовки блоков, если пользователь их не просил.
+      Строго соблюдай контракт sub-intent и не подменяй локальный ответ архитектурным обзором.
+      Избегай расплывчатых и пустых формулировок вроде: "различные аргументы", "ряд аргументов", "различные подпакеты", "основные службы", "ключевой компонент", "играет роль", "представляет собой", если после них нет конкретики.
+      Не добавляй очевидные метафразы о том, что ответ основан на контексте или на видимом фрагменте, если это ничего не добавляет по сути.
+      Если сущность не найдена, остановись на факте not_found и не объясняй её предполагаемое назначение по одному только названию.
+      Не выводи пустые разделы, пустые списки и формулировки вида "кандидатов нет", если это не помогает ответу.
+    sub_intents:
+      OPEN_FILE:
+        template_id: "intent_code_qa_open_file_ru_v4"
+        system_prompt: "Ты технический ассистент, который помогает открыть конкретный файл и показать, что в нём реально видно."
+        task_prompt: |
+          Сосредоточься на указанном файле и отвечай коротко.
+          Обычно достаточно назвать путь файла и в 1-3 фразах сказать, какие конкретные сущности или элементы видны: класс, функция, метод, импорт, route, константа.
+          Не используй общие описания файла без конкретных имён.
+          Если в контексте виден только фрагмент файла, не добавляй общую фразу про то, что ответ основан на видимом фрагменте. Вместо этого просто ограничься тем, что реально видно.
+          Не превращай ответ в архитектурный обзор проекта.
+          Не используй секции и подзаголовки.
+          Если файла нет, ответь одной короткой фразой: `Файл <path> не найден.`
+          Не придумывай анализ отсутствующего файла.
+
+      EXPLAIN:
+        template_id: "intent_code_qa_explain_ru_v4"
+        system_prompt: "Ты senior Python-инженер и code reviewer, который объясняет устройство кода без домысливания."
+        task_prompt: |
+          Объясни, как работает сущность из вопроса пользователя, обычным инженерным текстом.
+          Начни с самого важного: что это за сущность и где она находится, если это видно.
+          Затем кратко опиши подтверждённые зависимости, вызовы, аргументы, поля или шаги работы, только если они реально видны.
+          Не используй общие формулы без конкретных имён.
+          Если виден конструктор, метод или вызов, лучше назвать его явно, чем писать абстрактно про "инициализацию", "службы", "аргументы" или "компоненты".
+          Если вывод основан на косвенных признаках, явно пометь это как осторожный вывод.
+          Если сущность не найдена или evidence слабый, не пиши обычное объяснение — прямо скажи об этом и остановись.
+          Не используй обязательные секции и подзаголовки.
+
+      EXPLAIN_LOCAL:
+        template_id: "intent_code_qa_explain_local_ru_v4"
+        system_prompt: "Ты инженер, который объясняет локальный фрагмент кода без лишней теории и без перехода на уровень всей архитектуры."
+        task_prompt: |
+          Дай локальное объяснение по конкретному файлу, символу или короткому участку кода.
+          Сконцентрируйся на том, что делает этот участок, какие входы и выходы видны и какие ближайшие вызовы или зависимости заметны рядом.
+          Если виден только фрагмент, ограничь вывод тем, что прямо видно в этом фрагменте.
+          Не компенсируй нехватку локального контекста общими архитектурными фразами.
+          Не расписывай всю архитектуру проекта и не используй секции без необходимости.
+
+      FIND_TESTS:
+        template_id: "intent_code_qa_find_tests_ru_v4"
+        system_prompt: "Ты инженер, который ищет тестовое покрытие и различает прямые и косвенные тесты."
+        task_prompt: |
+          Найди связанные тесты и ответь, где они расположены.
+          Сначала назови прямые тесты, только если связь с сущностью подтверждается именем, импортом, вызовом или проверяемым поведением.
+          Если прямых тестов нет, прямо скажи это и только потом упомяни ближайшие косвенные тесты, если они есть.
+          Коротко поясни, что именно проверяется.
+          Не выдавай косвенные совпадения за подтверждённое покрытие и не используй отчётные секции без нужды.
+          Если косвенных тестов тоже нет, не добавляй отдельный пустой блок про их отсутствие.
+
+      FIND_ENTRYPOINTS:
+        template_id: "intent_code_qa_find_entrypoints_ru_v4"
+        system_prompt: "Ты инженер, который находит подтверждённые точки входа и отдельно помечает только возможные кандидаты."
+        task_prompt: |
+          Найди точки входа, обработчики запуска или важные entrypoints.
+          Для подтверждённых HTTP route сначала называй их в прикладном виде: HTTP method и route path, например `GET /health`.
+          Затем коротко добавляй, где route объявлен и какой handler, функция, метод или контекст его обслуживает, если это видно.
+          Подтверждённые entrypoints перечисляй первыми.
+          Кандидатов без явного route marker упоминай только если они действительно полезны, и явно помечай как кандидатов.
+          Не своди ответ к обсуждению декораторов вроде `@app.get`; пользователю важнее method, path и контекст.
+          Не используй искусственные секции, если ответ можно дать компактным списком или коротким абзацем.
+          Если кандидатов нет, не создавай отдельную строку или блок про их отсутствие.
+          Не заменяй `GET /health` абстрактной формулой вроде "route для health-check"; сначала всегда пиши method и path.
+
+      TRACE_FLOW:
+        template_id: "intent_code_qa_trace_flow_ru_v4"
+        system_prompt: "Ты инженер, который восстанавливает поток вызовов и движение данных только по доказуемой цепочке из контекста."
+        task_prompt: |
+          Проследи поток выполнения или поток данных по найденным артефактам.
+          Старайся описывать шаги последовательно и коротко, без лишних подзаголовков.
+          Не склеивай шаги, если между ними нет прямой связи в коде или явно подтверждённого отношения в извлечённых данных.
+          Если поток восстанавливается только частично, так и скажи.
+          Не заменяй конкретные шаги общими словами вроде "обрабатывает запрос", "передаёт данные" или "инициализирует службы", если можно назвать конкретный вызов, метод или route.
+
+      ARCHITECTURE:
+        template_id: "intent_code_qa_architecture_ru_v4"
+        system_prompt: "Ты инженер, который объясняет устройство подсистемы только по наблюдаемым компонентам и связям из кода."
+        task_prompt: |
+          Дай архитектурное объяснение без лишней теории.
+          Назови подтверждённые компоненты и конкретные связи между ними: создаёт, вызывает, регистрирует, читает, пишет, передаёт, оборачивает.
+          Затем коротко опиши границы ответственности, только если они реально видны в коде.
+          Не используй synthetic role labels как готовый пользовательский вывод, если они не поддержаны кодом.
+          Не придумывай скрытые слои и не расширяй архитектуру за пределы извлечённого контекста.
+          Не используй обязательные markdown-секции.
+          Не используй абстрактные формулы вроде "главный компонент", "центральный управляющий компонент", "управляет потоками данных и состоянием системы", если конкретная связь не раскрыта через наблюдаемые методы, поля или вызовы.
+
+      GENERAL_QA:
+        template_id: "intent_code_qa_general_ru_v2"
+        system_prompt: "Ты senior Python-инженер, который даёт обзорный ответ по подсистеме или проекту, но остаётся строго привязанным к коду из контекста."
+        task_prompt: |
+          Дай обзорный ответ по вопросу пользователя о коде, подсистеме или сценарии работы.
+          Сначала скажи, что можно уверенно подтвердить по коду, затем коротко укажи, какие файлы, классы, функции или route это подтверждают.
+          Если данных недостаточно, прямо скажи, чего именно не хватает.
+          Не подменяй обзор общими рассуждениями о типичной архитектуре таких систем.
+          Не используй секции без необходимости.
+          Не заполняй пробелы общими словами вроде "несколько модулей", "различные компоненты" или "ряд зависимостей", если конкретные имена не видны.
+
+  DOCS_QA:
+    template_id: "intent_docs_qa_v2"
+    system_prompt: "Ты технический писатель и инженер по документации, который отвечает только по извлечённым документам."
+    task_prompt: |
+      Отвечай строго по документации из контекста RAG.
+      Если есть несколько документов, кратко синтезируй общий вывод и различия между ними.
+      Не добавляй факты, которых нет в извлечённой документации.
+
+  GENERATE_DOCS_FROM_CODE:
+    template_id: "intent_generate_docs_v2"
+    system_prompt: "Ты технический писатель, который готовит документацию по коду без выдуманных деталей."
+    task_prompt: |
+      Сформируй структурированное описание: назначение, входы/выходы, зависимости и ограничения.
+      Включай только то, что подтверждается кодом или контекстом.
+      Если какая-то часть не подтверждена, явно помечай её как неизвестную.
+
+  PROJECT_MISC:
+    template_id: "intent_project_misc_v2"
+    system_prompt: "Ты инженер-ассистент по общим вопросам о проекте, который не выходит за пределы доступного контекста."
+    task_prompt: |
+      Дай короткий прикладной ответ по вопросу пользователя, опираясь на контекст.
+      Если контекст слабый, честно скажи об этом и укажи, какого контекста не хватает.
+      Не превращай ответ в общий обзор, если данных мало.
--- a/tests/pipeline_setup_v2/run.py
+++ b/tests/pipeline_setup_v2/run.py
@@ -0,0 +1,42 @@
+from __future__ import annotations
+
+import argparse
+import sys
+from pathlib import Path
+
+_agent_root = Path(__file__).resolve().parents[2]
+if str(_agent_root) not in sys.path:
+    sys.path.insert(0, str(_agent_root))
+_src = _agent_root / "src"
+if _src.exists() and str(_src) not in sys.path:
+    sys.path.insert(0, str(_src))
+
+from tests.pipeline_setup.env_loader import load_pipeline_setup_env
+from tests.pipeline_setup_v2.core.runner import V2Runner
+
+
+def main(argv: list[str] | None = None) -> int:
+    parser = argparse.ArgumentParser(description="Run unified pipeline_setup_v2 cases")
+    parser.add_argument("--cases-dir", required=True, help="Directory with YAML case files")
+    parser.add_argument("--run-name", default="manual_run", help="Output directory prefix")
+    parser.add_argument("--results-dir", default=None, help="Override results root directory")
+    ns = parser.parse_args(argv)
+
+    cases_dir = Path(str(ns.cases_dir)).expanduser().resolve()
+    results_dir = Path(str(ns.results_dir)).expanduser().resolve() if ns.results_dir else Path(__file__).resolve().parent / "test_results"
+    load_pipeline_setup_env(start_dir=_agent_root / "tests" / "pipeline_setup")
+    runner = V2Runner(cases_dir=cases_dir, results_dir=results_dir, run_name=str(ns.run_name).strip() or "manual_run")
+    print(f"Cases dir: {cases_dir}")
+    print(f"Run dir: {runner.run_dir}")
+    results, summary_path = runner.run()
+    passed = sum(1 for item in results if item.passed)
+    print(f"Passed: {passed}/{len(results)}")
+    print(f"Summary: {summary_path}")
+    for item in results:
+        if not item.passed:
+            print(f"FAIL {item.case.case_id}: {'; '.join(item.mismatches)}")
+    return 0 if passed == len(results) else 1
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())
--- a/tests/pipeline_setup_v2/runtime/init.py
+++ b/tests/pipeline_setup_v2/runtime/init.py
@@ -0,0 +1 @@
+"""Runtime-specific executors for pipeline_setup_v2."""
--- a/tests/pipeline_setup_v2/runtime/code_qa_eval_adapter.py
+++ b/tests/pipeline_setup_v2/runtime/code_qa_eval_adapter.py
@@ -0,0 +1,56 @@
+from __future__ import annotations
+
+from app.modules.agent.code_qa_runtime import CodeQaRuntimeExecutor
+from app.modules.rag.contracts.enums import RagLayer
+from app.modules.rag.intent_router_v2 import RepoContext
+from tests.pipeline_setup_v2.core.models import ExecutionPayload, V2Case
+
+
+class CodeQaEvalAdapter:
+    def __init__(self) -> None:
+        self._executor = CodeQaRuntimeExecutor(llm=None)
+
+    def execute(self, case: V2Case, rag_session_id: str | None) -> ExecutionPayload:
+        if not rag_session_id:
+            raise ValueError(f"Case '{case.case_id}' requires rag_session_id or repo_path")
+        result = self._executor.execute(user_query=case.query, rag_session_id=rag_session_id)
+        route_result = result.router_result
+        route = result.diagnostics.router_result
+        details = {
+            "case_id": case.case_id,
+            "query": case.query,
+            "rag_session_id": rag_session_id,
+            "actual": {
+                "intent": route.get("intent"),
+                "sub_intent": route.get("sub_intent"),
+                "graph_id": route.get("graph_id"),
+                "conversation_mode": route.get("conversation_mode"),
+                "rag_count": len(result.retrieval_result.code_chunks) if result.retrieval_result else 0,
+                "llm_answer": "",
+                "answer_mode": result.answer_mode,
+                "path_scope": tuple(route.get("path_scope") or []),
+                "symbol_candidates": tuple(route_result.query_plan.symbol_candidates or []) if route_result else (),
+                "layers": tuple(route.get("layers") or []),
+            },
+            "timings_ms": result.diagnostics.timings_ms,
+        }
+        actual = dict(details["actual"])
+        return ExecutionPayload(actual=actual, details=details)
+
+
+def _repo_context() -> RepoContext:
+    return RepoContext(
+        languages=["python"],
+        available_domains=["CODE", "DOCS"],
+        available_layers=[
+            RagLayer.CODE_ENTRYPOINTS,
+            RagLayer.CODE_SYMBOL_CATALOG,
+            RagLayer.CODE_DEPENDENCY_GRAPH,
+            RagLayer.CODE_SEMANTIC_ROLES,
+            RagLayer.CODE_SOURCE_CHUNKS,
+            RagLayer.DOCS_MODULE_CATALOG,
+            RagLayer.DOCS_FACT_INDEX,
+            RagLayer.DOCS_SECTION_INDEX,
+            RagLayer.DOCS_POLICY_INDEX,
+        ],
+    )
--- a/tests/pipeline_setup_v2/runtime/runtime_adapter.py
+++ b/tests/pipeline_setup_v2/runtime/runtime_adapter.py
@@ -0,0 +1,154 @@
+from __future__ import annotations
+
+from datetime import datetime
+from pathlib import Path
+
+from app.modules.agent.code_qa_runtime import CodeQaRuntimeExecutor
+from app.modules.agent.llm import AgentLlmService
+from app.modules.agent.prompt_loader import PromptLoader
+from app.modules.shared.gigachat.client import GigaChatClient
+from app.modules.shared.gigachat.settings import GigaChatSettings
+from app.modules.shared.gigachat.token_provider import GigaChatTokenProvider
+from tests.pipeline_setup.suite_02_pipeline.pipeline_intent_rag.helpers.env_bootstrap import PipelineEnvLoader
+from tests.pipeline_setup.suite_02_pipeline.pipeline_intent_rag.helpers.models import PhraseCase, PipelineResult
+from tests.pipeline_setup.suite_02_pipeline.pipeline_intent_rag.helpers.pipeline_runner import (
+    IntentRouterRagPipelineRunner,
+    RouterOnlyRunner,
+)
+from tests.pipeline_setup_v2.core.models import ExecutionPayload, V2Case
+
+
+class RuntimeAdapter:
+    def __init__(self) -> None:
+        self._test_root = (
+            Path(__file__).resolve().parents[2]
+            / "pipeline_setup"
+            / "suite_02_pipeline"
+            / "pipeline_intent_rag"
+        ).resolve()
+        PipelineEnvLoader(self._test_root).load()
+        self._started_at = datetime.now()
+        self._rag_adapter = None
+        self._executor: CodeQaRuntimeExecutor | None = None
+
+    def execute(self, case: V2Case, rag_session_id: str | None) -> ExecutionPayload:
+        phrase = PhraseCase(
+            case_id=case.case_id,
+            text=case.query,
+            rag_session_id=rag_session_id,
+            expected_intent=case.expectations.router.intent,
+            expect_non_empty_rag=bool(case.expectations.retrieval.non_empty),
+        )
+        if case.mode == "router_only":
+            result = RouterOnlyRunner(started_at=self._started_at).run_case(phrase)
+        elif case.mode == "router_rag":
+            result = IntentRouterRagPipelineRunner(
+                started_at=self._started_at,
+                rag_adapter=self._rag_components(),
+                session_resolver=_StaticSessionResolver(),
+            ).run_case(phrase)
+        else:
+            result = self._run_full_chain(phrase)
+        record = result.to_record()
+        return ExecutionPayload(actual=_actual_from_runtime_record(record), details=record)
+
+    def _run_full_chain(self, phrase: PhraseCase) -> PipelineResult:
+        result = self._executor_instance().execute(user_query=phrase.text, rag_session_id=phrase.rag_session_id or "")
+        route = dict(result.diagnostics.router_result)
+        retrieval = result.diagnostics.retrieval_request
+        diagnostics = {
+            "router_plan": {
+                "sub_intent": route.get("sub_intent"),
+                "graph_id": route.get("graph_id"),
+                "path_scope": list(retrieval.get("path_scope") or []),
+                "layers": list(retrieval.get("requested_layers") or []),
+                "symbol_candidates": list(result.router_result.query_plan.symbol_candidates or []) if result.router_result else [],
+            },
+            "timings_ms": dict(result.diagnostics.timings_ms or {}),
+            "answer_policy": {
+                "short_circuit": not result.llm_used,
+                "answer_mode": _answer_status(result.answer_mode, result.llm_used),
+                "failure_reason": ",".join(result.validation.reasons),
+            },
+        }
+        return PipelineResult(
+            case=phrase,
+            mode="full_chain",
+            run_started_at=self._started_at,
+            rag_session_id=phrase.rag_session_id,
+            intent=str(route.get("intent") or ""),
+            graph_id=str(route.get("graph_id") or ""),
+            conversation_mode=str(route.get("conversation_mode") or ""),
+            query=str(retrieval.get("query") or phrase.text),
+            rag_rows=list(result.retrieval_result.raw_rows) if result.retrieval_result else [],
+            symbol_resolution=result.router_result.symbol_resolution.model_dump() if result.router_result else {},
+            llm_answer=result.final_answer,
+            diagnostics=diagnostics,
+        )
+
+    def _rag_components(self):
+        if self._rag_adapter is None:
+            from app.modules.rag.persistence.repository import RagRepository
+            from tests.pipeline_setup.suite_02_pipeline.pipeline_intent_rag.helpers.rag_db_adapter import (
+                RagDbAdapter,
+                SessionEmbeddingDimensions,
+            )
+
+            self._rag_adapter = RagDbAdapter(
+                repository=RagRepository(),
+                dim_resolver=SessionEmbeddingDimensions(),
+            )
+        return self._rag_adapter
+
+    def _executor_instance(self) -> CodeQaRuntimeExecutor:
+        if self._executor is None:
+            self._executor = CodeQaRuntimeExecutor(_build_llm())
+        return self._executor
+
+
+class _StaticSessionResolver:
+    def resolve(self, case: PhraseCase) -> str:
+        if not case.rag_session_id:
+            raise ValueError(f"Case '{case.case_id}' requires rag_session_id or repo_path")
+        return case.rag_session_id
+
+
+def _actual_from_runtime_record(record: dict) -> dict:
+    diagnostics = dict(record.get("diagnostics") or {})
+    router_plan = dict(diagnostics.get("router_plan") or {})
+    summary = dict(record.get("summary") or {})
+    router_summary = dict(summary.get("router") or {})
+    return {
+        "intent": record.get("actual_intent"),
+        "sub_intent": router_summary.get("sub_intent") or router_plan.get("sub_intent"),
+        "graph_id": record.get("graph_id"),
+        "conversation_mode": record.get("conversation_mode"),
+        "rag_count": int(record.get("rag_count") or 0),
+        "llm_answer": str(record.get("llm_answer") or "").strip(),
+        "answer_mode": dict(summary.get("llm") or {}).get("answer_status"),
+        "path_scope": tuple(router_plan.get("path_scope") or []),
+        "symbol_candidates": tuple(router_plan.get("symbol_candidates") or []),
+        "layers": tuple(router_plan.get("layers") or []),
+    }
+
+
+def _ms(started: float) -> int:
+    return 0
+
+
+def _sub_intent_from_result(result: PipelineResult) -> str | None:
+    router_plan = dict(result.diagnostics.get("router_plan") or {})
+    value = str(router_plan.get("sub_intent") or "").strip()
+    return value or None
+
+
+def _answer_status(answer_mode: str, llm_used: bool) -> str:
+    if answer_mode == "normal" and llm_used:
+        return "answered"
+    return answer_mode
+
+
+def _build_llm() -> AgentLlmService:
+    settings = GigaChatSettings.from_env()
+    client = GigaChatClient(settings, GigaChatTokenProvider(settings))
+    return AgentLlmService(client=client, prompts=PromptLoader())
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `ControlPlaneService`\n\n### Описание файла и класса\n\nКласс `ControlPlaneService` определен в файле `src/app_runtime/control/service.py`.\n\n```python\n# src/app_runtime/control/service.py\nclass ControlPlaneService\n```\n\n### Назначение и обязанности\n\nНазвание класса предполагает, что он является службой управления плоскостью контроля (`Control Plane Service`), которая отвечает за управление определенными аспектами приложения или системы.\n\n#### Основные обязанности и роли:\n\n- **Назначение**: Предполагается, что класс реализует функциональность сервиса, связанный с управлением состоянием системы, взаимодействует с другими компонентами и участвует в различных этапах обработки данных (dataflow slices).\n  \n  - **Поведение сервиса**:\n    - Обрабатывает запросы и изменяет состояние системы через чтение и запись атрибутов состояния.\n  \n  - **Участие в потоке данных (dataflow)**: \n    Класс участвует в нескольких срезах потока данных (dataflow slices):\n      - Срез №5: Участие в общих сервисных операциях, связанных с управлением системой.\n  \n\n### Зависимости и взаимодействие\n\nКласс использует другие классы и интерфейсы для выполнения своих обязанностей:\n\n- Контроллер канала (`ControlChannel`) из модуля `base.py`: Это интерфейс, представляющий стандартный контроллер модели.\n- Контрольный набор действий (`ControlActionSet`) также из модуля `base.py`: Набор стандартных операций или действий, которые могут быть выполнены моделью.\n- Другие классы и сервисы, участвующие в выполнении HTTP-запросов, такие как `UvicornThreadRunner`, который используется для запуска HTTP-сервера на отдельном потоке, и `HttpControlChannel`, обеспечивающий HTTP-контроллеры.\n\nЭти зависимости позволяют классу эффективно участвовать в управлении состоянием системы и взаимодействии с внешними API и серверами.\n\n---\n\n### Поток данных и архитектура\n\nАрхитектура класса предполагает централизованное управление данными и состоянием через определенные срезы данных (dataflow slices). Каждый из этих срезов представляет собой этап или часть общего процесса работы системы, где данный класс выполняет свою роль.\n\nНапример:\n\n- В срезе №5 он может выполнять действия по управлению конфигурацией, состоянию и обработке ошибок, связанных с общим контролем над работой системы.\n\n---\n\n### Заключение\n\nТаким образом, `ControlPlaneService` — это ключевой элемент архитектуры, ответственный за обработку и управление состоянием системы, ее конфигурацией и взаимодействием с внешними компонентами и службами. Его функциональность интегрируется в общий процесс через различные срезы данных, обеспечивая гибкость и масштабируемость всей системы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `HttpControlChannel`\n\n### Файл и позиция класса\n```python\n# Источник: src/app_runtime/control/http_channel.py\n# Класс: HttpControlChannel\n```\n\n### Наследование и роль класса\nКласс `HttpControlChannel` наследует от базового класса `ControlChannel`. Его аннотация указывает на то, что он является частью стадии конвейера (`pipeline_stage`), что означает его участие в общем потоке обработки данных приложения.\n\n### Ответственность класса\nДокументированные обязанности класса включают:\n- Чтение и запись атрибутов состояния.\n- Участие в срезах потока данных (dataflow slices).\n\nВ документации упоминается конкретное количество таких срезов — 10.\n\n### Взаимодействие с другими сущностями\nДля понимания полной картины взаимодействия и архитектуры важно рассмотреть следующие классы и их роли:\n\n#### 1. **ControlChannel**\nЭтот базовый класс определяет основную модель поведения для всех каналов управления состоянием. Он имеет следующую документацию:\n```python\n# Источник: src/app_runtime/control/base.py\n# Класс: ControlChannel\nControlChannel\nrole: model\nResponsibilities:\n- default model role\n```\n\n#### 2. **ControlActionSet**\nЭто также базовый класс действий контроля, упомянутый в той же документации, но не приводится подробной информации о нем здесь.\n\n#### 3. **ControlPlaneService**\nЕще одна сущность, упомянутая в контексте, которая играет важную роль как сервис управления данными:\n```python\n# Источник: src/app_runtime/control/service.py\n# Класс: ControlPlaneService\nControlPlaneService\nrole: pipeline_stage\nResponsibilities:\n- name suffix suggests service\n- reads and writes state attributes\n- participates in dataflow slices (5)\n```\n\n#### 4. **UvicornThreadRunner**\nТакже упоминается еще один компонент, участвующий в управлении состоянием и потоков данных:\n```python\n# Источник: src/app_runtime/control/http_runner.py\n# Класс: UvicornThreadRunner\nUvicornThreadRunner\nrole: pipeline_stage\nResponsibilities:\n- reads and writes state attributes\n- participates in dataflow slices (24)\n```\n\n### Поток данных и взаимодействие между компонентами\nУчитывая вышеописанные классы и обязанности, можно предположить следующий сценарий работы системы:\n\n1. Пользовательский запрос поступает через HTTP API.\n2. Управление состоянием запроса осуществляется посредством объекта `HttpControlChannel`, который обеспечивает чтение и запись необходимых атрибутов состояния.\n3. Канал взаимодействует с общей системой управления состоянием через промежуточные службы, такие как `ControlPlaneService`.\n4. Эти службы участвуют в более широком потоке данных (dataflow slices) вместе с другим компонентом `UvicornThreadRunner`, обеспечивая параллельную обработку запросов и управление потоком выполнения задач.\n\nТаким образом, основная задача `HttpControlChannel` заключается в обеспечении надежной логики чтения и записи атрибутов состояния для отдельных частей системы, при этом совместно с другими компонентами он участвует в обработке и маршрутизации данных в рамках общего архитектурного подхода.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-runtime-manager
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни как работает класс RuntimeManager
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `RuntimeManager`\n\n### 1. Обзор файла и класса\n\nКласс `RuntimeManager` находится в файле `src/app_runtime/core/runtime.py`.\n\n```python\n# src/app_runtime/core/runtime.py\nclass RuntimeManager\n```\n\n### 2. Описание роли и обязанностей\n\nДокументация указывает следующие обязанности для данного класса:\n\n- **name suffix suggests manager**: Название класса предполагает управление другими сущностями или ресурсами.\n- **orchestrates role-like calls (4)**: Класс управляет вызовами ролей и выполняет координацию между ними.\n- **reads and writes state attributes**: Управление состоянием приложения и его атрибутов.\n- **participates in dataflow slices (50)**: Класс участвует в передаче данных через различные этапы обработки данных.\n\n### 3. Связанные классы и их роль\n\n- **ControlChannel** (`src/app_runtime/control/base.py`) — основной канал управления моделью.\n- **ControlActionSet** (`src/app_runtime/control/base.py`) — набор действий, связанных с управлением моделью.\n- **ControlPlaneService** (`src/app_runtime/control/service.py`) — сервис, связанный с управлением плоскостью контроля.\n- **UvicornThreadRunner** (`src/app_runtime/control/http_runner.py`) — запускает сервер на основе uvicorn и реализует многопоточную обработку запросов.\n\nЭти классы совместно участвуют в управлении жизненным циклом модели и потоков выполнения.\n\n### 4. Поток данных и архитектура\n\nАрхитектура включает следующее взаимодействие классов:\n\n- **RuntimeManager** координирует вызовы ролей и отвечает за состояние приложения.\n- **ControlChannel**, **ControlActionSet** обеспечивают логику управления моделями.\n- **ControlPlaneService** ответственен за хранение состояния приложения и передачу данных через различные потоки данных.\n- **UvicornThreadRunner** обеспечивает выполнение HTTP-запросов и синхронизацию потоков.\n\nТаким образом, общая схема выглядит следующим образом:\n\n```\n+----------+\n| RuntimeManager |\n+--+-----------+\n      |\n      v\n+----------+    +---------+   +---------+\n| ControlChannel | -> | ControlActionSet | -> | ControlPlaneService |\n                  ^               ^          ^\n                  |               |          |\n                  +---------------+----------+\n                            |\n                            v\n+--------------+\n| UvicornThreadRunner |\n+---------------------+\n```\n\n### 5. Поведение и примеры использования\n\nПредположим, что `RuntimeManager` используется следующим образом:\n\n```python\nfrom app_runtime.core.runtime import RuntimeManager\n\nruntime_manager = RuntimeManager()\n\n# Инициализация контроллеров и моделей\nruntime_manager.initialize_controllers_and_models()\n\n# Запуск основного потока управления\nruntime_manager.start()\n\n# Координация ролей и состояний\nruntime_manager.coordinate_roles_and_states()\n\n# Завершение работы системы\nruntime_manager.shutdown()\n```\n\n### Заключение\n\nКласс `RuntimeManager` является ключевым компонентом архитектуры, который управляет основными этапами жизненного цикла приложения, включая инициализацию компонентов, координацию вызовов ролей и контроль передачи данных между различными компонентами.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "RuntimeManager"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_090854/summary.md
@@ -0,0 +1,9 @@
+# pipeline_setup_v2 summary
+
+Passed: 3/3
+
+| File | Case | Runner | Mode | Intent | Sub-intent | Pass |
+|------|------|--------|------|--------|------------|------|
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `ControlPlaneService`\n\n### Описание файла и роли сущностей\n\nИсходный код находится в файле `src/app_runtime/control/service.py`, где определен класс `ControlPlaneService`.\nЭтот файл является частью модуля `app_runtime.control`, который отвечает за управление потоком данных и состоянием системы.\n\nВ контексте данного модуля представлены следующие ключевые сущности:\n\n- **`ControlChannel`** (`src/app_runtime/control/base.py`) – базовый интерфейс для взаимодействия с каналами управления.\n- **`ControlActionSet`** (`src/app_runtime/control/base.py`) – абстрактная сущность, представляющая набор действий, которые могут быть выполнены через каналы управления.\n- **`UvicornThreadRunner`** (`src/app_runtime/control/http_runner.py`) – класс, реализующий многопоточную обработку HTTP-запросов с использованием библиотеки uvicorn.\n- **`HttpControlChannel`** (`src/app_runtime/control/http_channel.py`) – канал управления, предназначенный для обработки HTTP запросов.\n\n### Архитектура и обязанности класса\n\nКласс `ControlPlaneService` играет роль сервисного компонента, отвечающего за координацию и выполнение различных задач внутри системы управления. Его основные обязанности включают:\n\n- Чтение и запись состояния атрибутов системы.\n- Участие в управлении данными на нескольких уровнях разделения данных (dataflow slices).\n\nЭти задачи выполняются в рамках более общей архитектуры, ориентированной на разделение потоков данных и состояний между различными компонентами системы.\n\n### Поток данных и взаимодействие компонентов\n\nПоток данных в системе включает несколько ключевых этапов:\n\n1. Пользователь отправляет запрос через HTTP API.\n2. Запрос обрабатывается каналом управления (`HttpControlChannel`), который инициирует соответствующую логику исполнения в зависимости от типа запроса.\n3. Сервисы (например, `ControlPlaneService`) участвуют в обработке этих запросов, взаимодействуя друг с другом посредством чтения и записи состояния атрибутов.\n4. Результаты выполнения записываются обратно в состояние системы или возвращаются клиенту как результат запроса.\n\n### Заключение\n\nТаким образом, класс `ControlPlaneService` представляет собой ключевой элемент архитектуры управления системой, обеспечивающий координацию и исполнение бизнес-логики в соответствии с заданными правилами и ограничениями потока данных.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-create-runtime
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни функцию create_runtime
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ функции `create_runtime` и контекста\n\n### 1. Общая информация о файле и функции\n\nФайл: **src/plba/bootstrap.py**\nФункция: **create_runtime(module)**\n\nЭта функция отвечает за создание runtime окружения для приложения, которое будет использоваться для выполнения различных задач и ролей внутри системы.\n\n---\n\n### 2. Архитектура и роли компонентов\n\n#### Ключевые компоненты и их роль:\n- **pipeline_stage**: Указывает на компонент, который участвует в потоке данных (dataflow slices).\n  \n#### Основные компоненты, участвующие в создании runtime:\n- **UvicornThreadRunner** (`src/app_runtime/control/http_runner.py`)\n- **WorkflowPersistence** (`src/app_runtime/workflow/persistence/workflow_persistence.py`)\n- **HttpControlChannel** (`src/app_runtime/control/http_channel.py`)\n- **InMemoryTaskQueue** (`src/app_runtime/queue/in_memory.py`)\n- **ConfigFileLoader** (`src/app_runtime/config/file_loader.py`)\n\nЭти компоненты являются основными строительными блоками runtime окружения и участвуют в обработке и передаче данных между различными частями системы.\n\n---\n\n### 3. Поток данных и логика работы\n\nПроцесс создания runtime можно разбить на несколько шагов:\n\n1. **Загрузка конфигурации из файла**:\n   - Вызов `ConfigFileLoader` для загрузки конфигурационных параметров из файла.\n   \n2. **Создание экземпляра WorkflowPersistence**:\n   - Создание объекта WorkflowPersistence для управления состоянием и выполнением рабочих процессов.\n\n3. **Запуск HTTP-сервера с использованием Uvicorn**:\n   - Использование UvicornThreadRunner для запуска HTTP-сервера и обработки запросов через контроллер.\n\n4. **Инициализация очереди задач**:\n   - Инициализация InMemoryTaskQueue для хранения и управления очередью задач.\n\n5. **Настройка каналов связи и взаимодействия**:\n   - Настройка HttpControlChannel для обеспечения взаимодействия между различными компонентами системы.\n\n---\n\n### 4. Кодовая реализация функции `create_runtime`\n\n```python\ndef create_runtime(module):\n    # Загружаем конфигурацию из файла\n    config = ConfigFileLoader().load_config()\n    \n    # Создаем объект WorkflowPersistence\n    workflow_persistence = WorkflowPersistence(config)\n    \n    # Запускаем HTTP-сервер с помощью Uvicorn\n    uvicorn_thread_runner = UvicornThreadRunner(\n        module,\n        host=config.get('http', 'host'),\n        port=int(config.get('http', 'port'))\n    )\n    \n    # Инициализируем очередь задач\n    task_queue = InMemoryTaskQueue()\n    \n    # Настраиваем канал связи для взаимодействия между компонентами\n    http_control_channel = HttpControlChannel(task_queue, workflow_persistence)\n```\n\n---\n\n### 5. Итоговое объяснение\n\nФункция `create_runtime` выполняет следующие задачи:\n- Загружает конфигурационные параметры из файла.\n- Создает объекты, необходимые для управления рабочим процессом и состояниями (WorkflowPersistence).\n- Запускает HTTP-сервер для приема и обработки входящих запросов.\n- Инициализирует очередь задач для выполнения асинхронных операций.\n- Настраивает каналы связи между различными компонентами системы.\n\nТаким образом, эта функция играет ключевую роль в настройке runtime окружения и обеспечении взаимодействия между различными компонентами приложения.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "create_runtime"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `HttpControlChannel`\n\n### 1. Общая информация о классе\n\n**Файл:**  \n`src/app_runtime/control/http_channel.py`\n\n**Класс:**  \n`HttpControlChannel`\n\n**Наследование:**  \n`HttpControlChannel(ControlChannel)`\n\n**Роль:**  \n`pipeline_stage`\n\n**Описание роли:**  \nПроводит чтение и запись атрибутов состояния; участвует в данных срезах потока данных (`dataflow slices`).\n\n---\n\n### 2. Архитектура и структура класса\n\n- **Основное назначение:**  \nКласс реализует канал управления для HTTP-коммуникаций. Он обеспечивает взаимодействие с внешним миром через HTTP-запросы и ответы.\n\n- **Связь с другими сущностями:**  \n- Наследуется от базового класса `ControlChannel`, который является моделью общего назначения для каналов управления.\n- Участвует в инфраструктуре управления данными потоков (`ControlPlaneService`), обеспечивая работу и интеграцию на уровне всей системы управления (контроля) данными.\n\n---\n\n### 3. Поток данных и обязанности класса\n\n#### Основные обязанности:\n- Чтение и запись атрибутов состояния канала.\n- Участие в обработке данных на этапе \"срезов\" данных (dataflow slices). Это подразумевает участие в разделении и передаче данных между различными этапами обработки информации.\n\n#### Процесс взаимодействия:\n1. Принимает запросы от внешнего мира через HTTP API.\n2. Обрабатывает входные данные и формирует соответствующие ответы.\n3. Передает результаты своей работы в систему контроля и управления (Control Plane Service).\n\n---\n\n### 4. Связи и зависимости\n\n- **Зависимости от других классов и компонентов:**\n  - `ControlChannel`: Базовый класс для всех каналов управления.\n  - `ControlPlaneService`: Основная служба управления процессом обработки данных.\n  - Другие классы и компоненты из модуля `http_channel`.\n\n- **Внешние интерфейсы и взаимодействия:**\n  - HTTP-серверы или клиентские библиотеки (например, `uvicorn`), обеспечивающие коммуникацию через HTTP-протокол.\n\n---\n\n### Заключение\n\nКласс `HttpControlChannel` играет важную роль в системе управления данными, обеспечивая взаимодействие с внешними запросами и их обработку через HTTP-протокол. Он наследует основные возможности чтения и записи состояний от базовой модели канала управления и интегрируется в общую структуру контроля данных, обеспечивая свою специфическую функциональность через HTTP-интерфейсы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-runtime-manager
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни как работает класс RuntimeManager
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `RuntimeManager`\n\n### Файл и путь:\n`src/app_runtime/core/runtime.py`\n\n### Описание класса:\n**Класс:** `RuntimeManager`\n\n**Роль:** \n- Менеджер роли (pipeline_stage)\n- Оркестратор вызовов ролей (4)\n- Читает и записывает состояние атрибутов\n- Участвует в срезах потока данных (50)\n\n### Основные обязанности и ответственность:\n1. **Менеджер состояния**: Класс управляет состоянием системы и отвечает за его изменение при выполнении различных операций.\n   \n2. **Оркестровка ролей**: Он координирует выполнение этапов обработки данных (roles) внутри конвейера (pipeline). Каждый этап выполняет определенную роль, например, чтение или запись состояний, обработку данных и т.д.\n\n3. **Чтение и запись состояний**: Класс поддерживает и обновляет внутренние состояния приложения через атрибуты объекта.\n\n4. **Участие в потоке данных**: Управление потоком данных происходит на уровне «срезов» (slices), что означает, что класс участвует в разделении и передаче данных между различными компонентами системы.\n\n---\n\n### Поток данных и архитектура:\n\n#### Входные данные\n- Данные поступают из внешнего источника или из предыдущего этапа конвейера.\n\n#### Логика работы:\n1. При инициализации экземпляра класса создаются начальные атрибуты состояния (`state_attributes`), которые представляют текущую информацию о системе.\n2. Для выполнения операций используется метод, принимающий внешние действия (`perform_action`) и аргументы для этих действий.\n   - Пример метода: `perform_action(self, action_name, *args)`\n     - В аргументах передаются имя действия и параметры, необходимые для этого действия.\n3. Внутри `perform_action` проверяется корректность входных параметров и вызывается соответствующая логика для выполнения нужного действия.\n4. После выполнения действия изменяется внутреннее состояние системы путем записи нового значения атрибута состояния.\n5. Информация передается следующему этапу конвейера.\n\n#### Выходные данные\n- Результат обработки передается дальше по конвейеру или возвращается клиенту, если это конечный результат.\n\n---\n\n### Ключевые компоненты и зависимости:\n- Внутренние атрибуты состояния (`state_attributes`): хранят текущее состояние системы, доступное для чтения и изменения.\n- Методы для выполнения конкретных действий (метод `perform_action`):\n  - Вызывают соответствующие методы других компонентов или классов.\n  \n### Пример использования:\n```python\n# Инициализация менеджера\nruntime_manager = RuntimeManager()\n\n# Выполнение действия с аргументами\nresult = runtime_manager.perform_action('action_name', arg1, arg2)\n```\n\n---\n\n### Заключение:\nКласс `RuntimeManager` играет ключевую роль в управлении состоянием и координацией выполнения этапов обработки данных в приложении. Его использование позволяет централизованно управлять потоком данных и обеспечивать согласованность состояния приложения на каждом этапе обработки.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "RuntimeManager"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-trace-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Как работает TraceService?
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 21,
+  "llm_answer": "## Анализ архитектуры и поведения системы с участием `TraceService`\n\n### Описание роли и ответственности компонента\n\nВ системе предоставлены несколько компонентов, выполняющих роль pipeline stage и участвующих в управлении состоянием приложения и его данными. Рассмотрим подробнее один из них — **`TraceService`**.\n\n---\n\n### Поведение и архитектура `TraceService`\n\n#### 1. Место в общей архитектуре\n- `TraceService` является классом, производным от класса `TraceContextFactory`.\n- Класс предназначен для работы с контекстом трассировки (`trace context`), что позволяет отслеживать выполнение задач и событий в приложении.\n  \n#### 2. Основные обязанности и ответственность\n- Название класса и суффикс «service» указывают на то, что он играет сервисную роль в системе.\n- Он участвует в обработке данных и их перемещении между различными компонентами (dataflow slices).\n- Имеет доступ к атрибутам состояния и может изменять их значение.\n\n#### 3. Участие в процессе выполнения запросов и управления данными\n- Класс взаимодействует с другими pipeline stages, такими как `UvicornThreadRunner`, `WorkflowPersistence`, `HttpControlChannel` и `InMemoryTaskQueue`. Эти компоненты совместно обеспечивают функционирование workflow и взаимодействие с внешним миром.\n\n---\n\n### Поток данных и логика обработки\n\n- Входные данные поступают через HTTP-запросы или другие каналы взаимодействия (например, запросы через очередь сообщений).\n- В рамках обработки запроса происходит создание контекста трассировки, который передается всем задействованным компонентам.\n- Контекст содержит информацию о запросе, включая идентификаторы, метаданные и другие параметры, необходимые для корректного отслеживания и логирования операций.\n- Все pipeline stages участвуют в передаче этих данных и обмениваются ими между собой, обеспечивая согласованность и целостность процесса.\n\n---\n\n### Примеры использования и вызовы методов\n\nДля лучшего понимания рассмотрим примерный сценарий взаимодействия компонентов:\n\n```python\n# Пример вызова сервиса trace service\nfrom app_runtime.tracing.service import TraceService\n\n# Создание экземпляра сервиса\ntrace_service = TraceService()\n\n# Обработка входных данных и получение контекста трассировки\ncontext = trace_service.get_trace_context(request_data)\n\n# Передача контекста другим pipeline stages\nuvicorn_thread_runner = UvicornThreadRunner()\nuvicorn_thread_runner.process_request(context)\n```\n\n---\n\n### Заключение\n\nТаким образом, **`TraceService`** представляет собой важный элемент системы, обеспечивающий централизованное управление контекстом трассировки и участие в потоках данных и состоянии приложения. Он активно взаимодействует с другими компонентами, обеспечивая корректное выполнение задач и передачу информации между ними.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "TraceService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-workflow-engine
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс WorkflowEngine
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 20,
+  "llm_answer": "## Архитектура и Поведение `WorkflowEngine`\n\n### Описание класса `WorkflowEngine` (`src/app_runtime/workflow/engine/workflow_engine.py`)\n\n**Класс:**  \n`WorkflowEngine`\n\n**Роль:**  \n`pipeline_stage`\n\n**Ответственности:**  \n- Чтение и запись атрибутов состояния.\n- Участие в срезах данных потока (dataflow slices).\n\n---\n\n### Поток данных и структура работы\n\n1. **Входные данные**\n   - Данные передаются через состояние приложения или из внешних источников (например, REST API вызовов).\n   \n2. **Основная логика работы `WorkflowEngine`:**\n   1. Принимает входные данные (через чтение атрибутов состояния).\n   2. Определяет текущее состояние системы на основе этих данных.\n   3. Использует внутренние механизмы для разрешения переходов между этапами выполнения workflow.\n   4. Записывает новое состояние после обработки.\n\n3. **Связь с другими сущностями:**\n   - **WorkflowEngineHooks:**  \n     Класс отвечает за определение стандартного поведения модели, используемой внутри workflow engine. В основном он выполняет действия по умолчанию, которые могут быть переопределены пользователем.\n     \n   - **TransitionResolver:**  \n     Используется для определения правил перехода между различными стадиями workflow. Этот механизм решает, как именно должны выполняться шаги workflow и какие условия их активируют.\n\n4. **Участие в потоках данных (dataflow slices):**\n   - **Dataflow Slices (6):**  \n     Срезы данных обеспечивают возможность параллельного выполнения различных частей workflow одновременно, что улучшает производительность системы.\n   - **Dataflow Slices (24):**  \n     Другой набор параллельных потоков, организованных через `UvicornThreadRunner`, обеспечивает параллельность выполнения HTTP-запросов и других асинхронных задач.\n\n5. **Пример взаимодействия с внешними компонентами:**\n   - Работа через внешние HTTP вызовы (`UvicornThreadRunner`) позволяет запускать различные задачи параллельно и возвращать результаты обратно в систему workflow.\n\n---\n\n### Ключевые моменты реализации:\n\n- `WorkflowEngine` выступает центральным элементом всей логики workflow и координирует выполнение этапов.\n- Все этапы определяются через правила перехода (`TransitionResolver`), которые помогают системе двигаться от одного этапа к другому.\n- Использование срезов данных и параллелизма (6 и 24 потоков) позволяет оптимизировать обработку и улучшить общую производительность.\n\n---\n\n### Заключение\n\n`WorkflowEngine` является ключевым компонентом системы управления workflow, отвечающим за координацию и управление процессом выполнения шагов workflow. Он взаимодействует с различными модулями, такими как `WorkflowEngineHooks` и `TransitionResolver`, обеспечивая корректное выполнение всех необходимых действий. Параллельная обработка (до 24 потоков) и четкая структура правил перехода делают этот подход эффективным и масштабируемым решением.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "WorkflowEngine"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091150/summary.md
@@ -0,0 +1,20 @@
+# pipeline_setup_v2 summary
+
+Passed: 6/6
+
+| File | Case | Runner | Mode | Intent | Sub-intent | Pass |
+|------|------|--------|------|--------|------------|------|
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-trace-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-create-runtime | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-workflow-engine | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+
+## LLM Answers
+- **plba-fullchain-explain-runtime-manager**: ## Анализ класса `RuntimeManager` ### Файл и путь: `src/app_runtime/core/runtime.py` ### Описание класса: **Класс:** `RuntimeManager` **Роль:** - Менеджер роли (pipeline_stage) - Оркестратор вызовов ролей (4) - Читает и…
+- **plba-fullchain-explain-http-control-channel**: ## Анализ класса `HttpControlChannel` ### 1. Общая информация о классе **Файл:** `src/app_runtime/control/http_channel.py` **Класс:** `HttpControlChannel` **Наследование:** `HttpControlChannel(ControlChannel)` **Роль:**…
+- **plba-fullchain-explain-control-plane-service**: ## Анализ класса `ControlPlaneService` ### Описание файла и роли сущностей Исходный код находится в файле `src/app_runtime/control/service.py`, где определен класс `ControlPlaneService`. Этот файл является частью модуля…
+- **plba-fullchain-explain-trace-service**: ## Анализ архитектуры и поведения системы с участием `TraceService` ### Описание роли и ответственности компонента В системе предоставлены несколько компонентов, выполняющих роль pipeline stage и участвующих в управлени…
+- **plba-fullchain-explain-create-runtime**: ## Анализ функции `create_runtime` и контекста ### 1. Общая информация о файле и функции Файл: **src/plba/bootstrap.py** Функция: **create_runtime(module)** Эта функция отвечает за создание runtime окружения для приложе…
+- **plba-fullchain-explain-workflow-engine**: ## Архитектура и Поведение `WorkflowEngine` ### Описание класса `WorkflowEngine` (`src/app_runtime/workflow/engine/workflow_engine.py`) **Класс:** `WorkflowEngine` **Роль:** `pipeline_stage` **Ответственности:** - Чтени…
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `ControlPlaneService`\n\n### Описание файла и роли классов\n\nФайл **`src/app_runtime/control/service.py`** содержит определение класса `ControlPlaneService`. Этот файл также импортирует классы и компоненты из других модулей (`base`, `http_channel`, `http_runner`), которые участвуют в общей архитектуре системы управления.\n\n### Класс `ControlPlaneService`\n\nКласс `ControlPlaneService` является ключевым компонентом архитектуры и играет роль «pipeline stage» (этап конвейера). Его основная ответственность заключается в управлении состоянием системы, чтении и записи атрибутов состояния, а также участии в различных срезах обработки данных («dataflow slices»).\n\n#### Архитектура и структура\n\n- **Название класса**: `ControlPlaneService`\n- **Путь к файлу**: `src/app_runtime/control/service.py`\n- **Роль**: `pipeline stage`\n  \n#### Основные обязанности (Responsibilities):\n\n1. **Имя суффикса указывает на сервисную природу объекта:** \n   - Имя класса подразумевает, что он управляет определенными аспектами работы системы или сервиса.\n   \n2. **Чтение и запись атрибутов состояния:**\n   - Контролирует состояние приложения через чтение и запись соответствующих атрибутов.\n   \n3. **Участие в данных срезах (Dataflow Slices):**\n   - Участие в 5 разных срезах данных, что означает его участие в нескольких параллельных процессах или каналах передачи данных.\n\n#### Взаимодействие с другими сущностями\n\n- **`ControlChannel`:**\n  - Используется для взаимодействия модели (ControlModel) внутри системы. Класс находится в модуле `src/app_runtime/control/base.py`.\n  \n- **`ControlActionSet`:**\n  - Также используется для настройки поведения модели. Находится в том же модуле.\n\n- **`UvicornThreadRunner`:**\n  - Служит механизмом запуска HTTP-сервиса через uvicorn. Находится в `src/app_runtime/control/http_runner.py`.\n\n- **`HttpControlChannel`:**\n  - Обеспечивает взаимодействие с внешним миром через HTTP-запросы. Находится в `src/app_runtime/control/http_channel.py`.\n\n---\n\n### Поток данных и управление состоянием\n\nКласс `ControlPlaneService` отвечает за поддержание согласованного состояния между различными компонентами системы. Он обеспечивает механизм для координации действий между разными частями приложения, участвует в распределении нагрузки и синхронизации потоков выполнения задач.\n\nПример простого сценария использования:\n\n```python\n# Создание экземпляра ControlPlaneService\nservice = ControlPlaneService()\n\n# Чтение текущего состояния\ncurrent_state = service.get_current_state()\n\n# Запись нового состояния\nservice.set_new_state(new_state_data)\n```\n\nТаким образом, `ControlPlaneService` выступает как центральный элемент управления состоянием всей системы, обеспечивая корректное функционирование и координацию всех компонентов приложения.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `HttpControlChannel`\n\n### 1. Обзор файла и контекста\n\nКласс `HttpControlChannel` определен в файле `src/app_runtime/control/http_channel.py`. Этот файл содержит классы и функции, связанные с управлением каналами HTTP, которые используются для взаимодействия с внешним миром через HTTP-запросы и ответы.\n\n### 2. Определение класса и его роль\n\n```python\nclass HttpControlChannel(ControlChannel):\n    role: pipeline_stage\n```\n\nЭтот класс наследует от базового класса `ControlChannel`, что указывает на то, что он предназначен для управления состоянием приложения или модели и участвует в общей логике обработки данных внутри системы.\n\n### 3. Ответственность и обязанности класса\n\nСогласно комментариям и документации:\n\n- **Responsibilities:** \n  - \"reads and writes state attributes\"\n  - \"participates in dataflow slices (10)\"\n\nЭто означает, что данный канал отвечает за чтение и запись атрибутов состояния и участвует в нескольких срезах потока данных (dataflow slices).\n\n### 4. Сравнение с другими классами\n\n- **ControlChannel** (`src/app_runtime/control/base.py`) — это базовый класс, который описывает модельные роли и действия, общие для всех каналов контроля.\n  \n- **ControlActionSet** (`src/app_runtime/control/base.py`) — этот класс также относится к моделям и представляет собой набор действий, связанных с моделью.\n\n- **ControlPlaneService** (`src/app_runtime/control/service.py`) — сервисный класс, участвующий в управлении состоянием и потоком данных.\n\n- **UvicornThreadRunner** (`src/app_runtime/control/http_runner.py`) — еще один компонент, связанный с обработкой HTTP-запросов и ответов, выполняемый в отдельном потоке.\n\n### 5. Поток данных и взаимодействие\n\nПоскольку `HttpControlChannel` участвует в \"dataflow slices\", предполагается, что он играет важную роль в координации потоков данных между различными компонентами системы, такими как сервисы, контроллеры и модели. Он взаимодействует с внешними системами посредством HTTP-запросов и отвечает за обновление внутреннего состояния системы на основе полученных ответов.\n\n### Заключение\n\nТаким образом, `HttpControlChannel` является специализированным каналом для управления состоянием и взаимодействия с внешней средой через HTTP-протокол. Он выполняет операции чтения и записи атрибутов состояния и участвует в обработке различных потоков данных внутри системы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-runtime-manager
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни как работает класс RuntimeManager
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `RuntimeManager`\n\n### 1. Положение и назначение класса\n\nКласс `RuntimeManager` определен в файле `src/app_runtime/core/runtime.py`. Его роль — **управляющий компонент**, который координирует выполнение различных ролей и подзадач внутри системы обработки данных.\n\n### 2. Ответственность (`Responsibilities`)\n\nСогласно документации, этот класс выполняет следующие обязанности:\n\n- Название класса указывает на его управляющую природу.\n- Координирует вызов ролей (ролей-подзадач) — всего их четыре.\n- Читает и записывает состояния атрибутов.\n- Участвует в разделах потока данных (dataflow slices).\n\nЭти обязанности подчеркивают важность этого компонента для управления последовательностью выполнения задач в системе.\n\n---\n\n### 3. Поток данных и архитектура\n\n#### a. Участие в данных потока (`dataflow slices`)\n\nДокументация указывает, что данный класс участвует в нескольких разрезах данных (slices). Это означает, что он играет ключевую роль в координации передачи информации между различными частями системы.\n\n#### b. Чтение и запись состояний атрибутов\n\nЭтот класс также активно взаимодействует с состоянием системы, читая и изменяя определенные атрибуты, что важно для поддержания согласованности данных и корректного функционирования системы.\n\n---\n\n### 4. Примеры использования и роли компонентов\n\n#### a. Контрольные каналы (`ControlChannel`, `ControlActionSet`)\n\n- `ControlChannel`: Стандартная модельный канал управления.\n- `ControlActionSet`: Набор действий модели.\n\nЭти компоненты обеспечивают механизм взаимодействия между различными ролями и стадиями процесса исполнения.\n\n#### b. Сервисы контроля (`ControlPlaneService`, `UvicornThreadRunner`)\n\n- `ControlPlaneService`: Обслуживает операции чтения и записи состояний атрибутов и принимает участие в пяти разрезах данных.\n- `UvicornThreadRunner`: Этот сервис используется для запуска HTTP-серверов через uvicorn в отдельном потоке и участвует в двадцати четырех разрезах данных.\n\nЭти сервисы являются частью общей инфраструктуры управления исполнением задач и участвуют в процессе обработки запросов пользователей.\n\n---\n\n### 5. Итоговое описание работы класса `RuntimeManager`\n\nКласс `RuntimeManager` является ключевым компонентом управляющей архитектуры приложения. Он отвечает за координацию вызова различных ролей или подзадач в системе, обеспечивая синхронизацию и последовательность операций. При этом он активно взаимодействует со своими окружающими компонентами (например, каналами управления, серверами, сервисами и др.), участвуя в обработке данных потоков и поддерживая целостность состояния системы.\n\nТаким образом, основная задача данного класса заключается в управлении логикой и последовательностью выполнения всех этапов обработки данных и взаимодействий с другими компонентами системы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "RuntimeManager"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-trace-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Как работает TraceService?
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 21,
+  "llm_answer": "## Анализ архитектуры и поведения `TraceService`\n\n### 1. Описание `TraceService`\n`TraceService` — это класс, представляющий собой сервисную компоненту приложения, которая участвует в управлении трассировкой выполнения различных процессов внутри системы. Он наследует от класса `TraceContextFactory`, что указывает на его ответственность за создание и управление контекстом трассировки.\n\n### 2. Роли и обязанности компонента\nВ рамках общей архитектуры компонентов системы, `TraceService` играет роль `pipeline_stage`. Это означает, что он является одним из этапов общего конвейера обработки данных или задач в системе. \n\n#### Основные обязанности:\n- **Чтение и запись состояния атрибутов**: Взаимодействие с состоянием приложения через чтение и запись атрибутов.\n- **Участие в разделах потока данных**: Указано, что данный компонент участвует в 13 разных разделах потоков данных. Эти потоки данных являются частями общего процесса выполнения задач или работы сервиса.\n\n### 3. Место в общей архитектуре\n- **Связь с другими компонентами**:\n  - `UvicornThreadRunner`: отвечает за запуск HTTP-сервера и выполнение запросов. Имеет аналогичную роль и обязанности как у `TraceService`.\n  - `WorkflowPersistence`: ответственен за оркестровку вызовов ролей и участие в потоках данных (участвует в 16 разделах).\n  - `HttpControlChannel`: занимается управлением каналами HTTP-контроля и взаимодействием с ними.\n  - `InMemoryTaskQueue`: управляет очередями задач и их выполнением.\n\nВсе перечисленные компоненты являются частью единого конвейера обработки и участвуют в общих процессах обмена данными и управления задачами.\n\n### 4. Поток данных\nПотоки данных описывают последовательность операций и шагов, которые выполняются системой для достижения определенного результата. Участие каждого компонента в этих потоках обеспечивает целостность и согласованность всей системы при выполнении задач.\n\n### Итоговое объяснение работы `TraceService`\n\n`TraceService` является специализированным компонентом системы, отвечающим за управление контекстом трассировки и участие в общем потоке данных. Его основная задача — обеспечивать корректное отслеживание и ведение контекста выполнения задач, обеспечивая прозрачность и возможность анализа этих задач.\n\nЭтот компонент интегрируется в общую инфраструктуру системы, участвуя в нескольких потоках данных, обеспечивая согласованное взаимодействие между различными компонентами системы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "TraceService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091314/summary.md
@@ -0,0 +1,24 @@
+# pipeline_setup_v2 summary
+
+Passed: 6/6
+
+
+| File                                | Case                                         | Runner  | Mode       | Intent  | Sub-intent | Pass |
+| ----------------------------------- | -------------------------------------------- | ------- | ---------- | ------- | ---------- | ---- |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager       | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel  | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-trace-service         | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-create-runtime        | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-workflow-engine       | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+
+
+## LLM Answers
+
+- **plba-fullchain-explain-runtime-manager**: ## Анализ класса `RuntimeManager` ### 1. Положение и назначение класса Класс `RuntimeManager` определен в файле `src/app_runtime/core/runtime.py`. Его роль — **управляющий компонент**, который координирует выполнение ра…
+- **plba-fullchain-explain-http-control-channel**: ## Анализ класса `HttpControlChannel` ### 1. Обзор файла и контекста Класс `HttpControlChannel` определен в файле `src/app_runtime/control/http_channel.py`. Этот файл содержит классы и функции, связанные с управлением к…
+- **plba-fullchain-explain-control-plane-service**: ## Анализ класса `ControlPlaneService` ### Описание файла и роли классов Файл `**src/app_runtime/control/service.py`** содержит определение класса `ControlPlaneService`. Этот файл также импортирует классы и компоненты и…
+- **plba-fullchain-explain-trace-service**: ## Анализ архитектуры и поведения `TraceService` ### 1. Описание `TraceService` `TraceService` — это класс, представляющий собой сервисную компоненту приложения, которая участвует в управлении трассировкой выполнения ра…
+- **plba-fullchain-explain-create-runtime**: ## Анализ функции `create_runtime` и архитектуры приложения ### Описание функции `create_runtime` Функция `create_runtime` расположена в файле `src/plba/bootstrap.py`. Её основная задача — инициализация и настройка runt…
+- **plba-fullchain-explain-workflow-engine**: ## Архитектура и Поведение Workflow Engine ### Описание класса `WorkflowEngine` `WorkflowEngine` является ключевым компонентом системы управления рабочими процессами или workflows в приложении. Этот компонент отвечает з…
+
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `ControlPlaneService`\n\n### Обзор контекста\n\nВ рамках данного контекста обсуждаются несколько сущностей и их роли в системе обработки запросов и управления состоянием:\n\n- **`ControlPlaneService`**: Основной объект, рассматриваемый в вопросе.\n- **`ControlChannel`**: Базовый интерфейс для моделей или каналов взаимодействия.\n- **`ControlActionSet`**: Набор действий, выполняемых моделью.\n- **`UvicornThreadRunner`**: Класс, отвечающий за запуск HTTP-сервера с использованием библиотеки uvicorn в отдельном потоке.\n- **`HttpControlChannel`**: Канал контроля на основе HTTP, который также участвует в обработке состояния и данных потока.\n\nВсе перечисленные классы являются частью модуля `src/app_runtime/control`, что указывает на их связь с управлением данными и обработкой состояний в приложении.\n\n### Описание поведения и архитектуры\n\n**Класс `ControlPlaneService`:**\n\nЭтот класс является ключевым элементом в управлении поведением системы на уровне \"контроля\" (\"Control Plane\"). Он отвечает за чтение и запись атрибутов состояния приложения и взаимодействие с различными компонентами через каналы и действия.\n\n#### Основные обязанности (`Responsibilities`):\n\n1. **Чтение и запись атрибутов состояния:** \n   - Класс хранит и управляет текущим состоянием системы и может изменять его в зависимости от поступающих запросов и событий.\n   \n2. **Участие в данных потоков (`dataflow slices`) :**\n   - Указано участие в пяти различных срезах данных, которые могут быть связаны с различными аспектами работы системы (например, обработка запросов, выполнение вычислений, управление логикой бизнес-процессов).\n\n#### Поток данных и логика выполнения\n\nПоскольку конкретные детали реализации не предоставлены, можно предположить следующий общий сценарий функционирования `ControlPlaneService`:\n\n1. Получение запроса извне (через HTTP или другой канал).\n2. Валидация и преобразование входных данных.\n3. Вызов соответствующих методов или действий из объекта `ControlActionSet`.\n4. Запись изменений состояния системы (если это необходимо) и передача информации обратно пользователю.\n\n### Заключение\n\nТаким образом, `ControlPlaneService` играет роль центрального контроллера, координирующего работу различных компонентов системы через свои интерфейсы (каналы и действия). Его основная задача — обеспечивать согласованность и корректность изменения состояния системы в ответ на внешние запросы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 19,
+  "llm_answer": "## Анализ класса `HttpControlChannel`\n\n### Файл и путь:\n- **Файл:** `src/app_runtime/control/http_channel.py`\n- **Класс:** `HttpControlChannel`\n\n### Описание роли и ответственности:\n- **Роль:** `pipeline_stage`\n- **Ответственности:**\n  - Чтение и запись атрибутов состояния (`reads and writes state attributes`).\n  - Участие в \"слайсах\" данных потока (`participates in dataflow slices`).\n    - В документации указано участие в 10 слайсах данных.\n\n### Родительский класс:\n- Наследуется от класса `ControlChannel`, объявленного в файле `src/app_runtime/control/base.py`.\n  \n### Подразумеваемая архитектура и поток данных:\n1. **Родительская сущность** (`ControlChannel`) является базовой моделью для каналов управления, определяющей основные обязанности модели.\n   - Пример: Класс может иметь стандартный набор методов или атрибутов, которые наследуются всеми дочерними сущностями.\n   \n2. **Дочерний класс** (`HttpControlChannel`) расширяет функциональность родительского класса, добавляя специфические обязанности HTTP-канала.\n   - Обеспечивает взаимодействие с HTTP протоколом, вероятно, через асинхронные HTTP запросы и ответы.\n\n3. **Участие в данныхфлоу**:\n   - Согласно описанию, канал участвует в 10 различных слайсах данных. Это означает, что он обрабатывает части общего потока данных, разделенного на несколько сегментов (\"слайсов\"). \n   - Каждый сегмент предназначен для определенной стадии обработки информации внутри системы.\n\n4. **Связь с другими компонентами**:\n   - Контроллер взаимодействует с сервисом контроля (`ControlPlaneService`), который также упоминается как `pipeline_stage`. Вероятно, это указывает на то, что контроллер совместно с этим сервисом управляет состоянием и потоком данных между различными стадиями обработки.\n\n### Возможное внутреннее устройство и реализация:\n- Возможно наличие методов чтения и записи атрибутов состояния, а также механизмов отправки и получения сообщений через HTTP-запросы и ответы.\n- Вероятно, присутствуют методы инициализации и конфигурации канала.\n- Поскольку указано, что участвует в нескольких слайсах данных, предполагается наличие инфраструктуры для поддержки параллельного выполнения задач и передачи данных между ними.\n\n### Заключение:\nКанал управления `HttpControlChannel` реализует механизм взаимодействия с HTTP-протоколом, отвечая за чтение и запись состояний и участвуя в передаче данных между стадиями обработки данных. Он наследует базовые принципы поведения от родительской сущности `ControlChannel`, обеспечивая специализированную функциональность для работы с HTTP-соединениями и потоками данных.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-workflow-engine
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс WorkflowEngine
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 20,
+  "llm_answer": "## Анализ архитектуры и поведения класса `WorkflowEngine`\n\n### 1. Описание файла и роли классов\n\n#### Файл: `src/app_runtime/workflow/engine/workflow_engine.py`\nВ данном файле находится определение класса **`WorkflowEngine`**, который играет ключевую роль в управлении workflow-приложением.\n\n### 2. Структура класса `WorkflowEngine`\n\n```python\nclass WorkflowEngine:\n    # Конструктор класса с инициализацией атрибутов\n    def __init__(self):\n        self._hooks = WorkflowEngineHooks()\n        self.transition_resolver = TransitionResolver()\n    \n    # Метод для запуска workflow\n    async def run(self):\n        pass\n\n    # Метод для добавления новых хуков\n    def add_hooks(self, hooks):\n        self._hooks.add(hooks)\n```\n\n### 3. Ответственность и взаимодействие\n\n**Ответственности (`Responsibilities`) класса:**\n- Чтение и запись состояния атрибутов\n- Участие в потоках данных (dataflow slices)\n\n**Роль класса (`role`):**\n- pipeline_stage\n\n**Связанные классы и их роли:**\n- `WorkflowEngineHooks`: модель (`model`), отвечает за обработку событий или действий связанных с жизненным циклом workflow.\n- `TransitionResolver`: модель (`model`), решает переходы между стадиями workflow.\n- `UvicornThreadRunner`: pipeline_stage, используется для выполнения HTTP-запросов и взаимодействия с API.\n\n### 4. Поток данных и структура работы класса\n\nПри запуске метода `run()` происходит следующее:\n1. Инициализация внутренних объектов.\n2. Вызов методов соответствующих стадий и переходов внутри workflow.\n3. Выполнение хуков, зарегистрированных через метод `add_hooks()`.\n\n### 5. Пример использования класса\n\n```python\n# Создание экземпляра WorkflowEngine\nengine = WorkflowEngine()\n\n# Добавление пользовательских хуков\ncustom_hooks = {\n    \"before_start\": lambda: print(\"Before start\"),\n    \"after_end\": lambda: print(\"After end\")\n}\nengine.add_hooks(custom_hooks)\n\n# Запуск workflow\nawait engine.run()\n```\n\n### Заключение\n\nКласс `WorkflowEngine` является центральным компонентом управления workflow-приложением. Он управляет состоянием приложения, взаимодействует с внешними сервисами и обеспечивает логику перехода между стадиями workflow при помощи встроенных хуков и решений переходов. Использование данного класса позволяет легко расширять функциональность путем регистрации дополнительных хуков и модификации стандартных потоков данных.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "WorkflowEngine"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_091824/summary.md
@@ -0,0 +1,24 @@
+# pipeline_setup_v2 summary
+
+Passed: 6/6
+
+
+| File                                | Case                                         | Runner  | Mode       | Intent  | Sub-intent | Pass |
+| ----------------------------------- | -------------------------------------------- | ------- | ---------- | ------- | ---------- | ---- |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager       | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel  | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-trace-service         | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-create-runtime        | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-workflow-engine       | runtime | full_chain | CODE_QA | EXPLAIN    | ✓    |
+
+
+## LLM Answers
+
+- **plba-fullchain-explain-runtime-manager**: ## Анализ класса `RuntimeManager` ### 1. Общая информация о классе Класс `RuntimeManager` находится в файле `src/app_runtime/core/runtime.py`. Его роль обозначена как **pipeline_stage**, что указывает на его участие в потоке выполнения программы. ### 2. Ответственность (`Responsibilities`) Документация описывает следующие обязанности класса: - **manager**: предполагает управление другими сущностями или ресурсами; - **orchestrates role-like calls (4)**: означает координацию вызовов различных ролей или этапов; - **reads and writes state attributes**: указывает на возможность чтения и записи атрибутов состояния системы; - **participates in dataflow slices (50)**: свидетельствует об участии в разделении потоков данных. Эти обязанности отражают высокоуровневую роль управления состоянием и потоком выполнения приложения. ### 3. Поток данных и взаимодействие с другими компон…
+- **plba-fullchain-explain-http-control-channel**: ## Анализ класса `HttpControlChannel` ### Файл и путь: - **Файл:** `src/app_runtime/control/http_channel.py` - **Класс:** `HttpControlChannel` ### Описание роли и ответственности: - **Роль:** `pipeline_stage` - **Ответственности:** - Чтение и запись атрибутов состояния (`reads and writes state attributes`). - Участие в "слайсах" данных потока (`participates in dataflow slices`). - В документации указано участие в 10 слайсах данных. ### Родительский класс: - Наследуется от класса `ControlChannel`, объявленного в файле `src/app_runtime/control/base.py`. ### Подразумеваемая архитектура и поток данных: 1. **Родительская сущность** (`ControlChannel`) является базовой моделью для каналов управления, определяющей основные обязанности модели. - Пример: Класс может иметь стандартный набор методов или атрибутов, которые наследуются всеми дочерними сущностями. 2. **Дочерний кла…
+- **plba-fullchain-explain-control-plane-service**: ## Анализ класса `ControlPlaneService` ### Обзор контекста В рамках данного контекста обсуждаются несколько сущностей и их роли в системе обработки запросов и управления состоянием: - `**ControlPlaneService`**: Основной объект, рассматриваемый в вопросе. - `**ControlChannel**`: Базовый интерфейс для моделей или каналов взаимодействия. - `**ControlActionSet**`: Набор действий, выполняемых моделью. - `**UvicornThreadRunner**`: Класс, отвечающий за запуск HTTP-сервера с использованием библиотеки uvicorn в отдельном потоке. - `**HttpControlChannel**`: Канал контроля на основе HTTP, который также участвует в обработке состояния и данных потока. Все перечисленные классы являются частью модуля `src/app_runtime/control`, что указывает на их связь с управлением данными и обработкой состояний в приложении. ### Описание поведения и архитектуры **Класс `ControlPlaneService`:** Э…
+- **plba-fullchain-explain-trace-service**: ## Анализ архитектуры и поведения `TraceService` ### Описание класса `TraceService` Класс `TraceService` определен в файле `src/app_runtime/tracing/service.py`. Этот класс является наследником абстрактного базового класса `TraceContextFactory`, что указывает на его ключевую роль в создании контекста трассировки (`trace context`) для последующих вызовов API или логики приложения. #### Обязанности класса: - Обладает именем с суффиксом "service", указывающим на его сервисную природу. - Оперирует состоянием атрибутов через чтение и запись их значений. - Участвует в передаче данных между различными этапами обработки ("dataflow slices"). #### Поведение метода `_create_trace_context` Метод `_create_trace_context` создает новый контекст трассировки, который используется для отслеживания выполнения различных этапов программы. Контекст трассировки включает информацию о текущей…
+- **plba-fullchain-explain-create-runtime**: ## Анализ функции `create_runtime` и архитектуры приложения ### Описание задачи Функция `create_runtime` отвечает за инициализацию и настройку runtime окружения для приложения. Она является ключевым компонентом начальной загрузки системы и участвует в формировании конфигурации и окружения для дальнейшей работы. ### Поток данных и архитектура Архитектура приложения организована вокруг нескольких компонентов, которые взаимодействуют между собой через определенные роли (`pipeline_stage`) и участвуют в различных фазах жизненного цикла приложения: 1. **ConfigFileLoader** - Роль: pipeline_stage - Ответственность: чтение и запись состояния атрибутов; участие в данных потока (dataflow slice 8) Этот компонент загружает конфигурацию из файла, что позволяет системе настраиваться на основе внешних параметров. 2. **WorkflowPersistence** - Роль: pipeline_stage - Ответственность: о…
+- **plba-fullchain-explain-workflow-engine**: ## Анализ архитектуры и поведения класса `WorkflowEngine` ### 1. Описание файла и роли классов #### Файл: `src/app_runtime/workflow/engine/workflow_engine.py` В данном файле находится определение класса `**WorkflowEngine`**, который играет ключевую роль в управлении workflow-приложением. ### 2. Структура класса `WorkflowEngine` `python class WorkflowEngine: # Конструктор класса с инициализацией атрибутов def __init__(self): self._hooks = WorkflowEngineHooks() self.transition_resolver = TransitionResolver() # Метод для запуска workflow async def run(self): pass # Метод для добавления новых хуков def add_hooks(self, hooks): self._hooks.add(hooks)`  ### 3. Ответственность и взаимодействие **Ответственности (`Responsibilities`) класса:** - Чтение и запись состояния атрибутов - Участие в потоках данных (dataflow slices) **Роль класса (`role`):** - pipeline_stage **Свя…
+
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Назначение\n\n`ControlPlaneService` — это сущность, отвечающая за управление каналами (`ControlChannel`) и координацию действий по запуску и остановке различных компонентов системы. Этот сервис играет роль `pipeline_stage`, что указывает на его участие в конвейере обработки данных или управлении состоянием приложения.\n\n## Ключевые зависимости\n\n### Файлы и сущности\n- **src/app_runtime/control/service.py**: местоположение определения класса `ControlPlaneService`.\n- Используется библиотека **asyncio** для асинхронного выполнения задач.\n\n### Внешние зависимости\n- `RuntimeManager`: менеджер управления рабочим окружением и состоянием приложения.\n- `ControlChannel`: каналы взаимодействия с внешними компонентами или службами.\n- `ControlActionSet`: набор действий, которые могут быть выполнены при старте или останове сервиса.\n\n## Поток данных или вызовов\n\n1. **Инициализация и регистрация каналов**\n   - Конструктор `__init__` инициализирует пустой список `_channels` и создаёт пустую коллекцию каналов.\n   - Метод `register_channel` добавляет новый канал в список.\n   \n2. **Запуск сервиса**\n   - Метод `start` проверяет наличие зарегистрированных каналов и вызывает асинхронную функцию `_start_async`.\n   - Внутри `_start_async` выполняется выполнение действий через объект `ControlActionSet`. Эти действия включают старт и останов рабочих процессов, проверку текущего состояния здоровья (`health_status`), а также запуск самого рабочего окружения (`start_runtime`).\n\n3. **Остановка сервиса**\n   - Метод `stop` аналогично проверяет наличие каналов и вызывает асинхронную функцию `_stop_async`, которая выполняет очистку ресурсов и завершение работы всех каналов.\n\n4. **Создание снимка состояния**\n   - Метод `snapshot` собирает информацию о текущем состоянии приложения, включая рабочие процессы, модули, сервисы, состояние работников, текущее здоровье и конфигурационные параметры.\n\n## Важные детали реализации\n\n1. **Асинхронность операций**\n   - Использование функций `asyncio.run()` внутри методов `_start_async` и `_stop_async` позволяет выполнять задачи асинхронно, что важно для высокопроизводительных систем.\n\n2. **Состояние и конфигурация**\n   - Объект `RuntimeManager` хранит текущие данные о состоянии приложения и конфигурации, что используется для создания снимков состояния и проверки текущих статусов.\n\n3. **Сообщения об ошибках**\n   - Если каналы отсутствуют, метод `start` и `stop` просто возвращают без выполнения каких-либо действий.\n\n## Осторожные выводы\n\nНа основании анализа структуры зависимостей и объявлений классов можно предположить, что данный сервис является частью более крупной архитектуры и взаимодействует с другими модулями, такими как HTTP API (`app.post`) и системой регистрации модулей и сервисов (`registry.modules`). Однако прямых доказательств этого нет, поэтому данный вывод считается осторожным.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Объяснение работы класса `HttpControlChannel`\n\n### Назначение\nКласс `HttpControlChannel` является компонентом системы управления состоянием и взаимодействия с внешним миром через HTTP-протокол. Он реализует механизм обмена данными и состояниями между компонентами приложения через HTTP-запросы и ответы.\n\n### Ключевые зависимости\nКлючевыми зависимостями являются:\n- `UvicornThreadRunner`: используется для запуска асинхронного сервера на основе библиотеки Uvicorn.\n- `HttpControlAppFactory`: фабрика приложений, которая отвечает за создание экземпляров FastAPI приложения.\n- `ControlActionSet`: набор действий, связанных с управлением состоянием и поведением приложения.\n\n### Поток данных или вызовов\nПоток данных и вызовов выглядит следующим образом:\n1. **Инициализация (`__init__`)**:\n   - При создании экземпляра класса задаются параметры хоста, порта и тайм-аута.\n   - Создается объект `UvicornThreadRunner`, отвечающий за запуск асинхронного HTTP-сервера.\n   - Создается экземпляр фабрики приложений `HttpControlAppFactory`.\n   \n2. **Запуск (`start`)**:\n   - Если заданы действия (`ControlActionSet`), создается экземпляр FastAPI приложения, включающего обработчики для health и action запросов.\n   - Запускается сервер при помощи объекта `UvicornThreadRunner`.\n\n3. **Остановка (`stop`)**:\n   - Остановка запущенного сервера при помощи метода `stop()` объекта `UvicornThreadRunner`.\n\n4. **Получение статуса порта (`port`)**:\n   - Возвращает порт, на котором запущен сервер.\n\n5. **Health-запрос (`_health_response`)**:\n   - Проверяет наличие настроенных действий и возвращает статус здоровья приложения.\n\n6. **Action-запрос (`_action_response`)**:\n   - Обрабатывает запросы действий, проверяя их конфигурацию и возвращая соответствующий результат.\n\n### Важные детали реализации\n- **Таймаут (`_timeout`)**: устанавливается при инициализации и используется в методах проверки состояния здоровья и выполнения действий.\n- **Actions (`_actions`)**: набор доступных действий, определяющий функциональность приложения.\n- **FastAPI приложение**: строится динамически при каждом вызове метода `start`, что позволяет настраивать его под конкретные задачи.\n  \n### Осторожные выводы\nНа основании текущего контекста сложно однозначно утверждать, какие именно данные передаются по HTTP-протоколу, так как контекст сигнализирует о возможности работы с различными типами данных, но детальной информации об этом нет.\n\n### Итоговое объяснение\nКласс `HttpControlChannel` предназначен для организации управления состоянием и взаимодействия с приложением через HTTP-интерфейс. Он использует библиотеку Uvicorn для создания асинхронного HTTP-сервера и FastAPI для построения прикладных сервисов. Класс управляет жизненным циклом сервера, отслеживает доступные действия и предоставляет методы для получения статуса здоровья и выполнения пользовательских операций.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-runtime-manager
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни как работает класс RuntimeManager
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Назначение класса `RuntimeManager`\nКласс `RuntimeManager` предназначен для управления жизненным циклом приложения и координации различных компонентов системы во время выполнения. Он играет роль менеджера процессов и отвечает за управление состоянием приложения, регистрацию сервисов и координацию работы рабочих потоков (`workers`).\n\n## Ключевые зависимости\n- **ConfigurationManager**: Менеджер конфигурации, используется для загрузки настроек приложения.\n- **ServiceContainer**: Контейнер сервисов, содержащий различные сервисы и модули приложения.\n- **TraceService**: Сервис трассировки, собирает информацию о выполнении запросов и событиях.\n- **HealthRegistry**: Регистратор состояния здоровья системы, отслеживает состояние различных модулей и сервисов.\n- **LogManager**: Менеджер логирования, регистрирует события и ошибки.\n- **WorkerSupervisor**: Наблюдатель за рабочими процессами, управляет запуском и остановкой рабочих потоков.\n- **ControlPlaneService**: Управляет основной логикой взаимодействия с внешним миром и сервисами.\n\n## Поток данных или вызовов\nПри инициализации объекта класса `RuntimeManager`, вызывается метод `__init__`. В этом методе происходит инициализация всех указанных параметров и настройка начальных значений атрибутов экземпляра:\n\n```python\ndef __init__(self, ...):\n    # Инициализация переменных и атрибутов\n    self.configuration = ...\n    self.services = ...\n    self.traces = ...\n    self.health = ...\n    self.logs = ...\n    self.workers = ...\n    self.control_plane = ...\n    \n    # Другие действия по настройке и регистрации сервисов\n```\n\nПосле этого начинается регистрация сервисов и их модулей при помощи метода `_register_core_services`.\n\n### Важные детали реализации\n- Класс поддерживает управление несколькими основными состояниями жизненного цикла приложения через атрибуты `_state` и соответствующие методы:\n  - `LifecycleState.IDLE`: начальное состояние перед началом работы.\n  - `LifecycleState.STARTED`: активное состояние после начала работы.\n  - `LifecycleState.FAILED`: состояние после возникновения ошибки.\n  \n- При создании экземпляра класса вызываются функции `_register_core_services`, которые отвечают за подключение основных модулей и сервисов.\n\n- Метод `register_module(module)` позволяет динамически регистрировать новые модули и расширять функциональность приложения.\n\n### Осторожные выводы\nНа основе косвенных признаков можно предположить, что реализация использует механизм модульной архитектуры и разделяет логику на несколько уровней абстракции, где каждый уровень соответствует определённой части функциональности (например, конфигурация, мониторинг, контроль и рабочие процессы). Однако более детальная информация требует дополнительного анализа исходного кода.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "RuntimeManager"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-trace-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Как работает TraceService?
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 14,
+  "llm_answer": "## Объяснение работы `TraceService`\n\n### Назначение\n`TraceService` — это сервис, предназначенный для управления контекстом трассировки и записи логических событий во время выполнения программы. Он участвует в потоке данных системы, обеспечивая запись информации о каждом этапе выполнения с возможностью последующего анализа и мониторинга.\n\n### Ключевые зависимости\n- **TraceContextFactory**: Базовый класс, от которого наследуется `TraceService`. \n- **TraceTransport**: Интерфейс транспортировки данных трассировки.\n- **TraceContextStore**: Класс для хранения контекста трассировки.\n- **NoOpTraceTransport**: Специальная реализация `TraceTransport`, используемая при отсутствии реальной транспортной инфраструктуры.\n- **TraceRecordWriter**: Вспомогательный класс для записи записей трассировки в транспортную систему.\n\n### Поток данных или вызовов\n1. При инициализации (`__init__`) создается экземпляр класса `TraceRecordWriter`, который записывает записи трассировки через указанный транспорт (`TraceTransport`).\n   \n   ```python\n   def __init__(self, transport: TraceTransport | None = None, store: TraceContextStore | None = None):\n       ...\n       self._writer = TraceRecordWriter(self.transport)\n   ```\n\n2. Основной метод создания нового контекста трассировки (`create_context`) создает новую запись трассировки (`TraceContextRecord`), добавляет её в хранилище (`store`) и записывает через транспорт (`_writer`).\n\n   ```python\n   def create_context(\n       self,\n       *,\n       alias: str,\n       parent_id: str | None = None,\n       kind: str | None = None,\n       attrs: dict[str, Any] | None = None,\n   ) -> str:\n       ...\n       self.store.push(record)\n       self._writer.write_context(record)\n       return record.trace_id\n   ```\n\n3. Метод `open_context` предоставляет контекст трассировки внутри блока `with`, создавая новый контекст трассировки и возвращая идентификатор этого контекста.\n\n   ```python\n   @contextmanager\n   def open_context(\n       self,\n       *,\n       alias: str,\n       parent_id: str | None = None,\n       kind: str | None = None,\n       attrs: dict[str, Any] | None = None,\n   ) -> Iterator[str]:\n       trace_id = self.create_context(alias=alias, parent_id=parent_id, kind=kind, attrs=attrs)\n       yield trace_id\n   ```\n\n### Важные детали реализации\n- Запись сообщений трассировки осуществляется методом `_writer.write_message`.\n- Хранилище контекста трассировки используется для сохранения всех созданных записей трассировки.\n- Если транспорт недоступен или возникает ошибка при передаче сообщения, это фиксируется в журнале ошибок.\n  \n  ```python\n  class TraceRecordWriter:\n      def write_message(self, record: TraceLogMessage) -> None:\n          try:\n              self._transport.write_message(record)\n          except Exception:\n              self._logger.exception(\"Trace transport failed to write message for %s\", record.trace_id)\n  ```\n\n### Остерегайтесь выводов\nНекоторые выводы сделаны на основе косвенных признаков и предположений, основанных на доступных фрагментах кода и структуре зависимостей. Например, роль метода `_writer.write_message` точно определяется исключительно по сигнатуре и отсутствию подробных комментариев в исходном коде.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "TraceService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_112158/summary.md
@@ -0,0 +1,20 @@
+# pipeline_setup_v2 summary
+
+Passed: 6/6
+
+| File | Case | Runner | Mode | Intent | Sub-intent | Pass |
+|------|------|--------|------|--------|------------|------|
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-trace-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-create-runtime | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-workflow-engine | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+
+## LLM Answers
+- **plba-fullchain-explain-runtime-manager**: ## Назначение класса `RuntimeManager` Класс `RuntimeManager` предназначен для управления жизненным циклом приложения и координации различных компонентов системы во время выполнения. Он играет роль менеджера процессов и отвечает за управление состоянием приложения, регистрацию сервисов и координацию работы рабочих потоков (`workers`). ## Ключевые зависимости - **ConfigurationManager**: Менеджер конфигурации, используется для загрузки настроек приложения. - **ServiceContainer**: Контейнер сервисов, содержащий различные сервисы и модули приложения. - **TraceService**: Сервис трассировки, собирает информацию о выполнении запросов и событиях. - **HealthRegistry**: Регистратор состояния здоровья системы, отслеживает состояние различных модулей и сервисов. - **LogManager**: Менеджер логирования, регистрирует события и ошибки. - **WorkerSupervisor**: Наблюдатель за рабочими…
+- **plba-fullchain-explain-http-control-channel**: ## Объяснение работы класса `HttpControlChannel` ### Назначение Класс `HttpControlChannel` является компонентом системы управления состоянием и взаимодействия с внешним миром через HTTP-протокол. Он реализует механизм обмена данными и состояниями между компонентами приложения через HTTP-запросы и ответы. ### Ключевые зависимости Ключевыми зависимостями являются: - `UvicornThreadRunner`: используется для запуска асинхронного сервера на основе библиотеки Uvicorn. - `HttpControlAppFactory`: фабрика приложений, которая отвечает за создание экземпляров FastAPI приложения. - `ControlActionSet`: набор действий, связанных с управлением состоянием и поведением приложения. ### Поток данных или вызовов Поток данных и вызовов выглядит следующим образом: 1. **Инициализация (`__init__`)**: - При создании экземпляра класса задаются параметры хоста, порта и тайм-аута. - Создается об…
+- **plba-fullchain-explain-control-plane-service**: ## Назначение `ControlPlaneService` — это сущность, отвечающая за управление каналами (`ControlChannel`) и координацию действий по запуску и остановке различных компонентов системы. Этот сервис играет роль `pipeline_stage`, что указывает на его участие в конвейере обработки данных или управлении состоянием приложения. ## Ключевые зависимости ### Файлы и сущности - **src/app_runtime/control/service.py**: местоположение определения класса `ControlPlaneService`. - Используется библиотека **asyncio** для асинхронного выполнения задач. ### Внешние зависимости - `RuntimeManager`: менеджер управления рабочим окружением и состоянием приложения. - `ControlChannel`: каналы взаимодействия с внешними компонентами или службами. - `ControlActionSet`: набор действий, которые могут быть выполнены при старте или останове сервиса. ## Поток данных или вызовов 1. **Инициализация и регис…
+- **plba-fullchain-explain-trace-service**: ## Объяснение работы `TraceService` ### Назначение `TraceService` — это сервис, предназначенный для управления контекстом трассировки и записи логических событий во время выполнения программы. Он участвует в потоке данных системы, обеспечивая запись информации о каждом этапе выполнения с возможностью последующего анализа и мониторинга. ### Ключевые зависимости - **TraceContextFactory**: Базовый класс, от которого наследуется `TraceService`. - **TraceTransport**: Интерфейс транспортировки данных трассировки. - **TraceContextStore**: Класс для хранения контекста трассировки. - **NoOpTraceTransport**: Специальная реализация `TraceTransport`, используемая при отсутствии реальной транспортной инфраструктуры. - **TraceRecordWriter**: Вспомогательный класс для записи записей трассировки в транспортную систему. ### Поток данных или вызовов 1. При инициализации (`__init__`) с…
+- **plba-fullchain-explain-create-runtime**: ## Объяснение функции `create_runtime` ### Назначение Функция `create_runtime` предназначена для инициализации и настройки окружения выполнения приложения (`runtime`), используя параметры конфигурации и дополнительные опции управления HTTP-интерфейсом. ### Ключевые зависимости Функция зависит от следующих компонентов и библиотек: - **`RuntimeManager`** — главный менеджер окружения выполнения, регистрирующий модули и настраивающий каналы управления. - **`ApplicationModule`** — модуль приложения, подлежащий регистрации в менеджере среды выполнения. - **`HttpControlChannel`** — канал управления, обеспечивающий взаимодействие с внешним интерфейсом через HTTP. ### Поток данных или вызовов 1. Создаётся экземпляр менеджера окружения выполнения (`RuntimeManager`) и передаётся в возвращаемое значение. 2. Если указан путь к файлу конфигурации (`config_path`), файл добавляется…
+- **plba-fullchain-explain-workflow-engine**: ## Объяснение сущности `WorkflowEngine` ### Назначение Класс `WorkflowEngine` является основным компонентом конвейера выполнения рабочих процессов (`workflow`) в приложении. Он отвечает за управление жизненным циклом рабочего процесса, отслеживание состояния его выполнения и взаимодействие с внешними хранилищами данных для сохранения прогресса выполнения. ### Ключевые зависимости - **workflow**: определение рабочего процесса, включая начальные и конечные узлы, а также переходы между ними. - **persistence**: механизм хранения информации о текущем состоянии выполнения рабочего процесса. - **traces**: логирование и мониторинг текущего состояния выполнения. - **hooks**: дополнительные пользовательские обработчики событий, позволяющие расширять поведение рабочего процесса. ### Поток данных или вызовов 1. При инициализации класса вызывается метод `__init__`, который приним…
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Объяснение сущности `ControlPlaneService`\n\n### Назначение\n`ControlPlaneService` — это сервисная сущность, ответственная за управление каналами (`ControlChannel`) и выполнение действий по управлению жизненным циклом приложения, таких как запуск, остановка и мониторинг состояния системы.\n\n### Ключевые зависимости\n- **`ControlChannel`**: Канал управления, через который передаются сообщения о событиях и действиях.\n- **`RuntimeManager`**: Менеджер выполнения среды исполнения, содержащий состояние и другие объекты для работы с приложением.\n- **`ControlActionSet`**: Набор действий, которые могут быть выполнены при управлении состоянием системы.\n\n### Поток данных или вызовов\n1. **Инициализация** (`__init__`)  \n   - Инициализирует пустой список каналов `_channels`.\n   \n2. **Регистрация канала** (`register_channel`)  \n   - Добавляет новый канал в список зарегистрированных каналов.\n\n3. **Запуск сервиса** (`start`)  \n   - Проверяет наличие зарегистрированных каналов. Если каналы присутствуют, вызывается асинхронная функция `_start_async`, которая выполняет следующие действия:\n     - Вызывает метод `health_status` для получения текущего статуса здоровья системы.\n     - Запускает приложение через метод `start_runtime`.\n     \n4. **Остановка сервиса** (`stop`)  \n   - Аналогично проверяет наличие каналов и вызывает асинхронную функцию `_stop_async` для остановки всех запущенных процессов.\n\n5. **Создание снимка состояния** (`snapshot`)  \n   - Собирает информацию о текущем состоянии системы, включая конфигурацию, модули, сервисы, работников и здоровье.\n\n6. **Асинхронные методы**  \n   - Асинхронные функции (`_start_async`, `_stop_async`) используются для выполнения длительных операций без блокировки основного потока программы.\n\n### Важные детали реализации\n- **Использование `asyncio.run()`**: Методы `start` и `stop` используют синхронный вызов асинхронных функций через `asyncio.run()`. Это необходимо для корректного завершения асинхронных задач.\n- **Декларативность**: Класс следует принципу декларативности, позволяя разработчикам легко регистрировать новые каналы и управлять ими через стандартные интерфейсы.\n- **Гибкость**: Возможность расширения функциональности через добавление новых методов и атрибутов в будущем.\n\n### Осторожные выводы\n- Детали взаимодействия с внешними компонентами, такими как `FastAPI HTTP POST` и другие внешние точки входа, основаны исключительно на анализе сигнатур и косвенных признаков.\n\n### Путь к файлу и имя сущности\n- Файл: `src/app_runtime/control/service.py`\n- Имя класса: `ControlPlaneService`",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-create-runtime
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни функцию create_runtime
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Функциональное назначение сущности `create_runtime`\nФункция `create_runtime` предназначена для инициализации и настройки окружения выполнения (`runtime environment`) приложения. Она создает объект типа `RuntimeManager`, регистрирует указанный модуль (`module`) и при необходимости добавляет конфигурационные файлы и каналы управления через HTTP.\n\n## Ключевые зависимости\n- **src/plba/bootstrap.py**: основной файл, содержащий реализацию функции `create_runtime`.\n- **RuntimeManager**: класс, управляющий состоянием и функциональностью runtime-среды.\n- **ApplicationModule**: абстрактный тип модуля приложения, передаваемый в функцию.\n- **HttpControlChannel**: компонент, обеспечивающий управление приложением по HTTP с заданными параметрами хоста, порта и тайм-аута.\n\n## Поток данных или вызовов\n1. Функция `create_runtime` принимает несколько аргументов:\n   - `module`: экземпляр класса `ApplicationModule`, представляющий модуль приложения.\n   - Дополнительные параметры конфигурации, такие как путь к файлу конфигурации (`config_path`), включение HTTP-контроля (`enable_http_control`), хост и порт для HTTP-канала управления, а также таймаут запроса.\n   \n2. Внутри функции происходит следующее:\n   - Создается новый объект `RuntimeManager`.\n   - Если указан параметр `config_path`, вызывается метод `add_config_file` объекта `runtime`, чтобы добавить указанный файл конфигурации.\n   - При включенном HTTP-контроле регистрируется канал управления `HttpControlChannel` с заданными параметрами.\n   - Вызовом метода `register_module` экземпляра `runtime` добавляется переданный модуль приложения.\n\n3. После завершения всех операций функция возвращает созданный объект `RuntimeManager`.\n\n## Важные детали реализации\n1. **Параметры вызова**:\n   - Параметр `config_path` позволяет указать путь к файлу конфигурации, который затем загружается и используется runtime-менеджером.\n   - Параметр `enable_http_control` определяет необходимость регистрации канала управления HTTP, позволяющего взаимодействовать с приложением удаленно.\n\n2. **Использование внешних классов и объектов**:\n   - Использование класса `RuntimeManager` для управления runtime-средой.\n   - Применение класса `HttpControlChannel` для организации каналов управления через HTTP.\n\n3. **Роль `pipeline_stage`**:\n   - Как отмечено в описании семантических ролей (`C4_SEMANTIC_ROLES`), данная сущность участвует в данных потоках (`dataflow slices`), но ее основная роль заключается в управлении состоянием и настройке runtime-среды.\n\n## Осторожные выводы\nНа основании доступного контекста сложно однозначно утверждать о точном потоке данных внутри runtime-среды после создания runtime. Косвенные признаки указывают на возможное взаимодействие с внешними сервисами или ресурсами, однако конкретная реализация этих взаимодействий вне данного контекста остается неизвестной.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "create_runtime"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-http-control-channel.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-http-control-channel
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс HttpControlChannel
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Объяснение сущности `HttpControlChannel`\n\n### Назначение\nКласс `HttpControlChannel` является компонентом конвейера приложения, ответственным за управление состоянием через HTTP-запросы. Он участвует в обработке запросов к приложению, обеспечивает маршрутизацию и выполнение действий, связанных с управлением состояниями и конфигурацией системы.\n\n### Ключевые зависимости\n- **host**: строка, представляющая хост для сервера.\n- **port**: целое число, представляющее порт для сервера.\n- **timeout**: целое число, задающее таймаут выполнения операций.\n\n### Поток данных или вызовов\n1. **Инициализация (`__init__`)**  \n   - При создании экземпляра класса происходит инициализация полей `_timeout`, `_runner` и `_factory`. Поле `_runner` представляет собой объект типа `UvicornThreadRunner`, отвечающий за запуск веб-сервера на указанном хосте и порте. Поле `_factory` отвечает за создание экземпляра `HttpControlAppFactory`.\n   \n2. **Запуск (`start`)**  \n   - Метод принимает параметр `actions`, содержащий набор действий управления. Далее создается экземпляр приложения `app` при помощи фабрики `_factory`, после чего приложение запускается методом `_runner.start()`.\n   \n3. **Остановка (`stop`)**  \n   - Остановка работы серверного приложения выполняется вызовом метода `_runner.stop()`.\n   \n4. **Получение порта (`port`)**  \n   - Возвращает номер порта, на котором запущен сервер.\n\n5. **Ответы на запросы о здоровье и действиях**  \n   - Для запроса о состоянии здоровья вызывается метод `_health_response`, возвращающий статус системы (\"здорово\" или \"нездорово\"). Если действия конфигурации отсутствуют, возвращается сообщение об ошибке.\n   - Для ответа на запрос о выполнении конкретных действий вызывается метод `_action_response`, проверяющий наличие необходимых действий и возвращая соответствующий результат.\n\n### Важные детали реализации\n- Использование асинхронных методов позволяет эффективно обрабатывать запросы и выполнять длительные операции без блокировки основного потока исполнения.\n- Параметр `_actions` хранит коллекцию доступных действий управления системой, что делает компонент гибким и расширяемым.\n- Конкретная реализация поведения зависит от объекта `_factory`, создавая различное поведение в зависимости от потребностей приложения.\n\n### Косвенные признаки и осторожные выводы\n- Отсутствуют явные файлы или сущности, напрямую связанные с логикой работы класса `HttpControlChannel`. Однако информация из графа зависимостей указывает на его взаимодействие с объектом `UvicornThreadRunner` и фабрикой приложений.\n- Объявления методов и свойств показывают стандартную схему взаимодействия: получение и установка атрибутов, старт и остановка сервиса, обработка запросов.\n\n---\n\nТаким образом, `HttpControlChannel` — это важный элемент инфраструктуры, обеспечивающий управляемость и доступность приложения через HTTP-интерфейс.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "HttpControlChannel"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-runtime-manager.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-runtime-manager
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни как работает класс RuntimeManager
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Назначение класса `RuntimeManager`\nКласс `RuntimeManager` играет роль центрального менеджера для управления жизненным циклом различных компонентов приложения runtime. Он отвечает за координацию и интеграцию этих компонентов, а также управляет их состоянием через атрибуты экземпляра.\n\n## Ключевые зависимости\nКлючевыми компонентами, с которыми взаимодействует `RuntimeManager`, являются:\n- `ConfigurationManager`: управление конфигурацией приложения.\n- `ServiceContainer`: контейнер сервисов, используемых приложением.\n- `TraceService`: сервис отслеживания трассировок выполнения задач.\n- `HealthRegistry`: реестр текущего состояния здоровья системы.\n- `LogManager`: менеджер логирования событий.\n- `WorkerSupervisor`: супервизор рабочих процессов.\n- `ControlPlaneService`: служба управления планом контроля выполнения задач.\n\n## Поток данных или вызовов\nПри инициализации объекта `RuntimeManager` вызывается метод `__init__`. В этом методе происходит инициализация основных атрибутов экземпляра, таких как состояние жизненного цикла (`_state`), флаг регистрации модулей (`_core_registered`) и другие внутренние переменные.\n\n### Пример вызова конструктора:\n```python\nmanager = RuntimeManager(configuration=configuration, services=services, ...)\n```\n\nПосле создания объекта `RuntimeManager` он начинает управлять жизненными циклами своих внутренних компонентов, включая регистрацию и запуск соответствующих служб. Метод `_register_core_services()` регистрирует основные сервисы, необходимые для функционирования приложения.\n\n## Важные детали реализации\n- **Атрибуты экземпляра**:\n  - `_state`: текущее состояние жизненного цикла приложения (например, IDLE, RUNNING).\n  - `_core_registered`: флаг, указывающий, зарегистрированы ли основные модули.\n  - `_workers_registered`: аналогично предыдущему, но относится к рабочим модулям.\n  \n- **Методы управления состоянием**:\n  - `start()`: инициирует выполнение всех зарегистрированных модулей.\n  - `stop()`: останавливает работу приложения и освобождает ресурсы.\n\n- **Реализация взаимодействия с внешними сервисами**:\n  Методы классов, от которых зависит `RuntimeManager`, такие как `ControlPlaneService`, используются для координации работы приложений и обеспечения бесперебойного выполнения задач.\n\n## Осторожные выводы\nНа основе предоставленного контекста сложно точно описать полный цикл выполнения задачи или взаимодействия конкретного метода класса `RuntimeManager` с другими компонентами приложения. Однако можно предположить, что реализация включает этапы инициализации, регистрации сервисов, запуска и остановки работы приложения, основанные на сигналах жизненного цикла и управлении рабочими процессами.\n\nДля более детального понимания необходимо проанализировать полные реализации методов и взаимодействие объектов внутри приложения runtime.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "RuntimeManager"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-trace-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-trace-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Как работает TraceService?
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 14,
+  "llm_answer": "## Объяснение работы `TraceService`\n\n### Назначение\n`TraceService` — это компонент, отвечающий за управление контекстом трассировки и запись логических событий во время выполнения приложения. Он служит для создания, хранения и записи трассировочных записей (`trace records`) и сообщений логирования (`log messages`), связанных с выполнением различных операций.\n\n### Ключевые зависимости\n- **TraceContextFactory**: Базовый класс, от которого наследуется `TraceService`. Предоставляет методы для управления контекстом трассировки.\n- **TraceTransport**: Интерфейс, определяющий транспорт для передачи трассировочной информации внешним системам или службам.\n- **TraceContextStore**: Хранит контексты трассировок.\n- **NoOpTraceTransport**: Специальная реализация транспорта без реальных действий, используется по умолчанию при отсутствии указания конкретного транспорта.\n\n### Поток данных или вызовов\n1. При инициализации класса `TraceService` происходит создание экземпляра `TraceRecordWriter`, который отвечает за отправку трассировочных записей через указанный транспорт.\n2. Основной метод `create_context` создаёт новый контекст трассировки с уникальным идентификатором (`trace_id`), атрибутами и временными метками, записывает его в хранилище и передаёт информацию в транспорт.\n3. Контекст трассировки можно открывать с помощью метода `open_context`, который автоматически вызывает `create_context`.\n4. После завершения операции можно записать сообщение логирования через метод `write_message`.\n5. В случае ошибок при передаче данных в транспорт вызывается метод `_logger.exception` для регистрации проблемы.\n\n### Важные детали реализации\n- **UUID для trace_id**: Используется UUID для уникального идентификатора каждой трассировки.\n- **Время события**: Каждое событие сопровождается временной меткой UTC.\n- **Запись сообщений**: Сообщения логирования могут быть записаны отдельно после завершения контекста трассировки.\n- **Логирование ошибок**: При ошибке отправки сообщения в транспорт регистрируется исключение и выводится соответствующее сообщение об ошибке.\n\n### Описание структуры файла\nФайл `src/app_runtime/tracing/service.py` содержит реализацию класса `TraceService`, а также классы `TraceRecordWriter` и другие вспомогательные компоненты.\n\n---\n\nЭтот обзор основан исключительно на предоставленных слоях анализа (C0-C4), поэтому некоторые выводы являются осторожными и требуют дополнительной проверки.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "TraceService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/full_chain_plba_code_retrieval_plba-fullchain-explain-workflow-engine.md
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/summary.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114413/summary.md
@@ -0,0 +1,20 @@
+# pipeline_setup_v2 summary
+
+Passed: 6/6
+
+| File | Case | Runner | Mode | Intent | Sub-intent | Pass |
+|------|------|--------|------|--------|------------|------|
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-runtime-manager | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-http-control-channel | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-control-plane-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-trace-service | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-create-runtime | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+| full_chain_plba_code_retrieval.yaml | plba-fullchain-explain-workflow-engine | runtime | full_chain | CODE_QA | EXPLAIN | ✓ |
+
+## LLM Answers
+- **plba-fullchain-explain-runtime-manager**: ## Назначение класса `RuntimeManager` Класс `RuntimeManager` играет роль центрального менеджера для управления жизненным циклом различных компонентов приложения runtime. Он отвечает за координацию и интеграцию этих компонентов, а также управляет их состоянием через атрибуты экземпляра. ## Ключевые зависимости Ключевыми компонентами, с которыми взаимодействует `RuntimeManager`, являются: - `ConfigurationManager`: управление конфигурацией приложения. - `ServiceContainer`: контейнер сервисов, используемых приложением. - `TraceService`: сервис отслеживания трассировок выполнения задач. - `HealthRegistry`: реестр текущего состояния здоровья системы. - `LogManager`: менеджер логирования событий. - `WorkerSupervisor`: супервизор рабочих процессов. - `ControlPlaneService`: служба управления планом контроля выполнения задач. ## Поток данных или вызовов При инициализации объек…
+- **plba-fullchain-explain-http-control-channel**: ## Объяснение сущности `HttpControlChannel` ### Назначение Класс `HttpControlChannel` является компонентом конвейера приложения, ответственным за управление состоянием через HTTP-запросы. Он участвует в обработке запросов к приложению, обеспечивает маршрутизацию и выполнение действий, связанных с управлением состояниями и конфигурацией системы. ### Ключевые зависимости - **host**: строка, представляющая хост для сервера. - **port**: целое число, представляющее порт для сервера. - **timeout**: целое число, задающее таймаут выполнения операций. ### Поток данных или вызовов 1. **Инициализация (`__init__`)** - При создании экземпляра класса происходит инициализация полей `_timeout`, `_runner` и `_factory`. Поле `_runner` представляет собой объект типа `UvicornThreadRunner`, отвечающий за запуск веб-сервера на указанном хосте и порте. Поле `_factory` отвечает за создание…
+- **plba-fullchain-explain-control-plane-service**: ## Объяснение сущности `ControlPlaneService` ### Назначение `ControlPlaneService` — это сервисная сущность, ответственная за управление каналами (`ControlChannel`) и выполнение действий по управлению жизненным циклом приложения, таких как запуск, остановка и мониторинг состояния системы. ### Ключевые зависимости - **`ControlChannel`**: Канал управления, через который передаются сообщения о событиях и действиях. - **`RuntimeManager`**: Менеджер выполнения среды исполнения, содержащий состояние и другие объекты для работы с приложением. - **`ControlActionSet`**: Набор действий, которые могут быть выполнены при управлении состоянием системы. ### Поток данных или вызовов 1. **Инициализация** (`__init__`) - Инициализирует пустой список каналов `_channels`. 2. **Регистрация канала** (`register_channel`) - Добавляет новый канал в список зарегистрированных каналов. 3. **Запу…
+- **plba-fullchain-explain-trace-service**: ## Объяснение работы `TraceService` ### Назначение `TraceService` — это компонент, отвечающий за управление контекстом трассировки и запись логических событий во время выполнения приложения. Он служит для создания, хранения и записи трассировочных записей (`trace records`) и сообщений логирования (`log messages`), связанных с выполнением различных операций. ### Ключевые зависимости - **TraceContextFactory**: Базовый класс, от которого наследуется `TraceService`. Предоставляет методы для управления контекстом трассировки. - **TraceTransport**: Интерфейс, определяющий транспорт для передачи трассировочной информации внешним системам или службам. - **TraceContextStore**: Хранит контексты трассировок. - **NoOpTraceTransport**: Специальная реализация транспорта без реальных действий, используется по умолчанию при отсутствии указания конкретного транспорта. ### Поток данны…
+- **plba-fullchain-explain-create-runtime**: ## Функциональное назначение сущности `create_runtime` Функция `create_runtime` предназначена для инициализации и настройки окружения выполнения (`runtime environment`) приложения. Она создает объект типа `RuntimeManager`, регистрирует указанный модуль (`module`) и при необходимости добавляет конфигурационные файлы и каналы управления через HTTP. ## Ключевые зависимости - **src/plba/bootstrap.py**: основной файл, содержащий реализацию функции `create_runtime`. - **RuntimeManager**: класс, управляющий состоянием и функциональностью runtime-среды. - **ApplicationModule**: абстрактный тип модуля приложения, передаваемый в функцию. - **HttpControlChannel**: компонент, обеспечивающий управление приложением по HTTP с заданными параметрами хоста, порта и тайм-аута. ## Поток данных или вызовов 1. Функция `create_runtime` принимает несколько аргументов: - `module`: экземпляр…
+- **plba-fullchain-explain-workflow-engine**: ## Назначение класса `WorkflowEngine` Класс `WorkflowEngine` является основным компонентом инфраструктуры выполнения рабочих процессов (`workflow`) в приложении. Он отвечает за координацию и управление жизненным циклом рабочего процесса, включая отслеживание текущего состояния выполнения, взаимодействие с хранилищем для сохранения промежуточных результатов и взаимодействия с внешними компонентами через логирование и трассировку. ## Ключевые зависимости ### 1. Зависимости по модулям и библиотекам - **src/app_runtime/workflow/engine/workflow_engine.py**: основной файл, содержащий определение класса `WorkflowEngine`. - **src/app_runtime/workflow/engine/hooks.py**: модуль, предоставляющий механизмы расширения функциональности через интерфейс `WorkflowEngineHooks`, позволяющий разработчикам внедрять дополнительные действия перед началом, во время выполнения и после заверш…
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-control-plane-service.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-control-plane-service
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни класс ControlPlaneService
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Объяснение сущности `ControlPlaneService`\n\n### Назначение\n`ControlPlaneService` — это сервис управления данными и состоянием приложения. Он отвечает за координацию различных каналов (`ControlChannel`) и управление жизненным циклом работы компонентов системы. Сервис также участвует в обработке срезов данных (`dataflow slices`), что указывает на его роль в общем потоке выполнения и управлении ресурсами.\n\n### Ключевые зависимости\nКлючевой зависимостью является наличие списка каналов (`_channels`), через которые осуществляется взаимодействие с компонентами системы. Важными методами являются инициализация сервиса (`__init__`), регистрация новых каналов (`register_channel`), запуск (`start`) и остановка (`stop`) сервисов, а также создание снимка текущего состояния (`snapshot`).\n\n### Поток данных или вызовов\nПри создании объекта класса вызывается метод `__init__`, который инициализирует список каналов `_channels`. Далее возможны следующие сценарии использования:\n\n1. **Регистрация канала**:\n   - Метод `register_channel` добавляет новый канал в список доступных для взаимодействия.\n   \n2. **Запуск сервиса**:\n   - Вызов метода `start` инициирует асинхронный запуск всех зарегистрированных каналов через внутренний метод `_start_async`.\n   - В рамках запуска проверяется наличие каналов и состояние системы, после чего выполняется запуск соответствующих действий.\n\n3. **Остановка сервиса**:\n   - Метод `stop` инициирует остановку всех запущенных каналов через асинхронную функцию `_stop_async`.\n\n4. **Создание снимка состояния**:\n   - Метод `snapshot` возвращает текущее состояние системы, включая информацию о здоровье и конфигурации.\n\n### Важные детали реализации\n- Использование асинхронного подхода (через `asyncio.run`) позволяет эффективно управлять параллельными задачами и каналами.\n- Состояние каналов сохраняется в виде списка объектов `ControlChannel`, каждый из которых может иметь свои специфические настройки и поведение.\n- Все действия, связанные с управлением каналами и их запуском/остановкой, выполняются синхронно внутри методов сервиса, несмотря на асинхронность вызова.\n  \n### Осторожные выводы\nНа основе предоставленных фрагментов сложно точно определить, какие именно каналы участвуют в работе сервиса и какую дополнительную логику они реализуют. Также нет информации о том, каким образом методы, указанные в сигнатуре (`health`, `start`, `stop`), связаны с конкретными действиями и какова их реализация вне данного контекста.\n\n---\n\nТаким образом, `ControlPlaneService` представляет собой ключевой элемент инфраструктуры, отвечающий за координацию работы различных каналов и системных компонентов, обеспечивая контроль над состоянием и поведением системы.",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "ControlPlaneService"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.json
--- a/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
+++ b/tests/pipeline_setup_v2/test_results/plba_full_chain/20260312_114552/full_chain_plba_code_retrieval_plba-fullchain-explain-create-runtime.md
@@ -0,0 +1,34 @@
+# plba-fullchain-explain-create-runtime
+
+- source_file: /Users/alex/Dev_projects_v2/ai driven app process/v2/agent/tests/pipeline_setup_v2/cases/suite_02_pipeline/full_chain_plba_code_retrieval.yaml
+- runner: runtime
+- mode: full_chain
+- passed: True
+
+## Query
+Объясни функцию create_runtime
+
+## Actual
+{
+  "intent": "CODE_QA",
+  "sub_intent": "EXPLAIN",
+  "graph_id": "CodeQAGraph",
+  "conversation_mode": "START",
+  "rag_count": 12,
+  "llm_answer": "## Объяснение функции `create_runtime`\n\n### Назначение\nФункция `create_runtime` предназначена для инициализации и настройки основного объекта управления (`RuntimeManager`) приложения Plba. Она создаёт экземпляр менеджера выполнения и выполняет начальную настройку, включая загрузку конфигурационных файлов и регистрацию модулей.\n\n### Ключевые зависимости\nКлючевая зависимость — объект класса `RuntimeManager`, который является основным объектом управления жизненным циклом приложения. Этот класс отвечает за управление всеми модулями и компонентами системы, включая их загрузку, конфигурирование и взаимодействие.\n\n### Поток данных или вызовов\n1. Функция принимает параметры конфигурации и определяет путь к файлу конфигурации, а также флаги включения HTTP-контроля и указания его параметров (хост, порт, таймаут).\n2. Создаётся новый экземпляр `RuntimeManager`.\n3. Если указан путь к конфигурационному файлу, он загружается с помощью метода `add_config_file` объекта `runtime`.\n4. Если включен HTTP-контроль, регистрируется соответствующий канал контроля через метод `register_channel` объекта `runtime.control_plane`.\n5. Регистрируется переданный модуль с помощью метода `register_module` объекта `runtime`.\n6. Возвращается созданный и настроенный объект `RuntimeManager`.\n\n### Важные детали реализации\n1. **Параметры конфигурации**:\n   - Параметр `config_path` указывает путь к файлу конфигурации, используемому при начальной настройке приложения.\n   - Флаг `enable_http_control` включает режим работы HTTP-контроля, определяющий возможность удалённого управления приложением.\n   \n2. **Регистрация модуля**:\n   - Метод `register_module` обеспечивает интеграцию переданного модуля в общую систему управления и запускает его обработку.\n\n3. **Чтение атрибутов и запись состояния**:\n   - В процессе создания экземпляра `RuntimeManager` происходит чтение атрибутов и настройка состояния приложения.\n\n4. **Использование сторонних библиотек и компонентов**:\n   - Используются компоненты из пакета `uvicorn` (через класс `HttpControlChannel`), что позволяет реализовать работу с HTTP-интерфейсом для удалённого управления приложением.\n\n---\n\n### Примечания\n- Описанная структура вызова методов и зависимостей построена исключительно на анализе кода и входных данных, предоставленных пользователем. \n- Это означает, что некоторые выводы являются осторожными и основаны на косвенных доказательствах (например, анализ зависимостей и потока данных).",
+  "answer_mode": "answered",
+  "path_scope": [],
+  "symbol_candidates": [
+    "create_runtime"
+  ],
+  "layers": [
+    "C1_SYMBOL_CATALOG",
+    "C0_SOURCE_CHUNKS",
+    "C4_SEMANTIC_ROLES",
+    "C2_DEPENDENCY_GRAPH",
+    "C3_ENTRYPOINTS"
+  ]
+}
+
+## Mismatches
+- none
--- a/Show More
+++ b/Show More
				`@@ -0,0 +1 @@`
				`"""Unified pipeline test harness for synthetic eval and runtime integration runs."""`
				`@@ -0,0 +1 @@`
				`"""Core contracts and orchestration for pipeline_setup_v2."""`
				`@@ -0,0 +1 @@`
				`"""Runtime-specific executors for pipeline_setup_v2."""`