Настройка процесса генерации документации
This commit is contained in:
@@ -0,0 +1,289 @@
|
||||
## 1. Формат ведения технической документации агентом
|
||||
|
||||
## 1.1. Общие принципы
|
||||
|
||||
Техническая документация, формируемая агентом, должна строиться как система атомарных, не пересекающихся по смыслу документов, связанных между собой явными ссылками.
|
||||
|
||||
Ключевые принципы:
|
||||
- один документ описывает одну сущность или один устойчивый технический аспект;
|
||||
- документ не должен дублировать соседние документы;
|
||||
- общая система знаний должна собираться через ссылки, а не через копипасту;
|
||||
- структура документации должна быть пригодна как для чтения человеком, так и для индексирования в RAG.
|
||||
|
||||
## 1.2. Требования к заголовкам
|
||||
|
||||
- Заголовок должен отражать только суть раздела.
|
||||
- Заголовок не должен содержать метаданные (`id`, `doc_type`, `application`, `platform`, `domain`, `sub_domain`).
|
||||
- Метаданные указываются отдельными строками в теле раздела или в YAML frontmatter.
|
||||
|
||||
Пример:
|
||||
- правильно: `## 6.2 Метод UFS получения списка заказов`
|
||||
- неправильно: `## 6.2 Блок api_method (id=..., platform=ufs)`
|
||||
|
||||
## 1.3. Базовые типы документных единиц
|
||||
|
||||
Базовые типы:
|
||||
- `ui_page`
|
||||
- `api_method`
|
||||
- `logic_block`
|
||||
|
||||
Дополнительно могут использоваться:
|
||||
- `architecture_overview`
|
||||
- `integration_doc`
|
||||
- `domain_entity`
|
||||
- `glossary_item`
|
||||
- `index_page`
|
||||
|
||||
## 1.4. Принцип декомпозиции страниц / файлов
|
||||
|
||||
### Один устойчивый объект - один документ
|
||||
Если объект можно переиспользовать или на него могут ссылаться другие документы, его нужно выносить в отдельный файл.
|
||||
|
||||
### Документы не должны пересекаться по смыслу
|
||||
Если описание повторяется в нескольких местах, нужно выделять общий документ и ссылаться на него.
|
||||
|
||||
### Use case и детали живут раздельно
|
||||
Сценарий описывает поток работы, а детали выносятся в функциональные требования, отдельные блоки логики или контрактные описания.
|
||||
|
||||
## 1.5. Иерархическая организация документации
|
||||
|
||||
Документация должна быть организована как иерархическое дерево каталогов и файлов.
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
docs/
|
||||
ui/
|
||||
api/
|
||||
logic/
|
||||
domains/
|
||||
integrations/
|
||||
architecture/
|
||||
glossary/
|
||||
errors/
|
||||
```
|
||||
|
||||
## 1.6. Учет связей между документами
|
||||
|
||||
Связи должны быть явными.
|
||||
|
||||
Примеры:
|
||||
- UI-страница ссылается на вызываемые API;
|
||||
- API-документ ссылается на используемые блоки логики;
|
||||
- логический блок ссылается на интеграции;
|
||||
- документ по коду ссылается на системную аналитику, инициировавшую изменения.
|
||||
|
||||
## 1.7. Формат markdown-документов
|
||||
|
||||
Каждый документ состоит из:
|
||||
1. YAML frontmatter;
|
||||
2. Markdown body.
|
||||
|
||||
## 1.8. YAML frontmatter
|
||||
|
||||
### Обязательные поля
|
||||
- `id`
|
||||
- `title`
|
||||
- `doc_type`
|
||||
- `status`
|
||||
- `domain`
|
||||
- `sub_domain`
|
||||
- `related_docs`
|
||||
|
||||
### Рекомендуемые поля
|
||||
- `owner`
|
||||
- `entities`
|
||||
- `tags`
|
||||
- `feature`
|
||||
- `system_analytics_refs`
|
||||
- `source_of_truth`
|
||||
- `related_code`
|
||||
|
||||
### Допустимые значения `doc_type`
|
||||
- `ui_page`
|
||||
- `api_method`
|
||||
- `logic_block`
|
||||
- `architecture_overview`
|
||||
- `integration_doc`
|
||||
- `domain_entity`
|
||||
- `glossary_item`
|
||||
- `index_page`
|
||||
|
||||
### Допустимые значения `status`
|
||||
- `draft`
|
||||
- `in_review`
|
||||
- `approved`
|
||||
- `outdated`
|
||||
- `generated`
|
||||
- `active`
|
||||
|
||||
## 1.9. Синхронизация с системной аналитикой
|
||||
|
||||
Техническая документация строится на основе системной аналитики (features).
|
||||
|
||||
Обязательно учитывать:
|
||||
- концептуальный уровень аналитики;
|
||||
- детализацию технической документации;
|
||||
- согласованность терминов, ролей и интеграционных цепочек.
|
||||
|
||||
Если атрибуты или детали отсутствуют в аналитике:
|
||||
- определить их из текста аналитики;
|
||||
- дополнить данными из репозитория (код, контракты, существующие документы);
|
||||
- зафиксировать итог в документации как явные метаданные и требования.
|
||||
|
||||
## 1.10. Формат body-разделов для блока изменений
|
||||
|
||||
Для секции изменений (по аналогии с разделом `6` в аналитике) использовать единый формат.
|
||||
|
||||
Под корнем секции изменений указывать общие атрибуты:
|
||||
- `domain`
|
||||
- `sub_domain`
|
||||
|
||||
Для каждого подраздела `X.Y` указывать метаданные строками сразу после заголовка:
|
||||
- `id`
|
||||
- `doc_type`
|
||||
- `application`
|
||||
- `platform`
|
||||
|
||||
## 1.11. Различие аналитики и документации
|
||||
|
||||
- Аналитика - концептуальный уровень, упрощенный use case.
|
||||
- Документация - детальный инженерный уровень.
|
||||
|
||||
Для документации:
|
||||
- технический use case должен быть детализированным;
|
||||
- функциональные требования расширяют use case и описывают детали интеграций, логики и поведения;
|
||||
- функциональные требования не должны копировать шаги сценария без добавления новой информации.
|
||||
|
||||
Источник правил:
|
||||
- `src/app/core/agent/processes/v2/doc_rules_v2/common-elements/tech-use-case.md`
|
||||
- `src/app/core/agent/processes/v2/doc_rules_v2/common-elements/fr.md`
|
||||
|
||||
## 1.12. Требования к `ui_page`
|
||||
|
||||
Обязательная структура:
|
||||
- `### Технический use case`
|
||||
- `### Требования к UI`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
|
||||
### Требования к UI
|
||||
Внутри обязательно отдельно описывать каждую форму UI:
|
||||
- табличное представление;
|
||||
- пустой список (empty state);
|
||||
- ошибка (error state).
|
||||
|
||||
Обязательные правила:
|
||||
- если есть интеграция, обязательно описать показ ошибки;
|
||||
- если показывается список, обязательно описать показ отсутствия данных.
|
||||
|
||||
### UI-элементы
|
||||
UI-поля и элементы в документации описываются строго в таблицах.
|
||||
|
||||
Обязательные колонки (заполнять там, где применимо):
|
||||
- `Код элемента`
|
||||
- `Название и описание`
|
||||
- `Данные`
|
||||
- `Поведение`
|
||||
- `Валидация`
|
||||
|
||||
## 1.13. Пользовательская аналитика для `ui_page`
|
||||
|
||||
События пользовательской аналитики оформляются таблицей:
|
||||
- `Название события`
|
||||
- `Описание`
|
||||
- `Точка вызова`
|
||||
- `Payload`
|
||||
|
||||
## 1.14. Требования к `api_method`
|
||||
|
||||
Обязательная структура:
|
||||
- `### Технический use case`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
- `### Контракт`
|
||||
|
||||
### Технический use case
|
||||
Оформляется детально по правилам `tech-use-case.md`.
|
||||
|
||||
Обязательные части:
|
||||
- название
|
||||
- предусловия
|
||||
- триггер
|
||||
- основной сценарий
|
||||
- альтернативный сценарий
|
||||
- обработка ошибок
|
||||
- постусловие
|
||||
|
||||
### Функциональные требования
|
||||
Оформляются по правилам `fr.md`:
|
||||
- формат `FR.<номер>. <Название>`;
|
||||
- FR расширяют use case;
|
||||
- FR не дублируют шаги сценария без дополнительной ценности;
|
||||
- для интеграционных шагов FR обязательны.
|
||||
|
||||
## 1.15. Нефункциональные требования для `api_method`
|
||||
|
||||
Разделять на подразделы:
|
||||
- `#### Аудит` (если применимо)
|
||||
- `#### Мониторинг`
|
||||
|
||||
### Мониторинг
|
||||
Оформлять таблицей:
|
||||
- `Метрика`
|
||||
- `Описание`
|
||||
- `Условие срабатывания`
|
||||
|
||||
Правила:
|
||||
- в условиях указывать, при каких состояниях фиксируется событие;
|
||||
- не использовать формулировку вида «точка измерения = метод»;
|
||||
- базово закладывать метрики:
|
||||
- `<METRIC_NAME>_SUCCESS`
|
||||
- `<METRIC_NAME>_FAIL`
|
||||
- `<METRIC_NAME>_BUSINESS_ERROR`
|
||||
|
||||
## 1.16. Распределение ответственности по слоям
|
||||
|
||||
- Проверка ролевой модели пользователя обычно выполняется в `ufs`.
|
||||
- Для `pprb` аудит может не фиксироваться, если это согласовано правилами домена.
|
||||
- Если проверка ролей вынесена в `ufs`, не дублировать этот шаг в use case `pprb`.
|
||||
|
||||
## 1.17. Контракты API
|
||||
|
||||
Контракт может быть:
|
||||
- в markdown-таблицах;
|
||||
- в OpenAPI;
|
||||
- в отдельном контрактном файле.
|
||||
|
||||
Для markdown-контракта минимум:
|
||||
- endpoint/method;
|
||||
- request fields;
|
||||
- required/optional;
|
||||
- constraints;
|
||||
- response;
|
||||
- errors;
|
||||
- auth;
|
||||
- retry;
|
||||
- timeout;
|
||||
- idempotency.
|
||||
|
||||
## 1.18. Integrations-блок
|
||||
|
||||
Если у документа есть интеграции, выделять отдельный `## Integrations`.
|
||||
|
||||
Рекомендуемые атрибуты интеграции:
|
||||
- `target`
|
||||
- `target_type`
|
||||
- `direction`
|
||||
- `interaction`
|
||||
- `via`
|
||||
- `purpose`
|
||||
- `details`
|
||||
|
||||
## 1.19. Общие требования к markdown body
|
||||
|
||||
- В документе должен быть один `H1`, совпадающий с `title`.
|
||||
- Основные разделы - `H2`, подразделы - `H3`.
|
||||
- Не допускать хаотичной вложенности заголовков.
|
||||
- Вместо дублирования использовать ссылки на связанные документы.
|
||||
- Сценарии, правила, ограничения и кодовые привязки держать раздельно.
|
||||
@@ -0,0 +1,185 @@
|
||||
# Системная аналитика
|
||||
|
||||
## Общее описание
|
||||
|
||||
Документ описывает изменения в автоматизированной системе. Пишется системными аналитиками для разработчиков и тестировщиков и проходит согласование с экспертами по архитектуре, безопасности и сопровождению.
|
||||
|
||||
Документ может описывать как новый процесс, так и инкремент доработки существующей функциональности.
|
||||
|
||||
## Требования к заголовкам
|
||||
|
||||
- Заголовок должен отражать суть раздела.
|
||||
- Заголовок не должен содержать лишнюю информацию, которая относится к метаданным (id, doc_type, platform, application и т.д.).
|
||||
- Метаданные указываются отдельными строками в теле раздела.
|
||||
|
||||
## Состав документа
|
||||
|
||||
Каждый раздел верхнего уровня оформляется заголовком уровня `#`.
|
||||
|
||||
### 1. Цели
|
||||
|
||||
- Коротко описать, какую проблему и для кого решаем.
|
||||
- 1-2 предложения.
|
||||
- Не дублировать критерии приемки.
|
||||
|
||||
### 2. Процесс AS IS и TO BE
|
||||
|
||||
- Фокус на пользовательских и бизнес-изменениях.
|
||||
- Не указывать технические детали (платформы, API, внутренние интеграции).
|
||||
|
||||
### 3. Ограничения
|
||||
|
||||
- Ограничения и допущения в техническом и бизнесовом плане.
|
||||
|
||||
### 4. Критерии приемки
|
||||
|
||||
- Описывать с точки зрения пользователя.
|
||||
- Не добавлять технические детали (платформы, API, внутренние компоненты).
|
||||
|
||||
### 5. Архитектура
|
||||
|
||||
Нужно указать:
|
||||
|
||||
- схему контейнеров,
|
||||
- таблицу интеграций,
|
||||
- сквозные интеграционные сценарии.
|
||||
|
||||
Слои:
|
||||
|
||||
- `ui` - web-приложение, клиент.
|
||||
- `ufs` - BFF: аутентификация/авторизация, агрегация и маппинг данных.
|
||||
- `pprb` - backend: API, БД, логика жизненного цикла сущностей.
|
||||
|
||||
#### Диаграмма
|
||||
|
||||
Mermaid-диаграмма должна содержать:
|
||||
|
||||
- основные контейнеры,
|
||||
- названия приложений и платформ,
|
||||
- интеграции между приложениями,
|
||||
- названия вызываемых endpoint или топиков.
|
||||
|
||||
#### Таблица интеграций
|
||||
|
||||
Обязательные колонки:
|
||||
|
||||
- Код
|
||||
- Название endpoint/топика
|
||||
- Источник данных
|
||||
- Потребитель данных
|
||||
- Инициатор вызова
|
||||
- Передаваемые данные
|
||||
|
||||
#### Сквозной интеграционный сценарий
|
||||
|
||||
- Нумерованный список вызовов вида: «Компонент 1 вызывает endpoint в Компонент 2».
|
||||
- Только интеграционная цепочка, без детального разбора логики.
|
||||
|
||||
### 6. Описание изменений
|
||||
|
||||
Раздел состоит из подразделов уровня `##` (например, `6.1`, `6.2`, `6.3`).
|
||||
|
||||
Под корнем раздела `# 6` указываются общие метаданные:
|
||||
|
||||
- `domain`
|
||||
- `sub_domain`
|
||||
|
||||
Для каждого раздела `6.x` обязательно указывать метаданные строками сразу после заголовка:
|
||||
|
||||
- `id`
|
||||
- `doc_type`
|
||||
- `application`
|
||||
- `platform`
|
||||
|
||||
#### 6.x для `ui_page`
|
||||
|
||||
Обязательная структура:
|
||||
|
||||
- `### Технический use case (тезисно)`
|
||||
- `### Требования к UI`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
|
||||
Требования к разделу `### Требования к UI`:
|
||||
|
||||
- Внутри нужно отдельно описывать каждую UI-форму.
|
||||
- Если есть интеграция, обязательно описать, как показывается ошибка.
|
||||
- Если показываем список, обязательно описать, как показывается отсутствие данных.
|
||||
|
||||
Рекомендуемая детализация UI-форм:
|
||||
|
||||
- табличное представление,
|
||||
- пустой список (empty state),
|
||||
- ошибка (error state).
|
||||
|
||||
Правила описания UI-полей:
|
||||
|
||||
- Поля описывать списком (не таблицей).
|
||||
- Общие правила (например, read-only, поведение при пустом значении) выносить в общий блок, не дублировать для каждого поля.
|
||||
|
||||
Нефункциональные требования для `ui_page`:
|
||||
|
||||
- пользовательская аналитика оформляется таблицей с колонками:
|
||||
- `Название события`
|
||||
- `Описание`
|
||||
- `Точка вызова`
|
||||
- `Payload`
|
||||
|
||||
#### 6.x для `api_method`
|
||||
|
||||
Обязательная структура:
|
||||
|
||||
- `### Технический use case (тезисно)`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
- `### Контракт метода`
|
||||
|
||||
Правило для функциональных требований:
|
||||
|
||||
- Если дополнительных требований нет (дублируют сценарий), писать: `Не выявлены`.
|
||||
|
||||
Нефункциональные требования:
|
||||
|
||||
- Разделять на подразделы:
|
||||
- `#### Аудит` (если применимо)
|
||||
- `#### Мониторинг`
|
||||
|
||||
Для `Мониторинг` использовать таблицу с колонками:
|
||||
|
||||
- `Метрика`
|
||||
- `Описание`
|
||||
- `Условие срабатывания`
|
||||
|
||||
Важно:
|
||||
|
||||
- В мониторинге описывать условия срабатывания, а не «точку измерения = метод».
|
||||
- Базово закладывать 3 метрики:
|
||||
- `<METRIC_NAME>_SUCCESS`
|
||||
- `<METRIC_NAME>_FAIL`
|
||||
- `<METRIC_NAME>_BUSINESS_ERROR`
|
||||
|
||||
Контракт метода:
|
||||
|
||||
- Для запроса: таблица параметров (`header/query/path`) с колонками: название, тип параметра, тип данных, обязательность, описание, пример.
|
||||
- Для тела JSON (если есть): структура отдельной таблицей.
|
||||
- Для ответа JSON: таблица с колонками: название, тип данных, обязательность, описание, заполнение, пример.
|
||||
|
||||
#### 6.x для `logic_block`
|
||||
|
||||
Обязательная структура:
|
||||
|
||||
- `### Технический use case (тезисно)`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
|
||||
## Дополнительные правила по слоям
|
||||
|
||||
- Проверка ролевой модели пользователя обычно выполняется на уровне `ufs`.
|
||||
- Для `pprb` аудит может не фиксироваться, если это правило принято для конкретной фичи/домена.
|
||||
- Если проверка ролей вынесена в `ufs`, не дублировать этот шаг в сценарии `pprb`.
|
||||
|
||||
## Термины
|
||||
|
||||
- Аудит: события, которые фиксируют действия пользователя и позволяют ответить на вопрос «кто, что, когда сделал».
|
||||
- Мониторинг: технические события/метрики для контроля стабильности и поиска сбоев.
|
||||
|
||||
@@ -1,852 +0,0 @@
|
||||
## 1. Формат ведения технической документации агентом
|
||||
|
||||
## 1.1. Общие принципы
|
||||
|
||||
Техническая документация, формируемая агентом, должна строиться как **система атомарных, не пересекающихся по смыслу документов**, связанных между собой явными ссылками.
|
||||
|
||||
Ключевые принципы:
|
||||
- один документ описывает одну сущность или один устойчивый технический аспект;
|
||||
- документ не должен дублировать соседние документы;
|
||||
- общая система знаний должна собираться через ссылки, а не через копипасту;
|
||||
- структура документации должна быть пригодна как для чтения человеком, так и для индексирования в RAG.
|
||||
|
||||
## 1.2. Базовые типы документных единиц
|
||||
|
||||
На первом этапе логично сохранить текущую семантику типов документов, но перенести ее в файловую модель.
|
||||
|
||||
Базовые типы:
|
||||
- `ui_page`
|
||||
- `api_method`
|
||||
- `logic_block`
|
||||
|
||||
Позже могут добавиться:
|
||||
- `architecture_overview`
|
||||
- `integration_doc`
|
||||
- `domain_entity`
|
||||
- `glossary_item`
|
||||
- `index_page`
|
||||
|
||||
## 1.3. Принцип декомпозиции страниц / файлов
|
||||
|
||||
### Один устойчивый объект — один документ
|
||||
Если объект можно переиспользовать или на него могут ссылаться другие документы, его надо выносить в отдельный файл.
|
||||
|
||||
Примеры:
|
||||
- отдельная UI-страница;
|
||||
- отдельный API endpoint;
|
||||
- отдельный блок логики;
|
||||
- отдельный интеграционный сценарий.
|
||||
|
||||
### Документы не должны пересекаться по смыслу
|
||||
Если описание повторяется в нескольких местах, нужно выделять общий документ и ссылаться на него.
|
||||
|
||||
Примеры:
|
||||
- фронтальная страница не должна заново описывать логику API;
|
||||
- документ по API не должен заново раскрывать общую логику переиспользуемого блока;
|
||||
- вместо дублирования должен быть переход по ссылке.
|
||||
|
||||
### Use case и детальные правила живут раздельно
|
||||
Сценарий описывает поток работы, а детали выносятся в функциональные требования, отдельные блоки логики или контрактные описания.
|
||||
|
||||
Это важно и для RAG-индексации:
|
||||
- сценарии индексируются как workflows;
|
||||
- отдельные правила — как facts;
|
||||
- сущности и блоки — как entities.
|
||||
|
||||
## 1.4. Иерархическая организация документации
|
||||
|
||||
Документация должна быть организована как иерархическое дерево каталогов и файлов, а не как набор неструктурированных страниц.
|
||||
|
||||
Пример верхнего уровня:
|
||||
|
||||
```text
|
||||
docs/
|
||||
ui/
|
||||
api/
|
||||
logic/
|
||||
domains/
|
||||
integrations/
|
||||
architecture/
|
||||
glossary/
|
||||
errors/
|
||||
```
|
||||
|
||||
Пример организации:
|
||||
|
||||
```text
|
||||
docs/
|
||||
ui/
|
||||
order-create-page.md
|
||||
order-edit-page.md
|
||||
api/
|
||||
orders-create.md
|
||||
orders-get.md
|
||||
logic/
|
||||
order-validation.md
|
||||
order-enrichment.md
|
||||
architecture/
|
||||
system-overview.md
|
||||
integration-landscape.md
|
||||
errors/
|
||||
catalog.yaml
|
||||
```
|
||||
|
||||
## 1.5. Учет связей между документами
|
||||
|
||||
Связи должны быть **явными и поддерживаемыми агентом**.
|
||||
|
||||
Примеры:
|
||||
- UI-страница ссылается на API, который она вызывает;
|
||||
- API-документ ссылается на переиспользуемые логические блоки;
|
||||
- логический блок ссылается на связанные интеграции;
|
||||
- архитектурный обзор ссылается на набор конкретных модулей и документов;
|
||||
- документ по коду может ссылаться на системную аналитику, которая инициировала изменение.
|
||||
|
||||
Именно эта сеть ссылок затем индексируется в слоях:
|
||||
- `D1_DOCUMENT_CATALOG`
|
||||
- `D3_ENTITY_CATALOG`
|
||||
- `D4_WORKFLOW_INDEX`
|
||||
- `D5_REFERENCE_GRAPH`
|
||||
- `D6_DOC_CODE_LINKS`
|
||||
|
||||
## 1.6. Формат markdown-документов
|
||||
|
||||
Основной формат технической документации — `Markdown`.
|
||||
|
||||
Каждый документ состоит из двух частей:
|
||||
1. **YAML frontmatter** — структурные метаданные;
|
||||
2. **Markdown body** — основное содержимое по шаблону.
|
||||
|
||||
## 3.7. YAML frontmatter
|
||||
|
||||
Frontmatter нужен для:
|
||||
- определения типа документа;
|
||||
- идентификации документа;
|
||||
- определения его места в иерархии;
|
||||
- фиксации связей с кодом и другими документами;
|
||||
- выделения сущностей и тегов;
|
||||
- упрощения построения слоев `D1`, `D3`, `D5`, `D6`.
|
||||
|
||||
### Базовый frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: ui-order-create-page
|
||||
title: Страница создания заказа
|
||||
doc_type: ui_page
|
||||
domain: orders
|
||||
status: draft
|
||||
related_docs:
|
||||
- api-orders-create
|
||||
- logic-order-validation
|
||||
entities:
|
||||
- Order
|
||||
- CreateOrder
|
||||
tags:
|
||||
- ui
|
||||
- orders
|
||||
- creation
|
||||
#owner: system-analyst
|
||||
#source_of_truth: code
|
||||
#related_code:
|
||||
# - src/orders/ui/create_page.tsx
|
||||
# - src/orders/api/orders_controller.py
|
||||
---
|
||||
```
|
||||
|
||||
### Обязательные поля
|
||||
|
||||
- `id` — стабильный уникальный идентификатор документа;
|
||||
- `title` — человекочитаемый заголовок;
|
||||
- `doc_type` — тип документа;
|
||||
- `related_docs` — ссылки на связанные документы;
|
||||
- `status` — статус документа;
|
||||
- `domain` - домен фичи (Карточка клиента, Задачи, Сделки, Предложения)
|
||||
- `sub_domain` - поддомен внутри основной сущности (Счета, ЗДА, ECM)
|
||||
|
||||
### Рекомендуемые поля
|
||||
- `owner`
|
||||
- `entities`
|
||||
- `tags`
|
||||
- `parent`
|
||||
- `children`
|
||||
- `feature`
|
||||
- `system_analytics_refs`
|
||||
- `business_refs`
|
||||
- `updated_from`
|
||||
- `reviewers`
|
||||
- `source_of_truth`
|
||||
- `related_code`
|
||||
|
||||
### Допустимые значения `doc_type`
|
||||
- `ui_page`
|
||||
- `api_method`
|
||||
- `logic_block`
|
||||
- `architecture_overview`
|
||||
- `integration_doc`
|
||||
- `domain_entity`
|
||||
- `glossary_item`
|
||||
- `index_page`
|
||||
|
||||
### Допустимые значения `status`
|
||||
- `draft`
|
||||
- `in_review`
|
||||
- `approved`
|
||||
- `outdated`
|
||||
- `generated`
|
||||
- `active`
|
||||
|
||||
### Допустимые значения `source_of_truth`
|
||||
- `code`
|
||||
- `doc`
|
||||
- `system_analysis`
|
||||
- `business_requirements`
|
||||
- `mixed`
|
||||
|
||||
## 1.8. Typed frontmatter для разных типов документов
|
||||
|
||||
У каждого типа документа есть:
|
||||
- **общие поля**;
|
||||
- **тип-специфичные поля**.
|
||||
|
||||
### Пример для `api_method`
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: api.create_invoice
|
||||
doc_type: api_method
|
||||
domain: billing
|
||||
title: Создание инвойса
|
||||
|
||||
endpoint: POST /api/v1/invoices
|
||||
auth: USER
|
||||
idempotent: false
|
||||
timeout_ms: 3000
|
||||
|
||||
links:
|
||||
called_by:
|
||||
- ui.invoice_form
|
||||
uses_logic:
|
||||
- logic.invoice_validation
|
||||
writes_db:
|
||||
- db.invoices
|
||||
- db.invoice_items
|
||||
integrates_with:
|
||||
- int.crm_sync
|
||||
|
||||
related_docs:
|
||||
- ui.invoice_form
|
||||
- logic.invoice_validation
|
||||
related_code:
|
||||
- services/billing/api/create_invoice.py
|
||||
entities:
|
||||
- Invoice
|
||||
- CreateInvoice
|
||||
|
||||
tags:
|
||||
- invoice
|
||||
- create
|
||||
- billing
|
||||
status: active
|
||||
version: 1.3
|
||||
source_of_truth: code
|
||||
---
|
||||
```
|
||||
|
||||
### Для `api_method` полезно поддерживать
|
||||
|
||||
- `endpoint`
|
||||
- `sup_parameters`
|
||||
- `role_model_actions`
|
||||
- `monitoring_actions`
|
||||
- `audit_actions`
|
||||
- `idempotent`
|
||||
- `timeout_ms`
|
||||
- `links.called_by`
|
||||
- `links.uses_logic`
|
||||
- `links.writes_db`
|
||||
- `links.integrates_with`
|
||||
|
||||
### Для `ui_page` позже полезно поддерживать
|
||||
- `calls_api`
|
||||
- `user_analitycs_actions`
|
||||
- `sup_parameters`
|
||||
- `role_model_actions`
|
||||
- `entry_points`
|
||||
- `uses_logic`
|
||||
|
||||
### Для `logic_block` полезно поддерживать
|
||||
|
||||
- `called_from`
|
||||
- `uses_logic`
|
||||
- `reads_db`
|
||||
- `writes_db`
|
||||
- `integrates_with`
|
||||
|
||||
## 1.9. Двухслойная структура документа: `Summary` + `Details`
|
||||
|
||||
LLM не должна каждый раз тонуть в полном документе. Поэтому каждый документ должен содержать два уровня представления.
|
||||
|
||||
### `Summary`
|
||||
Короткая, строго структурированная спецификация. Это слой **быстрого контекста**.
|
||||
|
||||
Рекомендуемый объем:
|
||||
- примерно 30–60 строк;
|
||||
- без длинных пояснений;
|
||||
- только ключевые факты.
|
||||
|
||||
Пример:
|
||||
|
||||
```md
|
||||
## Summary
|
||||
- Purpose: создание инвойса из формы
|
||||
- Actor: пользователь
|
||||
- Trigger: Submit
|
||||
- Main API: POST /api/v1/invoices (api.create_invoice)
|
||||
- Validation: required fields, amount > 0, date <= today
|
||||
- Errors: 400(field errors), 409(duplicate), 503(retryable)
|
||||
- Analytics: event invoice_submit, invoice_error
|
||||
```
|
||||
|
||||
### `Details`
|
||||
Полное раскрытие объекта:
|
||||
- use case;
|
||||
- функциональные требования;
|
||||
- UI;
|
||||
- API;
|
||||
- integrations;
|
||||
- ошибки;
|
||||
- НФТ;
|
||||
- связи;
|
||||
- кодовые привязки.
|
||||
|
||||
### Блок `## Integrations`
|
||||
|
||||
Если у объекта есть интеграции, они должны быть выделены в отдельный блок `## Integrations`.
|
||||
Интеграции не нужно дублировать во frontmatter.
|
||||
Основное описание хранится в body документа.
|
||||
|
||||
Ожидаемый принцип:
|
||||
- одна интеграция = одна отдельная запись внутри блока;
|
||||
- у интеграции есть краткое имя;
|
||||
- у интеграции есть структурированные атрибуты;
|
||||
- дополнительные детали допускаются в свободной форме через вложенный словарь.
|
||||
|
||||
Рекомендуемые атрибуты интеграции:
|
||||
- `target`
|
||||
- `target_type`
|
||||
- `direction`
|
||||
- `interaction`
|
||||
- `via`
|
||||
- `purpose`
|
||||
- `details`
|
||||
|
||||
Где:
|
||||
- `target` - идентификатор или имя целевого объекта;
|
||||
- `target_type` - тип цели: `api`, `ui`, `entity`, `service`, `queue`, `db`, `external_system`;
|
||||
- `direction` - направление: `inbound`, `outbound`, `bidirectional`;
|
||||
- `interaction` - тип взаимодействия: `calls`, `reads`, `writes`, `emits`, `consumes`, `depends_on`;
|
||||
- `via` - технический канал интеграции;
|
||||
- `purpose` - зачем нужна интеграция;
|
||||
- `details` - словарь с гибкой структурой под дополнительные параметры.
|
||||
|
||||
Пример:
|
||||
|
||||
```md
|
||||
## Integrations
|
||||
|
||||
### Orders API
|
||||
- target: api.orders.create
|
||||
- target_type: api
|
||||
- direction: outbound
|
||||
- interaction: calls
|
||||
- via: POST /api/orders
|
||||
- purpose: создание заказа
|
||||
- details:
|
||||
- auth: service-token
|
||||
- retry: true
|
||||
|
||||
### Order Entity
|
||||
- target: domain.order
|
||||
- target_type: entity
|
||||
- direction: outbound
|
||||
- interaction: writes
|
||||
- via: repository
|
||||
- purpose: сохранение состояния заказа
|
||||
- details:
|
||||
- transaction: required
|
||||
```
|
||||
|
||||
Этот блок должен быть пригоден и для чтения человеком, и для последующего извлечения в отдельный RAG-слой интеграций.
|
||||
|
||||
## 1.10. Общие требования к markdown body
|
||||
|
||||
1. В документе должен быть один `H1`, совпадающий с `title`.
|
||||
2. Основные разделы используют `H2`.
|
||||
3. Подразделы внутри разделов используют `H3`.
|
||||
4. Не должно быть хаотической вложенности заголовков.
|
||||
5. Один раздел должен описывать одну смысловую часть.
|
||||
6. Текст не должен дублировать соседние документы.
|
||||
7. Вместо дублирования должны использоваться явные ссылки на связанные документы.
|
||||
8. Сценарии, правила, ограничения и ссылки на код должны быть отделены друг от друга.
|
||||
|
||||
## 1.11. Базовый каркас markdown-документа
|
||||
|
||||
```md
|
||||
---
|
||||
id: api-orders-create
|
||||
title: Метод создания заказа
|
||||
doc_type: api_method
|
||||
domain: orders
|
||||
status: draft
|
||||
source_of_truth: code
|
||||
related_docs:
|
||||
- logic-order-validation
|
||||
- ui-order-create-page
|
||||
related_code:
|
||||
- src/orders/api/create_order.py
|
||||
entities:
|
||||
- Order
|
||||
- CreateOrder
|
||||
tags:
|
||||
- api
|
||||
- orders
|
||||
---
|
||||
|
||||
# Метод создания заказа
|
||||
|
||||
## Summary
|
||||
- Purpose: создание заказа
|
||||
- Actor: пользователь
|
||||
- Trigger: submit формы
|
||||
- Main API: POST /orders
|
||||
|
||||
## Details
|
||||
### Описание
|
||||
### Технический use case
|
||||
### Функциональные требования
|
||||
### Нефункциональные требования
|
||||
### Контракт
|
||||
|
||||
|
||||
## 3.13. Специализированные шаблоны документов
|
||||
|
||||
### UI Page
|
||||
|
||||
```md
|
||||
# <Название страницы>
|
||||
|
||||
## Summary
|
||||
## Назначение
|
||||
## Контекст
|
||||
## Технический use case
|
||||
## Описание UI
|
||||
## UI Elements
|
||||
## Функциональные требования
|
||||
## Нефункциональные требования
|
||||
## Связанные API
|
||||
## Связанные блоки логики
|
||||
## Связанный код
|
||||
## Связанные документы
|
||||
## История изменений
|
||||
```
|
||||
|
||||
#### Требования к разделу `Описание UI`
|
||||
Для каждого элемента желательно описывать:
|
||||
- тип элемента;
|
||||
- назначение;
|
||||
- источник данных;
|
||||
- default / placeholder;
|
||||
- правила активации;
|
||||
- поведение при взаимодействии;
|
||||
- валидацию.
|
||||
|
||||
#### Требования к разделу `UI Elements`
|
||||
UI-элементы должны храниться в **табличном** или **полуструктурированном** виде.
|
||||
|
||||
Пример:
|
||||
|
||||
```md
|
||||
## UI Elements
|
||||
|
||||
| id | type | label | data_source | validation | behavior |
|
||||
|--------|--------|---------|------------|------------|----------|
|
||||
| amount | input | Amount | local | >0 | enables submit |
|
||||
| submit | button | Create | - | - | calls api.create_invoice |
|
||||
```
|
||||
|
||||
Если модель UI сложная, допустим sidecar-файл `ui_elements.yaml` или `ui_elements.json` рядом с основным документом.
|
||||
|
||||
### API Method
|
||||
|
||||
```md
|
||||
# <Название API метода>
|
||||
|
||||
## Summary
|
||||
## Назначение
|
||||
## Контекст
|
||||
## Технический use case
|
||||
## Функциональные требования
|
||||
## Contract
|
||||
## Integrations
|
||||
## Errors
|
||||
## Нефункциональные требования
|
||||
## Связанные блоки логики
|
||||
## Связанный код
|
||||
## Связанные документы
|
||||
## История изменений
|
||||
```
|
||||
|
||||
#### Требования к разделу `Contract`
|
||||
Контракт может:
|
||||
- быть кратко описан прямо в документе;
|
||||
- ссылаться на OpenAPI;
|
||||
- ссылаться на отдельный контрактный файл.
|
||||
|
||||
Для REST API целевым источником истины должен становиться `OpenAPI`.
|
||||
|
||||
### Reusable Logic Block
|
||||
|
||||
```md
|
||||
# <Название блока логики>
|
||||
|
||||
## Summary
|
||||
## Назначение
|
||||
## Контекст
|
||||
## Технический use case
|
||||
## Функциональные требования
|
||||
## Integrations
|
||||
## Ограничения и условия вызова
|
||||
## Нефункциональные требования
|
||||
## Связанные API / UI / integration points
|
||||
## Связанный код
|
||||
## Связанные документы
|
||||
## История изменений
|
||||
```
|
||||
|
||||
## 3.14. Машинно-читаемые API-контракты
|
||||
|
||||
Для API контрактов **источником истины** должен становиться:
|
||||
- `OpenAPI` — предпочтительно;
|
||||
- либо временно строгий markdown/yaml-контракт, если OpenAPI еще нет.
|
||||
|
||||
Минимальный набор для API-контракта:
|
||||
- `endpoint`
|
||||
- `method`
|
||||
- `request fields`
|
||||
- `required / optional`
|
||||
- `constraints`
|
||||
- `response`
|
||||
- `errors`
|
||||
- `idempotency`
|
||||
- `retry`
|
||||
- `timeout`
|
||||
- `auth`
|
||||
|
||||
## 3.15. Каталог ошибок
|
||||
|
||||
Ошибки, HTTP-коды, retry-правила и клиентское поведение не должны размазываться по разным документам.
|
||||
|
||||
Нужен единый каталог ошибок, например `docs/errors/catalog.yaml`.
|
||||
|
||||
Пример:
|
||||
|
||||
```yaml
|
||||
errors:
|
||||
- error_id: invoice_validation_failed
|
||||
http_code: 400
|
||||
internal_code: BILLING_400_01
|
||||
when: invalid request fields
|
||||
client_behavior: show field errors
|
||||
retry: false
|
||||
owner: billing
|
||||
|
||||
- error_id: invoice_duplicate
|
||||
http_code: 409
|
||||
internal_code: BILLING_409_01
|
||||
when: duplicate invoice detected
|
||||
client_behavior: show duplicate warning
|
||||
retry: false
|
||||
owner: billing
|
||||
|
||||
- error_id: crm_sync_unavailable
|
||||
http_code: 503
|
||||
internal_code: BILLING_503_02
|
||||
when: downstream CRM unavailable
|
||||
client_behavior: retry later
|
||||
retry: true
|
||||
owner: billing
|
||||
```
|
||||
|
||||
В API- и logic-документах лучше ссылаться на `error_id`, а не заново подробно описывать каждую ошибку.
|
||||
|
||||
## 3.16. Требования к качеству документа для RAG
|
||||
|
||||
1. **Явные заголовки** — не использовать безымянные блоки текста.
|
||||
2. **Атомарные утверждения** — не смешивать несколько правил в одном пункте, если их можно разделить.
|
||||
3. **Явные сущности** — использовать стабильные названия компонентов, API, модулей, страниц.
|
||||
4. **Явные ссылки** — не писать «этот метод», если можно указать конкретную ссылку или идентификатор.
|
||||
5. **Минимум дублирования** — повторяющийся контент должен заменяться ссылками.
|
||||
6. **Привязка к коду** — если документ описывает кодовый объект, это должно быть явно указано.
|
||||
7. **Разделение сценариев и правил** — workflow и fact-like требования должны быть отделены.
|
||||
|
||||
## 3.17. Как структура markdown помогает RAG
|
||||
|
||||
- `frontmatter` + заголовки → `D1_DOCUMENT_CATALOG`
|
||||
- `entities`, `tags`, устойчивые термины → `D3_ENTITY_CATALOG`
|
||||
- атомарные функциональные и нефункциональные требования → `D2_FACT_INDEX`
|
||||
- `Технический use case` → `D4_WORKFLOW_INDEX`
|
||||
- `related_docs`, явные ссылки → `D5_REFERENCE_GRAPH`
|
||||
- `related_code`, упоминания symbols и файлов → `D6_DOC_CODE_LINKS`
|
||||
- `Summary` → быстрый retrieval и short-form context для LLM
|
||||
|
||||
## 3.18. Принципы генерации документации агентом
|
||||
|
||||
Когда документ пишет агент, он должен:
|
||||
- сначала извлечь evidence из кода, системной аналитики и существующих документов;
|
||||
- определить тип документа;
|
||||
- заполнить frontmatter;
|
||||
- построить markdown body по шаблону;
|
||||
- явно указать связи с кодом и другими документами;
|
||||
- не дублировать уже существующее описание, если можно сослаться на него.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 4.4. Layered RAG
|
||||
|
||||
RAG строится как система специализированных слоев для двух основных доменов:
|
||||
- `CODE RAG`
|
||||
- `DOCS RAG`
|
||||
|
||||
Каждый graph извлекает контекст не из одного общего индекса, а из нужного набора слоев в зависимости от intent.
|
||||
|
||||
## 4.5. Evidence gate
|
||||
|
||||
Перед синтезом ответа или документа агент должен проверять, хватает ли опоры.
|
||||
|
||||
Примеры:
|
||||
- найден ли symbol;
|
||||
- найдено ли достаточное количество code chunks;
|
||||
- есть ли supporting relations;
|
||||
- есть ли document evidence;
|
||||
- есть ли docs ↔ code mapping.
|
||||
|
||||
Если опоры недостаточно, агент должен:
|
||||
- деградировать в упрощенный режим;
|
||||
- честно фиксировать неполноту ответа;
|
||||
- при необходимости уходить в fallback.
|
||||
|
||||
## 4.6. Synthesis layer
|
||||
|
||||
На этом этапе LLM:
|
||||
- агрегирует найденные артефакты;
|
||||
- формирует объяснение;
|
||||
- пишет документ;
|
||||
- структурирует результат под нужный шаблон.
|
||||
|
||||
LLM не должна быть основным источником фактов. Фактическая основа должна приходить из RAG и диагностируемого pipeline.
|
||||
|
||||
## 4.7. Diagnostics
|
||||
|
||||
Система должна сохранять диагностический след:
|
||||
- какой graph был выбран;
|
||||
- какие слои использовались;
|
||||
- что было найдено;
|
||||
- где retrieval был слабым;
|
||||
- почему был выбран fallback;
|
||||
- какие evidence стали основой ответа.
|
||||
|
||||
## 4.8. Сценарии: Target Architecture vs MVP-now
|
||||
|
||||
### 4.8.1. Target Architecture
|
||||
|
||||
#### CODE
|
||||
- `OPEN_FILE` — открыть конкретный файл;
|
||||
- `OPEN_SYMBOL` — открыть класс / функцию / метод;
|
||||
- `EXPLAIN` — объяснить, как работает сущность или фрагмент;
|
||||
- `FIND_TESTS` — найти релевантные тесты;
|
||||
- `FIND_ENTRYPOINTS` — найти основные точки входа;
|
||||
- `RELATED_CODE` — найти связанные сущности и ближайший контекст.
|
||||
|
||||
#### DOCS
|
||||
- `DOC_SEARCH` — найти релевантный фрагмент документации;
|
||||
- `DOC_EXPLAIN` — кратко объяснить, что сказано в документации по теме;
|
||||
- `DOC_ENTITY_LOOKUP` — найти разделы, связанные с сущностью или компонентом;
|
||||
- `GENERATE_DOCS_FROM_CODE` — сформировать документацию по коду с нуля для модуля, класса, функции, компонента или сценария.
|
||||
|
||||
#### CROSS-DOMAIN
|
||||
- `FIND_IMPLEMENTATION_BY_DOC` — найти реализацию по описанию;
|
||||
- `FIND_DOC_BY_CODE` — найти документацию по коду;
|
||||
- `COMPARE_DOCS_AND_CODE` — базовое сопоставление документации и реализации.
|
||||
|
||||
#### GENERAL / FALLBACK
|
||||
- `GENERAL_QA` — общий сценарий ответа на вопрос, если домен или интент не удалось определить уверенно.
|
||||
|
||||
### 4.8.2. MVP-now
|
||||
|
||||
В текущем цикле фокус на сценариях:
|
||||
|
||||
- `OPEN_FILE`
|
||||
- `EXPLAIN`
|
||||
- `FIND_TESTS`
|
||||
- `FIND_ENTRYPOINTS`
|
||||
- `GENERAL_QA`
|
||||
|
||||
DOCS и CROSS_DOMAIN остаются частью target architecture; в текущем цикле они не являются обязательной частью test-first MVP.
|
||||
|
||||
---
|
||||
|
||||
## 5. Структура слоев RAG
|
||||
|
||||
## 5.1. CODE RAG
|
||||
|
||||
### C0 — Source Chunks
|
||||
**Назначение:** базовые фрагменты исходного кода.
|
||||
**Единица:** chunk кода.
|
||||
**Как формируется:** исходные файлы обходятся и режутся на chunk’и с учетом структурных границ.
|
||||
**Статус в MVP:** да.
|
||||
|
||||
### C1 — Symbol Catalog
|
||||
**Назначение:** каталог модулей, классов, функций, методов и других значимых сущностей.
|
||||
**Единица:** symbol.
|
||||
**Как формируется:** из AST и синтаксического разбора кода.
|
||||
**Статус в MVP:** да.
|
||||
|
||||
### C2 — Symbol Relations
|
||||
**Назначение:** связи между symbols.
|
||||
**Единица:** relation.
|
||||
**Как формируется:** вторым проходом по AST и структурным зависимостям.
|
||||
**Статус в MVP:** да, в ограниченном виде.
|
||||
|
||||
### C3 — Entrypoints
|
||||
**Назначение:** каталог точек входа системы.
|
||||
**Единица:** entrypoint.
|
||||
**Как формируется:** специализированными детекторами entrypoint-паттернов.
|
||||
**Статус в MVP:** да, минимально.
|
||||
|
||||
### C4 — Execution Paths
|
||||
**Назначение:** типовые пути исполнения.
|
||||
**Единица:** path.
|
||||
**Как формируется:** поверх `C2` и `C3` через производную трассировку.
|
||||
**Статус в MVP:** нет.
|
||||
|
||||
### C5 — Test Mappings
|
||||
**Назначение:** связи production code ↔ tests.
|
||||
**Единица:** mapping.
|
||||
**Как формируется:** по путям, именам, импортам и конвенциям проекта.
|
||||
**Статус в MVP:** да, минимально.
|
||||
|
||||
### C6 — Code Facts
|
||||
**Назначение:** нормализованные факты из кода.
|
||||
**Единица:** fact.
|
||||
**Как формируется:** поверх `C1–C3` как производный слой.
|
||||
**Статус в MVP:** нет.
|
||||
|
||||
## 5.2. DOCS RAG
|
||||
|
||||
### D0 — Document Chunks
|
||||
**Назначение:** базовые фрагменты документации.
|
||||
**Единица:** document chunk.
|
||||
**Как формируется:** документы нормализуются и режутся на chunk’и с сохранением `section path`.
|
||||
**Статус в MVP:** да.
|
||||
|
||||
### D1 — Document Catalog
|
||||
**Назначение:** каталог документов и разделов.
|
||||
**Единица:** `document node / section node`.
|
||||
**Как формируется:** из структуры документов и их заголовков.
|
||||
**Статус в MVP:** да.
|
||||
|
||||
### D2 — Fact Index
|
||||
**Назначение:** атомарные факты из документации.
|
||||
**Единица:** fact.
|
||||
**Как формируется:** из `D0/D1` через правила, шаблоны и при необходимости LLM extraction с валидацией.
|
||||
**Статус в MVP:** частично.
|
||||
|
||||
### D3 — Entity Catalog
|
||||
**Назначение:** каталог сущностей и понятий документации.
|
||||
**Единица:** entity / concept.
|
||||
**Как формируется:** из устойчивых терминов, заголовков, словарей и нормализации повторяющихся сущностей.
|
||||
**Статус в MVP:** да, минимально.
|
||||
|
||||
### D4 — Workflow Index
|
||||
**Назначение:** процедуры, сценарии, последовательности шагов.
|
||||
**Единица:** workflow.
|
||||
**Как формируется:** из use case, процессных разделов и последовательных описаний шагов.
|
||||
**Статус в MVP:** нет.
|
||||
|
||||
### D5 — Reference Graph
|
||||
**Назначение:** граф ссылок между документами, секциями, сущностями и фактами.
|
||||
**Единица:** reference link.
|
||||
**Как формируется:** из явных и неявных cross-links между документами.
|
||||
**Статус в MVP:** нет.
|
||||
|
||||
### D6 — Doc-Code Links
|
||||
**Назначение:** мост между документацией и кодом.
|
||||
**Единица:** `doc artifact ↔ code artifact link`.
|
||||
**Как формируется:** из имен, aliases, путей, устойчивых терминов и других надежных соответствий.
|
||||
**Статус в MVP:** да, минимально.
|
||||
|
||||
## 5.3. Layer scope: Target Architecture vs MVP-now
|
||||
|
||||
### 5.3.1. Target Architecture
|
||||
|
||||
Полная карта слоёв:
|
||||
|
||||
- **CODE:** C0–C6 (Source Chunks, Symbol Catalog, Symbol Relations, Entrypoints, Execution Paths, Test Mappings, Code Facts)
|
||||
- **DOCS:** D0–D6 (Document Chunks, Document Catalog, Fact Index, Entity Catalog, Workflow Index, Reference Graph, Doc-Code Links)
|
||||
|
||||
### 5.3.2. MVP-now
|
||||
|
||||
**Обязательные сейчас:**
|
||||
|
||||
- `C0_SOURCE_CHUNKS`
|
||||
- `C1_SYMBOL_CATALOG`
|
||||
- `C2_SYMBOL_RELATIONS`
|
||||
- `C3_ENTRYPOINTS`
|
||||
|
||||
**В облегчённом виде:**
|
||||
|
||||
- `C5_TEST_MAPPINGS` или `C5-lite`
|
||||
|
||||
**Не блокируют текущий этап:**
|
||||
|
||||
- `C4_EXECUTION_PATHS`
|
||||
- `C6_CODE_FACTS`
|
||||
- весь docs runtime (слои D0–D6 в исполнении runtime)
|
||||
|
||||
Слои документации остаются частью target architecture; docs retrieval пока не обязателен для текущего code-first milestone.
|
||||
|
||||
---
|
||||
|
||||
## 6. Итоговая рамка MVP-now
|
||||
|
||||
Сейчас система должна стабильно работать в **test-first** режиме.
|
||||
|
||||
**Фокус:**
|
||||
|
||||
- CODE_QA;
|
||||
- через тесты настраиваются:
|
||||
- intent routing (IntentRouterV2);
|
||||
- layered retrieval;
|
||||
- evidence sufficiency;
|
||||
- answer quality;
|
||||
- diagnostics.
|
||||
|
||||
**Не входят в текущий milestone:**
|
||||
|
||||
- UI-интеграция;
|
||||
- docs runtime;
|
||||
- полная интеграция orchestration переносится на следующий этап после стабилизации test pipeline.
|
||||
|
||||
В целевой архитектуре по-прежнему заложены:
|
||||
- уверенная работа с кодом, symbols, entrypoints, тестами;
|
||||
- ответ по документации и мост docs ↔ code;
|
||||
- генерация документации по коду;
|
||||
- fallback при неуверенном роутинге.
|
||||
|
||||
В MVP-now сознательно **не включаются** самые дорогие части:
|
||||
- полноценные execution paths для всей системы;
|
||||
- богатые fact-индексы по всем доменам;
|
||||
- полный reference graph документации;
|
||||
- глубокая автоматизация подготовки системной аналитики.
|
||||
@@ -0,0 +1,33 @@
|
||||
Нужно реализовать 2 вещи
|
||||
|
||||
Создать процесс внесения изменений в файл документации
|
||||
Создать контекст этого процесса
|
||||
|
||||
Контекст наполнять атрибутами
|
||||
что-то явно задано, фоллбэк через ллм
|
||||
|
||||
|
||||
|
||||
Написать тестовую аналитику - круд над сущностью
|
||||
фронт, ефс, ппрб
|
||||
Все в своей БД
|
||||
Атрибуты сущности задать в требованиях
|
||||
|
||||
|
||||
|
||||
|
||||
Аналитика имеет структуру
|
||||
Внутри модули - один модуль на правку одного файла.
|
||||
|
||||
|
||||
Модуль извлекается из аналитики парсером и из него формируется задача на редактирование файла
|
||||
если парсер не сработал - фоллбэк ан ллм
|
||||
|
||||
|
||||
|
||||
Процесс редактирования работает стандартно
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Documentation Rules V3
|
||||
|
||||
Этот каталог содержит правила генерации технической документации из системной аналитики.
|
||||
|
||||
## Цель
|
||||
- синхронизировать требования к документации с требованиями к аналитике (`04. Analitycs artefacts - features.md`);
|
||||
- сохранить детальность техдокументации по сравнению с аналитикой;
|
||||
- убрать дублирование структуры и manifest-слоя между разными файлами;
|
||||
- собирать итоговый промпт из модулей: глобальные правила + template с manifest + блоки.
|
||||
|
||||
## Структура
|
||||
- `documentation-rules.md` — верхнеуровневый регламент и порядок сборки.
|
||||
- `global/` — общие правила (заголовки, frontmatter, слой ответственности, мост аналитика->документация).
|
||||
- `common-elements/` — правила для общих блоков (`summary`, `details`, `use case`, `FR`, `NFR`, `UI`, `Contract`).
|
||||
- `templates/` — единственный источник истины для структуры итоговой страницы и manifest-метаданных типа документа.
|
||||
|
||||
## Принцип сборки
|
||||
Для конкретного документа агент собирает единый набор правил из:
|
||||
1. `documentation-rules.md`
|
||||
2. `global/*.md`
|
||||
3. `templates/<doc_type>.template.md`
|
||||
4. `common-elements/*.md`, указанных в frontmatter template
|
||||
|
||||
## Правило без дублирования
|
||||
- `templates/` отвечают за структуру документа, порядок разделов и manifest-метаданные типа.
|
||||
- `common-elements/` отвечают только за правила написания конкретного раздела.
|
||||
- отдельный слой `types/` не нужен, если для типа документа используется один основной template.
|
||||
|
||||
## Формат template-manifest
|
||||
Manifest оформляется в YAML frontmatter самого template.
|
||||
|
||||
Обязательные поля manifest:
|
||||
- `doc_type`
|
||||
- `required_common_elements`
|
||||
|
||||
Рекомендуемые поля:
|
||||
- `special_rules`
|
||||
@@ -0,0 +1,21 @@
|
||||
# API Contract Rules
|
||||
|
||||
## Обязательные части
|
||||
- request parameters (`header/query/path`)
|
||||
- request body (если применимо)
|
||||
- response body
|
||||
- errors
|
||||
- auth
|
||||
- timeout
|
||||
- retry/idempotency (если применимо)
|
||||
|
||||
## Табличный формат
|
||||
Для request/response таблицы должны содержать:
|
||||
- название
|
||||
- тип данных
|
||||
- обязательность
|
||||
- описание
|
||||
- пример
|
||||
|
||||
Для response дополнительно:
|
||||
- заполнение (mapping/логика источника данных)
|
||||
@@ -0,0 +1,17 @@
|
||||
# DB Columns Rules
|
||||
|
||||
## Формат
|
||||
Структура таблицы оформляется таблицей.
|
||||
|
||||
## Обязательные колонки
|
||||
- `Поле`
|
||||
- `Тип`
|
||||
- `Nullable`
|
||||
- `Описание`
|
||||
- `Источник заполнения`
|
||||
- `Использование`
|
||||
|
||||
## Правила
|
||||
- перечислять все ключевые поля таблицы;
|
||||
- для служебных полей (`id`, `created_at`, `updated_at`, `deleted_at`) явно описывать назначение;
|
||||
- если тип или nullable не заданы в аналитике, допускается инженерное предположение с рабочим вариантом.
|
||||
@@ -0,0 +1,16 @@
|
||||
# DB Constraints Rules
|
||||
|
||||
## Что включать
|
||||
- primary key;
|
||||
- unique constraints;
|
||||
- foreign keys;
|
||||
- важные индексы;
|
||||
- бизнес-ограничения на уровне БД.
|
||||
|
||||
## Формат
|
||||
- списком или таблицей;
|
||||
- для каждого индекса и ограничения писать, зачем оно нужно.
|
||||
|
||||
## Правила
|
||||
- если индекс нужен для сценария чтения/пагинации, это должно быть явно сказано;
|
||||
- если точные названия индексов неизвестны, можно использовать осмысленные проектные названия.
|
||||
@@ -0,0 +1,12 @@
|
||||
# DB Table Purpose Rules
|
||||
|
||||
## Что описывать
|
||||
- назначение таблицы;
|
||||
- в каком сценарии она используется;
|
||||
- кто является владельцем данных;
|
||||
- является ли таблица источником истины или производным хранилищем.
|
||||
|
||||
## Формат
|
||||
- 1-3 абзаца без воды;
|
||||
- явно указывать доменную сущность, которую хранит таблица;
|
||||
- если сделаны допущения по БД, фиксировать их отдельной фразой.
|
||||
@@ -0,0 +1,11 @@
|
||||
# DB Usage Rules
|
||||
|
||||
## Что описывать
|
||||
- какие API / logic block / batch job используют таблицу;
|
||||
- какие операции выполняются: read / insert / update / delete;
|
||||
- как таблица участвует в пользовательском сценарии.
|
||||
|
||||
## Правила
|
||||
- ссылки на связанные документы давать по `doc_id` или path;
|
||||
- не дублировать полный use case, а показывать роль таблицы в сценарии;
|
||||
- если таблица используется для пагинации, фильтрации или сортировки, это нужно отметить явно.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Details Rules
|
||||
|
||||
## Назначение
|
||||
Этот файл задает общие правила для секции `## Details`.
|
||||
|
||||
## Правила
|
||||
- `Details` оформляется как `## Details`.
|
||||
- Внутри `Details` используются заголовки уровня `###` и ниже.
|
||||
- Структура `Details` определяется template типа документа.
|
||||
- В `Details` не нужно дублировать навигацию и связи, если они уже есть во frontmatter.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Functional Requirements Rules
|
||||
|
||||
## Формат
|
||||
- `FR.<номер>. <Название>`
|
||||
- Нумерация инкрементальная внутри документа.
|
||||
|
||||
## Правила
|
||||
- FR расширяют шаги сценария.
|
||||
- FR не копируют шаги сценария без добавления новой информации.
|
||||
- Для интеграционных шагов FR обязательны.
|
||||
- Если в сценарии есть вызов внешнего API / сервиса / БД, нужен отдельный FR на интеграцию.
|
||||
|
||||
## FR для интеграционных шагов
|
||||
Для интеграционного FR обязательно раскрывать:
|
||||
- как формируется запрос;
|
||||
- откуда берется каждый значимый атрибут запроса;
|
||||
- какой downstream вызывается;
|
||||
- какой ответ считается успешным;
|
||||
- какие ответы и ситуации считаются бизнес-ошибкой;
|
||||
- какие ситуации считаются технической ошибкой;
|
||||
- как downstream-ответ маппится в контракт текущего слоя.
|
||||
|
||||
## FR для шагов доступа к БД
|
||||
Если шаг читает или пишет БД, FR должен по возможности включать:
|
||||
- таблицу или набор таблиц;
|
||||
- логику фильтрации;
|
||||
- логику сортировки;
|
||||
- логику пагинации;
|
||||
- пример SQL или близкий к рабочему псевдо-SQL.
|
||||
|
||||
Если СУБД и диалект не заданы, допускается сделать рабочее предположение и явно зафиксировать его.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Non-Functional Requirements Rules
|
||||
|
||||
## Для api_method
|
||||
- Подразделы:
|
||||
- `#### Аудит` (если применимо)
|
||||
- `#### Мониторинг`
|
||||
|
||||
## Мониторинг
|
||||
Оформлять таблицей:
|
||||
- `Метрика`
|
||||
- `Описание`
|
||||
- `Условие срабатывания`
|
||||
|
||||
Запрещено:
|
||||
- использовать «точка измерения = метод» вместо условий срабатывания.
|
||||
|
||||
Базовые суффиксы метрик:
|
||||
- `_SUCCESS`
|
||||
- `_FAIL`
|
||||
- `_BUSINESS_ERROR`
|
||||
@@ -0,0 +1,15 @@
|
||||
# SQL Example Rules
|
||||
|
||||
## Назначение
|
||||
Секция показывает пример рабочего SQL для основного сценария использования таблицы.
|
||||
|
||||
## Правила
|
||||
- SQL должен быть близок к рабочему, а не абстрактным псевдокодом;
|
||||
- если диалект БД не указан, допускается выбрать наиболее вероятный вариант и явно зафиксировать допущение;
|
||||
- пример должен отражать реальный сценарий документа: чтение, вставка, обновление или агрегация;
|
||||
- для read-сценариев по возможности показывать фильтрацию, сортировку и пагинацию;
|
||||
- если есть join, нужно кратко пояснить, зачем он нужен.
|
||||
|
||||
## Формат
|
||||
- fenced code block с указанием `sql`;
|
||||
- под кодом 1-3 поясняющих bullets о ключевых условиях, индексах и параметрах.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Summary Rules
|
||||
|
||||
## Назначение
|
||||
Этот файл задает правила для секции `## Summary`.
|
||||
|
||||
## Правила
|
||||
- `Summary` должен быть коротким слоем быстрого контекста.
|
||||
- `Summary` должен объяснять суть документа без длинных деталей.
|
||||
- Предпочтительный формат: краткий список ключевых фактов.
|
||||
- `Summary` не должен дублировать `Details`.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Tech Use Case Rules
|
||||
|
||||
## Обязательные части
|
||||
- название
|
||||
- предусловия
|
||||
- триггер
|
||||
- основной сценарий
|
||||
- альтернативный сценарий
|
||||
- обработка ошибок
|
||||
- постусловие
|
||||
|
||||
## Правила шага
|
||||
- Один шаг = одно предложение до 15-20 слов.
|
||||
- Формат шага: смысловое действие + техническая реализация (endpoint/топик/операция).
|
||||
- Длинные технические детали выносить в FR и ссылаться на FR из шага.
|
||||
- Для интеграционных шагов описание обработки ошибок обязательно.
|
||||
@@ -0,0 +1,22 @@
|
||||
# UI Requirements Rules
|
||||
|
||||
## Структура блока
|
||||
- `### Требования к UI`
|
||||
- Внутри обязательно отдельные формы:
|
||||
- табличное представление
|
||||
- пустой список (empty state)
|
||||
- ошибка (error state)
|
||||
|
||||
## Обязательные правила
|
||||
- Если есть интеграция, обязательно описывать показ ошибки.
|
||||
- Если есть список, обязательно описывать показ отсутствия данных.
|
||||
|
||||
## Описание UI-элементов
|
||||
UI-элементы описываются строго в таблице.
|
||||
|
||||
Обязательные колонки (где применимо):
|
||||
- `Код элемента`
|
||||
- `Название и описание`
|
||||
- `Данные`
|
||||
- `Поведение`
|
||||
- `Валидация`
|
||||
@@ -0,0 +1,7 @@
|
||||
# User Analytics Rules
|
||||
|
||||
События пользовательской аналитики оформлять таблицей:
|
||||
- `Название события`
|
||||
- `Описание`
|
||||
- `Точка вызова`
|
||||
- `Payload`
|
||||
@@ -0,0 +1,45 @@
|
||||
# Documentation Rules V3
|
||||
|
||||
## 1. Общий контракт
|
||||
- Документация строится на основе системной аналитики, но на более детальном уровне.
|
||||
- Заголовки отражают только суть раздела; метаданные в заголовках запрещены.
|
||||
- Метаданные указываются во frontmatter и/или отдельными строками в body.
|
||||
- Структура документа определяется только template соответствующего типа.
|
||||
- Правила написания конкретного раздела определяются только соответствующим `common-elements` файлом.
|
||||
- Manifest типа документа хранится во frontmatter соответствующего template.
|
||||
|
||||
## 2. Источники требований
|
||||
При генерации документа учитывать:
|
||||
- `/Users/alex/Dev_projects_v2/ai driven app process/v2/agent/_process/04. Analitycs artefacts - documentation.md`
|
||||
- `/Users/alex/Dev_projects_v2/ai driven app process/v2/agent/_process/04. Analitycs artefacts - features.md`
|
||||
- правила v2 из `src/app/core/agent/processes/v2/doc_rules_v2`
|
||||
|
||||
## 3. Разрыв аналитика vs документация
|
||||
- Аналитика: концептуальная, укрупненная.
|
||||
- Документация: технически детальная.
|
||||
- Технический use case в документации не копирует аналитический 1-в-1, а детализирует его.
|
||||
- Функциональные требования расширяют сценарий и не дублируют шаги без новой информации.
|
||||
|
||||
## 4. Заполнение пробелов
|
||||
Если атрибуты/детали отсутствуют в аналитике:
|
||||
1. восстановить из формулировок аналитики;
|
||||
2. уточнить по репозиторию (код, контракты, существующие документы);
|
||||
3. зафиксировать в документации явно.
|
||||
|
||||
## 5. Сборка итогового промпта
|
||||
1. Загрузить global-правила.
|
||||
2. Загрузить template типа документа.
|
||||
3. Прочитать YAML frontmatter template как manifest.
|
||||
4. Загрузить общие блоки, указанные в manifest.
|
||||
5. Применить body template как единственный источник структуры.
|
||||
5. Проверить чек-лист совместимости с аналитикой (domain/sub_domain, роли слоев, интеграции, ошибки).
|
||||
|
||||
## 6. Формат manifest типа документа
|
||||
Manifest типа документа хранится во frontmatter `templates/<doc_type>.template.md`.
|
||||
|
||||
Минимальная схема:
|
||||
- `doc_type`
|
||||
- `required_common_elements`
|
||||
|
||||
Дополнительно можно указывать:
|
||||
- `special_rules`
|
||||
@@ -0,0 +1,10 @@
|
||||
# Analytics to Documentation Mapping
|
||||
|
||||
## Принцип
|
||||
- Системная аналитика задает «что».
|
||||
- Документация детализирует «как».
|
||||
|
||||
## Маппинг
|
||||
- Из раздела архитектуры аналитики переносить контейнеры, интеграции и цепочки вызовов.
|
||||
- Из раздела изменений аналитики строить отдельные технические страницы (`ui_page`, `api_method`, `logic_block`).
|
||||
- Если в аналитике упрощенный use case, в документации раскрывать полный технический сценарий по правилам `tech-use-case.md`.
|
||||
@@ -0,0 +1,67 @@
|
||||
# Правила определения путей файлов
|
||||
|
||||
Текущая happy-path реализация строит путь документа по фиксированному шаблону:
|
||||
|
||||
`docs/<domain>/<platform>/<doc_type>/<doc_id>.md`
|
||||
|
||||
Пример:
|
||||
|
||||
`docs/orders/pprb/ui_page/orders.ui.list.md`
|
||||
|
||||
## Источники атрибутов
|
||||
|
||||
Для построения пути используются четыре основных атрибута:
|
||||
|
||||
- `domain`
|
||||
- `application`
|
||||
- `platform`
|
||||
- `doc_type`
|
||||
- `id` как `doc_id`
|
||||
|
||||
Если атрибуты явно указаны в подразделе `6.x`, нужно использовать их.
|
||||
Если атрибут не указан, он может быть взят из общих метаданных аналитики или определен fallback-логикой.
|
||||
|
||||
## Нормализация сегментов
|
||||
|
||||
Каждый сегмент пути нормализуется одинаково:
|
||||
|
||||
- значение переводится в lowercase;
|
||||
- все символы, кроме `a-z`, `0-9`, `.`, `_`, `-`, заменяются на `-`;
|
||||
- ведущие и хвостовые `.` и `-` удаляются.
|
||||
|
||||
Примеры нормализации:
|
||||
|
||||
- `Payment Status` -> `payment-status`
|
||||
- `UFS Orders` -> `ufs-orders`
|
||||
- `crm.mobile` -> `crm.mobile`
|
||||
|
||||
## Значения по умолчанию
|
||||
|
||||
Если после нормализации сегмент пустой, используются fallback-значения:
|
||||
|
||||
- корневая папка: `domain`, иначе `application`, иначе `common`
|
||||
- `platform` -> `web`
|
||||
- `doc_type` -> `misc`
|
||||
- `doc_id` -> `untitled`
|
||||
|
||||
## Что важно в текущей версии
|
||||
|
||||
- для корневой папки сначала используется `domain`;
|
||||
- если `domain` не задан, используется `application`;
|
||||
- `sub_domain` сейчас не участвует в построении пути;
|
||||
- операции `create`, `update`, `delete` работают с одним и тем же правилом вычисления пути;
|
||||
- специальных исключений для разных типов документов пока нет;
|
||||
- отдельные каталоги для `pprb`, `ufs`, `web` задаются только через значение `platform`.
|
||||
|
||||
## Практическое правило для агента
|
||||
|
||||
Если нужно предложить или определить путь новой страницы, агент должен:
|
||||
|
||||
1. определить `application`;
|
||||
2. определить `domain`;
|
||||
3. определить `platform`;
|
||||
4. определить `doc_type`;
|
||||
5. определить стабильный `doc_id`;
|
||||
6. взять корневую папку как `domain`, а если он пустой, то `application`;
|
||||
7. нормализовать все сегменты;
|
||||
8. собрать путь по шаблону `docs/<root>/<platform>/<doc_type>/<doc_id>.md`.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Frontmatter Rules
|
||||
|
||||
## Обязательные поля
|
||||
```yaml
|
||||
id: string
|
||||
title: string
|
||||
doc_type: string
|
||||
domain: string
|
||||
sub_domain: string
|
||||
related_docs: []
|
||||
status: string
|
||||
```
|
||||
|
||||
## Рекомендуемые поля
|
||||
```yaml
|
||||
tags: []
|
||||
entities: []
|
||||
source_of_truth: string
|
||||
related_code: []
|
||||
system_analytics_refs: []
|
||||
```
|
||||
|
||||
## Body-метаданные для секции изменений
|
||||
Под корнем секции изменений указывать:
|
||||
- `domain`
|
||||
- `sub_domain`
|
||||
|
||||
Для каждого подраздела `X.Y` указывать строками:
|
||||
- `id`
|
||||
- `doc_type`
|
||||
- `application`
|
||||
- `platform`
|
||||
@@ -0,0 +1,10 @@
|
||||
# Header Rules
|
||||
|
||||
## Правила
|
||||
- Заголовок описывает только смысл раздела.
|
||||
- Не включать в заголовок: `id`, `doc_type`, `application`, `platform`, `domain`, `sub_domain`.
|
||||
- Метаданные указываются отдельными строками ниже заголовка или во frontmatter.
|
||||
|
||||
## Пример
|
||||
- Правильно: `## 6.2 Метод UFS получения списка заказов`
|
||||
- Неправильно: `## 6.2 Блок api_method (id=..., platform=ufs)`
|
||||
@@ -0,0 +1,10 @@
|
||||
# Layer Responsibility
|
||||
|
||||
- `ui`: отображение, UX, запуск пользовательских сценариев.
|
||||
- `ufs`: авторизация/аутентификация, агрегация, маппинг, оркестрация вызовов.
|
||||
- `pprb`: API, БД, доменная логика backend.
|
||||
|
||||
## Правила согласованности
|
||||
- Проверка ролевой модели пользователя обычно фиксируется на уровне `ufs`.
|
||||
- Если проверка роли вынесена в `ufs`, в `pprb`-сценарии не дублировать этот шаг.
|
||||
- Аудит для `pprb` может отсутствовать, если это явно принято для домена/фичи.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
doc_type: api_method
|
||||
required_common_elements:
|
||||
- common-elements/summary.md
|
||||
- common-elements/details.md
|
||||
- common-elements/tech-use-case.md
|
||||
- common-elements/fr.md
|
||||
- common-elements/nfr.md
|
||||
- common-elements/api-contract.md
|
||||
special_rules:
|
||||
- Технический use case детализируется по `common-elements/tech-use-case.md`.
|
||||
- FR расширяют use case и не дублируют шаги сценария без новой информации.
|
||||
- Для интеграционных шагов FR обязательны.
|
||||
---
|
||||
|
||||
# <title>
|
||||
|
||||
## Summary
|
||||
Правила оформления: `../common-elements/summary.md`
|
||||
|
||||
## Details
|
||||
Правила оформления: `../common-elements/details.md`
|
||||
|
||||
### Технический use case
|
||||
Правила оформления: `../common-elements/tech-use-case.md`
|
||||
|
||||
### Функциональные требования
|
||||
Правила оформления: `../common-elements/fr.md`
|
||||
|
||||
### Нефункциональные требования
|
||||
Правила оформления: `../common-elements/nfr.md`
|
||||
|
||||
### Контракт
|
||||
Правила оформления: `../common-elements/api-contract.md`
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
doc_type: db_table
|
||||
required_common_elements:
|
||||
- common-elements/summary.md
|
||||
- common-elements/details.md
|
||||
- common-elements/db-purpose.md
|
||||
- common-elements/db-columns.md
|
||||
- common-elements/db-constraints.md
|
||||
- common-elements/db-usage.md
|
||||
- common-elements/sql-example.md
|
||||
special_rules:
|
||||
- Документ описывает одну физическую таблицу БД или materialized view.
|
||||
- Нужно фиксировать назначение таблицы, поля, ограничения, индексы, связи и сценарии использования.
|
||||
- Если точные детали БД не заданы, допустимо сделать рабочие инженерные допущения и явно записать их в документ.
|
||||
---
|
||||
|
||||
# <title>
|
||||
|
||||
## Summary
|
||||
Правила оформления: `../common-elements/summary.md`
|
||||
|
||||
## Details
|
||||
Правила оформления: `../common-elements/details.md`
|
||||
|
||||
### Назначение таблицы
|
||||
Правила оформления: `../common-elements/db-purpose.md`
|
||||
|
||||
### Структура таблицы
|
||||
Правила оформления: `../common-elements/db-columns.md`
|
||||
|
||||
### Ограничения и индексы
|
||||
Правила оформления: `../common-elements/db-constraints.md`
|
||||
|
||||
### Использование в сценариях
|
||||
Правила оформления: `../common-elements/db-usage.md`
|
||||
|
||||
### Пример SQL
|
||||
Правила оформления: `../common-elements/sql-example.md`
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
doc_type: logic_block
|
||||
required_common_elements:
|
||||
- common-elements/summary.md
|
||||
- common-elements/details.md
|
||||
- common-elements/tech-use-case.md
|
||||
- common-elements/fr.md
|
||||
- common-elements/nfr.md
|
||||
special_rules:
|
||||
- Logic block описывает переиспользуемую логику без дублирования UI/API деталей.
|
||||
---
|
||||
|
||||
# <title>
|
||||
|
||||
## Summary
|
||||
Правила оформления: `../common-elements/summary.md`
|
||||
|
||||
## Details
|
||||
Правила оформления: `../common-elements/details.md`
|
||||
|
||||
### Технический use case
|
||||
Правила оформления: `../common-elements/tech-use-case.md`
|
||||
|
||||
### Функциональные требования
|
||||
Правила оформления: `../common-elements/fr.md`
|
||||
|
||||
### Нефункциональные требования
|
||||
Правила оформления: `../common-elements/nfr.md`
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
doc_type: ui_page
|
||||
required_common_elements:
|
||||
- common-elements/summary.md
|
||||
- common-elements/details.md
|
||||
- common-elements/tech-use-case.md
|
||||
- common-elements/ui-requirements.md
|
||||
- common-elements/fr.md
|
||||
- common-elements/user-analytics.md
|
||||
special_rules:
|
||||
- Для списочных страниц обязательно описывать табличное представление, empty state и error state.
|
||||
- UI-элементы описываются в таблицах по правилам `common-elements/ui-requirements.md`.
|
||||
---
|
||||
|
||||
# <title>
|
||||
|
||||
## Summary
|
||||
Правила оформления: `../common-elements/summary.md`
|
||||
|
||||
## Details
|
||||
Правила оформления: `../common-elements/details.md`
|
||||
|
||||
### Технический use case
|
||||
Правила оформления: `../common-elements/tech-use-case.md`
|
||||
|
||||
### Требования к UI
|
||||
Правила оформления: `../common-elements/ui-requirements.md`
|
||||
|
||||
### Функциональные требования
|
||||
Правила оформления: `../common-elements/fr.md`
|
||||
|
||||
### Нефункциональные требования
|
||||
Правила оформления: `../common-elements/user-analytics.md`
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,103 +0,0 @@
|
||||
# Runtime Trace: 20260408-130754-c008300db553
|
||||
|
||||
- active_rag_session_id: 273bb6f2-0921-412a-9c73-c008300db553
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_e2b3901d8fcd4b2f88ba2fd5e09e4073",
|
||||
"session_id": "as_da9ab26d0dbe4ee2b6a2b392ff1ebdc9",
|
||||
"active_rag_session_id": "273bb6f2-0921-412a-9c73-c008300db553",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:07:54.329187+00:00",
|
||||
"message": "Напиши документацию по системной аналитике \n/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FIND_FILES",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY",
|
||||
"FIND_FILES"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по системной аналитике из конкретного файла feature1.md.",
|
||||
"rag_session_id": "273bb6f2-0921-412a-9c73-c008300db553"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FIND_FILES",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY",
|
||||
"FIND_FILES"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "error",
|
||||
"error": {
|
||||
"code": "api_runtime_error",
|
||||
"desc": "Agent request failed unexpectedly.",
|
||||
"module": "agent"
|
||||
},
|
||||
"completed_at": "2026-04-08T13:07:57.414809+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,103 +0,0 @@
|
||||
# Runtime Trace: 20260408-130830-d398ef674b67
|
||||
|
||||
- active_rag_session_id: b0fed7d3-965b-4103-91b5-d398ef674b67
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_9ee1b7dae1cb4f8dbc81537e678734b8",
|
||||
"session_id": "as_c1e2c54c04c4483da7f956fb94fedd3e",
|
||||
"active_rag_session_id": "b0fed7d3-965b-4103-91b5-d398ef674b67",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:08:30.296355+00:00",
|
||||
"message": "Напиши документацию по системной аналитике \n/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FIND_FILES",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY",
|
||||
"FIND_FILES"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по системной аналитике из указанного файла feature1.md.",
|
||||
"rag_session_id": "b0fed7d3-965b-4103-91b5-d398ef674b67"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FIND_FILES",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY",
|
||||
"FIND_FILES"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "error",
|
||||
"error": {
|
||||
"code": "api_runtime_error",
|
||||
"desc": "Agent request failed unexpectedly.",
|
||||
"module": "agent"
|
||||
},
|
||||
"completed_at": "2026-04-08T13:08:32.914987+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,303 +0,0 @@
|
||||
# Runtime Trace: 20260408-131217-d6aef7712b50
|
||||
|
||||
- active_rag_session_id: 09fb3332-3623-4164-9bb4-d6aef7712b50
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_44b293c2d2d34247a4ad4ffbf6e529f9",
|
||||
"session_id": "as_c3998b60e2814f7090ead25d83aa990e",
|
||||
"active_rag_session_id": "09fb3332-3623-4164-9bb4-d6aef7712b50",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:12:17.468690+00:00",
|
||||
"message": "Напиши документацию по системной аналитике \n/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по указанному файлу feature1.md.",
|
||||
"rag_session_id": "09fb3332-3623-4164-9bb4-d6aef7712b50"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "resolve_source",
|
||||
"title": "Определение источника аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "load_source",
|
||||
"title": "Загрузка системной аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_change_plan",
|
||||
"title": "Построение плана изменений"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_changeset",
|
||||
"title": "Формирование changeset"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "finalize",
|
||||
"title": "Подготовка ответа"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 801,
|
||||
"issues": 0,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "resolve_source",
|
||||
"title": "Определение источника аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "load_source",
|
||||
"title": "Загрузка системной аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований",
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_change_plan",
|
||||
"title": "Построение плана изменений",
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_changeset",
|
||||
"title": "Формирование changeset",
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize",
|
||||
"title": "Подготовка ответа",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 801,
|
||||
"issues": 0,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "docs_update_changeset",
|
||||
"answer_length": 801,
|
||||
"changeset_items": 1
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nПлан изменений:\n- create: docs/api/api-telegram-messages-get.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/api/api-telegram-messages-get.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: api.telegram.messages.get\\ntitle: Реализация эндпоинта `GET /telegram/messages`\\ndoc_type: api_method\\ndomain: unknown\\nsub_domain: unknown\\nstatus: generated\\nrelated_docs:\\n - TBD\\nsource_of_truth: system_analysis\\nsystem_analytics_refs:\\n - section: 5. Функциональные требования\\n---\\n\\n## Summary\\n\\nЧерновик сгенерирован workflow DOC_UPDATE/FROM_FEATURE.\\n\",\n \"reason\": \"Из unit 'Реализация эндпоинта `GET /telegram/messages`' системной аналитики (analysis).\",\n \"hunks\": []\n }\n]\n```",
|
||||
"completed_at": "2026-04-08T13:12:20.251846+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,303 +0,0 @@
|
||||
# Runtime Trace: 20260408-133710-3fcdfdcab8be
|
||||
|
||||
- active_rag_session_id: a603ea81-9785-4846-8c05-3fcdfdcab8be
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_c5a90cbf219046cc91239e4fae39ac3e",
|
||||
"session_id": "as_5bad25c4dd394e33884ff7471bbcbf4a",
|
||||
"active_rag_session_id": "a603ea81-9785-4846-8c05-3fcdfdcab8be",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:37:10.869126+00:00",
|
||||
"message": "Напиши документацию по системной аналитике \n/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по указанному файлу feature1.md.",
|
||||
"rag_session_id": "a603ea81-9785-4846-8c05-3fcdfdcab8be"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "resolve_source",
|
||||
"title": "Определение источника аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "load_source",
|
||||
"title": "Загрузка системной аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_change_plan",
|
||||
"title": "Построение плана изменений"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_changeset",
|
||||
"title": "Формирование changeset"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "finalize",
|
||||
"title": "Подготовка ответа"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2340,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "resolve_source",
|
||||
"title": "Определение источника аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "load_source",
|
||||
"title": "Загрузка системной аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований",
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_change_plan",
|
||||
"title": "Построение плана изменений",
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_changeset",
|
||||
"title": "Формирование changeset",
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize",
|
||||
"title": "Подготовка ответа",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2340,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "docs_update_changeset",
|
||||
"answer_length": 2340,
|
||||
"changeset_items": 1
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nОбнаружены несоответствия/нехватка данных:\n- Отсутствует analysis_id в metadata аналитики.\n- Отсутствует domains в metadata аналитики.\n- Отсутствует subdomains в metadata аналитики.\n\nПлан изменений:\n- create: docs/api/api-telegram-messages-get.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/api/api-telegram-messages-get.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: api.telegram.messages.get\\ntitle: Реализация эндпоинта `GET /telegram/messages`\\ndoc_type: api_method\\ndomain: unknown\\nsub_domain: unknown\\nstatus: generated\\nrelated_docs:\\n - TBD\\nsource_of_truth: system_analysis\\nsystem_analytics_refs:\\n - section: 5. Функциональные требования\\n---\\n\\n## Context\\n\\nЧерновик сгенерирован workflow DOC_UPDATE/FROM_FEATURE на основе системной аналитики.\\n\\n## Functional Requirements\\n\\nСценарий описывает поведение endpoint и включает все обязательные функциональные требования.\\n\\n1. Потребитель вызывает endpoint `GET /telegram/messages` и передает параметр `secret`.\\n2. Сервис сравнивает переданный `secret` со значением `APP_ENDPOINT_SECRET` из защищенной конфигурации.\\n3. Если `secret` не совпадает:\\n\\n- сервис возвращает отказ в доступе (`403 Forbidden`);\\n- обработка завершается;\\n- вызов в Telegram API не выполняется.\\n\\n1. Если `secret` совпадает, сервис выполняет вызов Telegram Bot API:\\n\\n- Метод: `getUpdates`;\\n- HTTP: `POST https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getUpdates`;\\n- Допустимые параметры запроса (по необходимости): `offset`, `limit`, `timeout`, `allowed_updates`.\\n\\n1. Сервис получает список update, выделяет непрочитанные (необработанные) сообщения и формирует доменный результат.\\n2. Сервис возвращает клиенту ответ в формате `AppResponseDto` (статус выполнения + полезная нагрузка).\\n3. Если Telegram API возвращает ошибку/некорректный ответ, сервис возвращает контролируемую ошибку без утечки внутренних данных интеграции.\\n\\nНеобходимые секреты для реализации сценария:\\n\\n- `APP_ENDPOINT_SECRET` - секрет для авторизации входящего запроса к endpoint;\\n- `TELEGRAM_BOT_TOKEN` - токен Telegram-бота для вызова метода `getUpdates`.\\n\",\n \"reason\": \"Из unit 'Реализация эндпоинта `GET /telegram/messages`' системной аналитики (analysis).\",\n \"hunks\": []\n }\n]\n```",
|
||||
"completed_at": "2026-04-08T13:37:13.627111+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,305 +0,0 @@
|
||||
# Runtime Trace: 20260408-134243-ae814cadec74
|
||||
|
||||
- active_rag_session_id: 07b0a164-32cd-47cc-ba4d-ae814cadec74
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_a1f51efe7fe540a393f2840f830f0710",
|
||||
"session_id": "as_968bcb99e71d454eb0b38cbe5021ac32",
|
||||
"active_rag_session_id": "07b0a164-32cd-47cc-ba4d-ae814cadec74",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:42:43.644632+00:00",
|
||||
"message": "Напиши документацию по системной аналитике\n/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по системной аналитике из указанного файла feature1.md.",
|
||||
"rag_session_id": "07b0a164-32cd-47cc-ba4d-ae814cadec74"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "resolve_source",
|
||||
"title": "Определение источника аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "load_source",
|
||||
"title": "Загрузка системной аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_change_plan",
|
||||
"title": "Построение плана изменений"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_changeset",
|
||||
"title": "Формирование changeset"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "finalize",
|
||||
"title": "Подготовка ответа"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2340,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "resolve_source",
|
||||
"title": "Определение источника аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "load_source",
|
||||
"title": "Загрузка системной аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований",
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_change_plan",
|
||||
"title": "Построение плана изменений",
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_changeset",
|
||||
"title": "Формирование changeset",
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize",
|
||||
"title": "Подготовка ответа",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2340,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "docs_update_changeset",
|
||||
"answer_length": 2340,
|
||||
"changeset_items": 1
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nОбнаружены несоответствия/нехватка данных:\n- Отсутствует analysis_id в metadata аналитики.\n- Отсутствует domains в metadata аналитики.\n- Отсутствует subdomains в metadata аналитики.\n\nПлан изменений:\n- create: docs/api/api-telegram-messages-get.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/api/api-telegram-messages-get.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: api.telegram.messages.get\\ntitle: Реализация эндпоинта `GET /telegram/messages`\\ndoc_type: api_method\\ndomain: unknown\\nsub_domain: unknown\\nstatus: generated\\nrelated_docs:\\n - TBD\\nsource_of_truth: system_analysis\\nsystem_analytics_refs:\\n - section: 5. Функциональные требования\\n---\\n\\n## Context\\n\\nЧерновик сгенерирован workflow DOC_UPDATE/FROM_FEATURE на основе системной аналитики.\\n\\n## Functional Requirements\\n\\nСценарий описывает поведение endpoint и включает все обязательные функциональные требования.\\n\\n1. Потребитель вызывает endpoint `GET /telegram/messages` и передает параметр `secret`.\\n2. Сервис сравнивает переданный `secret` со значением `APP_ENDPOINT_SECRET` из защищенной конфигурации.\\n3. Если `secret` не совпадает:\\n\\n- сервис возвращает отказ в доступе (`403 Forbidden`);\\n- обработка завершается;\\n- вызов в Telegram API не выполняется.\\n\\n1. Если `secret` совпадает, сервис выполняет вызов Telegram Bot API:\\n\\n- Метод: `getUpdates`;\\n- HTTP: `POST https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getUpdates`;\\n- Допустимые параметры запроса (по необходимости): `offset`, `limit`, `timeout`, `allowed_updates`.\\n\\n1. Сервис получает список update, выделяет непрочитанные (необработанные) сообщения и формирует доменный результат.\\n2. Сервис возвращает клиенту ответ в формате `AppResponseDto` (статус выполнения + полезная нагрузка).\\n3. Если Telegram API возвращает ошибку/некорректный ответ, сервис возвращает контролируемую ошибку без утечки внутренних данных интеграции.\\n\\nНеобходимые секреты для реализации сценария:\\n\\n- `APP_ENDPOINT_SECRET` - секрет для авторизации входящего запроса к endpoint;\\n- `TELEGRAM_BOT_TOKEN` - токен Telegram-бота для вызова метода `getUpdates`.\\n\",\n \"reason\": \"Из unit 'Реализация эндпоинта `GET /telegram/messages`' системной аналитики (analysis).\",\n \"hunks\": []\n }\n]\n```",
|
||||
"completed_at": "2026-04-08T13:42:47.600078+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,306 +0,0 @@
|
||||
# Runtime Trace: 20260408-135621-3d42c447c174
|
||||
|
||||
- active_rag_session_id: 7bc8440f-382f-4df3-9a82-3d42c447c174
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_5bd727fe052841efbbd9f69651e57bca",
|
||||
"session_id": "as_8d0e3b766f3a49b495e3074a3bcfe777",
|
||||
"active_rag_session_id": "7bc8440f-382f-4df3-9a82-3d42c447c174",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:56:21.477390+00:00",
|
||||
"message": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по системной аналитике из указанного файла feature1.md.",
|
||||
"rag_session_id": "7bc8440f-382f-4df3-9a82-3d42c447c174"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "resolve_source",
|
||||
"title": "Определение источника аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "load_source",
|
||||
"title": "Загрузка системной аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_change_plan",
|
||||
"title": "Построение плана изменений"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_changeset",
|
||||
"title": "Формирование changeset"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "finalize",
|
||||
"title": "Подготовка ответа"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2364,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "resolve_source",
|
||||
"title": "Определение источника аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "load_source",
|
||||
"title": "Загрузка системной аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований",
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_change_plan",
|
||||
"title": "Построение плана изменений",
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_changeset",
|
||||
"title": "Формирование changeset",
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize",
|
||||
"title": "Подготовка ответа",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2364,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "docs_update_changeset",
|
||||
"answer_length": 2364,
|
||||
"changeset_items": 1,
|
||||
"apply_changeset": false
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nОбнаружены несоответствия/нехватка данных:\n- Отсутствует analysis_id в metadata аналитики.\n- Отсутствует domains в metadata аналитики.\n- Отсутствует subdomains в metadata аналитики.\n\nПлан изменений:\n- create: docs/api/api-telegram-messages-get.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/api/api-telegram-messages-get.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: api.telegram.messages.get\\ntitle: Реализация эндпоинта `GET /telegram/messages`\\ndoc_type: api_method\\ndomain: unknown\\nsub_domain: unknown\\nstatus: generated\\nrelated_docs:\\n - TBD\\nsource_of_truth: system_analysis\\nsystem_analytics_refs:\\n - section: 5. Функциональные требования\\n---\\n\\n## Context\\n\\nЧерновик сгенерирован workflow DOC_UPDATE/FROM_FEATURE на основе системной аналитики.\\n\\n## Functional Requirements\\n\\nСценарий описывает поведение endpoint и включает все обязательные функциональные требования.\\n\\n1. Потребитель вызывает endpoint `GET /telegram/messages` и передает параметр `secret`.\\n2. Сервис сравнивает переданный `secret` со значением `APP_ENDPOINT_SECRET` из защищенной конфигурации.\\n3. Если `secret` не совпадает:\\n\\n- сервис возвращает отказ в доступе (`403 Forbidden`);\\n- обработка завершается;\\n- вызов в Telegram API не выполняется.\\n\\n1. Если `secret` совпадает, сервис выполняет вызов Telegram Bot API:\\n\\n- Метод: `getUpdates`;\\n- HTTP: `POST https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getUpdates`;\\n- Допустимые параметры запроса (по необходимости): `offset`, `limit`, `timeout`, `allowed_updates`.\\n\\n1. Сервис получает список update, выделяет непрочитанные (необработанные) сообщения и формирует доменный результат.\\n2. Сервис возвращает клиенту ответ в формате `AppResponseDto` (статус выполнения + полезная нагрузка).\\n3. Если Telegram API возвращает ошибку/некорректный ответ, сервис возвращает контролируемую ошибку без утечки внутренних данных интеграции.\\n\\nНеобходимые секреты для реализации сценария:\\n\\n- `APP_ENDPOINT_SECRET` - секрет для авторизации входящего запроса к endpoint;\\n- `TELEGRAM_BOT_TOKEN` - токен Telegram-бота для вызова метода `getUpdates`.\\n\",\n \"reason\": \"Из unit 'Реализация эндпоинта `GET /telegram/messages`' системной аналитики (analysis).\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: false",
|
||||
"completed_at": "2026-04-08T13:56:24.354339+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,306 +0,0 @@
|
||||
# Runtime Trace: 20260408-135847-14bbe60d0cc3
|
||||
|
||||
- active_rag_session_id: 3be9766d-2a4d-4fa6-9d86-14bbe60d0cc3
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_6662d31380114d628963f48516560a7e",
|
||||
"session_id": "as_6df21081790f4954b93cc47f6f418554",
|
||||
"active_rag_session_id": "3be9766d-2a4d-4fa6-9d86-14bbe60d0cc3",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-08T13:58:47.981631+00:00",
|
||||
"message": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"normalized_query": "Напиши документацию по системной аналитике /Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [
|
||||
"Users",
|
||||
"Dev_projects_v2"
|
||||
],
|
||||
"file_names": [
|
||||
"/users/alex/dev_projects_v2/apps/test_echo_app/_incoming/feature1.md"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
]
|
||||
},
|
||||
"confidence": 0.8,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно указывает на обновление документации по указанному файлу feature1.md.",
|
||||
"rag_session_id": "3be9766d-2a4d-4fa6-9d86-14bbe60d0cc3"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_UPDATE",
|
||||
"subintent": "FROM_FEATURE",
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [
|
||||
"DOMAIN_ENTITY"
|
||||
],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "resolve_source",
|
||||
"title": "Определение источника аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "load_source",
|
||||
"title": "Загрузка системной аналитики"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_change_plan",
|
||||
"title": "Построение плана изменений"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "build_changeset",
|
||||
"title": "Формирование changeset"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"step": {
|
||||
"id": "finalize",
|
||||
"title": "Подготовка ответа"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2363,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_update.from_feature",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "resolve_source",
|
||||
"title": "Определение источника аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"source_ref": "/Users/alex/Dev_projects_v2/apps/test_echo_app/_incoming/feature1.md",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "load_source",
|
||||
"title": "Загрузка системной аналитики",
|
||||
"input": {},
|
||||
"output": {
|
||||
"source_kind": "markdown_file",
|
||||
"content_loaded": true,
|
||||
"project_root": "/Users/alex/Dev_projects_v2/apps/test_echo_app",
|
||||
"issues": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "parse_feature",
|
||||
"title": "Парсинг функциональных требований",
|
||||
"input": {},
|
||||
"output": {
|
||||
"analysis_id": "",
|
||||
"domains": [],
|
||||
"subdomains": [],
|
||||
"units": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_change_plan",
|
||||
"title": "Построение плана изменений",
|
||||
"input": {},
|
||||
"output": {
|
||||
"docs_rows": 26,
|
||||
"planned_changes": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_changeset",
|
||||
"title": "Формирование changeset",
|
||||
"input": {},
|
||||
"output": {
|
||||
"changeset_items": 1,
|
||||
"issues": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize",
|
||||
"title": "Подготовка ответа",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 2363,
|
||||
"issues": 3,
|
||||
"changeset_items": 1
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.docs_update.from_feature
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_update.from_feature"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "docs_update_changeset",
|
||||
"answer_length": 2363,
|
||||
"changeset_items": 1,
|
||||
"apply_changeset": true
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nОбнаружены несоответствия/нехватка данных:\n- Отсутствует analysis_id в metadata аналитики.\n- Отсутствует domains в metadata аналитики.\n- Отсутствует subdomains в metadata аналитики.\n\nПлан изменений:\n- create: docs/api/api-telegram-messages-get.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/api/api-telegram-messages-get.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: api.telegram.messages.get\\ntitle: Реализация эндпоинта `GET /telegram/messages`\\ndoc_type: api_method\\ndomain: unknown\\nsub_domain: unknown\\nstatus: generated\\nrelated_docs:\\n - TBD\\nsource_of_truth: system_analysis\\nsystem_analytics_refs:\\n - section: 5. Функциональные требования\\n---\\n\\n## Context\\n\\nЧерновик сгенерирован workflow DOC_UPDATE/FROM_FEATURE на основе системной аналитики.\\n\\n## Functional Requirements\\n\\nСценарий описывает поведение endpoint и включает все обязательные функциональные требования.\\n\\n1. Потребитель вызывает endpoint `GET /telegram/messages` и передает параметр `secret`.\\n2. Сервис сравнивает переданный `secret` со значением `APP_ENDPOINT_SECRET` из защищенной конфигурации.\\n3. Если `secret` не совпадает:\\n\\n- сервис возвращает отказ в доступе (`403 Forbidden`);\\n- обработка завершается;\\n- вызов в Telegram API не выполняется.\\n\\n1. Если `secret` совпадает, сервис выполняет вызов Telegram Bot API:\\n\\n- Метод: `getUpdates`;\\n- HTTP: `POST https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getUpdates`;\\n- Допустимые параметры запроса (по необходимости): `offset`, `limit`, `timeout`, `allowed_updates`.\\n\\n1. Сервис получает список update, выделяет непрочитанные (необработанные) сообщения и формирует доменный результат.\\n2. Сервис возвращает клиенту ответ в формате `AppResponseDto` (статус выполнения + полезная нагрузка).\\n3. Если Telegram API возвращает ошибку/некорректный ответ, сервис возвращает контролируемую ошибку без утечки внутренних данных интеграции.\\n\\nНеобходимые секреты для реализации сценария:\\n\\n- `APP_ENDPOINT_SECRET` - секрет для авторизации входящего запроса к endpoint;\\n- `TELEGRAM_BOT_TOKEN` - токен Telegram-бота для вызова метода `getUpdates`.\\n\",\n \"reason\": \"Из unit 'Реализация эндпоинта `GET /telegram/messages`' системной аналитики (analysis).\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true",
|
||||
"completed_at": "2026-04-08T13:58:52.631789+00:00"
|
||||
}
|
||||
```
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,347 +0,0 @@
|
||||
# Runtime Trace: 20260409-143441-a16face9a0ab
|
||||
|
||||
- active_rag_session_id: 3d1215ce-79fc-4c87-bf29-a16face9a0ab
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_11c7ba17c1fa47faa497f324f165c1ee",
|
||||
"session_id": "as_7827e863066042b2a6b4be9e8153acdf",
|
||||
"active_rag_session_id": "3d1215ce-79fc-4c87-bf29-a16face9a0ab",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T14:34:41.894633+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [
|
||||
"методы",
|
||||
"апи",
|
||||
"проекте"
|
||||
],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "unknown",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.9500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается перечня доступных API-методов.",
|
||||
"rag_session_id": "3d1215ce-79fc-4c87-bf29-a16face9a0ab"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.9500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": [
|
||||
"методы",
|
||||
"апи",
|
||||
"проекте"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%",
|
||||
"%методы%",
|
||||
"%апи%",
|
||||
"%проекте%"
|
||||
],
|
||||
"query_signals": [
|
||||
"методы",
|
||||
"апи",
|
||||
"проекте"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%",
|
||||
"%методы%",
|
||||
"%апи%",
|
||||
"%проекте%"
|
||||
],
|
||||
"query_signals": [
|
||||
"методы",
|
||||
"апи",
|
||||
"проекте"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T14:34:43.947325+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,323 +0,0 @@
|
||||
# Runtime Trace: 20260409-143722-a9b20eb67e95
|
||||
|
||||
- active_rag_session_id: 35471db5-4c18-415d-b48e-a9b20eb67e95
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_2980c9e2eb324182a000e72b8307a56d",
|
||||
"session_id": "as_20c1a7f7aaec4885bc268beff2cae6a0",
|
||||
"active_rag_session_id": "35471db5-4c18-415d-b48e-a9b20eb67e95",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T14:37:22.885815+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов проекта.",
|
||||
"rag_session_id": "35471db5-4c18-415d-b48e-a9b20eb67e95"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T14:37:24.566326+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,323 +0,0 @@
|
||||
# Runtime Trace: 20260409-145546-36056dd8dcfe
|
||||
|
||||
- active_rag_session_id: 2d21c11a-66a3-464f-9e0f-36056dd8dcfe
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_ada6c4f21ef84484ae228a784f854fd8",
|
||||
"session_id": "as_0190277b106e4573875b6923235196f7",
|
||||
"active_rag_session_id": "2d21c11a-66a3-464f-9e0f-36056dd8dcfe",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T14:55:46.412183+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов проекта.",
|
||||
"rag_session_id": "2d21c11a-66a3-464f-9e0f-36056dd8dcfe"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T14:55:48.141440+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,323 +0,0 @@
|
||||
# Runtime Trace: 20260409-151154-b91584f20703
|
||||
|
||||
- active_rag_session_id: 43fa52d5-9de5-42df-a893-b91584f20703
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_934d42145442462a933fdc2c947d40f1",
|
||||
"session_id": "as_00827751b492436dad07247663772b07",
|
||||
"active_rag_session_id": "43fa52d5-9de5-42df-a893-b91584f20703",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T15:11:54.906256+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается перечисления методов API.",
|
||||
"rag_session_id": "43fa52d5-9de5-42df-a893-b91584f20703"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T15:11:56.675323+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,323 +0,0 @@
|
||||
# Runtime Trace: 20260409-151329-2d1087092e43
|
||||
|
||||
- active_rag_session_id: 8be14345-e958-4753-9057-2d1087092e43
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_05929401b62a4c85974ffb7eb543a682",
|
||||
"session_id": "as_a9ce0b45b3ba46aa89c0454462cabb54",
|
||||
"active_rag_session_id": "8be14345-e958-4753-9057-2d1087092e43",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T15:13:29.796982+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается перечисления методов API.",
|
||||
"rag_session_id": "8be14345-e958-4753-9057-2d1087092e43"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T15:13:31.532828+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,323 +0,0 @@
|
||||
# Runtime Trace: 20260409-151338-51ca80f9145e
|
||||
|
||||
- active_rag_session_id: eb664e6b-655a-46ca-b7e9-51ca80f9145e
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_4031d419064f454f97e0872671bbd00a",
|
||||
"session_id": "as_20977051bd8c4e6fa68cb489934fb998",
|
||||
"active_rag_session_id": "eb664e6b-655a-46ca-b7e9-51ca80f9145e",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-09T15:13:38.600938+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов.",
|
||||
"rag_session_id": "eb664e6b-655a-46ca-b7e9-51ca80f9145e"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0,
|
||||
"endpoints": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 0
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 62
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "insufficient_evidence",
|
||||
"answer_length": 62
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Не нашёл задокументированных API-эндпоинтов в выбранном scope.",
|
||||
"completed_at": "2026-04-09T15:13:41.304004+00:00"
|
||||
}
|
||||
```
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,511 +0,0 @@
|
||||
# Runtime Trace: 20260409-173834-30e34019284e
|
||||
|
||||
- active_rag_session_id: a6337d0c-ba32-4623-a0a7-30e34019284e
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_7ab17b2149da404eb4240744fc8caafd",
|
||||
"session_id": "as_314611f8510341588db2ef5c4d39c8af",
|
||||
"active_rag_session_id": "a6337d0c-ba32-4623-a0a7-30e34019284e",
|
||||
"process_version": "v1",
|
||||
"created_at": "2026-04-09T17:38:34.234881+00:00",
|
||||
"message": "Слава России"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"input": {}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"output": {
|
||||
"prepared_message_length": 12
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"input": {
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"prepared_message_length": 12
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "request",
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"system_prompt": "Ты полезный ассистент.\nОтветь на сообщение пользователя по существу.\nНе придумывай факты, если данных недостаточно.\nЕсли пользователь пишет по-русски, отвечай по-русски.",
|
||||
"user_prompt": "Слава России",
|
||||
"log_context": "agent:req_7ab17b2149da404eb4240744fc8caafd"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "response",
|
||||
"text": "Генеративные языковые модели не обладают собственным мнением — их ответы являются обобщением информации, находящейся в открытом доступе. Чтобы избежать ошибок и неправильного толкования, разговоры на чувствительные темы могут быть ограничены."
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"output": {
|
||||
"answer_length": 242
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"input": {
|
||||
"answer_length_before_strip": 242
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"output": {
|
||||
"answer_length": 242
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Генеративные языковые модели не обладают собственным мнением — их ответы являются обобщением информации, находящейся в открытом доступе. Чтобы избежать ошибок и неправильного толкования, разговоры на чувствительные темы могут быть ограничены.",
|
||||
"completed_at": "2026-04-09T17:38:34.571901+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_07784c71844a4be8b5b0eef444c6ae70",
|
||||
"session_id": "as_314611f8510341588db2ef5c4d39c8af",
|
||||
"active_rag_session_id": "a6337d0c-ba32-4623-a0a7-30e34019284e",
|
||||
"process_version": "v1",
|
||||
"created_at": "2026-04-09T17:38:38.999976+00:00",
|
||||
"message": "Слава КНР"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"input": {}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"output": {
|
||||
"prepared_message_length": 9
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"input": {
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"prepared_message_length": 9
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "request",
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"system_prompt": "Ты полезный ассистент.\nОтветь на сообщение пользователя по существу.\nНе придумывай факты, если данных недостаточно.\nЕсли пользователь пишет по-русски, отвечай по-русски.",
|
||||
"user_prompt": "Слава КНР",
|
||||
"log_context": "agent:req_07784c71844a4be8b5b0eef444c6ae70"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "response",
|
||||
"text": "Вы выразили уважение в адрес Китайской Народной Республики. Если хотите обсудить что-то конкретное или получить информацию о Китае, спрашивайте."
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"output": {
|
||||
"answer_length": 144
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"input": {
|
||||
"answer_length_before_strip": 144
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"output": {
|
||||
"answer_length": 144
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Вы выразили уважение в адрес Китайской Народной Республики. Если хотите обсудить что-то конкретное или получить информацию о Китае, спрашивайте.",
|
||||
"completed_at": "2026-04-09T17:38:40.015136+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_31c6227ead58470abe728eb51e5638f5",
|
||||
"session_id": "as_314611f8510341588db2ef5c4d39c8af",
|
||||
"active_rag_session_id": "a6337d0c-ba32-4623-a0a7-30e34019284e",
|
||||
"process_version": "v1",
|
||||
"created_at": "2026-04-09T17:38:59.421698+00:00",
|
||||
"message": "Слава КПСС"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"input": {}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"output": {
|
||||
"prepared_message_length": 10
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"input": {
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"prepared_message_length": 10
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "request",
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"system_prompt": "Ты полезный ассистент.\nОтветь на сообщение пользователя по существу.\nНе придумывай факты, если данных недостаточно.\nЕсли пользователь пишет по-русски, отвечай по-русски.",
|
||||
"user_prompt": "Слава КПСС",
|
||||
"log_context": "agent:req_31c6227ead58470abe728eb51e5638f5"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "response",
|
||||
"text": "Тебе, вероятно, известна эта аббревиатура как выражение уважения или ностальгии по Советскому Союзу и Коммунистической партии. Это часть истории нашей страны, которая вызывает разные чувства у разных людей. Если хочешь обсудить эту тему подробнее, я готов помочь."
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"output": {
|
||||
"answer_length": 263
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"input": {
|
||||
"answer_length_before_strip": 263
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"output": {
|
||||
"answer_length": 263
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Тебе, вероятно, известна эта аббревиатура как выражение уважения или ностальгии по Советскому Союзу и Коммунистической партии. Это часть истории нашей страны, которая вызывает разные чувства у разных людей. Если хочешь обсудить эту тему подробнее, я готов помочь.",
|
||||
"completed_at": "2026-04-09T17:39:00.634600+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_fa978ad58b8c41a6b9296f88250c379a",
|
||||
"session_id": "as_314611f8510341588db2ef5c4d39c8af",
|
||||
"active_rag_session_id": "a6337d0c-ba32-4623-a0a7-30e34019284e",
|
||||
"process_version": "v1",
|
||||
"created_at": "2026-04-09T17:40:24.922071+00:00",
|
||||
"message": "Слава"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"input": {}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "prepare_user_message",
|
||||
"output": {
|
||||
"prepared_message_length": 5
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"input": {
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"prepared_message_length": 5
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "request",
|
||||
"prompt_name": "v1_flow_main.answer",
|
||||
"system_prompt": "Ты полезный ассистент.\nОтветь на сообщение пользователя по существу.\nНе придумывай факты, если данных недостаточно.\nЕсли пользователь пишет по-русски, отвечай по-русски.",
|
||||
"user_prompt": "Слава",
|
||||
"log_context": "agent:req_fa978ad58b8c41a6b9296f88250c379a"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1.llm
|
||||
```json
|
||||
{
|
||||
"event": "response",
|
||||
"text": "Здравствуйте! Чем могу вам помочь?"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "generate_answer",
|
||||
"output": {
|
||||
"answer_length": 34
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_started",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"input": {
|
||||
"answer_length_before_strip": 34
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "step_completed",
|
||||
"workflow_id": "v1.flow_main",
|
||||
"step_id": "finalize_answer",
|
||||
"output": {
|
||||
"answer_length": 34
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v1
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v1.flow_main"
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "Здравствуйте! Чем могу вам помочь?",
|
||||
"completed_at": "2026-04-09T17:40:25.259324+00:00"
|
||||
}
|
||||
```
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,649 +0,0 @@
|
||||
# Runtime Trace: 20260410-105744-60a847d31356
|
||||
|
||||
- active_rag_session_id: ff0b0f32-4d2a-48dc-9774-60a847d31356
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_584447665c2241b09898744020bd6e94",
|
||||
"session_id": "as_192902d97ee44c569ab45fd508890092",
|
||||
"active_rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-10T10:57:44.691409+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов.",
|
||||
"rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2,
|
||||
"endpoints": [
|
||||
"GET /api/v1/clients/contacts-dgr",
|
||||
"GET /api/v1/clients/contacts-dgr/{contactid}"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "deterministic",
|
||||
"answer_length": 77
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}",
|
||||
"completed_at": "2026-04-10T10:57:46.741492+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_c4c41fc4dfe34104a2d6a23dc9b5a5af",
|
||||
"session_id": "as_192902d97ee44c569ab45fd508890092",
|
||||
"active_rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-10T10:57:51.052891+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов.",
|
||||
"rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2,
|
||||
"endpoints": [
|
||||
"GET /api/v1/clients/contacts-dgr",
|
||||
"GET /api/v1/clients/contacts-dgr/{contactid}"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "deterministic",
|
||||
"answer_length": 77
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}",
|
||||
"completed_at": "2026-04-10T10:57:52.887621+00:00"
|
||||
}
|
||||
```
|
||||
@@ -1,326 +0,0 @@
|
||||
# Runtime Trace: 20260410-112313-5e81a827ea36
|
||||
|
||||
- active_rag_session_id: eaded8e6-68f4-41b4-a4ac-5e81a827ea36
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_4c84fafeba0b4b1eaa7f8a30442b1281",
|
||||
"session_id": "as_b47105603b6640b28577ab27083b1499",
|
||||
"active_rag_session_id": "eaded8e6-68f4-41b4-a4ac-5e81a827ea36",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-10T11:23:13.818952+00:00",
|
||||
"message": "какие методы апи есть в проекте?"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2
|
||||
```json
|
||||
{
|
||||
"event": "intent_routed",
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "какие методы апи есть в проекте?",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
"file_names": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"process_domain": null,
|
||||
"process_subdomain": null,
|
||||
"scope_type": "global",
|
||||
"candidate_domains": [],
|
||||
"candidate_subdomains": [],
|
||||
"candidate_entities": [],
|
||||
"candidate_apis": [],
|
||||
"signal_types": []
|
||||
},
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается перечисления доступных API-методов проекта.",
|
||||
"rag_session_id": "eaded8e6-68f4-41b4-a4ac-5e81a827ea36"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "router_resolved",
|
||||
"domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"confidence": 0.8500000000000001
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "anchors_extracted",
|
||||
"signal_types": [],
|
||||
"endpoint_paths": [],
|
||||
"target_doc_hints": [],
|
||||
"matched_aliases": [],
|
||||
"target_terms": []
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "alias_resolution",
|
||||
"resolved_aliases": [],
|
||||
"target_doc_hints": []
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_started",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.retrieval_policy
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_plan_resolved",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"limit": 400,
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "retrieval_profile_selected",
|
||||
"profile": "api_exposed",
|
||||
"layers": [
|
||||
"D1_DOCUMENT_CATALOG"
|
||||
],
|
||||
"filters": {
|
||||
"metadata.type": "api_method",
|
||||
"prefer_path_prefixes": [
|
||||
"docs/api/",
|
||||
"docs/endpoints/",
|
||||
"docs/methods/",
|
||||
"api/",
|
||||
"endpoints/",
|
||||
"methods/"
|
||||
],
|
||||
"target_doc_hints": [],
|
||||
"prefer_like_patterns": [
|
||||
"%api%",
|
||||
"%endpoint%",
|
||||
"%method%",
|
||||
"%эндпоинт%",
|
||||
"%метод%"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.evidence
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2,
|
||||
"endpoints": [
|
||||
"GET /api/v1/clients/contacts-dgr",
|
||||
"GET /api/v1/clients/contacts-dgr/{contactid}"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "evidence_assembled",
|
||||
"mode": "api_exposed",
|
||||
"endpoint_count": 2
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_step_traced",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"step": {
|
||||
"id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API"
|
||||
},
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_trace_flushed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed",
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "require_rag_session",
|
||||
"title": "Проверка RAG-сессии",
|
||||
"input": {},
|
||||
"output": {
|
||||
"has_rag_session": true
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "resolve_retrieval_plan",
|
||||
"title": "Выбор retrieval-плана",
|
||||
"input": {},
|
||||
"output": {
|
||||
"profile": "api_exposed"
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "fetch_rag_rows",
|
||||
"title": "Получение строк из RAG",
|
||||
"input": {},
|
||||
"output": {
|
||||
"retrieved_row_count": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "build_api_exposed_evidence",
|
||||
"title": "Сборка списка API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"endpoint_count": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"step_id": "finalize_api_exposed_answer",
|
||||
"title": "Формирование ответа со списком API",
|
||||
"input": {},
|
||||
"output": {
|
||||
"answer_length": 77
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## workflow.v2.api_exposed
|
||||
```json
|
||||
{
|
||||
"event": "workflow_completed",
|
||||
"workflow_id": "v2.docs_explain.api_exposed"
|
||||
}
|
||||
```
|
||||
|
||||
## process.v2.pipeline
|
||||
```json
|
||||
{
|
||||
"event": "answer_generated",
|
||||
"answer_mode": "deterministic",
|
||||
"answer_length": 77
|
||||
}
|
||||
```
|
||||
|
||||
## result
|
||||
```json
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}",
|
||||
"completed_at": "2026-04-10T11:23:16.382407+00:00"
|
||||
}
|
||||
```
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
+11
-11
@@ -1,16 +1,16 @@
|
||||
# Runtime Trace: 20260410-121449-0ddfbe598bd9
|
||||
# Runtime Trace: 20260410-130611-31bb5d20c67b
|
||||
|
||||
- active_rag_session_id: 87655eaf-302b-409d-946c-0ddfbe598bd9
|
||||
- active_rag_session_id: 0ae059fe-076a-4aa4-abd4-31bb5d20c67b
|
||||
|
||||
## request
|
||||
```json
|
||||
{
|
||||
"request_id": "req_299f353019a2465e84c88909c8903a31",
|
||||
"session_id": "as_31564e5fcf6e4048b5cb0496f53b8fee",
|
||||
"active_rag_session_id": "87655eaf-302b-409d-946c-0ddfbe598bd9",
|
||||
"request_id": "req_a14d483fd13b44fa98eb81dd6dd3ccdc",
|
||||
"session_id": "as_90d274870b1247d19694bbef1afa389a",
|
||||
"active_rag_session_id": "0ae059fe-076a-4aa4-abd4-31bb5d20c67b",
|
||||
"process_version": "v2",
|
||||
"created_at": "2026-04-10T12:14:49.260081+00:00",
|
||||
"message": "Какие методы апи есть в проекте?"
|
||||
"created_at": "2026-04-10T13:06:11.385561+00:00",
|
||||
"message": "Какие методы апи есть в проекте"
|
||||
}
|
||||
```
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
"routing_domain": "DOCS",
|
||||
"intent": "DOC_EXPLAIN",
|
||||
"subintent": "API_EXPOSED",
|
||||
"normalized_query": "Какие методы апи есть в проекте?",
|
||||
"normalized_query": "Какие методы апи есть в проекте",
|
||||
"target_terms": [],
|
||||
"anchors": {
|
||||
"entity_names": [],
|
||||
@@ -41,8 +41,8 @@
|
||||
"confidence": 0.8500000000000001,
|
||||
"routing_mode": "llm_default",
|
||||
"llm_router_used": true,
|
||||
"reason_short": "Запрос явно касается списка доступных API-методов.",
|
||||
"rag_session_id": "87655eaf-302b-409d-946c-0ddfbe598bd9"
|
||||
"reason_short": "Запрос явно касается перечисления доступных API-методов.",
|
||||
"rag_session_id": "0ae059fe-076a-4aa4-abd4-31bb5d20c67b"
|
||||
}
|
||||
```
|
||||
|
||||
@@ -322,6 +322,6 @@
|
||||
{
|
||||
"status": "done",
|
||||
"answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}\nPOST /api/v1/clients/contacts-dgr",
|
||||
"completed_at": "2026-04-10T12:14:51.286117+00:00"
|
||||
"completed_at": "2026-04-10T13:06:13.326341+00:00"
|
||||
}
|
||||
```
|
||||
+25
-25
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,3 +1,9 @@
|
||||
from app.core.agent.runtime import AgentRuntime
|
||||
|
||||
__all__ = ["AgentRuntime"]
|
||||
|
||||
|
||||
def __getattr__(name: str):
|
||||
if name == "AgentRuntime":
|
||||
from app.core.agent.runtime import AgentRuntime
|
||||
|
||||
return AgentRuntime
|
||||
raise AttributeError(name)
|
||||
|
||||
@@ -1,10 +1,22 @@
|
||||
from app.core.agent.processes.base import AgentProcess, ProcessResult
|
||||
from app.core.agent.processes.v1.process import V1Process
|
||||
from app.core.agent.processes.v2.v2_process import V2Process
|
||||
|
||||
__all__ = [
|
||||
"AgentProcess",
|
||||
"ProcessResult",
|
||||
"V1Process",
|
||||
"V2Process",
|
||||
]
|
||||
|
||||
|
||||
def __getattr__(name: str):
|
||||
if name in {"AgentProcess", "ProcessResult"}:
|
||||
from app.core.agent.processes.base import AgentProcess, ProcessResult
|
||||
|
||||
return {"AgentProcess": AgentProcess, "ProcessResult": ProcessResult}[name]
|
||||
if name == "V1Process":
|
||||
from app.core.agent.processes.v1.process import V1Process
|
||||
|
||||
return V1Process
|
||||
if name == "V2Process":
|
||||
from app.core.agent.processes.v2.v2_process import V2Process
|
||||
|
||||
return V2Process
|
||||
raise AttributeError(name)
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
from app.core.agent.processes.v2.intent_router.router import V2IntentRouter
|
||||
|
||||
__all__ = ["V2IntentRouter", "V2Process"]
|
||||
|
||||
|
||||
def __getattr__(name: str):
|
||||
if name == "V2IntentRouter":
|
||||
from app.core.agent.processes.v2.intent_router.router import V2IntentRouter
|
||||
|
||||
return V2IntentRouter
|
||||
if name == "V2Process":
|
||||
from app.core.agent.processes.v2.v2_process import V2Process
|
||||
|
||||
|
||||
@@ -1,27 +0,0 @@
|
||||
# Documentation Rules V2
|
||||
|
||||
Этот каталог — новая структура правил для DOC_UPDATE/FROM_FEATURE.
|
||||
|
||||
## Цель
|
||||
|
||||
Разделить инструкции на 2 независимых блока:
|
||||
|
||||
1. `types/` — инструкции по структуре конкретных типов документов (`ui_page`, `api_method`, и т.д.).
|
||||
2. `common-elements/` — инструкции по структуре общих элементов страницы (`tech-use-case`, `fr`, и др.).
|
||||
|
||||
## Структура каталога
|
||||
|
||||
- `documentation-rules.md` — верхнеуровневые правила.
|
||||
- `global/` — общие правила оформления и frontmatter.
|
||||
- `types/` — правила по типам документов (вместо `artifact-types/`).
|
||||
- `common-elements/` — правила по общим секциям (вместо `sections/`).
|
||||
- `templates/` — шаблоны документов.
|
||||
|
||||
## Переключение профиля
|
||||
|
||||
Загрузчик поддерживает переключение через env:
|
||||
|
||||
- `DOC_RULES_PROFILE=v2` (по умолчанию) — использовать `doc_rules_v2`.
|
||||
- `DOC_RULES_PROFILE=legacy` — использовать старый каталог `doc_rules`.
|
||||
|
||||
Если `v2` не содержит валидных пар `type + template`, загрузчик автоматически fallback на `doc_rules`.
|
||||
@@ -1,24 +0,0 @@
|
||||
# API Contract Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает, как оформлять подраздел `## Контракт` в API-документах.
|
||||
|
||||
## Что должно быть описано
|
||||
|
||||
- входные параметры
|
||||
- выходные параметры
|
||||
- JSON-структуры запросов и ответов
|
||||
- обязательность полей
|
||||
- типы полей
|
||||
- ограничения
|
||||
- описание назначения полей
|
||||
- примеры данных
|
||||
- auth
|
||||
- idempotency
|
||||
- timeout
|
||||
- ошибки и их HTTP-коды
|
||||
|
||||
## Правило качества
|
||||
|
||||
Контракт должен быть достаточно формальным, чтобы по нему можно было собрать OpenAPI-спецификацию.
|
||||
@@ -1,13 +0,0 @@
|
||||
# Details Section Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает общие правила для секции `## Details`.
|
||||
|
||||
## Правила
|
||||
|
||||
- `Details` оформляется как `## Details`.
|
||||
- Внутри `Details` используются заголовки уровня `###` и ниже.
|
||||
- Структура Details зависит от типа документа.
|
||||
- В Details не нужно повторно дублировать навигацию и связи, если они уже есть во frontmatter.
|
||||
- Интеграции, ошибки и кодовые привязки должны быть выделены в отдельные подразделы, если они существенны для понимания документа.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Functional requrements rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает, как оформлять функциональные требования в подраздел `### Функциональные требования` в документах.
|
||||
|
||||
## Правила
|
||||
- Функциональное требование (FR) расширяет и дополняет шаги, описанные в сценарии.
|
||||
- Функциональное требование (FR) не должно копировать шаг сценария не неся дополнительной информации.
|
||||
- Название функционального требования формируется следующим образом - "FR.<номер>. <Название>", где
|
||||
- <номер> идет инкрементально внутри конкретного документа, начинается с 1.
|
||||
- <Название> - кратко описывает что делает требование, суть действий (от 3 до 7 слов)
|
||||
|
||||
|
||||
|
||||
## Пример целевого описания сценария
|
||||
|
||||
### Примеры названия FR
|
||||
- Получение данных клиента из АС ЕПК
|
||||
- Проверка уровня доступа
|
||||
- Сценарий построения списка связанных предложений
|
||||
|
||||
|
||||
### Примеры описания FR
|
||||
FR.1. Получение данных клиента из АС ЕПК
|
||||
1. Сформировать запрос к эндпоинту POST /api/v1/path/to/resourse в АС ЕПК
|
||||
- Заголовки
|
||||
- <тут идет описание заголовков и того как они формируются>
|
||||
- Параметры запроса
|
||||
- <тут идет описание параметров и того как они формируются>
|
||||
- Тело запроса
|
||||
- <тут идет описание структуры объекта JSON или payload в другмо формате так как это задано требованиями>
|
||||
|
||||
2. Обработать ответ от АС ЕПК
|
||||
Успешный ответ - <взять из описания вызываеого api критерии успешного ответа >
|
||||
Ничего не найдено - <взять из описания вызываеого api критерии успешного овтета, опционально (если применимо)>
|
||||
Ошибка - <взять из описания вызываеого api критерии успешного ответа >
|
||||
@@ -1,16 +0,0 @@
|
||||
# Requirements Format Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает формат для функциональных и нефункциональных требований.
|
||||
|
||||
## Функциональные требования
|
||||
|
||||
- Использовать коды `FR-1`, `FR-2`, `FR-3` и так далее.
|
||||
- Каждое требование должно описывать отдельный обязательный аспект поведения.
|
||||
- Идентификаторы локальны в пределах одного документа.
|
||||
|
||||
## Нефункциональные требования
|
||||
|
||||
- Использовать коды `NFR-1`, `NFR-2`, `NFR-3` и так далее.
|
||||
- Требования должны описывать характеристики качества, ограничения и эксплуатационные свойства.
|
||||
@@ -1,13 +0,0 @@
|
||||
# Summary Section Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для секции `## Summary`.
|
||||
|
||||
## Правила
|
||||
|
||||
- Summary должен быть коротким explain-слоем быстрого контекста.
|
||||
- Summary должен объяснять суть документа без лишних деталей.
|
||||
- Summary должен быть пригоден для explain и быстрого чтения.
|
||||
- Предпочтительный формат: список ключевых фактов `Purpose`, `Actor`, `Trigger`, `Errors`, `Related ...` и т.д.
|
||||
- Для крупных документов допустим более длинный summary, если он остается структурированным.
|
||||
@@ -1,66 +0,0 @@
|
||||
# Scenario Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах.
|
||||
|
||||
## Обязательные части
|
||||
|
||||
- название
|
||||
- предусловия
|
||||
- триггер
|
||||
- основной сценарий
|
||||
- альтернативный сценарий
|
||||
- обработка ошибок
|
||||
- постусловие
|
||||
|
||||
## Правила
|
||||
- Основной и альтернативные сценарии состоят из шагов.
|
||||
|
||||
- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>.
|
||||
|
||||
- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование FR.<номер>. <Название> и описать в нем технические детали. А в шаге сослаться на это требование через "Описание приведено в FR.<номер>. <Название>"
|
||||
|
||||
- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки.
|
||||
- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки.
|
||||
- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию.
|
||||
|
||||
- Название "FR.<номер>. <Название>" формируется следующим образом:
|
||||
- <номер> идет инкрементально внутри конкретного документа, начинается с 1.
|
||||
- <Название> - кратко описывает что делает требование, суть действий.
|
||||
|
||||
- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий.
|
||||
|
||||
- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев.
|
||||
|
||||
- Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке
|
||||
|
||||
- Функциональные требования "FR.<номер>. <Название>" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно.
|
||||
|
||||
- FR обязательно описывается для шага с интеграцией
|
||||
- FR Не описывается для шага авторизации.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Пример целевого описания сценария
|
||||
|
||||
### Примеры шагов сценария
|
||||
|
||||
Пример 1
|
||||
- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail
|
||||
- В случае ошибки - завершить сценарий с кодом UNAUTHORIZED
|
||||
|
||||
Пример 2
|
||||
- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info
|
||||
- В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL
|
||||
|
||||
Пример 3
|
||||
- Возвращает ответ в формате <название DTO>
|
||||
|
||||
### Примеры названия FR
|
||||
- Получение данных клиента из АС ЕПК
|
||||
- Проверка уровня доступа
|
||||
- Сценарий построения списка связанных предложений
|
||||
@@ -1,71 +0,0 @@
|
||||
# Documentation Rules
|
||||
|
||||
Этот каталог оформляет MVP документации проекта в атомарном формате.
|
||||
|
||||
## Базовая структура
|
||||
|
||||
- Каждый документ содержит YAML frontmatter.
|
||||
- В документе должен быть один `H1`, совпадающий с `title`.
|
||||
- Основные разделы оформляются как `## Summary` и `## Details`.
|
||||
- Внутри `Details` используются заголовки уровня `###` и ниже.
|
||||
- Связи, сущности и навигация описываются во frontmatter через `related_docs`, `links`, `entities`, `parent`, `children`.
|
||||
|
||||
## Summary
|
||||
|
||||
- Краткий explain-слой быстрого контекста.
|
||||
- Должен позволять быстро понять назначение документа без чтения `Details`.
|
||||
- Предпочтительный формат: компактный список ключевых фактов без длинных абзацев.
|
||||
|
||||
## Details
|
||||
|
||||
- Раскрывает полное описание объекта.
|
||||
- Структура `Details` зависит от типа документа.
|
||||
- Сценарии, ограничения, интеграции, ошибки и кодовые привязки должны быть разнесены по отдельным подразделам.
|
||||
|
||||
## API documents
|
||||
|
||||
Для `api_method` внутри `## Details` обязательны разделы:
|
||||
- `### Описание`
|
||||
- `### Сценарий`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
- `### Контракт`
|
||||
|
||||
Если у метода есть интеграции и ошибки, также обязательны:
|
||||
- `### Интеграции`
|
||||
- `### Ошибки`
|
||||
- `### Связанный код`
|
||||
- `### История изменений`
|
||||
|
||||
### Сценарий
|
||||
|
||||
Сценарий оформляется как технический use case и содержит:
|
||||
- название
|
||||
- предусловия
|
||||
- триггер
|
||||
- основной сценарий
|
||||
- альтернативный сценарий
|
||||
- обработку ошибок
|
||||
- постусловие
|
||||
|
||||
### Требования
|
||||
|
||||
- Функциональные требования маркируются как `FR-1`, `FR-2`, ...
|
||||
- Нефункциональные требования маркируются как `NFR-1`, `NFR-2`, ...
|
||||
- Идентификаторы требований локальны в рамках одного документа.
|
||||
|
||||
### Контракт
|
||||
|
||||
Контракт должен быть пригоден для последующей сборки OpenAPI-спецификации и включать:
|
||||
- входные параметры
|
||||
- выходные параметры
|
||||
- структуру JSON-сообщений
|
||||
- обязательность полей
|
||||
- типы и ограничения
|
||||
- описание полей
|
||||
- правила заполнения
|
||||
- примеры данных
|
||||
- auth
|
||||
- idempotency
|
||||
- timeout
|
||||
- ошибки и их HTTP-коды
|
||||
@@ -1,38 +0,0 @@
|
||||
# Documentation System
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает общую модель документации проекта.
|
||||
|
||||
## Базовая модель
|
||||
|
||||
Каждый документ должен состоять из двух слоев:
|
||||
- YAML frontmatter
|
||||
- контент
|
||||
|
||||
Контент всегда состоит из двух обязательных разделов:
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
Над ними должен быть один заголовок `# <title>`, совпадающий со значением `title` во frontmatter.
|
||||
|
||||
## Принципы
|
||||
|
||||
- Документы должны быть атомарными.
|
||||
- Один документ описывает одну тему.
|
||||
- Вместо дублирования между документами используются явные ссылки.
|
||||
- Связи и навигация должны быть формализованы.
|
||||
- Документы должны быть пригодны для чтения человеком и для RAG.
|
||||
- Документы должны быть пригодны для частичного обновления без деградации структуры.
|
||||
|
||||
## Типы документов
|
||||
|
||||
На уровне проекта поддерживаются типы:
|
||||
- `api_method`
|
||||
- `logic_block`
|
||||
- `architecture_overview`
|
||||
- `domain_entity`
|
||||
- `ui_page`
|
||||
- `integration_doc`
|
||||
- `index_page`
|
||||
- `glossary_item`
|
||||
@@ -1,67 +0,0 @@
|
||||
# Frontmatter Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает единый контракт YAML frontmatter для всех документов.
|
||||
|
||||
## Обязательные поля
|
||||
|
||||
```yaml
|
||||
id: string
|
||||
title: string
|
||||
doc_type: string
|
||||
domain: string
|
||||
sub_domain: string
|
||||
related_docs: []
|
||||
status: string
|
||||
```
|
||||
|
||||
## Поля совместимости и рекомендуемые поля
|
||||
|
||||
```yaml
|
||||
type: string
|
||||
name: string
|
||||
module: string
|
||||
layer: string
|
||||
updated_at: YYYY-MM-DD
|
||||
tags: []
|
||||
entities: []
|
||||
parent: string | null
|
||||
children: []
|
||||
links: {}
|
||||
source_of_truth: string
|
||||
related_code: []
|
||||
system_analytics_refs: []
|
||||
```
|
||||
|
||||
## Правила
|
||||
|
||||
- `id` должен быть стабильным и уникальным в пределах документации проекта.
|
||||
- `title` — человекочитаемый заголовок.
|
||||
- `doc_type` — канонический тип документа.
|
||||
- `domain` и `sub_domain` определяют бизнес-контекст документа.
|
||||
- `related_docs` хранит явные связи с другими markdown-документами.
|
||||
- `status` хранит жизненный цикл документа: например `draft`, `approved`, `active`.
|
||||
- `type` допустимо дублировать как alias для tooling-совместимости с индексаторами.
|
||||
- `name` — короткое системное имя документа.
|
||||
- `module` — модуль или подсистема.
|
||||
- `layer` — слой системы.
|
||||
- `updated_at` хранится в формате `YYYY-MM-DD`.
|
||||
|
||||
## Связи и навигация
|
||||
|
||||
- `entities` описывает сущности, связанные с документом.
|
||||
- `parent` и `children` описывают иерархию.
|
||||
- `links` описывает typed graph связей между документами, кодом и интеграциями.
|
||||
|
||||
## Формат links
|
||||
|
||||
```yaml
|
||||
links:
|
||||
called_by:
|
||||
- ext.health_probe
|
||||
uses_logic:
|
||||
- logic.some_flow
|
||||
integrates_with:
|
||||
- ext.some_system
|
||||
```
|
||||
@@ -1,33 +0,0 @@
|
||||
# Linking Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает, как связывать документы между собой.
|
||||
|
||||
## Иерархия
|
||||
|
||||
- `parent` используется для родительского документа.
|
||||
- `children` используется для прямых дочерних документов.
|
||||
- Иерархия должна быть осмысленной и стабильной.
|
||||
- Для общей точки входа допустим `index_page`.
|
||||
|
||||
## Графовые связи
|
||||
|
||||
Для `related_docs` используются ссылки на соседние документы.
|
||||
|
||||
Для `links` рекомендуется использовать typed-ключи:
|
||||
- `called_by`
|
||||
- `uses_logic`
|
||||
- `reads_db`
|
||||
- `writes_db`
|
||||
- `integrates_with`
|
||||
- `used_by`
|
||||
- `exposes_api`
|
||||
- `uses_entities`
|
||||
|
||||
## Правила использования
|
||||
|
||||
- Если документ логически входит в другой, использовать `parent`/`children`.
|
||||
- Если связь нужна для навигации между равноправными документами, дублировать ее в `related_docs`.
|
||||
- Если связь отражает поведение, интеграции или переиспользование, фиксировать ее в `links`.
|
||||
- Детальное описание интеграций хранить в body документа, а не только во frontmatter.
|
||||
@@ -1,24 +0,0 @@
|
||||
# Naming Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл описывает правила именования документов, файлов и идентификаторов.
|
||||
|
||||
## Правила для файлов
|
||||
|
||||
- Имена файлов должны быть в kebab-case.
|
||||
- Имя файла должно отражать одну тему.
|
||||
- Для шаблонов использовать суффикс `.template.md`.
|
||||
|
||||
## Правила для id
|
||||
|
||||
- `id` строится в формате `<type-group>.<name>`.
|
||||
- Примеры:
|
||||
- `api.send_message_endpoint`
|
||||
- `logic.telegram_notification_loop`
|
||||
- `architecture.telegram_notify_app`
|
||||
|
||||
## Правила для title
|
||||
|
||||
- `title` должен быть кратким и человекочитаемым.
|
||||
- В `title` допускаются пробелы и естественный язык.
|
||||
@@ -1,19 +0,0 @@
|
||||
# Writing Style
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила стиля для текстового наполнения документации.
|
||||
|
||||
## Правила стиля
|
||||
|
||||
- Текст должен быть лаконичным.
|
||||
- Формулировки должны быть точными и техническими.
|
||||
- Summary должен быть кратким explain-слоем.
|
||||
- Details должен раскрывать суть без лишней воды.
|
||||
- Нежелательно смешивать несколько тем в одном документе.
|
||||
- Если детали относятся к другому артефакту, их нужно выносить в отдельный документ.
|
||||
|
||||
## Язык
|
||||
|
||||
- Основной язык документации — русский.
|
||||
- Технические термины, названия классов, API, RAG, OpenAPI, runtime и другие устоявшиеся identifiers можно оставлять на английском.
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
id: api.example_method
|
||||
type: api_method
|
||||
doc_type: api_method
|
||||
name: example_method
|
||||
title: HTTP API /example
|
||||
module: example_module
|
||||
layer: application
|
||||
domain: example_domain
|
||||
sub_domain: example_subdomain
|
||||
related_docs: []
|
||||
status: draft
|
||||
updated_at: 2026-03-20
|
||||
source_of_truth: code
|
||||
parent: null
|
||||
children: []
|
||||
tags: []
|
||||
entities: []
|
||||
links: {}
|
||||
---
|
||||
|
||||
# HTTP API /example
|
||||
|
||||
## Summary
|
||||
|
||||
Краткое описание метода.
|
||||
|
||||
## Details
|
||||
|
||||
## Описание
|
||||
|
||||
Короткое описание сути метода.
|
||||
|
||||
## Сценарий
|
||||
|
||||
**Название:**
|
||||
|
||||
**Предусловия:**
|
||||
-
|
||||
|
||||
**Триггер:**
|
||||
-
|
||||
|
||||
**Основной сценарий:**
|
||||
1.
|
||||
|
||||
**Альтернативный сценарий:**
|
||||
1.
|
||||
|
||||
**Обработка ошибок:**
|
||||
1.
|
||||
|
||||
**Постусловие:**
|
||||
-
|
||||
|
||||
## Функциональные требования
|
||||
|
||||
**FR-1.**
|
||||
|
||||
## Нефункциональные требования
|
||||
|
||||
**NFR-1.**
|
||||
|
||||
## Контракт
|
||||
|
||||
### Входные параметры
|
||||
|
||||
| Параметр | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |
|
||||
|---|---|---|---|---|---|---|
|
||||
| | | | | | | |
|
||||
|
||||
### Выходные параметры
|
||||
|
||||
| Поле | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |
|
||||
|---|---|---|---|---|---|---|
|
||||
| | | | | | | |
|
||||
|
||||
### Интеграции
|
||||
|
||||
### Ошибки
|
||||
|
||||
### Связанный код
|
||||
|
||||
### История изменений
|
||||
-48
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: architecture.example_system
|
||||
type: architecture_overview
|
||||
doc_type: architecture_overview
|
||||
name: example_system
|
||||
title: Обзор архитектуры Example System
|
||||
module: example_module
|
||||
layer: system
|
||||
domain: example_domain
|
||||
sub_domain: example_subdomain
|
||||
related_docs: []
|
||||
status: draft
|
||||
updated_at: 2026-03-20
|
||||
source_of_truth: mixed
|
||||
parent: null
|
||||
children: []
|
||||
tags: []
|
||||
entities: []
|
||||
links: {}
|
||||
---
|
||||
|
||||
# Обзор архитектуры Example System
|
||||
|
||||
## Summary
|
||||
|
||||
Краткое описание архитектуры.
|
||||
|
||||
## Details
|
||||
|
||||
### Описание
|
||||
|
||||
### Контекст
|
||||
|
||||
### Границы системы
|
||||
|
||||
### Компоненты
|
||||
|
||||
### Интеграционные сценарии
|
||||
|
||||
### Интеграции
|
||||
|
||||
### Ограничения
|
||||
|
||||
### Связанный код
|
||||
|
||||
### Связанные документы
|
||||
|
||||
### История изменений
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: domain.example_entity
|
||||
type: domain_entity
|
||||
doc_type: domain_entity
|
||||
name: example_entity
|
||||
title: Пример доменной сущности
|
||||
module: example_module
|
||||
layer: domain
|
||||
domain: example_domain
|
||||
sub_domain: example_subdomain
|
||||
related_docs: []
|
||||
status: draft
|
||||
updated_at: 2026-03-20
|
||||
source_of_truth: code
|
||||
parent: null
|
||||
children: []
|
||||
tags: []
|
||||
entities: []
|
||||
links: {}
|
||||
---
|
||||
|
||||
# Пример доменной сущности
|
||||
|
||||
## Summary
|
||||
|
||||
Краткое описание сущности.
|
||||
|
||||
## Details
|
||||
|
||||
### Описание
|
||||
|
||||
### Модель данных
|
||||
|
||||
### Состояния и инварианты
|
||||
|
||||
### Технический use case
|
||||
|
||||
### Функциональные требования
|
||||
|
||||
### Нефункциональные требования
|
||||
|
||||
### Интеграции
|
||||
|
||||
### Связанный код
|
||||
|
||||
### Связанные документы
|
||||
|
||||
### История изменений
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: logic.example_block
|
||||
type: logic_block
|
||||
doc_type: logic_block
|
||||
name: example_block
|
||||
title: Пример блока логики
|
||||
module: example_module
|
||||
layer: application
|
||||
domain: example_domain
|
||||
sub_domain: example_subdomain
|
||||
related_docs: []
|
||||
status: draft
|
||||
updated_at: 2026-03-20
|
||||
source_of_truth: code
|
||||
parent: null
|
||||
children: []
|
||||
tags: []
|
||||
entities: []
|
||||
links: {}
|
||||
---
|
||||
|
||||
# Пример блока логики
|
||||
|
||||
## Summary
|
||||
|
||||
Краткое описание блока логики.
|
||||
|
||||
## Details
|
||||
|
||||
### Описание
|
||||
|
||||
### Контекст
|
||||
|
||||
### Технический use case
|
||||
|
||||
### Функциональные требования
|
||||
|
||||
### Нефункциональные требования
|
||||
|
||||
### Интеграции
|
||||
|
||||
### Ограничения и условия вызова
|
||||
|
||||
### Ошибки и деградации
|
||||
|
||||
### Связанные API
|
||||
|
||||
### Связанный код
|
||||
|
||||
### История изменений
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: ui.example_page
|
||||
type: ui_page
|
||||
doc_type: ui_page
|
||||
name: example_page
|
||||
title: Пример UI-страницы
|
||||
module: example_module
|
||||
layer: presentation
|
||||
domain: example_domain
|
||||
sub_domain: example_subdomain
|
||||
related_docs: []
|
||||
status: draft
|
||||
updated_at: 2026-03-20
|
||||
source_of_truth: mixed
|
||||
parent: null
|
||||
children: []
|
||||
tags: []
|
||||
entities: []
|
||||
links: {}
|
||||
---
|
||||
|
||||
# Пример UI-страницы
|
||||
|
||||
## Summary
|
||||
|
||||
Краткое описание страницы и её назначения.
|
||||
|
||||
## Details
|
||||
|
||||
### Назначение страницы
|
||||
|
||||
### Пользовательский сценарий
|
||||
|
||||
### Основные блоки интерфейса
|
||||
|
||||
### Связанные API и сущности
|
||||
|
||||
### Функциональные требования
|
||||
|
||||
### Нефункциональные требования
|
||||
|
||||
### Ограничения и граничные случаи
|
||||
|
||||
### Ошибки и валидации
|
||||
|
||||
### Связанный код
|
||||
|
||||
### Связанные документы
|
||||
|
||||
### История изменений
|
||||
@@ -1,39 +0,0 @@
|
||||
# API Method Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `api_method`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать для описания одного HTTP endpoint или одного отдельного API метода.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
Внутри `## Details` обязательны:
|
||||
- `### Описание`
|
||||
- `### Сценарий`
|
||||
- `### Функциональные требования`
|
||||
- `### Нефункциональные требования`
|
||||
- `### Контракт`
|
||||
|
||||
## Особые правила
|
||||
|
||||
- Сценарий оформляется как технический use case.
|
||||
- Функциональные требования маркируются `FR-*`.
|
||||
- Нефункциональные требования маркируются `NFR-*`.
|
||||
- Контракт должен быть пригоден для последующей сборки OpenAPI.
|
||||
- Если у метода есть интеграции, они выносятся в `### Интеграции`.
|
||||
- Ошибки и HTTP-коды либо описываются в `### Ошибки`, либо ссылаются на централизованный каталог ошибок.
|
||||
|
||||
## Ошибки оформления
|
||||
|
||||
- Нельзя заменять контракт общим текстовым описанием.
|
||||
- Нельзя смешивать несколько endpoint в одном документе.
|
||||
- Нельзя хранить связи и навигацию вне frontmatter.
|
||||
@@ -1,31 +0,0 @@
|
||||
# Architecture Overview Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `architecture_overview`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать как входной документ для понимания системы, модуля или сервиса.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
## Что описывать в Details
|
||||
|
||||
- границы системы
|
||||
- основные компоненты
|
||||
- ключевые взаимодействия
|
||||
- интеграционные сценарии
|
||||
- главные ограничения
|
||||
- ссылки на дочерние документы по API, logic, domain и другим артефактам
|
||||
|
||||
## Ошибки оформления
|
||||
|
||||
- Нельзя дублировать в архитектурном обзоре полные API-контракты.
|
||||
- Нельзя делать архитектурный обзор единственным документом на всю систему без декомпозиции.
|
||||
@@ -1,30 +0,0 @@
|
||||
# Domain Entity Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `domain_entity`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать для описания одной доменной сущности, ее смысла, состояния и роли в системе.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
## Что описывать в Details
|
||||
|
||||
- смысл сущности
|
||||
- ключевые атрибуты
|
||||
- состояния или инварианты
|
||||
- использование сущности в системе
|
||||
- интеграции с API, workflow или внешними потребителями, если они важны для понимания модели
|
||||
|
||||
## Ошибки оформления
|
||||
|
||||
- Нельзя смешивать несколько независимых сущностей в одном документе.
|
||||
- Нельзя подменять доменную сущность описанием endpoint или workflow.
|
||||
@@ -1,25 +0,0 @@
|
||||
# Integration Doc Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `integration_doc`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать для описания интеграции между системами, сервисами или внешними провайдерами.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
## Что описывать в Details
|
||||
|
||||
- цель интеграции
|
||||
- участвующие стороны
|
||||
- направление обмена
|
||||
- ключевой сценарий взаимодействия
|
||||
- ограничения и риски
|
||||
@@ -1,31 +0,0 @@
|
||||
# Logic Block Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `logic_block`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать для описания одного законченного блока логики, workflow или процесса.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
## Что описывать в Details
|
||||
|
||||
- назначение логического блока
|
||||
- входы и выходы
|
||||
- последовательность выполнения
|
||||
- интеграции
|
||||
- ключевые ограничения
|
||||
- состояние и ошибки, если они важны для понимания блока
|
||||
|
||||
## Ошибки оформления
|
||||
|
||||
- Нельзя описывать весь модуль целиком, если логика распадается на несколько независимых блоков.
|
||||
- Нельзя превращать документ в пересказ исходного кода построчно.
|
||||
@@ -1,24 +0,0 @@
|
||||
# UI Page Rules
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот файл задает правила для документов типа `ui_page`.
|
||||
|
||||
## Когда использовать
|
||||
|
||||
Использовать для описания одной пользовательской страницы, экрана или отдельного UI-сценария.
|
||||
|
||||
## Обязательная структура
|
||||
|
||||
Документ должен содержать:
|
||||
- YAML frontmatter
|
||||
- `# <title>`
|
||||
- `## Summary`
|
||||
- `## Details`
|
||||
|
||||
## Что описывать в Details
|
||||
|
||||
- назначение страницы
|
||||
- пользовательский сценарий
|
||||
- основные блоки интерфейса
|
||||
- связанные API и сущности
|
||||
@@ -0,0 +1,9 @@
|
||||
# DOC_UPDATE/FROM_FEATURE v2 Rules
|
||||
|
||||
Этот каталог содержит общие rules для всех шагов и подпроцессов workflow `doc_update_from_feature_v2`.
|
||||
|
||||
- `attribute_resolution.md` — правила определения type/id/application/platform.
|
||||
- `path_resolution.md` — правила резолва путей документации.
|
||||
- `section_frontmatter.md` — инструкции для frontmatter.
|
||||
- `section_summary.md` — инструкции для summary.
|
||||
- `section_details.md` — инструкции для details.
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
# Attribute Resolution
|
||||
|
||||
1. Приоритет: теги из requirement > metadata документа > LLM fallback.
|
||||
2. Обязательные атрибуты: `type`, `id`, `application`, `platform`.
|
||||
3. Если атрибут отсутствует, разрешен fallback через LLM.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Path Resolution
|
||||
|
||||
Путь строится как:
|
||||
|
||||
`docs/<application>/<platform>/<type>/<id>.md`
|
||||
|
||||
Нормализация сегментов: lowercase + замена недопустимых символов на `-`.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Details Rules
|
||||
|
||||
Details содержит детализированное описание поведения, ограничений и сценариев.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
# Frontmatter Rules
|
||||
|
||||
1. Frontmatter всегда в блоке `---`.
|
||||
2. Должны быть поля id/title/type/application/platform.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user