Files
agent/runtime_traces/agent_requests/20260410-131717-21b9ef59fe19.md
T

1862 lines
138 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Runtime Trace: 20260410-131717-21b9ef59fe19
- active_rag_session_id: 199e3b54-8cd7-4c9b-b745-21b9ef59fe19
## request
```json
{
"request_id": "req_a8243a0c23844505861d7635d0fa0c8d",
"session_id": "as_583fd1f700ab42318bcc9e46783140e2",
"active_rag_session_id": "199e3b54-8cd7-4c9b-b745-21b9ef59fe19",
"process_version": "v2",
"created_at": "2026-04-10T13:17:17.674398+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": "199e3b54-8cd7-4c9b-b745-21b9ef59fe19"
}
```
## 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": 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": 2
}
},
{
"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-10T13:17:19.560496+00:00"
}
```
## request
```json
{
"request_id": "req_6222663333ee44a5a2aec41830c97f0a",
"session_id": "as_583fd1f700ab42318bcc9e46783140e2",
"active_rag_session_id": "199e3b54-8cd7-4c9b-b745-21b9ef59fe19",
"process_version": "v2",
"created_at": "2026-04-10T13:17:54.957315+00:00",
"message": "Создай документацию по аналитике \n/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md"
}
```
## process.v2
```json
{
"event": "intent_routed",
"routing_domain": "DOCS",
"intent": "DOC_UPDATE",
"subintent": "FROM_FEATURE",
"normalized_query": "Создай документацию по аналитике /Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"target_terms": [
"/users/alex/dev_projects_v2/ai"
],
"anchors": {
"entity_names": [
"Users",
"Dev_projects_v2"
],
"file_names": [
"process/v2/test_doc/features/create_contact.md"
],
"endpoint_paths": [
"/users/alex/dev_projects_v2/ai"
],
"target_doc_hints": [
"/users/alex/dev_projects_v2/ai",
"users-alex-dev_projects_v2-ai",
"users-alex-dev_projects_v2-ai-endpoint",
"users-alex-dev_projects_v2-ai endpoint",
"ai",
"ai-endpoint",
"ai endpoint",
"docs/logic/telegram-notification-loop.md"
],
"matched_aliases": [],
"process_domain": null,
"process_subdomain": null,
"scope_type": "entity",
"candidate_domains": [],
"candidate_subdomains": [],
"candidate_entities": [],
"candidate_apis": [],
"signal_types": [
"API_ENDPOINT",
"DOMAIN_ENTITY",
"LOGIC_FLOW"
]
},
"confidence": 0.8500000000000001,
"routing_mode": "llm_default",
"llm_router_used": true,
"reason_short": "Запрос явно указывает на создание документации по указанному файлу feature markdown.",
"rag_session_id": "199e3b54-8cd7-4c9b-b745-21b9ef59fe19"
}
```
## process.v2.pipeline
```json
{
"event": "router_resolved",
"domain": "DOCS",
"intent": "DOC_UPDATE",
"subintent": "FROM_FEATURE",
"confidence": 0.8500000000000001
}
```
## process.v2.pipeline
```json
{
"event": "anchors_extracted",
"signal_types": [
"API_ENDPOINT",
"DOMAIN_ENTITY",
"LOGIC_FLOW"
],
"endpoint_paths": [
"/users/alex/dev_projects_v2/ai"
],
"target_doc_hints": [
"/users/alex/dev_projects_v2/ai",
"users-alex-dev_projects_v2-ai",
"users-alex-dev_projects_v2-ai-endpoint",
"users-alex-dev_projects_v2-ai endpoint",
"ai",
"ai-endpoint",
"ai endpoint",
"docs/logic/telegram-notification-loop.md"
],
"matched_aliases": [],
"target_terms": [
"/users/alex/dev_projects_v2/ai"
]
}
```
## process.v2.pipeline
```json
{
"event": "alias_resolution",
"resolved_aliases": [],
"target_doc_hints": [
"/users/alex/dev_projects_v2/ai",
"users-alex-dev_projects_v2-ai",
"users-alex-dev_projects_v2-ai-endpoint",
"users-alex-dev_projects_v2-ai endpoint",
"ai",
"ai-endpoint",
"ai endpoint",
"docs/logic/telegram-notification-loop.md"
]
}
```
## workflow.v2.docs_update.from_feature
```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": {
"source_kind": "",
"source_ref": "",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature
```json
{
"event": "workflow_step_traced",
"workflow_id": "v2.docs_update.from_feature",
"step": {
"id": "load_source",
"title": "Загрузка системной аналитики"
},
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"source_kind": "markdown_file",
"content_loaded": true,
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature
```json
{
"event": "workflow_step_traced",
"workflow_id": "v2.docs_update.from_feature",
"step": {
"id": "parse_feature",
"title": "Парсинг функциональных требований"
},
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature
```json
{
"event": "workflow_step_traced",
"workflow_id": "v2.docs_update.from_feature",
"step": {
"id": "load_doc_rules",
"title": "Загрузка doc_rules"
},
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"enabled": true,
"loaded": true,
"supported_doc_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "request",
"prompt_name": "v2_docs_update.plan_change_units",
"system_prompt": "Ты классифицируешь units системной аналитики для построения плана изменений документации.\n\nВерни только JSON:\n{\n \"items\": [\n {\n \"index\": 0,\n \"doc_type\": \"api_method\",\n \"id\": \"ufs.contacts_dgr.api.create\",\n \"application\": \"coverage\",\n \"platform\": \"ufs\",\n \"page_type\": \"api\",\n \"path\": \"docs/coverage/ufs/api/ufs.contacts_dgr.api.create.md\",\n \"reason\": \"...\"\n }\n ]\n}\n\nПравила:\n- Используй только doc_type из allowed_doc_types.\n- Не пропускай item, даже если не уверен: выбери наиболее близкий тип.\n- Ориентируйся на heading и snippet.\n- path — это служебное поле плана изменений, не поле frontmatter.\n- id:\n - брать из metadata unit, если задан;\n - если id нет, сгенерировать стабильный id по смыслу unit и по аналогии с существующей документацией.\n- имя файла всегда формировать строго как <id>.md.\n- для существующего документа (если это видно из контекста и индекса) путь не менять.\n- для нового документа путь формировать строго как docs/<application>/<platform>/<page_type>/<id>.md.\n- platform использовать только из допустимых значений: web, ufs, pprb.\n- page_type выбирать по doc_type (например ui_page -> ui, api_method -> api, logic_block -> logic).\n- последний сегмент path обязан совпадать с <id>.md.\n- Никакого markdown и текста вне JSON.",
"user_prompt": "{\n \"system_rules\": \"Системные правила документации:\\n1. Один устойчивый объект — один документ.\\n2. Документы не должны дублировать друг друга по смыслу.\\n3. Связи между документами должны быть явными (related_docs/links).\\n4. Документация организована иерархически по папкам docs/*.\\n5. Markdown-документ состоит из YAML frontmatter и body.\\n6. Обязательные поля frontmatter: id, title, doc_type, related_docs, status, domain, sub_domain.\",\n \"allowed_doc_types\": [\n \"ui_page\",\n \"api_method\",\n \"logic_block\",\n \"architecture_overview\",\n \"integration_doc\",\n \"domain_entity\",\n \"glossary_item\",\n \"index_page\"\n ],\n \"items\": [\n {\n \"index\": 0,\n \"heading\": \"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\",\n \"snippet\": \"Основной сценарий:\\n- Пользователь заполняет атрибуты карточки и нажимает кнопку «Добавить».\\n- ui.contacts_dgr вызывает endpoint POST /api/v1/clients/contacts-dgr для создания карточки контакта ДГР.\\n- ufs.contacts_dgr обрабатывает запрос и возвращает ответ.\\n- ui.contacts_dgr отображает результат создания контакта ДГР в виде push-уведомления.\",\n \"known\": {\n \"type\": \"ui_page\",\n \"id\": \"ui.contacts_dgr.create\",\n \"application\": \"contacts_dgr\",\n \"platform\": \"web\"\n }\n },\n {\n \"index\": 1,\n \"heading\": \"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr\",\n \"snippet\": \"Требования для основного сценария:\\n- Проверить входящий запрос на соответствие JSON-схеме. Если ошибка, завершить сценарий с кодом BAD_REQUEST.\\n- Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create. При отсутствии пермишена завершить основной сценарий с кодом UNAUTHORIZED.\\n- Для исполнения запроса на создание контакта вызвать endpoint POST /contacts в prpb.contacts_dgr.\\n- Вернут\",\n \"known\": {\n \"type\": \"api_method\",\n \"id\": \"ufs.contacts_dgr.api.create\",\n \"application\": \"contacts_dgr\",\n \"platform\": \"ufs\"\n }\n }\n ]\n}",
"log_context": "workflow.v2.docs_update.from_feature.plan"
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "response",
"text": "{\n \"items\": [\n {\n \"index\": 0,\n \"doc_type\": \"ui_page\",\n \"id\": \"ui.contacts_dgr.create\",\n \"application\": \"contacts_dgr\",\n \"platform\": \"web\",\n \"page_type\": \"ui\",\n \"path\": \"docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md\"\n },\n {\n \"index\": 1,\n \"doc_type\": \"api_method\",\n \"id\": \"ufs.contacts_dgr.api.create\",\n \"application\": \"contacts_dgr\",\n \"platform\": \"ufs\",\n \"page_type\": \"api\",\n \"path\": \"docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md\"\n }\n ]\n}"
}
```
## 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": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"docs_rows": 7,
"planned_changes": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "changeset_prompt_built",
"doc_type": "ui_page",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"prompt_chars": 15882,
"rules_chars": 14400
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "request",
"prompt_name": "v2_docs_update.build_doc_changeset",
"system_prompt": "Ты формируешь один item changeset для документации на основе системной аналитики и правил doc_rules.\n\nВерни только один JSON-объект (RFC8259) формата:\n{\n \"op\": \"create|update|delete\",\n \"path\": \"docs/...\",\n \"reason\": \"краткая причина\",\n \"proposed_content\": \"полный markdown документа для create/update\"\n}\n\nСхема и ограничения:\n- Обязательные поля всегда: op, path, reason.\n- Для op=create/update поле proposed_content обязательно и содержит полный markdown документа:\n 1) frontmatter между --- и ---,\n 2) затем body согласно doc_rules.\n- Для op=delete поле proposed_content запрещено.\n- В JSON используй двойные кавычки, без trailing commas.\n- Никаких code fences (```), комментариев и текста до/после JSON.\n\nПравила:\n- Строго соблюдай структуру и ограничения из doc_rules_context.\n- Для create/update верни полный итоговый markdown (frontmatter + body).\n- Для update не используй placeholder-тексты; возвращай пригодный к сохранению документ.\n- reason обязателен, короткий, по сути изменения.\n- Никакого markdown и текста вне JSON.",
"user_prompt": "{\n \"change_request\": {\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md\",\n \"doc_type\": \"ui_page\",\n \"doc_id\": \"ui.contacts_dgr.create\",\n \"title\": \"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\",\n \"domain\": \"contacts_dgr\",\n \"sub_domain\": \"create_contact\",\n \"reason\": \"Из unit 'FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»' системной аналитики (test).\",\n \"source_refs\": [\n \"section: 5. Функциональные требования\"\n ],\n \"related_docs\": [],\n \"requirement_body\": \"Основной сценарий:\\n- Пользователь заполняет атрибуты карточки и нажимает кнопку «Добавить».\\n- ui.contacts_dgr вызывает endpoint POST /api/v1/clients/contacts-dgr для создания карточки контакта ДГР.\\n- ufs.contacts_dgr обрабатывает запрос и возвращает ответ.\\n- ui.contacts_dgr отображает результат создания контакта ДГР в виде push-уведомления.\"\n },\n \"doc_rules_context\": \"## Global rules\\n\\n### documentation-rules.md\\n\\n# Documentation Rules\\n\\nЭтот каталог оформляет MVP документации проекта в атомарном формате.\\n\\n## Базовая структура\\n\\n- Каждый документ содержит YAML frontmatter.\\n- В документе должен быть один `H1`, совпадающий с `title`.\\n- Основные разделы оформляются как `## Summary` и `## Details`.\\n- Внутри `Details` используются заголовки уровня `###` и ниже.\\n- Связи, сущности и навигация описываются во frontmatter через `related_docs`, `links`, `entities`, `parent`, `children`.\\n\\n## Summary\\n\\n- Краткий explain-слой быстрого контекста.\\n- Должен позволять быстро понять назначение документа без чтения `Details`.\\n- Предпочтительный формат: компактный список ключевых фактов без длинных абзацев.\\n\\n## Details\\n\\n- Раскрывает полное описание объекта.\\n- Структура `Details` зависит от типа документа.\\n- Сценарии, ограничения, интеграции, ошибки и кодовые привязки должны быть разнесены по отдельным подразделам.\\n\\n## API documents\\n\\nДля `api_method` внутри `## Details` обязательны разделы:\\n- `### Описание`\\n- `### Сценарий`\\n- `### Функциональные требования`\\n- `### Нефункциональные требования`\\n- `### Контракт`\\n\\nЕсли у метода есть интеграции и ошибки, также обязательны:\\n- `### Интеграции`\\n- `### Ошибки`\\n- `### Связанный код`\\n- `### История изменений`\\n\\n### Сценарий\\n\\nСценарий оформляется как технический use case и содержит:\\n- название\\n- предусловия\\n- триггер\\n- основной сценарий\\n- альтернативный сценарий\\n- обработку ошибок\\n- постусловие\\n\\n### Требования\\n\\n- Функциональные требования маркируются как `FR-1`, `FR-2`, ...\\n- Нефункциональные требования маркируются как `NFR-1`, `NFR-2`, ...\\n- Идентификаторы требований локальны в рамках одного документа.\\n\\n### Контракт\\n\\nКонтракт должен быть пригоден для последующей сборки OpenAPI-спецификации и включать:\\n- входные параметры\\n- выходные параметры\\n- структуру JSON-сообщений\\n- обязательность полей\\n- типы и ограничения\\n- описание полей\\n- правила заполнения\\n- примеры данных\\n- auth\\n- idempotency\\n- timeout\\n- ошибки и их HTTP-коды\\n\\n### global/documentation-system.md\\n\\n# Documentation System\\n\\n## Назначение\\n\\nЭтот файл задает общую модель документации проекта.\\n\\n## Базовая модель\\n\\nКаждый документ должен состоять из двух слоев:\\n- YAML frontmatter\\n- контент\\n\\nКонтент всегда состоит из двух обязательных разделов:\\n- `## Summary`\\n- `## Details`\\n\\nНад ними должен быть один заголовок `# <title>`, совпадающий со значением `title` во frontmatter.\\n\\n## Принципы\\n\\n- Документы должны быть атомарными.\\n- Один документ описывает одну тему.\\n- Вместо дублирования между документами используются явные ссылки.\\n- Связи и навигация должны быть формализованы.\\n- Документы должны быть пригодны для чтения человеком и для RAG.\\n- Документы должны быть пригодны для частичного обновления без деградации структуры.\\n\\n## Типы документов\\n\\nНа уровне проекта поддерживаются типы:\\n- `api_method`\\n- `logic_block`\\n- `architecture_overview`\\n- `domain_entity`\\n- `ui_page`\\n- `integration_doc`\\n- `index_page`\\n- `glossary_item`\\n\\n### global/frontmatter.md\\n\\n# Frontmatter Rules\\n\\n## Назначение\\n\\nЭтот файл описывает единый контракт YAML frontmatter для всех документов.\\n\\n## Обязательные поля\\n\\n```yaml\\nid: string\\ntitle: string\\ndoc_type: string\\ndomain: string\\nsub_domain: string\\nrelated_docs: []\\nstatus: string\\n```\\n\\n## Поля совместимости и рекомендуемые поля\\n\\n```yaml\\ntype: string\\nname: string\\nmodule: string\\nlayer: string\\nupdated_at: YYYY-MM-DD\\ntags: []\\nentities: []\\nparent: string | null\\nchildren: []\\nlinks: {}\\nsource_of_truth: string\\nrelated_code: []\\nsystem_analytics_refs: []\\n```\\n\\n## Правила\\n\\n- `id` должен быть стабильным и уникальным в пределах документации проекта.\\n- `title` — человекочитаемый заголовок.\\n- `doc_type` — канонический тип документа.\\n- `domain` и `sub_domain` определяют бизнес-контекст документа.\\n- `related_docs` хранит явные связи с другими markdown-документами.\\n- `status` хранит жизненный цикл документа: например `draft`, `approved`, `active`.\\n- `type` допустимо дублировать как alias для tooling-совместимости с индексаторами.\\n- `name` — короткое системное имя документа.\\n- `module` — модуль или подсистема.\\n- `layer` — слой системы.\\n- `updated_at` хранится в формате `YYYY-MM-DD`.\\n- Для документов с `doc_type: api_method` поле `endpoint` является обязательным.\\n\\n## Связи и навигация\\n\\n- `entities` описывает сущности, связанные с документом.\\n- `parent` и `children` описывают иерархию.\\n- `links` описывает typed graph связей между документами, кодом и интеграциями.\\n\\n## Формат links\\n\\n```yaml\\nlinks:\\n called_by:\\n - ext.health_probe\\n uses_logic:\\n - logic.some_flow\\n integrates_with:\\n - ext.some_system\\n```\\n\\n### global/linking.md\\n\\n# Linking Rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как связывать документы между собой.\\n\\n## Иерархия\\n\\n- `parent` используется для родительского документа.\\n- `children` используется для прямых дочерних документов.\\n- Иерархия должна быть осмысленной и стабильной.\\n- Для общей точки входа допустим `index_page`.\\n\\n## Графовые связи\\n\\nДля `related_docs` используются ссылки на соседние документы.\\n\\nДля `links` рекомендуется использовать typed-ключи:\\n- `called_by`\\n- `uses_logic`\\n- `reads_db`\\n- `writes_db`\\n- `integrates_with`\\n- `used_by`\\n- `exposes_api`\\n- `uses_entities`\\n\\n## Правила использования\\n\\n- Если документ логически входит в другой, использовать `parent`/`children`.\\n- Если связь нужна для навигации между равноправными документами, дублировать ее в `related_docs`.\\n- Если связь отражает поведение, интеграции или переиспользование, фиксировать ее в `links`.\\n- Детальное описание интеграций хранить в body документа, а не только во frontmatter.\\n\\n### global/naming.md\\n\\n# Naming Rules\\n\\n## Назначение\\n\\nЭтот файл описывает правила именования документов, файлов и идентификаторов.\\n\\n## Правила для файлов\\n\\n- Имена файлов должны быть в kebab-case.\\n- Имя файла должно отражать одну тему.\\n- Для шаблонов использовать суффикс `.template.md`.\\n\\n## Правила для id\\n\\n- `id` строится в формате `<type-group>.<name>`.\\n- Примеры:\\n - `api.send_message_endpoint`\\n - `logic.telegram_notification_loop`\\n - `architecture.telegram_notify_app`\\n\\n## Правила для title\\n\\n- `title` должен быть кратким и человекочитаемым.\\n- В `title` допускаются пробелы и естественный язык.\\n\\n### global/writing-style.md\\n\\n# Writing Style\\n\\n## Назначение\\n\\nЭтот файл задает правила стиля для текстового наполнения документации.\\n\\n## Правила стиля\\n\\n- Текст должен быть лаконичным.\\n- Формулировки должны быть точными и техническими.\\n- Summary должен быть кратким explain-слоем.\\n- Details должен раскрывать суть без лишней воды.\\n- Нежелательно смешивать несколько тем в одном документе.\\n- Если детали относятся к другому артефакту, их нужно выносить в отдельный документ.\\n\\n## Язык\\n\\n- Основной язык документации — русский.\\n- Технические термины, названия классов, API, RAG, OpenAPI, runtime и другие устоявшиеся identifiers можно оставлять на английском.\\n\\n## Artifact rules (ui_page)\\n\\n# UI Page Rules\\n\\n## Назначение\\n\\nЭтот файл задает правила для документов типа `ui_page`.\\n\\n## Когда использовать\\n\\nИспользовать для описания одной пользовательской страницы, экрана или отдельного UI-сценария.\\n\\n## Обязательная структура\\n\\nДокумент должен содержать:\\n- YAML frontmatter\\n- `# <title>`\\n- `## Summary`\\n- `## Details`\\n\\n## Что описывать в Details\\n\\n- назначение страницы\\n- пользовательский сценарий\\n- основные блоки интерфейса\\n- связанные API и сущности\\n\\n## Template (ui_page)\\n\\n---\\nid: ui.example_page\\ntype: ui_page\\ndoc_type: ui_page\\nname: example_page\\ntitle: Пример UI-страницы\\nmodule: example_module\\nlayer: presentation\\ndomain: example_domain\\nsub_domain: example_subdomain\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2026-03-20\\nsource_of_truth: mixed\\nparent: null\\nchildren: []\\ntags: []\\nentities: []\\nlinks: {}\\n---\\n\\n# Пример UI-страницы\\n\\n## Summary\\n\\nКраткое описание страницы и её назначения.\\n\\n## Details\\n\\n### Назначение страницы\\n\\n### Пользовательский сценарий\\n\\n### Основные блоки интерфейса\\n\\n### Связанные API и сущности\\n\\n### Функциональные требования\\n\\n### Нефункциональные требования\\n\\n### Ограничения и граничные случаи\\n\\n### Ошибки и валидации\\n\\n### Связанный код\\n\\n### Связанные документы\\n\\n### История изменений\\n\\n## Section rule: details\\n\\n# Details Section Rules\\n\\n## Назначение\\n\\nЭтот файл задает общие правила для секции `## Details`.\\n\\n## Правила\\n\\n- `Details` оформляется как `## Details`.\\n- Внутри `Details` используются заголовки уровня `###` и ниже.\\n- Структура Details зависит от типа документа.\\n- В Details не нужно повторно дублировать навигацию и связи, если они уже есть во frontmatter.\\n- Интеграции, ошибки и кодовые привязки должны быть выделены в отдельные подразделы, если они существенны для понимания документа.\\n\\n## Section rule: fr\\n\\n# Functional requrements rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как оформлять функциональные требования в подраздел `### Функциональные требования` в документах.\\n\\n## Правила\\n- Функциональное требование (FR) расширяет и дополняет шаги, описанные в сценарии.\\n- Функциональное требование (FR) не должно копировать шаг сценария не неся дополнительной информации.\\n- Название функционального требования формируется следующим образом - \\\"FR.<номер>. <Название>\\\", где \\n - <номер> идет инкрементально внутри конкретного документа, начинается с 1.\\n - <Название> - кратко описывает что делает требование, суть действий (от 3 до 7 слов)\\n\\n \\n\\n## Пример целевого описания сценария\\n\\n### Примеры названия FR\\n - Получение данных клиента из АС ЕПК\\n - Проверка уровня доступа\\n - Сценарий построения списка связанных предложений\\n\\n\\n ### Примеры описания FR\\nFR.1. Получение данных клиента из АС ЕПК\\n1. Сформировать запрос к эндпоинту POST /api/v1/path/to/resourse в АС ЕПК\\n - Заголовки\\n - <тут идет описание заголовков и того как они формируются>\\n - Параметры запроса\\n - <тут идет описание параметров и того как они формируются>\\n - Тело запроса\\n - <тут идет описание структуры объекта JSON или payload в другмо формате так как это задано требованиями>\\n\\n2. Обработать ответ от АС ЕПК\\n Успешный ответ - <взять из описания вызываеого api критерии успешного ответа >\\n Ничего не найдено - <взять из описания вызываеого api критерии успешного овтета, опционально (если применимо)>\\n Ошибка - <взять из описания вызываеого api критерии успешного ответа >\\n\\n## Section rule: requirements-format\\n\\n# Requirements Format Rules\\n\\n## Назначение\\n\\nЭтот файл задает формат для функциональных и нефункциональных требований.\\n\\n## Функциональные требования\\n\\n- Использовать коды `FR-1`, `FR-2`, `FR-3` и так далее.\\n- Каждое требование должно описывать отдельный обязательный аспект поведения.\\n- Идентификаторы локальны в пределах одного документа.\\n\\n## Нефункциональные требования\\n\\n- Использовать коды `NFR-1`, `NFR-2`, `NFR-3` и так далее.\\n- Требования должны описывать характеристики качества, ограничения и эксплуатационные свойства.\\n\\n## Section rule: summary\\n\\n# Summary Section Rules\\n\\n## Назначение\\n\\nЭтот файл задает правила для секции `## Summary`.\\n\\n## Правила\\n\\n- Summary должен быть коротким explain-слоем быстрого контекста.\\n- Summary должен объяснять суть документа без лишних деталей.\\n- Summary должен быть пригоден для explain и быстрого чтения.\\n- Предпочтительный формат: список ключевых фактов `Purpose`, `Actor`, `Trigger`, `Errors`, `Related ...` и т.д.\\n- Для крупных документов допустим более длинный summary, если он остается структурированным.\\n\\n## Section rule: tech-use-case\\n\\n# Scenario Rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах.\\n\\n## Обязательные части\\n\\n- название\\n- предусловия\\n- триггер\\n- основной сценарий\\n- альтернативный сценарий\\n- обработка ошибок\\n- постусловие\\n\\n## Правила\\n- Основной и альтернативные сценарии состоят из шагов. \\n\\n- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>.\\n\\n- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование FR.<номер>. <Название> и описать в нем технические детали. А в шаге сослаться на это требование через \\\"Описание приведено в FR.<номер>. <Название>\\\"\\n\\n- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки.\\n- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки.\\n- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию.\\n\\n- Название \\\"FR.<номер>. <Название>\\\" формируется следующим образом: \\n - <номер> идет инкрементально внутри конкретного документа, начинается с 1.\\n - <Название> - кратко описывает что делает требование, суть действий.\\n\\n- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий. \\n\\n- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев.\\n\\n - Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке\\n\\n - Функциональные требования \\\"FR.<номер>. <Название>\\\" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно.\\n\\n - FR обязательно описывается для шага с интеграцией\\n - FR Не описывается для шага авторизации.\\n\\n\\n\\n\\n\\n\\n## Пример целевого описания сценария\\n\\n### Примеры шагов сценария\\n\\nПример 1\\n- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail\\n - В случае ошибки - завершить сценарий с кодом UNAUTHORIZED\\n\\nПример 2\\n- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info\\n - В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL\\n\\nПример 3\\n- Возвращает ответ в формате <название DTO>\\n\\n### Примеры названия FR\\n - Получение данных клиента из АС ЕПК\\n - Проверка уровня доступа\\n - Сценарий построения списка связанных предложений\"\n}",
"log_context": "workflow.v2.docs_update.from_feature.changeset"
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "response",
"text": "{\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md\",\n \"reason\": \"Реализация сценария создания карточки контакта ДГР\",\n \"proposed_content\": \"---\\\\nid: ui.contacts_dgr.create\\\\ndoc_type: ui_page\\\\ntitle: Создание карточки контакта ДГР\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\nrelated_docs: []\\\\nstatus: draft\\\\n---\\\\n# Создание карточки контакта ДГР\\\\n## Summary\\\\n- Пользователь вводит данные контакта ДГР и отправляет форму.\\\\n- Система создает карточку через API.\\\\n- Отображается уведомление о результате.\\\\n## Details\\\\n### Назначение страницы\\\\nСтраница предназначена для ввода и сохранения новых контактов ДГР.\\\\n### Пользовательский сценарий\\\\nПользователь заполняет форму, система отправляет данные на сервер и отображает уведомление об успешности операции.\\\\n### Основные блоки интерфейса\\\\nФорма ввода данных, кнопка отправки, уведомления.\\\\n### Связанные API и сущности\\\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr\\\\n### Функциональные требования\\\\nFR-1: Отправка заполненной формы контактных данных через API.\\\\n### Нефункциональные требования\\\\nNFR-1: Высокая доступность и надежность взаимодействия с backend.\\\\n### Ограничения и граничные случаи\\\\nПроверка корректности введенных данных перед отправкой.\\\\n### Ошибки и валидации\\\\nОбработка ошибок API и отображение пользователю.\\\\n### Связанный код\\\\nUI-компоненты формы и обработчики событий.\\\\n### Связанные документы\\\\nОтсутствуют.\\\\n### История изменений\\\\nНет.\"\n}"
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "changeset_prompt_built",
"doc_type": "api_method",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"prompt_chars": 20119,
"rules_chars": 16054
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "request",
"prompt_name": "v2_docs_update.build_doc_changeset",
"system_prompt": "Ты формируешь один item changeset для документации на основе системной аналитики и правил doc_rules.\n\nВерни только один JSON-объект (RFC8259) формата:\n{\n \"op\": \"create|update|delete\",\n \"path\": \"docs/...\",\n \"reason\": \"краткая причина\",\n \"proposed_content\": \"полный markdown документа для create/update\"\n}\n\nСхема и ограничения:\n- Обязательные поля всегда: op, path, reason.\n- Для op=create/update поле proposed_content обязательно и содержит полный markdown документа:\n 1) frontmatter между --- и ---,\n 2) затем body согласно doc_rules.\n- Для op=delete поле proposed_content запрещено.\n- В JSON используй двойные кавычки, без trailing commas.\n- Никаких code fences (```), комментариев и текста до/после JSON.\n\nПравила:\n- Строго соблюдай структуру и ограничения из doc_rules_context.\n- Для create/update верни полный итоговый markdown (frontmatter + body).\n- Для update не используй placeholder-тексты; возвращай пригодный к сохранению документ.\n- reason обязателен, короткий, по сути изменения.\n- Никакого markdown и текста вне JSON.",
"user_prompt": "{\n \"change_request\": {\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md\",\n \"doc_type\": \"api_method\",\n \"doc_id\": \"ufs.contacts_dgr.api.create\",\n \"title\": \"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr\",\n \"domain\": \"contacts_dgr\",\n \"sub_domain\": \"create_contact\",\n \"reason\": \"Из unit 'FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr' системной аналитики (test).\",\n \"source_refs\": [\n \"section: 5. Функциональные требования\"\n ],\n \"related_docs\": [],\n \"requirement_body\": \"Требования для основного сценария:\\n- Проверить входящий запрос на соответствие JSON-схеме. Если ошибка, завершить сценарий с кодом BAD_REQUEST.\\n- Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create. При отсутствии пермишена завершить основной сценарий с кодом UNAUTHORIZED.\\n- Для исполнения запроса на создание контакта вызвать endpoint POST /contacts в prpb.contacts_dgr.\\n- Вернуть ответ ui.contacts_dgr в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\nКонтракт POST /contacts\\n\\nЗапрос\\n\\n**headers**\\n\\n| Атрибут | Обязательность | Тип | Где передаем | Описание |\\n|---|---|---|---|---|\\n| `X-Request-Id` | 1 | `uuid` | `header` | Сквозной идентификатор вызова |\\n| `X-Client-Ident-Id` | 1 | `string(50)` | `header` | Идентификатор системы потребителя |\\n| `X-Employee-Number` | 0..1 | `string(8)` | `header` | Табельный номер пользователя, вызвавшего сервис |\\n\\n**body**\\n\\n| Атрибут | Обязательность | Тип | Описание |\\n|---|---|---|---|\\n| `contact` | 1 | `object` | Данные контакта ДГР |\\n| `contact.lastName` | 0..1 | `string(100)` | Фамилия контакта |\\n| `contact.firstName` | 0..1 | `string(100)` | Имя контакта |\\n| `contact.middleName` | 0..1 | `string(100)` | Отчество контакта |\\n| `contact.name` | 0..1 | `string(100)` | Название группового контакта |\\n| `contact.description` | 0..1 | `string(1000)` | Описание группового контакта |\\n| `contact.position` | 0..1 | `string(100)` | Должность контакта у клиента |\\n| `contact.comment` | 0..1 | `string(1000)` | Комментарий к контакту |\\n| `contact.contactType` | 1 | `enum(string)` | `Individual`, `Group` |\\n| `contact.crossboarding` | 1 | `boolean` | Признак принадлежности контакта к процессу онбординга |\\n| `contact.createdBy` | 1 | `string(8)` | Табельный номер пользователя, создавшего контакт |\\n| `contact.emails` | 0..1 | `array(object)` | Массив электронных адресов контакта |\\n| `contact.emails.value` | 1 | `string(100)` | Электронный адрес |\\n| `contact.emails.main` | 1 | `boolean` | Признак основной почты |\\n| `contact.phones` | 0..1 | `array(object)` | Массив телефонных номеров контакта |\\n| `contact.phones.value` | 1 | `string(20)` | Телефонный номер контакта |\\n| `contact.phones.extValue` | 0..1 | `string(10)` | Добавочный номер |\\n| `contact.phones.main` | 1 | `boolean` | Признак основного телефона |\\n| `contact.phones.mobile` | 1 | `boolean` | Признак мобильного телефона |\\n| `client` | 1 | `object` | Данные клиента |\\n| `client.ucpId` | 0..1 | `string(36)` | Идентификатор клиента ПАО |\\n| `client.sbpId` | 0..1 | `string(36)` | Идентификатор клиента АО |\\n| `client.inn` | 0..1 | `string(12)` | ИНН клиента |\\n| `client.kpp` | 0..1 | `string(9)` | КПП клиента |\\n\\nОтвет\\n\\n**ContactDGRCreateRsDto**\\n\\n| Атрибут | Обязательность | Тип | Описание |\\n|---|---|---|---|\\n| `contactId` | 1 | `string(36)` | Идентификатор контакта |\"\n },\n \"doc_rules_context\": \"## Global rules\\n\\n### documentation-rules.md\\n\\n# Documentation Rules\\n\\nЭтот каталог оформляет MVP документации проекта в атомарном формате.\\n\\n## Базовая структура\\n\\n- Каждый документ содержит YAML frontmatter.\\n- В документе должен быть один `H1`, совпадающий с `title`.\\n- Основные разделы оформляются как `## Summary` и `## Details`.\\n- Внутри `Details` используются заголовки уровня `###` и ниже.\\n- Связи, сущности и навигация описываются во frontmatter через `related_docs`, `links`, `entities`, `parent`, `children`.\\n\\n## Summary\\n\\n- Краткий explain-слой быстрого контекста.\\n- Должен позволять быстро понять назначение документа без чтения `Details`.\\n- Предпочтительный формат: компактный список ключевых фактов без длинных абзацев.\\n\\n## Details\\n\\n- Раскрывает полное описание объекта.\\n- Структура `Details` зависит от типа документа.\\n- Сценарии, ограничения, интеграции, ошибки и кодовые привязки должны быть разнесены по отдельным подразделам.\\n\\n## API documents\\n\\nДля `api_method` внутри `## Details` обязательны разделы:\\n- `### Описание`\\n- `### Сценарий`\\n- `### Функциональные требования`\\n- `### Нефункциональные требования`\\n- `### Контракт`\\n\\nЕсли у метода есть интеграции и ошибки, также обязательны:\\n- `### Интеграции`\\n- `### Ошибки`\\n- `### Связанный код`\\n- `### История изменений`\\n\\n### Сценарий\\n\\nСценарий оформляется как технический use case и содержит:\\n- название\\n- предусловия\\n- триггер\\n- основной сценарий\\n- альтернативный сценарий\\n- обработку ошибок\\n- постусловие\\n\\n### Требования\\n\\n- Функциональные требования маркируются как `FR-1`, `FR-2`, ...\\n- Нефункциональные требования маркируются как `NFR-1`, `NFR-2`, ...\\n- Идентификаторы требований локальны в рамках одного документа.\\n\\n### Контракт\\n\\nКонтракт должен быть пригоден для последующей сборки OpenAPI-спецификации и включать:\\n- входные параметры\\n- выходные параметры\\n- структуру JSON-сообщений\\n- обязательность полей\\n- типы и ограничения\\n- описание полей\\n- правила заполнения\\n- примеры данных\\n- auth\\n- idempotency\\n- timeout\\n- ошибки и их HTTP-коды\\n\\n### global/documentation-system.md\\n\\n# Documentation System\\n\\n## Назначение\\n\\nЭтот файл задает общую модель документации проекта.\\n\\n## Базовая модель\\n\\nКаждый документ должен состоять из двух слоев:\\n- YAML frontmatter\\n- контент\\n\\nКонтент всегда состоит из двух обязательных разделов:\\n- `## Summary`\\n- `## Details`\\n\\nНад ними должен быть один заголовок `# <title>`, совпадающий со значением `title` во frontmatter.\\n\\n## Принципы\\n\\n- Документы должны быть атомарными.\\n- Один документ описывает одну тему.\\n- Вместо дублирования между документами используются явные ссылки.\\n- Связи и навигация должны быть формализованы.\\n- Документы должны быть пригодны для чтения человеком и для RAG.\\n- Документы должны быть пригодны для частичного обновления без деградации структуры.\\n\\n## Типы документов\\n\\nНа уровне проекта поддерживаются типы:\\n- `api_method`\\n- `logic_block`\\n- `architecture_overview`\\n- `domain_entity`\\n- `ui_page`\\n- `integration_doc`\\n- `index_page`\\n- `glossary_item`\\n\\n### global/frontmatter.md\\n\\n# Frontmatter Rules\\n\\n## Назначение\\n\\nЭтот файл описывает единый контракт YAML frontmatter для всех документов.\\n\\n## Обязательные поля\\n\\n```yaml\\nid: string\\ntitle: string\\ndoc_type: string\\ndomain: string\\nsub_domain: string\\nrelated_docs: []\\nstatus: string\\n```\\n\\n## Поля совместимости и рекомендуемые поля\\n\\n```yaml\\ntype: string\\nname: string\\nmodule: string\\nlayer: string\\nupdated_at: YYYY-MM-DD\\ntags: []\\nentities: []\\nparent: string | null\\nchildren: []\\nlinks: {}\\nsource_of_truth: string\\nrelated_code: []\\nsystem_analytics_refs: []\\n```\\n\\n## Правила\\n\\n- `id` должен быть стабильным и уникальным в пределах документации проекта.\\n- `title` — человекочитаемый заголовок.\\n- `doc_type` — канонический тип документа.\\n- `domain` и `sub_domain` определяют бизнес-контекст документа.\\n- `related_docs` хранит явные связи с другими markdown-документами.\\n- `status` хранит жизненный цикл документа: например `draft`, `approved`, `active`.\\n- `type` допустимо дублировать как alias для tooling-совместимости с индексаторами.\\n- `name` — короткое системное имя документа.\\n- `module` — модуль или подсистема.\\n- `layer` — слой системы.\\n- `updated_at` хранится в формате `YYYY-MM-DD`.\\n- Для документов с `doc_type: api_method` поле `endpoint` является обязательным.\\n\\n## Связи и навигация\\n\\n- `entities` описывает сущности, связанные с документом.\\n- `parent` и `children` описывают иерархию.\\n- `links` описывает typed graph связей между документами, кодом и интеграциями.\\n\\n## Формат links\\n\\n```yaml\\nlinks:\\n called_by:\\n - ext.health_probe\\n uses_logic:\\n - logic.some_flow\\n integrates_with:\\n - ext.some_system\\n```\\n\\n### global/linking.md\\n\\n# Linking Rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как связывать документы между собой.\\n\\n## Иерархия\\n\\n- `parent` используется для родительского документа.\\n- `children` используется для прямых дочерних документов.\\n- Иерархия должна быть осмысленной и стабильной.\\n- Для общей точки входа допустим `index_page`.\\n\\n## Графовые связи\\n\\nДля `related_docs` используются ссылки на соседние документы.\\n\\nДля `links` рекомендуется использовать typed-ключи:\\n- `called_by`\\n- `uses_logic`\\n- `reads_db`\\n- `writes_db`\\n- `integrates_with`\\n- `used_by`\\n- `exposes_api`\\n- `uses_entities`\\n\\n## Правила использования\\n\\n- Если документ логически входит в другой, использовать `parent`/`children`.\\n- Если связь нужна для навигации между равноправными документами, дублировать ее в `related_docs`.\\n- Если связь отражает поведение, интеграции или переиспользование, фиксировать ее в `links`.\\n- Детальное описание интеграций хранить в body документа, а не только во frontmatter.\\n\\n### global/naming.md\\n\\n# Naming Rules\\n\\n## Назначение\\n\\nЭтот файл описывает правила именования документов, файлов и идентификаторов.\\n\\n## Правила для файлов\\n\\n- Имена файлов должны быть в kebab-case.\\n- Имя файла должно отражать одну тему.\\n- Для шаблонов использовать суффикс `.template.md`.\\n\\n## Правила для id\\n\\n- `id` строится в формате `<type-group>.<name>`.\\n- Примеры:\\n - `api.send_message_endpoint`\\n - `logic.telegram_notification_loop`\\n - `architecture.telegram_notify_app`\\n\\n## Правила для title\\n\\n- `title` должен быть кратким и человекочитаемым.\\n- В `title` допускаются пробелы и естественный язык.\\n\\n### global/writing-style.md\\n\\n# Writing Style\\n\\n## Назначение\\n\\nЭтот файл задает правила стиля для текстового наполнения документации.\\n\\n## Правила стиля\\n\\n- Текст должен быть лаконичным.\\n- Формулировки должны быть точными и техническими.\\n- Summary должен быть кратким explain-слоем.\\n- Details должен раскрывать суть без лишней воды.\\n- Нежелательно смешивать несколько тем в одном документе.\\n- Если детали относятся к другому артефакту, их нужно выносить в отдельный документ.\\n\\n## Язык\\n\\n- Основной язык документации — русский.\\n- Технические термины, названия классов, API, RAG, OpenAPI, runtime и другие устоявшиеся identifiers можно оставлять на английском.\\n\\n## Artifact rules (api_method)\\n\\n# API Method Rules\\n\\n## Назначение\\n\\nЭтот файл задает правила для документов типа `api_method`.\\n\\n## Когда использовать\\n\\nИспользовать для описания одного HTTP endpoint или одного отдельного API метода.\\n\\n## Обязательная структура\\n\\nДокумент должен содержать:\\n- YAML frontmatter\\n- `# <title>`\\n- `## Summary`\\n- `## Details`\\n\\nВнутри `## Details` обязательны:\\n- `### Описание`\\n- `### Сценарий`\\n- `### Функциональные требования`\\n- `### Нефункциональные требования`\\n- `### Контракт`\\n\\n## Особые правила\\n\\n- Во frontmatter обязательно указывать `endpoint` (например: `POST /api/v1/clients/contacts-dgr`).\\n- Сценарий оформляется как технический use case.\\n- Функциональные требования маркируются `FR-*`.\\n- Нефункциональные требования маркируются `NFR-*`.\\n- Контракт должен быть пригоден для последующей сборки OpenAPI.\\n- Если у метода есть интеграции, они выносятся в `### Интеграции`.\\n- Ошибки и HTTP-коды либо описываются в `### Ошибки`, либо ссылаются на централизованный каталог ошибок.\\n\\n## Ошибки оформления\\n\\n- Нельзя заменять контракт общим текстовым описанием.\\n- Нельзя смешивать несколько endpoint в одном документе.\\n- Нельзя хранить связи и навигацию вне frontmatter.\\n\\n## Template (api_method)\\n\\n---\\nid: api.example_method\\ntype: api_method\\ndoc_type: api_method\\nname: example_method\\ntitle: HTTP API /example\\nmodule: example_module\\nlayer: application\\ndomain: example_domain\\nsub_domain: example_subdomain\\nendpoint: POST /api/v1/example\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2026-03-20\\nsource_of_truth: code\\nparent: null\\nchildren: []\\ntags: []\\nentities: []\\nlinks: {}\\n---\\n\\n# HTTP API /example\\n\\n## Summary\\n\\nКраткое описание метода.\\n\\n## Details\\n\\n## Описание\\n\\nКороткое описание сути метода.\\n\\n## Сценарий\\n\\n**Название:**\\n\\n**Предусловия:**\\n- \\n\\n**Триггер:**\\n- \\n\\n**Основной сценарий:**\\n1. \\n\\n**Альтернативный сценарий:**\\n1. \\n\\n**Обработка ошибок:**\\n1. \\n\\n**Постусловие:**\\n- \\n\\n## Функциональные требования\\n\\n**FR-1.**\\n\\n## Нефункциональные требования\\n\\n**NFR-1.**\\n\\n## Контракт\\n\\n### Входные параметры\\n\\n| Параметр | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |\\n|---|---|---|---|---|---|---|\\n| | | | | | | |\\n\\n### Выходные параметры\\n\\n| Поле | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |\\n|---|---|---|---|---|---|---|\\n| | | | | | | |\\n\\n### Интеграции\\n\\n### Ошибки\\n\\n### Связанный код\\n\\n### История изменений\\n\\n## Section rule: api-contract\\n\\n# API Contract Rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как оформлять подраздел `## Контракт` в API-документах.\\n\\n## Что должно быть описано\\n\\n- входные параметры\\n- выходные параметры\\n- JSON-структуры запросов и ответов\\n- обязательность полей\\n- типы полей\\n- ограничения\\n- описание назначения полей\\n- примеры данных\\n- auth\\n- idempotency\\n- timeout\\n- ошибки и их HTTP-коды\\n\\n## Правило качества\\n\\nКонтракт должен быть достаточно формальным, чтобы по нему можно было собрать OpenAPI-спецификацию.\\n\\n## Section rule: details\\n\\n# Details Section Rules\\n\\n## Назначение\\n\\nЭтот файл задает общие правила для секции `## Details`.\\n\\n## Правила\\n\\n- `Details` оформляется как `## Details`.\\n- Внутри `Details` используются заголовки уровня `###` и ниже.\\n- Структура Details зависит от типа документа.\\n- В Details не нужно повторно дублировать навигацию и связи, если они уже есть во frontmatter.\\n- Интеграции, ошибки и кодовые привязки должны быть выделены в отдельные подразделы, если они существенны для понимания документа.\\n\\n## Section rule: fr\\n\\n# Functional requrements rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как оформлять функциональные требования в подраздел `### Функциональные требования` в документах.\\n\\n## Правила\\n- Функциональное требование (FR) расширяет и дополняет шаги, описанные в сценарии.\\n- Функциональное требование (FR) не должно копировать шаг сценария не неся дополнительной информации.\\n- Название функционального требования формируется следующим образом - \\\"FR.<номер>. <Название>\\\", где \\n - <номер> идет инкрементально внутри конкретного документа, начинается с 1.\\n - <Название> - кратко описывает что делает требование, суть действий (от 3 до 7 слов)\\n\\n \\n\\n## Пример целевого описания сценария\\n\\n### Примеры названия FR\\n - Получение данных клиента из АС ЕПК\\n - Проверка уровня доступа\\n - Сценарий построения списка связанных предложений\\n\\n\\n ### Примеры описания FR\\nFR.1. Получение данных клиента из АС ЕПК\\n1. Сформировать запрос к эндпоинту POST /api/v1/path/to/resourse в АС ЕПК\\n - Заголовки\\n - <тут идет описание заголовков и того как они формируются>\\n - Параметры запроса\\n - <тут идет описание параметров и того как они формируются>\\n - Тело запроса\\n - <тут идет описание структуры объекта JSON или payload в другмо формате так как это задано требованиями>\\n\\n2. Обработать ответ от АС ЕПК\\n Успешный ответ - <взять из описания вызываеого api критерии успешного ответа >\\n Ничего не найдено - <взять из описания вызываеого api критерии успешного овтета, опционально (если применимо)>\\n Ошибка - <взять из описания вызываеого api критерии успешного ответа >\\n\\n## Section rule: requirements-format\\n\\n# Requirements Format Rules\\n\\n## Назначение\\n\\nЭтот файл задает формат для функциональных и нефункциональных требований.\\n\\n## Функциональные требования\\n\\n- Использовать коды `FR-1`, `FR-2`, `FR-3` и так далее.\\n- Каждое требование должно описывать отдельный обязательный аспект поведения.\\n- Идентификаторы локальны в пределах одного документа.\\n\\n## Нефункциональные требования\\n\\n- Использовать коды `NFR-1`, `NFR-2`, `NFR-3` и так далее.\\n- Требования должны описывать характеристики качества, ограничения и эксплуатационные свойства.\\n\\n## Section rule: summary\\n\\n# Summary Section Rules\\n\\n## Назначение\\n\\nЭтот файл задает правила для секции `## Summary`.\\n\\n## Правила\\n\\n- Summary должен быть коротким explain-слоем быстрого контекста.\\n- Summary должен объяснять суть документа без лишних деталей.\\n- Summary должен быть пригоден для explain и быстрого чтения.\\n- Предпочтительный формат: список ключевых фактов `Purpose`, `Actor`, `Trigger`, `Errors`, `Related ...` и т.д.\\n- Для крупных документов допустим более длинный summary, если он остается структурированным.\\n\\n## Section rule: tech-use-case\\n\\n# Scenario Rules\\n\\n## Назначение\\n\\nЭтот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах.\\n\\n## Обязательные части\\n\\n- название\\n- предусловия\\n- триггер\\n- основной сценарий\\n- альтернативный сценарий\\n- обработка ошибок\\n- постусловие\\n\\n## Правила\\n- Основной и альтернативные сценарии состоят из шагов. \\n\\n- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>.\\n\\n- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование FR.<номер>. <Название> и описать в нем технические детали. А в шаге сослаться на это требование через \\\"Описание приведено в FR.<номер>. <Название>\\\"\\n\\n- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки.\\n- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки.\\n- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию.\\n\\n- Название \\\"FR.<номер>. <Название>\\\" формируется следующим образом: \\n - <номер> идет инкрементально внутри конкретного документа, начинается с 1.\\n - <Название> - кратко описывает что делает требование, суть действий.\\n\\n- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий. \\n\\n- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев.\\n\\n - Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке\\n\\n - Функциональные требования \\\"FR.<номер>. <Название>\\\" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно.\\n\\n - FR обязательно описывается для шага с интеграцией\\n - FR Не описывается для шага авторизации.\\n\\n\\n\\n\\n\\n\\n## Пример целевого описания сценария\\n\\n### Примеры шагов сценария\\n\\nПример 1\\n- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail\\n - В случае ошибки - завершить сценарий с кодом UNAUTHORIZED\\n\\nПример 2\\n- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info\\n - В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL\\n\\nПример 3\\n- Возвращает ответ в формате <название DTO>\\n\\n### Примеры названия FR\\n - Получение данных клиента из АС ЕПК\\n - Проверка уровня доступа\\n - Сценарий построения списка связанных предложений\"\n}",
"log_context": "workflow.v2.docs_update.from_feature.changeset"
}
```
## workflow.v2.docs_update.from_feature.llm
```json
{
"event": "response",
"text": "{\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/ufs/api/ufs.contacts_dgr_api_create.md\",\n \"reason\": \"Создание нового API-метода для сервиса CLIENTS. POST /api/v1/clients/contacts-dgr\",\n \"proposed_content\": \"---\\nid: ufs.contacts_dgr.api.create\\ntype: api_method\\ndoc_type: api_method\\nname: create_contact\\ntitle: Создать контакт ДГР\\nmodule: contacts_dgr\\nlayer: application\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nendpoint: POST /api/v1/clients/contacts-dgr\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-04\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [UFSP]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создать контакт ДГР\\n\\n## Summary\\n\\nМетод предназначен для создания контакта ДГР в системе клиентов.\\n\\n**Purpose**: Создание контакта ДГР.\\n**Actor**: Клиентская система.\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\n**Related Docs**: отсутствует.\\n\\n## Details\\n\\n## Описание\\n\\nHTTP-метод для создания контакта ДГР в системе клиентов.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Наличие валидного токена аутентификации.\\n- Наличие необходимых прав доступа.\\n\\n**Триггер:**\\n- Отправка HTTP-запроса POST /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется валидность входящего запроса по JSON-схеме.\\n2. Выполняется проверка наличия пермишена CI02792632.ContactsDGR.Create.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- При ошибке проверки схемы или отсутствия пермишена выполняется возврат соответствующего кода ошибки.\\n\\n**Обработка ошибок:**\\n- BAD_REQUEST при несоответствии JSON-схемы.\\n- UNAUTHORIZED при отсутствии необходимого пермишена.\\n\\n**Постусловие:**\\n- Создан новый контакт ДГР в системе.\\n\\n## Функциональные требования\\n\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n**FR-4.** Вернуть ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n## Нефункциональные требования\\n\\nОтсутствуют.\\n\\n## Контракт\\n\\n### Входные параметры\\n\\n| Атрибут | Обязательность | Тип | Где передается | Описание |\\n|---------------------------|---------------|---------------|------------------|----------------------------------------------|\\n| X-Request-Id | 1 | uuid | header | Сквозной идентификатор вызова |\\n| X-Client-Ident-Id | 1 | string(50) | header | Идентификатор системы потребителя |\\n| X-Employee-Number | 0..1 | string(8) | header | Табельный номер пользователя |\\n| contact | 1 | object | body | Данные контакта ДГР |\\n| contact.lastName | 0..1 | string(100) | part of body | Фамилия контакта |\\n| contact.firstName | 0..1 | string(100) | part of body | Имя контакта |\\n| contact.middleName | 0..1 | string(100) | part of body | Отчество контакта |\\n| contact.name | 0..1 | string(100) | part of body | Название группового контакта |\\n| contact.description | 0..1 | string(1000) | part of body | Описание группового контакта |\\n| contact.position | 0..1 | string(100) | part of body | Должность контакта у клиента |\\n| contact.comment | 0..1 | string(1000) | part of body | Комментарий к контакту |\\n| contact.contactType | 1 | enum(string) | part of body | Индивидуальный или групповой контакт |\\n| contact.crossboarding | 1 | boolean | part of body | Признак принадлежности к процессу онбординга |\\n| contact.createdBy | 1 | string(8) | part of body | Табельный номер создателя контакта |\\n| contact.emails | 0..1 | array(object) | part of body | Массив электронных адресов контакта |\\n| contact.emails.value | 1 | string(100) | part of emails | Электронный адрес |\\n| contact.emails.main | 1 | boolean | part of emails | Признак основной почты |\\n| contact.phones | 0..1 | array(object) | part of body | Массив телефонных номеров контакта |\\n| contact.phones.value | 1 | string(20) | part of phones | Телефонный номер контакта |\\n| contact.phones.extValue | 0..1 | string(10) | part of phones | Добавочный номер |\\n| contact.phones.main | 1 | boolean | part of phones | Признак основного телефона |\\n| contact.phones.mobile | 1 | boolean | part of phones | Признак мобильного телефона |\\n| client | 1 | object | body | Данные клиента |\\n| client.ucpId | 0..1 | string(36) | part of client | Идентификатор клиента ПАО |\\n| client.sbpId | 0..1 | string(36) | part of client | Идентификатор клиента АО |\\n| client.inn | 0..1 | string(12) | part of client | ИНН клиента |\\n| client.kpp | 0..1 | string(9) | part of client | КПП клиента |\\n\\n### Выходные параметры\\n\\n| Атрибут | Тип | Обязательность | Описание |\\n|--------------|--------------|---------------|-----------------------|\\n| contactId | string(36) | 1 | Идентификатор контакта |\\n\\n## Интеграции\\n\\nИнтеграция с сервисом prpb.contacts_dgr для создания контакта.\\n\\n## Ошибки\\n\\n| Код ошибки | HTTP-код | Причина |\\n|--------------|----------|-------------------------------------|\\n| BAD_REQUEST | 400 | Несоответствие входящего запроса схеме|\\n| UNAUTHORIZED | 401 | Отсутствие необходимого пермишена |\\n\\n## Связанный код\\n\\nОтсутствует.\\n\\n## История изменений\\n\\nОтсутствует.\"\n}"
}
```
## 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": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"changeset_items": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## workflow.v2.docs_update.from_feature
```json
{
"event": "workflow_step_traced",
"workflow_id": "v2.docs_update.from_feature",
"step": {
"id": "finalize",
"title": "Подготовка ответа"
},
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"answer_length": 8728,
"issues": 0,
"changeset_items": 2,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": true,
"answer_len": 8728,
"issues_count": 0,
"issues_preview": []
}
}
}
```
## 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": {
"source_kind": "",
"source_ref": "",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "load_source",
"title": "Загрузка системной аналитики",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "",
"feature_content_len": 0,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"source_kind": "markdown_file",
"content_loaded": true,
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "parse_feature",
"title": "Парсинг функциональных требований",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "",
"application": "",
"platform": "",
"domains": [],
"subdomains": [],
"units_count": 0,
"unit_headings": [],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "load_doc_rules",
"title": "Загрузка doc_rules",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": false,
"doc_rules_supported_types": [],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"enabled": true,
"loaded": true,
"supported_doc_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "build_change_plan",
"title": "Построение плана изменений",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 0,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 0,
"planned_changes_preview": [],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"docs_rows": 7,
"planned_changes": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "build_changeset",
"title": "Формирование changeset",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 0,
"changeset_preview": [],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"changeset_items": 2,
"issues": 0,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
}
}
},
{
"step_id": "finalize",
"title": "Подготовка ответа",
"input": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": false,
"answer_len": 0,
"issues_count": 0,
"issues_preview": []
},
"output": {
"answer_length": 8728,
"issues": 0,
"changeset_items": 2,
"_context": {
"source_kind": "markdown_file",
"source_ref": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features/create_contact.md",
"project_root": "/Users/alex/Dev_projects_v2/ai driven app process/v2/test_doc/features",
"feature_content_len": 6250,
"analysis_id": "test",
"application": "contacts_dgr",
"platform": "web",
"domains": [
"contacts_dgr"
],
"subdomains": [
"create_contact"
],
"units_count": 2,
"unit_headings": [
"FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»",
"FR2. Реализовать сервис CLIENTS. POST /api/v1/clients/contacts-dgr"
],
"docs_rows_count": 7,
"doc_rules_enabled": true,
"doc_rules_loaded": true,
"doc_rules_supported_types": [
"api_method",
"architecture_overview",
"domain_entity",
"logic_block",
"ui_page"
],
"planned_changes_count": 2,
"planned_changes_preview": [
{
"op": "create",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md",
"doc_type": "ui_page"
},
{
"op": "create",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md",
"doc_type": "api_method"
}
],
"changeset_count": 2,
"changeset_preview": [
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md"
},
{
"op": "ChangeOp.CREATE",
"path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md"
}
],
"apply_changeset": true,
"answer_len": 8728,
"issues_count": 0,
"issues_preview": []
}
}
}
]
}
```
## 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": 8728,
"changeset_items": 2,
"apply_changeset": true
}
```
## result
```json
{
"status": "done",
"answer": "DOC_UPDATE/FROM_FEATURE: результат построения changeset.\n\nПлан изменений:\n- create: docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md (ui_page)\n- create: docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md (api_method)\n\nChangeset (для плагина):\n```json\n[\n {\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/web/ui/ui.contacts_dgr.create.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\\\nid: ui.contacts_dgr.create\\\\ndoc_type: ui_page\\\\ntitle: Создание карточки контакта ДГР\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\nrelated_docs: []\\\\nstatus: draft\\\\n---\\\\n# Создание карточки контакта ДГР\\\\n## Summary\\\\n- Пользователь вводит данные контакта ДГР и отправляет форму.\\\\n- Система создает карточку через API.\\\\n- Отображается уведомление о результате.\\\\n## Details\\\\n### Назначение страницы\\\\nСтраница предназначена для ввода и сохранения новых контактов ДГР.\\\\n### Пользовательский сценарий\\\\nПользователь заполняет форму, система отправляет данные на сервер и отображает уведомление об успешности операции.\\\\n### Основные блоки интерфейса\\\\nФорма ввода данных, кнопка отправки, уведомления.\\\\n### Связанные API и сущности\\\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr\\\\n### Функциональные требования\\\\nFR-1: Отправка заполненной формы контактных данных через API.\\\\n### Нефункциональные требования\\\\nNFR-1: Высокая доступность и надежность взаимодействия с backend.\\\\n### Ограничения и граничные случаи\\\\nПроверка корректности введенных данных перед отправкой.\\\\n### Ошибки и валидации\\\\nОбработка ошибок API и отображение пользователю.\\\\n### Связанный код\\\\nUI-компоненты формы и обработчики событий.\\\\n### Связанные документы\\\\nОтсутствуют.\\\\n### История изменений\\\\nНет.\",\n \"reason\": \"Реализация сценария создания карточки контакта ДГР\",\n \"hunks\": []\n },\n {\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md\",\n \"base_hash\": null,\n \"proposed_content\": \"---\\nid: ufs.contacts_dgr.api.create\\ntype: api_method\\ndoc_type: api_method\\nname: create_contact\\ntitle: Создать контакт ДГР\\nmodule: contacts_dgr\\nlayer: application\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nendpoint: POST /api/v1/clients/contacts-dgr\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-04\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [UFSP]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создать контакт ДГР\\n\\n## Summary\\n\\nМетод предназначен для создания контакта ДГР в системе клиентов.\\n\\n**Purpose**: Создание контакта ДГР.\\n**Actor**: Клиентская система.\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\n**Related Docs**: отсутствует.\\n\\n## Details\\n\\n## Описание\\n\\nHTTP-метод для создания контакта ДГР в системе клиентов.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Наличие валидного токена аутентификации.\\n- Наличие необходимых прав доступа.\\n\\n**Триггер:**\\n- Отправка HTTP-запроса POST /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется валидность входящего запроса по JSON-схеме.\\n2. Выполняется проверка наличия пермишена CI02792632.ContactsDGR.Create.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- При ошибке проверки схемы или отсутствия пермишена выполняется возврат соответствующего кода ошибки.\\n\\n**Обработка ошибок:**\\n- BAD_REQUEST при несоответствии JSON-схемы.\\n- UNAUTHORIZED при отсутствии необходимого пермишена.\\n\\n**Постусловие:**\\n- Создан новый контакт ДГР в системе.\\n\\n## Функциональные требования\\n\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n**FR-4.** Вернуть ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n## Нефункциональные требования\\n\\nОтсутствуют.\\n\\n## Контракт\\n\\n### Входные параметры\\n\\n| Атрибут | Обязательность | Тип | Где передается | Описание |\\n|---------------------------|---------------|---------------|------------------|----------------------------------------------|\\n| X-Request-Id | 1 | uuid | header | Сквозной идентификатор вызова |\\n| X-Client-Ident-Id | 1 | string(50) | header | Идентификатор системы потребителя |\\n| X-Employee-Number | 0..1 | string(8) | header | Табельный номер пользователя |\\n| contact | 1 | object | body | Данные контакта ДГР |\\n| contact.lastName | 0..1 | string(100) | part of body | Фамилия контакта |\\n| contact.firstName | 0..1 | string(100) | part of body | Имя контакта |\\n| contact.middleName | 0..1 | string(100) | part of body | Отчество контакта |\\n| contact.name | 0..1 | string(100) | part of body | Название группового контакта |\\n| contact.description | 0..1 | string(1000) | part of body | Описание группового контакта |\\n| contact.position | 0..1 | string(100) | part of body | Должность контакта у клиента |\\n| contact.comment | 0..1 | string(1000) | part of body | Комментарий к контакту |\\n| contact.contactType | 1 | enum(string) | part of body | Индивидуальный или групповой контакт |\\n| contact.crossboarding | 1 | boolean | part of body | Признак принадлежности к процессу онбординга |\\n| contact.createdBy | 1 | string(8) | part of body | Табельный номер создателя контакта |\\n| contact.emails | 0..1 | array(object) | part of body | Массив электронных адресов контакта |\\n| contact.emails.value | 1 | string(100) | part of emails | Электронный адрес |\\n| contact.emails.main | 1 | boolean | part of emails | Признак основной почты |\\n| contact.phones | 0..1 | array(object) | part of body | Массив телефонных номеров контакта |\\n| contact.phones.value | 1 | string(20) | part of phones | Телефонный номер контакта |\\n| contact.phones.extValue | 0..1 | string(10) | part of phones | Добавочный номер |\\n| contact.phones.main | 1 | boolean | part of phones | Признак основного телефона |\\n| contact.phones.mobile | 1 | boolean | part of phones | Признак мобильного телефона |\\n| client | 1 | object | body | Данные клиента |\\n| client.ucpId | 0..1 | string(36) | part of client | Идентификатор клиента ПАО |\\n| client.sbpId | 0..1 | string(36) | part of client | Идентификатор клиента АО |\\n| client.inn | 0..1 | string(12) | part of client | ИНН клиента |\\n| client.kpp | 0..1 | string(9) | part of client | КПП клиента |\\n\\n### Выходные параметры\\n\\n| Атрибут | Тип | Обязательность | Описание |\\n|--------------|--------------|---------------|-----------------------|\\n| contactId | string(36) | 1 | Идентификатор контакта |\\n\\n## Интеграции\\n\\nИнтеграция с сервисом prpb.contacts_dgr для создания контакта.\\n\\n## Ошибки\\n\\n| Код ошибки | HTTP-код | Причина |\\n|--------------|----------|-------------------------------------|\\n| BAD_REQUEST | 400 | Несоответствие входящего запроса схеме|\\n| UNAUTHORIZED | 401 | Отсутствие необходимого пермишена |\\n\\n## Связанный код\\n\\nОтсутствует.\\n\\n## История изменений\\n\\nОтсутствует.\",\n \"reason\": \"Создание нового API-метода для сервиса CLIENTS. POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true",
"completed_at": "2026-04-10T13:18:40.416295+00:00"
}
```