165 lines
19 KiB
Markdown
165 lines
19 KiB
Markdown
# Runtime Trace: 20260414-123804-48a26f1d804d
|
|
|
|
- active_rag_session_id: 0d8b6e8a-c199-4cb5-82a6-48a26f1d804d
|
|
|
|
## request
|
|
```json
|
|
{
|
|
"request_id": "req_2076be5e40fe49ac83b32b466d52d6c7",
|
|
"session_id": "as_f82580c0351240cd8e16de1280145396",
|
|
"active_rag_session_id": "0d8b6e8a-c199-4cb5-82a6-48a26f1d804d",
|
|
"process_version": "v2",
|
|
"created_at": "2026-04-14T12:38:04.589305+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": "Запрос содержит указание на конкретный md-файл с аналитикой и требует собрать документацию.",
|
|
"rag_session_id": "0d8b6e8a-c199-4cb5-82a6-48a26f1d804d"
|
|
}
|
|
```
|
|
|
|
## 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/ui_page/orders.ui.list.md: не найден текущий файл.\n\nTasks:\n- 6.3 create: docs/orders/pprb/api_method/orders.api.pprb.list.md [pprb | api_method]\n- 6.2 create: docs/orders/ufs/api_method/orders.api.ufs.list.md [ufs | api_method]\n- 6.4 create: docs/orders/ufs/logic_block/orders.logic.list.mapping.md [ufs | logic_block]\n- 6.1 delete: docs/orders/web/ui_page/orders.ui.list.md [web | ui_page]\n\nChangeset:\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/orders/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: create\\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Метод `GET /orders` предназначен для получения списка заказов от UFS с использованием пагинации. Он возвращает JSON-ответ, содержащий массив заказов с информацией о названии, клиенте, сумме и статусе, а также общее количество заказов. Контракт метода включает обязательные параметры запроса, такие как `X-Request-Id`, `page` и `size`. В разделе мониторинга определены ключевые метрики для отслеживания успешных запросов, технических и бизнес-ошибок.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n1. **Предусловия**: \\n - Пользователь аутентифицирован и авторизован.\\n \\n2. **Триггер**: \\n - Поступает HTTP-запрос типа GET на endpoint `/orders`.\\n\\n3. **Основной сценарий**:\\n - 3.1. Выполняется валидация параметров запроса (обязательные параметры: `X-Request-Id`, `page`, `size`).\\n - 3.2. Выполняется SQL-запрос к базе данных с использованием пагинации.\\n - 3.3. Формируется ответ, содержащий список заказов и общее количество заказов.\\n - 3.4. Возвращается JSON-ответ клиенту.\\n\\n4. **Альтернативный сценарий**:\\n - При отсутствии прав доступа инициируется бизнес-ошибка.\\n\\n5. **Обработка ошибок**:\\n - В случае технических сбоев (например, ошибки базы данных) формируется соответствующий код ошибки и сообщение.\\n\\n6. **Постусловие**:\\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Контракты метода описаны в разделе Контракт.\\n\",\n \"reason\": \"Метод PPRB получения списка заказов\",\n \"hunks\": []\n },\n {\n \"op\": \"create\",\n \"path\": \"docs/orders/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: create\\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Метод `GET /api/v1/orders` предназначен для получения списка заказов в системе UFS. Поддерживается пагинация через обязательные параметры запроса `page` и `size`. \\n\\nКлючевые особенности:\\n- Авторизация осуществляется проверкой наличия экшена ролевой модели `Role.Orders.List`.\\n- Производится валидация обязательных параметров запроса, включая уникальный идентификатор запроса `X-Request-Id`.\\n- Результат возвращается в виде JSON с деталями заказов (название, клиент, сумма, статус), а также данными о пагинации.\\n- Реализованы меры аудита и мониторинга для отслеживания успешных запросов, технических и бизнес-ошибок.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n1. **Предусловия**: \\n - Пользователь аутентифицирован и авторизован на уровне UFS.\\n \\n2. **Триггер**: \\n - Поступает HTTP-запрос типа GET на endpoint `/api/v1/orders`.\\n\\n3. **Основной сценарий**:\\n - 3.1. Выполняется валидация query-параметров (`X-Request-Id`, `page`, `size`), которые являются обязательными.\\n - 3.2. Выполняется проверка наличия экшена ролевой модели `Role.Orders.List` у текущего пользователя.\\n - 3.3. Вызывается метод PPRB `GET /orders` с передачей необходимых параметров пагинации.\\n - 3.4. Полученные данные маппятся в контракт UFS согласно описанному соглашению.\\n - 3.5. Формируется финальный JSON-ответ, который отправляется пользователю.\\n\\n4. **Альтернативный сценарий**:\\n - Если текущий пользователь не обладает необходимым экшеном ролевой модели, инициируется бизнес-ошибка и фиксируется соответствующая метрика аудита.\\n\\n5. **Обработка ошибок**:\\n - В случае возникновения технических проблем (ошибки сети, таймауты, недоступность PPRB-сервиса) возвращается соответствующий статус ошибки HTTP и регистрируется инцидент мониторинга.\\n\\n6. **Постусловие**:\\n - Запрос либо успешно выполнен и вернул корректный ответ, либо зафиксирована ошибка с соответствующей записью в системе мониторинга и аудите.\\n\\n### Контракт метода `GET /api/v1/orders`\\nЗапрос (параметры):\\n\\n| Название | Тип параметра | Тип данных | Обязательность | Описание | Пример |\\n| -------------- | ------------- | ---------- | -------------- | ------------------------------ | -------------------------------------- |\\n| `X-Request-Id` | `header` | `uuid` | 1 | Сквозной идентификатор запроса | `c7f4d8ce-9d6f-4ef9-a7ba-0d6f5ed8f111` |\\n| `page` | `query` | `integer` | 1 | Номер страницы, начиная с 1 | `1` |\\n| `size` | `query` | `integer` | 1 | Размер страницы | `20` |\\n\\nОтвет (JSON):\\n\\n| Название | Тип данных | Обязательность | Описание | Заполнение | Пример |\\n| -------------------- | --------------- | -------------- | ------------------------ | ---------------------------------------- | ------------------------ |\\n| `items` | `array<object>` | 1 | Список заказов | Из `orders[]` ответа PPRB после маппинга | `[{\\\\\\\"name\\\\\\\":\\\\\\\"Заказ-001\\\\\\\"}]` |\\n| `items[].name` | `string` | 1 | Наименование заказа | `orders[].orderName` | `Заказ-001` |\\n| `items[].clientName` | `string` | 1 | Наименование клиента | `orders[].clientDisplayName` | `ООО Ромашка` |\\n| `items[].amount` | `number` | 1 | Сумма заказа | `orders[].orderAmount` | `125000.50` |\\n| `items[].status` | `string` | 1 | Статус заказа | `orders[].orderStatus` | `NEW` |\\n| `pagination.page` | `integer` | 1 | Текущая страница | Из query `page` | `1` |\\n| `pagination.size` | `integer` | 1 | Размер страницы | Из query `size` | `20` |\\n| `pagination.total` | `integer` | 1 | Общее количество записей | `totalCount` из ответа PPRB | `245` |\\n\",\n \"reason\": \"Метод UFS получения списка заказов\",\n \"hunks\": []\n },\n {\n \"op\": \"create\",\n \"path\": \"docs/orders/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: create\\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- Основные маппинги: `orderName -> name`, `clientDisplayName -> clientName`, `orderAmount -> amount`, `orderStatus -> status`.\\n- Пустые строки преобразуются в пустую строку `\\\" \\\"` без изменения порядка элементов исходного списка.\\n- Не требует аудита и включает мониторинг времени выполнения маппинга на уровне debug/trace.\\n\\n## Details\\n\\n## Details\\n\\n### Технический use case\\n1. **Предусловия:** \\n - Имеется DTO ответа от PPRB.\\n \\n2. **Триггер:** \\n - Запуск процедуры маппинга.\\n\\n3. **Основной сценарий:**\\n - 3.1. Получение DTO ответа от PPRB.\\n - 3.2. Выполнение маппинга полей в соответствии с контрактом UFS:\\n - `orderName -> name`\\n - `clientDisplayName -> clientName`\\n - `orderAmount -> amount`\\n - `orderStatus -> status`\\n - 3.3. Преобразование пустых строковых значений в пустые строки `\\\"\\\"`\\n - 3.4. Сохранение порядка элементов списка без изменений.\\n - 3.5. Возврат нормализованной структуры для представления на UI.\\n\\n4. **Альтернативный сценарий:** \\n - Нет специфических альтернативных сценариев.\\n\\n5. **Обработка ошибок:** \\n - Внутренние ошибки обрабатываются на уровне логики, информируя систему мониторинга.\\n\\n6. **Постусловие:** \\n - Либо структура успешно нормализована и передана, либо произошла внутренняя ошибка с регистрацией инцидента мониторинга.\\n\\n### Контракт\\nМаппинг выполняется следующим образом:\\n\\n| Поле PPRB | Поле UFS |\\n|----------------|----------------|\\n| orderName | name |\\n| clientDisplayName | clientName |\\n| orderAmount | amount |\\n| orderStatus | status |\\n\",\n \"reason\": \"Маппинг модели PPRB в модель UFS\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true",
|
|
"completed_at": "2026-04-14T12:39:03.564534+00:00"
|
|
}
|
|
```
|