165 lines
19 KiB
Markdown
165 lines
19 KiB
Markdown
# Runtime Trace: 20260414-123147-7612de47e98e
|
||
|
||
- active_rag_session_id: 343f820f-d3c7-4789-97cd-7612de47e98e
|
||
|
||
## request
|
||
```json
|
||
{
|
||
"request_id": "req_8e0720e600f94f00a2fa7ab8c12b17a3",
|
||
"session_id": "as_92c0afd4286b4863aa65b8230a07f30b",
|
||
"active_rag_session_id": "343f820f-d3c7-4789-97cd-7612de47e98e",
|
||
"process_version": "v2",
|
||
"created_at": "2026-04-14T12:31:47.039206+00:00",
|
||
"message": "Собери документацию из аналитики\n/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/order_list.md"
|
||
}
|
||
```
|
||
|
||
## process.v2
|
||
```json
|
||
{
|
||
"event": "intent_routed",
|
||
"routing_domain": "DOCS",
|
||
"intent": "DOC_UPDATE",
|
||
"subintent": "FROM_FEATURE",
|
||
"normalized_query": "Собери документацию из аналитики /Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/order_list.md",
|
||
"target_terms": [
|
||
"/users/alex/dev_projects_v2/ai"
|
||
],
|
||
"anchors": {
|
||
"entity_names": [
|
||
"Users",
|
||
"Dev_projects_v2"
|
||
],
|
||
"file_names": [
|
||
"process/v2/test_doc/features/order_list.md"
|
||
],
|
||
"endpoint_paths": [
|
||
"/users/alex/dev_projects_v2/ai"
|
||
],
|
||
"target_doc_hints": [
|
||
"/users/alex/dev_projects_v2/ai",
|
||
"users-alex-dev_projects_v2-ai",
|
||
"users-alex-dev_projects_v2-ai-endpoint",
|
||
"users-alex-dev_projects_v2-ai endpoint",
|
||
"ai",
|
||
"ai-endpoint",
|
||
"ai endpoint",
|
||
"docs/logic/telegram-notification-loop.md"
|
||
],
|
||
"matched_aliases": [],
|
||
"process_domain": null,
|
||
"process_subdomain": null,
|
||
"scope_type": "entity",
|
||
"candidate_domains": [],
|
||
"candidate_subdomains": [],
|
||
"candidate_entities": [
|
||
"list"
|
||
],
|
||
"candidate_apis": [],
|
||
"signal_types": [
|
||
"API_ENDPOINT",
|
||
"DOMAIN_ENTITY",
|
||
"LOGIC_FLOW"
|
||
]
|
||
},
|
||
"confidence": 0.9,
|
||
"routing_mode": "llm_default",
|
||
"llm_router_used": true,
|
||
"reason_short": "Запрос на сбор документации из файла аналитики, указан конкретный путь к файлу.",
|
||
"rag_session_id": "343f820f-d3c7-4789-97cd-7612de47e98e"
|
||
}
|
||
```
|
||
|
||
## process.v2.pipeline
|
||
```json
|
||
{
|
||
"event": "router_resolved",
|
||
"domain": "DOCS",
|
||
"intent": "DOC_UPDATE",
|
||
"subintent": "FROM_FEATURE",
|
||
"confidence": 0.9
|
||
}
|
||
```
|
||
|
||
## process.v2.pipeline
|
||
```json
|
||
{
|
||
"event": "anchors_extracted",
|
||
"signal_types": [
|
||
"API_ENDPOINT",
|
||
"DOMAIN_ENTITY",
|
||
"LOGIC_FLOW"
|
||
],
|
||
"endpoint_paths": [
|
||
"/users/alex/dev_projects_v2/ai"
|
||
],
|
||
"target_doc_hints": [
|
||
"/users/alex/dev_projects_v2/ai",
|
||
"users-alex-dev_projects_v2-ai",
|
||
"users-alex-dev_projects_v2-ai-endpoint",
|
||
"users-alex-dev_projects_v2-ai endpoint",
|
||
"ai",
|
||
"ai-endpoint",
|
||
"ai endpoint",
|
||
"docs/logic/telegram-notification-loop.md"
|
||
],
|
||
"matched_aliases": [],
|
||
"target_terms": [
|
||
"/users/alex/dev_projects_v2/ai"
|
||
]
|
||
}
|
||
```
|
||
|
||
## process.v2.pipeline
|
||
```json
|
||
{
|
||
"event": "alias_resolution",
|
||
"resolved_aliases": [],
|
||
"target_doc_hints": [
|
||
"/users/alex/dev_projects_v2/ai",
|
||
"users-alex-dev_projects_v2-ai",
|
||
"users-alex-dev_projects_v2-ai-endpoint",
|
||
"users-alex-dev_projects_v2-ai endpoint",
|
||
"ai",
|
||
"ai-endpoint",
|
||
"ai endpoint",
|
||
"docs/logic/telegram-notification-loop.md"
|
||
]
|
||
}
|
||
```
|
||
|
||
## workflow.v2.docs_update.from_feature_v2
|
||
```json
|
||
{
|
||
"event": "workflow_started",
|
||
"workflow_id": "v2.docs_update.from_feature_v2"
|
||
}
|
||
```
|
||
|
||
## workflow.v2.docs_update.from_feature_v2
|
||
```json
|
||
{
|
||
"event": "workflow_completed",
|
||
"workflow_id": "v2.docs_update.from_feature_v2"
|
||
}
|
||
```
|
||
|
||
## process.v2.pipeline
|
||
```json
|
||
{
|
||
"event": "answer_generated",
|
||
"answer_mode": "docs_update_changeset_v2",
|
||
"changeset_items": 3,
|
||
"apply_changeset": true
|
||
}
|
||
```
|
||
|
||
## result
|
||
```json
|
||
{
|
||
"status": "done",
|
||
"answer": "DOC_UPDATE/FROM_FEATURE v2: сформирован changeset.\n\nIssues:\n- Не найден metadata-тег analysis_id в начале аналитики.\n- Пропущен DELETE для docs/orders_web/web/ui_page/orders.ui.list.md: не найден текущий файл.\n\nTasks:\n- 6.3 create: docs/orders_pprb/pprb/api_method/orders.api.pprb.list.md [pprb | api_method]\n- 6.2 create: docs/orders_ufs/ufs/api_method/orders.api.ufs.list.md [ufs | api_method]\n- 6.4 create: docs/orders_ufs/ufs/logic_block/orders.logic.list.mapping.md [ufs | logic_block]\n- 6.1 delete: docs/orders_web/web/ui_page/orders.ui.list.md [web | ui_page]\n\nChangeset:\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/orders_pprb/pprb/api_method/orders.api.pprb.list.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: orders.api.pprb.list\\ntitle: Метод PPRB получения списка заказов\\ndoc_type: api_method\\nstatus: created\\ndomain: orders\\nsub_domain: list_read\\nrelated_docs:\\n - orders.api.ufs.list\\n - orders.logic.list.mapping\\n - orders.ui.list\\n---\\n\\n## Summary\\n\\n- Документ описывает метод PPRB для получения списка заказов.\\n- Метод обрабатывает GET-запросы к `/orders` от UFS с параметрами пагинации.\\n- Возвращает список заказов с информацией о сумме, статусе, клиенте и общем количестве заказов.\\n- Реализованы метрики мониторинга успешных запросов, технических и бизнес-ошибок.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n\\n**Предусловия:** \\n- Пользователь прошел аутентификацию и авторизацию.\\n- Передан валидный X-Request-Id.\\n\\n**Триггер:** \\n- Поступает GET-запрос на endpoint `/orders`.\\n\\n**Основной сценарий:**\\n\\n1. **Проверка параметров запроса.** \\n Сервис проверяет наличие обязательных параметров `page`, `size` и `X-Request-Id`. \\n \\n2. **Получение списка заказов.** \\n Выполняется SQL-запрос к базе данных с использованием пагинации согласно переданным параметрам.\\n\\n3. **Формирование ответа.** \\n Формируется JSON-ответ, содержащий список заказов и общее количество записей.\\n\\n4. **Возврат результата клиенту.** \\n Результат отправляется в виде HTTP-ответа со статусом 200 OK.\\n\\n**Альтернативный сценарий (при наличии бизнес-ошибки):** \\n- При отсутствии у пользователя необходимых прав сервис возвращает ошибку с кодом 403 Forbidden.\\n\\n**Обработка ошибок:**\\n- В случае технических ошибок (например, проблемы с базой данных) возвращается статус 500 Internal Server Error.\\n\\n**Постусловие:** \\n- Запись успешных операций мониторинга фиксируется метрикой `ORDERS_LIST_PPRB_SUCCESS`.\\n- В случае технической ошибки регистрируется метрика `ORDERS_LIST_PPRB_FAIL`.\\n- При бизнес-ошибке доступа регистрируется метрика `ORDERS_LIST_PPRB_BUSINESS_ERROR`.\\n\\n### Функциональные требования\\n\\nФункциональные требования не выявлены.\\n\\n### Нефункциональные требования\\n\\n#### Мониторинг\\n\\nМониторинг осуществляется по следующим метрикам:\\n\\n| Метрика | Описание | Условие срабатывания |\\n| --------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |\\n| `ORDERS_LIST_PPRB_SUCCESS` | Метрика успешной обработки запроса на стороне PPRB. | Фиксируется при успешном чтении данных из БД и возврате корректного ответа без ошибок. |\\n| `ORDERS_LIST_PPRB_FAIL` | Метрика технической ошибки на стороне PPRB. | Фиксируется при техническом сбое (ошибка БД, таймаут, недоступность инфраструктуры, необработанное исключение, ошибка 5xx). |\\n| `ORDERS_LIST_PPRB_BUSINESS_ERROR` | Метрика бизнес-ошибки доступа на стороне PPRB. | Фиксируется, если проверка ролевой модели завершилась отказом (нет требуемого экшена). |\\n\",\n \"reason\": \"Метод PPRB получения списка заказов\",\n \"hunks\": []\n },\n {\n \"op\": \"create\",\n \"path\": \"docs/orders_ufs/ufs/api_method/orders.api.ufs.list.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: orders.api.ufs.list\\ntitle: Метод UFS получения списка заказов\\ndoc_type: api_method\\nstatus: created\\ndomain: orders\\nsub_domain: list_read\\nrelated_docs:\\n - orders.api.pprb.list\\n - orders.logic.list.mapping\\n - orders.ui.list\\n---\\n\\n## Summary\\n\\n- Описывает метод UFS для получения списка заказов.\\n- Получает запросы `GET /api/v1/orders` с параметрами пагинации.\\n- Проводит валидацию query-параметров и авторизацию пользователя по ролям.\\n- Интегрируется с методом PPRB для получения данных.\\n- Отображает список заказов с информацией о сумме, статусе, названии клиента и общим количеством заказов.\\n- Реализована система аудита и мониторинга успешности запросов, технических и бизнес-ошибок.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n\\n**Предусловия:** \\n- Пользователь успешно авторизован и прошел проверку ролевой модели.\\n- Передан валидный X-Request-Id.\\n\\n**Триггер:** \\n- Поступает GET-запрос на endpoint `/api/v1/orders`.\\n\\n**Основной сценарий:**\\n\\n1. **Провалидировать параметры запроса.** \\n Сервис проверяет наличие и корректность обязательных параметров `page`, `size` и `X-Request-Id`.\\n \\n2. **Авторизация пользователя.** \\n Проверяется наличие у пользователя необходимого экшена ролевой модели `Role.Orders.List`.\\n\\n3. **Получение списка заказов от PPRB.** \\n Выполняется вызов метода PPRB с передачей параметров пагинации. \\n\\n4. **Смаппинг ответа PPRB в контракт UFS.** \\n Ответ PPRB преобразуется в формат контракта UFS, включающий данные о заказах (сумма, статус, наименование клиента).\\n\\n5. **Возврат сформированного ответа UI.** \\n Отформатированный результат передается обратно пользователю.\\n\\n**Альтернативный сценарий (отсутствие нужных прав):** \\n- Если у пользователя отсутствует необходимый экшен ролевой модели, возвращается ошибка с кодом 403 Forbidden.\\n\\n**Обработка ошибок:** \\n- В случае возникновения технических проблем (таймауты, сетевые сбои, ошибки базы данных) возвращается статус 500 Internal Server Error.\\n\\n**Постусловие:** \\n- Записи об успешном выполнении запроса фиксируются метрикой `ORDERS_LIST_UFS_SUCCESS`.\\n- В случае технической ошибки регистрируется метрика `ORDERS_LIST_UFS_FAIL`.\\n- При бизнес-ошибке доступа регистрируется метрика `ORDERS_LIST_UFS_BUSINESS_ERROR`.\\n\\n### Функциональные требования\\n\\nФункциональные требования не выявлены.\\n\\n### Нефункциональные требования\\n\\n#### Аудит\\n\\nАудиторские записи фиксируются следующей метрикой:\\n\\n| Код события | Описание события | Логируемые атрибуты |\\n|------------------------|----------------------------------------------|--------------------------------------------------------|\\n| `ORDERS_LIST_REQUESTED` | Вызов метода получения списка заказов в UFS. | `requestId`, `userId`, `page`, `size`, `responseCode` |\\n\\n#### Мониторинг\\n\\nМониторинг осуществляется по следующим метрикам:\\n\\n| Метрика | Описание | Условие срабатывания |\\n|-----------------------------------|-----------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|\\n| `ORDERS_LIST_UFS_SUCCESS` | Метрика успешной обработки обработки на получение списка заказов. | Фиксируется при успешном завершении сценария и возврате корректного ответа без ошибок. |\\n| `ORDERS_LIST_UFS_FAIL` | Метрика технической ошибки при обработке запроса. | Фиксируется при техническом сбое (ошибка сети, таймаут, необработанное исключение, недоступность зависимого сервиса, ошибка 5xx). |\\n| `ORDERS_LIST_UFS_BUSINESS_ERROR` | Метрика бизнес-ошибки доступа. | Фиксируется, если у пользователя отсутствует экшен ролевой модели `Role.Orders.List`. |\\n\",\n \"reason\": \"Метод UFS получения списка заказов\",\n \"hunks\": []\n },\n {\n \"op\": \"create\",\n \"path\": \"docs/orders_ufs/ufs/logic_block/orders.logic.list.mapping.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: orders.logic.list.mapping\\ntitle: Маппинг модели PPRB в модель UFS\\ndoc_type: logic_block\\nstatus: created\\ndomain: orders\\nsub_domain: list_read\\nrelated_docs:\\n - orders.api.pprb.list\\n - orders.api.ufs.list\\n - orders.ui.list\\n---\\n\\n## Summary\\n\\n- Данный документ описывает маппинг модели PPRB в модель UFS для получения списка заказов.\\n- Осуществляется преобразование полей DTO ответа PPRB в контракт UFS с последующей нормализацией структуры для представления на UI.\\n- Ключевые преобразования включают маппинг полей `orderName -> name`, `clientDisplayName -> clientName`, `orderAmount -> amount`, `orderStatus -> status`.\\n- Обеспечивается обработка пустых строковых значений путем возврата пустой строки `\\\" \\\"` и сохранение порядка элементов списка без изменений.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n\\n**Предусловия:** \\n- Получен ответ DTO от PPRB.\\n\\n**Триггер:** \\n- Необходимость преобразования полученного DTO в формат контракта UFS.\\n\\n**Основной сценарий:** \\n1. **Получение DTO от PPRB.** \\n Используется ответ, полученный от PPRB в формате DTO.\\n \\n2. **Выполнение маппинга полей.** \\n Выполняется маппинг следующих полей:\\n - `orderName -> name`\\n - `clientDisplayName -> clientName`\\n - `orderAmount -> amount`\\n - `orderStatus -> status`\\n\\n3. **Нормализация структуры.** \\n Преобразованный объект приводится к нормализованной структуре, пригодной для использования UI-компонентами.\\n\\n4. **Формирование окончательного вывода.** \\n Возвращается нормализованная структура данных.\\n\\n**Альтернативный сценарий (для пустых строковых значений):** \\n- Все пустые строки заменяются на `\\\"\\\"`\\n\\n**Обработка ошибок:** \\n- Внутренние ошибки маппинга фиксируются на уровне trace/debug логирования.\\n\\n**Постусловие:** \\n- Порядок элементов исходного списка сохраняется неизменным.\\n\",\n \"reason\": \"Маппинг модели PPRB в модель UFS\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true",
|
||
"completed_at": "2026-04-14T12:32:48.704586+00:00"
|
||
}
|
||
```
|