Роутер работает нормально в process v2
This commit is contained in:
@@ -314,11 +314,71 @@ LLM не должна каждый раз тонуть в полном доку
|
||||
- функциональные требования;
|
||||
- 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`.
|
||||
@@ -428,6 +488,7 @@ UI-элементы должны храниться в **табличном** и
|
||||
## Технический use case
|
||||
## Функциональные требования
|
||||
## Contract
|
||||
## Integrations
|
||||
## Errors
|
||||
## Нефункциональные требования
|
||||
## Связанные блоки логики
|
||||
@@ -454,6 +515,7 @@ UI-элементы должны храниться в **табличном** и
|
||||
## Контекст
|
||||
## Технический use case
|
||||
## Функциональные требования
|
||||
## Integrations
|
||||
## Ограничения и условия вызова
|
||||
## Нефункциональные требования
|
||||
## Связанные API / UI / integration points
|
||||
@@ -787,4 +849,4 @@ DOCS и CROSS_DOMAIN остаются частью target architecture; в те
|
||||
- полноценные execution paths для всей системы;
|
||||
- богатые fact-индексы по всем доменам;
|
||||
- полный reference graph документации;
|
||||
- глубокая автоматизация подготовки системной аналитики.
|
||||
- глубокая автоматизация подготовки системной аналитики.
|
||||
|
||||
Reference in New Issue
Block a user