diff --git a/runtime_traces/agent_requests/20260410-085902-560bc90e200f.md b/runtime_traces/agent_requests/20260410-085902-560bc90e200f.md new file mode 100644 index 0000000..66f7174 --- /dev/null +++ b/runtime_traces/agent_requests/20260410-085902-560bc90e200f.md @@ -0,0 +1,1538 @@ +# Runtime Trace: 20260410-085902-560bc90e200f + +- active_rag_session_id: 3ae94f79-50e6-4382-bfac-560bc90e200f + +## request +```json +{ + "request_id": "req_5470648ea86a44b38f82c238f0372e19", + "session_id": "as_11e6a693c42447cfa2c4c0ac612cd0e7", + "active_rag_session_id": "3ae94f79-50e6-4382-bfac-560bc90e200f", + "process_version": "v2", + "created_at": "2026-04-10T08:59:02.572471+00:00", + "message": "Сделай документацию по системной аналитике /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.9500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно указывает на создание документации по системной аналитике из указанного файла create_contact.md.", + "rag_session_id": "3ae94f79-50e6-4382-bfac-560bc90e200f" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_UPDATE", + "subintent": "FROM_FEATURE", + "confidence": 0.9500000000000001 +} +``` + +## 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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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- имя файла всегда формировать строго как .md.\n- для существующего документа (если это видно из контекста и индекса) путь не менять.\n- для нового документа путь формировать строго как docs////.md.\n- platform использовать только из допустимых значений: web, ufs, pprb.\n- page_type выбирать по doc_type (например ui_page -> ui, api_method -> api, logic_block -> logic).\n- последний сегмент path обязан совпадать с .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": 6243, + "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": 6243, + "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": 13794, + "rules_chars": 12362 +} +``` + +## 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` во 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\\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: 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\\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\\nstatus: draft\\nrelated_docs: []\\nupdated_at: 2023-10-10\\n---\\n\\n# Контакты ДГР. Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: создание новой карточки контакта ДГР.\\n- Actor: пользователь системы.\\n- Trigger: заполнение формы и нажатие кнопки «Добавить».\\n- Интеграция: вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Результат: отображение push-уведомления о результате операции.\\n\\n## Details\\n\\n### Назначение страницы\\nСоздание нового контакта ДГР путем ввода атрибутов и отправки данных через UI-интерфейс.\\n\\n### Пользовательский сценарий\\n- Пользователь вводит необходимые атрибуты контакта ДГР в форму.\\n- Пользователь подтверждает ввод, нажимая кнопку «Добавить», после чего инициируется вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Система ожидает ответа от backend и отображает push-уведомление об успешности или ошибке операции.\\n\\n### Основные блоки интерфейса\\n- Форма ввода атрибутов контакта ДГР.\\n- Кнопка подтверждения «Добавить».\\n- Блок отображения push-уведомлений.\\n\\n### Связанные API и сущности\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\"\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": 17899, + "rules_chars": 13886 +} +``` + +## 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\\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- Сценарий оформляется как технический 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\\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: 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\\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\": \"Реализация сервиса 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_dgr\\ntitle: Создать контакт ДГР (POST /api/v1/clients/contacts-dgr)\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-05\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [api, contacts_dgr]\\nlinks: {}\\n---\\n\\n# Создать контакт ДГР (POST /api/v1/clients/contacts-dgr)\\n\\n## Summary\\n\\n**Purpose**: Создание нового контакта ДГР в системе клиентов.\\n**Actors**: Клиенты, API\\n**Trigger**: POST-запрос на `/api/v1/clients/contacts-dgr`\\n**Errors**: BAD_REQUEST, UNAUTHORIZED\\n**Related**: UI-страница создания контакта, контракты на уровень ниже (prpb.contacts_dgr)\\n\\n## Details\\n\\n### Описание\\nСоздание контакта ДГР осуществляется через POST-запрос к `/api/v1/clients/contacts-dgr`. Метод проверяет корректность запроса, авторизирует доступ и делегирует создание контакта другой системе.\\n\\n### Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь аутентифицирован в системе.\\n- У пользователя есть периметр CI02792632.ContactsDGR.Create.\\n\\n**Триггер:**\\nПользователь отправляет POST-запрос на `/api/v1/clients/contacts-dgr` с данными нового контакта.\\n\\n**Основной сценарий:**\\n1. Проверяется соответствие запроса JSON-схеме. Если ошибка, завершается сценарий с кодом BAD_REQUEST.\\n2. Выполняется проверка наличия периметра CI02792632.ContactsDGR.Create. При его отсутствии сценарий завершается с кодом UNAUTHORIZED.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n4. Возвращается результат в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\nНет.\\n\\n**Обработка ошибок:**\\nСм. раздел \\\"Ошибки\\\".\\n\\n**Постусловие:**\\nСоздан новый контакт ДГР.\\n\\n### Функциональные требования\\n\\n**FR-1.** Проверка входящего запроса на соответствие JSON-схеме.\\n**FR-2.** Авторизация пользователя по периметру CI02792632.ContactsDGR.Create.\\n**FR-3.** Передача данных контакта в систему prpb.contacts_dgr.\\n**FR-4.** Формирование ответа в формате UfsBaseResponseContactDGRCreateRsDto.\\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| client | 1 | object | body | Данные клиента |\\n| и т.д. | | | | |\\n\\n#### Выходные параметры\\n\\n| Атрибут | Обязательность | Тип | Описание |\\n|----------------|---------------|---------|-----------------------------------------|\\n| contactId | 1 | string | Идентификатор созданного контакта ДГР |\\n\\n### Интеграции\\nИнтеграция с системой prpb.contacts_dgr через endpoint POST /contacts.\\n\\n### Ошибки\\n- BAD_REQUEST: Некорректный формат запроса.\\n- UNAUTHORIZED: Отсутствие необходимого периметра.\\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": 6243, + "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": 6243, + "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": 6243, + "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": 6096, + "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": 6243, + "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": 6096, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6243, + "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": 6096, + "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": 6243, + "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": 6096, + "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": 6096, + "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\\nstatus: draft\\nrelated_docs: []\\nupdated_at: 2023-10-10\\n---\\n\\n# Контакты ДГР. Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: создание новой карточки контакта ДГР.\\n- Actor: пользователь системы.\\n- Trigger: заполнение формы и нажатие кнопки «Добавить».\\n- Интеграция: вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Результат: отображение push-уведомления о результате операции.\\n\\n## Details\\n\\n### Назначение страницы\\nСоздание нового контакта ДГР путем ввода атрибутов и отправки данных через UI-интерфейс.\\n\\n### Пользовательский сценарий\\n- Пользователь вводит необходимые атрибуты контакта ДГР в форму.\\n- Пользователь подтверждает ввод, нажимая кнопку «Добавить», после чего инициируется вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Система ожидает ответа от backend и отображает push-уведомление об успешности или ошибке операции.\\n\\n### Основные блоки интерфейса\\n- Форма ввода атрибутов контакта ДГР.\\n- Кнопка подтверждения «Добавить».\\n- Блок отображения push-уведомлений.\\n\\n### Связанные API и сущности\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\",\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_dgr\\ntitle: Создать контакт ДГР (POST /api/v1/clients/contacts-dgr)\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-05\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [api, contacts_dgr]\\nlinks: {}\\n---\\n\\n# Создать контакт ДГР (POST /api/v1/clients/contacts-dgr)\\n\\n## Summary\\n\\n**Purpose**: Создание нового контакта ДГР в системе клиентов.\\n**Actors**: Клиенты, API\\n**Trigger**: POST-запрос на `/api/v1/clients/contacts-dgr`\\n**Errors**: BAD_REQUEST, UNAUTHORIZED\\n**Related**: UI-страница создания контакта, контракты на уровень ниже (prpb.contacts_dgr)\\n\\n## Details\\n\\n### Описание\\nСоздание контакта ДГР осуществляется через POST-запрос к `/api/v1/clients/contacts-dgr`. Метод проверяет корректность запроса, авторизирует доступ и делегирует создание контакта другой системе.\\n\\n### Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь аутентифицирован в системе.\\n- У пользователя есть периметр CI02792632.ContactsDGR.Create.\\n\\n**Триггер:**\\nПользователь отправляет POST-запрос на `/api/v1/clients/contacts-dgr` с данными нового контакта.\\n\\n**Основной сценарий:**\\n1. Проверяется соответствие запроса JSON-схеме. Если ошибка, завершается сценарий с кодом BAD_REQUEST.\\n2. Выполняется проверка наличия периметра CI02792632.ContactsDGR.Create. При его отсутствии сценарий завершается с кодом UNAUTHORIZED.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr для создания контакта.\\n4. Возвращается результат в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\nНет.\\n\\n**Обработка ошибок:**\\nСм. раздел \\\"Ошибки\\\".\\n\\n**Постусловие:**\\nСоздан новый контакт ДГР.\\n\\n### Функциональные требования\\n\\n**FR-1.** Проверка входящего запроса на соответствие JSON-схеме.\\n**FR-2.** Авторизация пользователя по периметру CI02792632.ContactsDGR.Create.\\n**FR-3.** Передача данных контакта в систему prpb.contacts_dgr.\\n**FR-4.** Формирование ответа в формате UfsBaseResponseContactDGRCreateRsDto.\\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| client | 1 | object | body | Данные клиента |\\n| и т.д. | | | | |\\n\\n#### Выходные параметры\\n\\n| Атрибут | Обязательность | Тип | Описание |\\n|----------------|---------------|---------|-----------------------------------------|\\n| contactId | 1 | string | Идентификатор созданного контакта ДГР |\\n\\n### Интеграции\\nИнтеграция с системой prpb.contacts_dgr через endpoint POST /contacts.\\n\\n### Ошибки\\n- BAD_REQUEST: Некорректный формат запроса.\\n- UNAUTHORIZED: Отсутствие необходимого периметра.\\n\\n### Связанный код\\nОтсутствует.\\n\\n### История изменений\\nОтсутствует.\",\n \"reason\": \"Реализация сервиса CLIENTS. Создание контакта ДГР через POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T08:59:37.933223+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-090548-70665e6dd3a5.md b/runtime_traces/agent_requests/20260410-090548-70665e6dd3a5.md new file mode 100644 index 0000000..e97a071 --- /dev/null +++ b/runtime_traces/agent_requests/20260410-090548-70665e6dd3a5.md @@ -0,0 +1,1861 @@ +# Runtime Trace: 20260410-090548-70665e6dd3a5 + +- active_rag_session_id: d35c05d7-7fd6-4b8f-a46e-70665e6dd3a5 + +## request +```json +{ + "request_id": "req_27feafb8d5944d0781d4b94161288975", + "session_id": "as_0d483786550f45219b7351ea78ebe08d", + "active_rag_session_id": "d35c05d7-7fd6-4b8f-a46e-70665e6dd3a5", + "process_version": "v2", + "created_at": "2026-04-10T09:05:48.812142+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": "Запрос явно касается перечня доступных эндпоинтов проекта.", + "rag_session_id": "d35c05d7-7fd6-4b8f-a46e-70665e6dd3a5" +} +``` + +## 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-10T09:05:51.354056+00:00" +} +``` + +## request +```json +{ + "request_id": "req_8b9170d7907c414ba720ad88e08ae22b", + "session_id": "as_0d483786550f45219b7351ea78ebe08d", + "active_rag_session_id": "d35c05d7-7fd6-4b8f-a46e-70665e6dd3a5", + "process_version": "v2", + "created_at": "2026-04-10T09:05:56.158204+00:00", + "message": "Сделай документацию по системной аналитике /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.9500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно указывает на создание документации по системной аналитике из указанного файла create_contact.md.", + "rag_session_id": "d35c05d7-7fd6-4b8f-a46e-70665e6dd3a5" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_UPDATE", + "subintent": "FROM_FEATURE", + "confidence": 0.9500000000000001 +} +``` + +## 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": 14167, + "rules_chars": 12728 +} +``` + +## 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\\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: 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: Создание карточки контакта ДГР\\nmodule: contacts_dgr\\nlayer: presentation\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [create, contact, dgr]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: создание новой карточки контакта ДГР.\\n- Актор: пользователь системы.\\n- Триггер: заполнение формы и нажатие кнопки «Добавить».\\n- API интеграция: вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Результат: отображение push-уведомления о результате операции.\\n\\n## Details\\n\\n### Назначение страницы\\nСоздание нового контакта ДГР путем ввода необходимых атрибутов и отправки данных в систему.\\n\\n### Пользовательский сценарий\\n#### Предусловия\\nПользователь имеет доступ к форме создания контактов ДГР.\\n\\n#### Триггер\\nЗаполнение атрибутов карточки и нажатие кнопки «Добавить».\\n\\n#### Основной сценарий\\n1. Пользователь вводит необходимые данные контакта ДГР.\\n2. Ui.contacts_dgr вызывает endpoint POST /api/v1/clients/contacts-dgr для создания контакта ДГР.\\n3. Ufs.contacts_dgr обрабатывает запрос и возвращает ответ.\\n4. Ui.contacts_dgr отображает результат создания контакта ДГР в виде push-уведомления.\\n\\n### Основные блоки интерфейса\\nФорма ввода данных контакта ДГР, кнопка «Добавить», блок уведомлений.\\n\\n### Связанные API и сущности\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr\\n- Обрабатывающая сущность: ufs.contacts_dgr\\n\\n### Функциональные требования\\nFR-1: Пользователю доступна форма создания контакта ДГР с необходимыми полями.\\nFR-2: При нажатии кнопки «Добавить» вызывается endpoint POST /api/v1/clients/contacts-dgr.\\nFR-3: Система корректно обрабатывает ответ от ufs.contacts_dgr и отображает уведомление пользователю.\\n\\n### Нефункциональные требования\\nОтсутствуют.\\n\\n### Ограничения и граничные случаи\\nПри ошибках интеграции выводится соответствующее сообщение об ошибке.\\n\\n### Ошибки и валидации\\nОшибки обработки запроса отображаются пользователю в виде уведомлений.\\n\\n### Связанный код\\nОтсутствует.\\n\\n### Связанные документы\\nОтсутствуют.\\n\\n### История изменений\\n- 2023-10-10: Документ создан.\"\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": 18272, + "rules_chars": 14252 +} +``` + +## 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\\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- Сценарий оформляется как технический 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\\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: 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\": \"Реализация сервиса CLIENTS. Создание контакта ДГР через POST /api/v1/clients/contacts-dgr\",\n \"proposed_content\": \"---\\nid: ufs.contacts_dgr.api.create\\ndoc_type: api_method\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\ntags: [UFs]\\nentities: []\\nlinks: {}\\n---\\n\\n# HTTP API POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nМетод создает новый контакт ДГР для клиента.\\n\\n- **Domain**: contacts_dgr\\n- **Sub-domain**: create_contact\\n- **Тип**: API метод\\n- **HTTP-метод**: POST\\n- **Путь**: /api/v1/clients/contacts-dgr\\n- **Аутентификация**: требуется пермишен CI02792632.ContactsDGR.Create\\n- **Ошибки**: BAD_REQUEST, UNAUTHORIZED\\n\\n## Details\\n\\n### Описание\\n\\nСоздание нового контакта ДГР путем отправки POST-запроса на endpoint /api/v1/clients/contacts-dgr. После успешной проверки схемы и аутентификации запрос передается в систему prpb.contacts_dgr для дальнейшей обработки.\\n\\n### Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь имеет право создавать контакты ДГР.\\n- Данные о контакте корректно заполнены и соответствуют схеме.\\n\\n**Триггер:**\\nОтправлен POST-запрос на endpoint /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется схема входящего запроса.\\n - В случае ошибки завершается сценарий с кодом BAD_REQUEST.\\n2. Авторизация запроса по пермишену CI02792632.ContactsDGR.Create.\\n - При отсутствии пермишена завершается сценарий с кодом UNAUTHORIZED.\\n3. Вызывается endpoint POST /contacts в системе prpb.contacts_dgr.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\nНет.\\n\\n**Обработка ошибок:**\\nОпределяется схемой ответа.\\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| client | 1 | object | body | Данные клиента |\\n\\nПолная спецификация тела запроса доступна в тексте требования.\\n\\n#### Выходные параметры\\n\\n| Атрибут | Тип | Обязательность | Описание |\\n|---|---|---|---|\\n| contactId | string(36) | 1 | Идентификатор контакта |\\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": 5916, + "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": 5916, + "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": 5916, + "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": 5916, + "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": 5916, + "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: Создание карточки контакта ДГР\\nmodule: contacts_dgr\\nlayer: presentation\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [create, contact, dgr]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: создание новой карточки контакта ДГР.\\n- Актор: пользователь системы.\\n- Триггер: заполнение формы и нажатие кнопки «Добавить».\\n- API интеграция: вызов endpoint POST /api/v1/clients/contacts-dgr.\\n- Результат: отображение push-уведомления о результате операции.\\n\\n## Details\\n\\n### Назначение страницы\\nСоздание нового контакта ДГР путем ввода необходимых атрибутов и отправки данных в систему.\\n\\n### Пользовательский сценарий\\n#### Предусловия\\nПользователь имеет доступ к форме создания контактов ДГР.\\n\\n#### Триггер\\nЗаполнение атрибутов карточки и нажатие кнопки «Добавить».\\n\\n#### Основной сценарий\\n1. Пользователь вводит необходимые данные контакта ДГР.\\n2. Ui.contacts_dgr вызывает endpoint POST /api/v1/clients/contacts-dgr для создания контакта ДГР.\\n3. Ufs.contacts_dgr обрабатывает запрос и возвращает ответ.\\n4. Ui.contacts_dgr отображает результат создания контакта ДГР в виде push-уведомления.\\n\\n### Основные блоки интерфейса\\nФорма ввода данных контакта ДГР, кнопка «Добавить», блок уведомлений.\\n\\n### Связанные API и сущности\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr\\n- Обрабатывающая сущность: ufs.contacts_dgr\\n\\n### Функциональные требования\\nFR-1: Пользователю доступна форма создания контакта ДГР с необходимыми полями.\\nFR-2: При нажатии кнопки «Добавить» вызывается endpoint POST /api/v1/clients/contacts-dgr.\\nFR-3: Система корректно обрабатывает ответ от ufs.contacts_dgr и отображает уведомление пользователю.\\n\\n### Нефункциональные требования\\nОтсутствуют.\\n\\n### Ограничения и граничные случаи\\nПри ошибках интеграции выводится соответствующее сообщение об ошибке.\\n\\n### Ошибки и валидации\\nОшибки обработки запроса отображаются пользователю в виде уведомлений.\\n\\n### Связанный код\\nОтсутствует.\\n\\n### Связанные документы\\nОтсутствуют.\\n\\n### История изменений\\n- 2023-10-10: Документ создан.\",\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\\ndoc_type: api_method\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\ntags: [UFs]\\nentities: []\\nlinks: {}\\n---\\n\\n# HTTP API POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nМетод создает новый контакт ДГР для клиента.\\n\\n- **Domain**: contacts_dgr\\n- **Sub-domain**: create_contact\\n- **Тип**: API метод\\n- **HTTP-метод**: POST\\n- **Путь**: /api/v1/clients/contacts-dgr\\n- **Аутентификация**: требуется пермишен CI02792632.ContactsDGR.Create\\n- **Ошибки**: BAD_REQUEST, UNAUTHORIZED\\n\\n## Details\\n\\n### Описание\\n\\nСоздание нового контакта ДГР путем отправки POST-запроса на endpoint /api/v1/clients/contacts-dgr. После успешной проверки схемы и аутентификации запрос передается в систему prpb.contacts_dgr для дальнейшей обработки.\\n\\n### Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь имеет право создавать контакты ДГР.\\n- Данные о контакте корректно заполнены и соответствуют схеме.\\n\\n**Триггер:**\\nОтправлен POST-запрос на endpoint /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется схема входящего запроса.\\n - В случае ошибки завершается сценарий с кодом BAD_REQUEST.\\n2. Авторизация запроса по пермишену CI02792632.ContactsDGR.Create.\\n - При отсутствии пермишена завершается сценарий с кодом UNAUTHORIZED.\\n3. Вызывается endpoint POST /contacts в системе prpb.contacts_dgr.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\nНет.\\n\\n**Обработка ошибок:**\\nОпределяется схемой ответа.\\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| client | 1 | object | body | Данные клиента |\\n\\nПолная спецификация тела запроса доступна в тексте требования.\\n\\n#### Выходные параметры\\n\\n| Атрибут | Тип | Обязательность | Описание |\\n|---|---|---|---|\\n| contactId | string(36) | 1 | Идентификатор контакта |\\n\",\n \"reason\": \"Реализация сервиса CLIENTS. Создание контакта ДГР через POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T09:06:35.660220+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-105605-341eb1cf5caa.md b/runtime_traces/agent_requests/20260410-105605-341eb1cf5caa.md new file mode 100644 index 0000000..c81153d --- /dev/null +++ b/runtime_traces/agent_requests/20260410-105605-341eb1cf5caa.md @@ -0,0 +1,2544 @@ +# Runtime Trace: 20260410-105605-341eb1cf5caa + +- active_rag_session_id: 1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa + +## request +```json +{ + "request_id": "req_064c067ec48a441e941c2eb560de067d", + "session_id": "as_ce21456f5ea547cd948b7ecbe1a64e09", + "active_rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa", + "process_version": "v2", + "created_at": "2026-04-10T10:56:05.888269+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": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa" +} +``` + +## 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-10T10:56:08.447916+00:00" +} +``` + +## request +```json +{ + "request_id": "req_a653f52a80f848859ec4a2f01dde6be3", + "session_id": "as_ce21456f5ea547cd948b7ecbe1a64e09", + "active_rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa", + "process_version": "v2", + "created_at": "2026-04-10T10:56:34.423797+00:00", + "message": "Какой метод апи относится к функции создания (create)?" +} +``` + +## process.v2 +```json +{ + "event": "intent_routed", + "routing_domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "normalized_query": "Какой метод апи относится к функции создания (create)?", + "target_terms": [], + "anchors": { + "entity_names": [], + "file_names": [], + "endpoint_paths": [], + "target_doc_hints": [ + "create", + "/create", + "create-endpoint", + "create endpoint" + ], + "matched_aliases": [], + "process_domain": null, + "process_subdomain": null, + "scope_type": "global", + "candidate_domains": [], + "candidate_subdomains": [], + "candidate_entities": [], + "candidate_apis": [], + "signal_types": [ + "API_ENDPOINT" + ] + }, + "confidence": 0.8, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно касается поиска метода API, связанного с функцией создания.", + "rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "confidence": 0.8 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [ + "API_ENDPOINT" + ], + "endpoint_paths": [], + "target_doc_hints": [ + "create", + "/create", + "create-endpoint", + "create endpoint" + ], + "matched_aliases": [], + "target_terms": [] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [ + "create", + "/create", + "create-endpoint", + "create endpoint" + ] +} +``` + +## 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": [ + "create", + "/create", + "create-endpoint", + "create endpoint" + ], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%", + "%create%", + "%/create%", + "%create-endpoint%", + "%create endpoint%" + ] + } +} +``` + +## 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": [ + "create", + "/create", + "create-endpoint", + "create endpoint" + ], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%", + "%create%", + "%/create%", + "%create-endpoint%", + "%create endpoint%" + ] + } +} +``` + +## 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-10T10:56:36.527870+00:00" +} +``` + +## request +```json +{ + "request_id": "req_654fe92a6b2241d9bfe8e950ee2dda2a", + "session_id": "as_ce21456f5ea547cd948b7ecbe1a64e09", + "active_rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa", + "process_version": "v2", + "created_at": "2026-04-10T10:56:47.643161+00:00", + "message": "Сделай документацию по системной аналитике /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.9, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно указывает на создание документации по системной аналитике из указанного файла create_contact.md.", + "rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_UPDATE", + "subintent": "FROM_FEATURE", + "confidence": 0.9 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [ + "API_ENDPOINT", + "DOMAIN_ENTITY", + "LOGIC_FLOW" + ], + "endpoint_paths": [ + "/users/alex/dev_projects_v2/ai" + ], + "target_doc_hints": [ + "/users/alex/dev_projects_v2/ai", + "users-alex-dev_projects_v2-ai", + "users-alex-dev_projects_v2-ai-endpoint", + "users-alex-dev_projects_v2-ai endpoint", + "ai", + "ai-endpoint", + "ai endpoint", + "docs/logic/telegram-notification-loop.md" + ], + "matched_aliases": [], + "target_terms": [ + "/users/alex/dev_projects_v2/ai" + ] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [ + "/users/alex/dev_projects_v2/ai", + "users-alex-dev_projects_v2-ai", + "users-alex-dev_projects_v2-ai-endpoint", + "users-alex-dev_projects_v2-ai endpoint", + "ai", + "ai-endpoint", + "ai endpoint", + "docs/logic/telegram-notification-loop.md" + ] +} +``` + +## workflow.v2.docs_update.from_feature +```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": 15800, + "rules_chars": 14319 +} +``` + +## 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\\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: FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-04\\n---\\n\\n# FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\n\n## Summary\n\n- Назначение: создание новой карточки контакта ДГР.\n- Действие пользователя: заполнение атрибутов и нажатие кнопки «Добавить».\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\n- Ответственный компонент: ufs.contacts_dgr.\n- Результат: push-уведомление о результате создания контакта.\n\n## Details\n\n### Назначение страницы\n\nСтраница предназначена для создания новых карточек контактов ДГР пользователями системы.\n\n### Пользовательский сценарий\n\nПользователь заполняет необходимые атрибуты контактной карточки и инициирует процесс создания, нажимая кнопку «Добавить».\n\n### Основные блоки интерфейса\n\n- Форма ввода атрибутов контакта.\n- Кнопка подтверждения добавления («Добавить»).\n\n### Связанные API и сущности\n\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\n- Ответственный сервис: ufs.contacts_dgr.\n\n### Функциональные требования\n\nFR-1: Отправка корректно заполненной формы на сервер через endpoint POST /api/v1/clients/contacts-dgr.\n\n### Нефункциональные требования\n\nNFR-1: Время отклика сервера на создание нового контакта не превышает 3 секунд.\n\n### Ограничения и граничные случаи\n\n- Обязательность заполнения всех обязательных полей перед отправкой.\n- Валидность введённых данных.\n\n### Ошибки и валидации\n\nВ случае некорректности данных или сетевых проблем отображается соответствующее уведомление пользователю.\n\n### Связанный код\n\nКод реализации формы и логики отправки находится в модуле `clients_contacts`.\n\n### Связанные документы\n\nОтсутствуют.\n\n### История изменений\n\nДата: 04.10.2023 - Первоначальная версия документа.\"\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": 19905, + "rules_chars": 15843 +} +``` + +## 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\\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- Сценарий оформляется как технический 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\\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\": \"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\n \"proposed_content\": \"---\\nid: ufs.contacts_dgr.api.create\\ndoc_type: api_method\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\ntags: []\\nentities: []\\nlinks: {}\\n---\\n\\n# Сервис создания контактов CLIENTS. Метод POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nЦель данного API-метода – создать новый контакт клиента в системе CLIENTS.\\n\\n**Purpose**: Создание нового контакта клиента.\\n**Method**: POST\\n**URL**: `/api/v1/clients/contacts-dgr`\\n**Auth required**: Да\\n**Errors**: BAD_REQUEST, UNAUTHORIZED\\n\\n## Details\\n\\n## Описание\\nМетод предназначен для создания новых индивидуальных или групповых контактов клиентов в системе CLIENTS.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта\\n\\n**Предусловия:**\\n- Запрос содержит корректную схему JSON.\\n- Пользователь имеет пермишен CI02792632.ContactsDGR.Create.\\n\\n**Триггер:**\\nОтправка POST-запроса на URL `/api/v1/clients/contacts-dgr`.\\n\\n**Основной сценарий:**\\n1. Проверяется валидность JSON-схемы запроса.\\n2. Производится авторизация пользователя.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- Если схема JSON некорректна, завершается сценарий с ошибкой BAD_REQUEST.\\n- Если пользователь не обладает необходимым пермишеном, завершается сценарий с ошибкой UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- Пошагово описаны выше.\\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**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| client | 1 | object | Данные клиента |\\n(и далее атрибуты объектов contact и client)\\n\\n### Выходные параметры\\n\\n| Поле | Тип | Обязательность | Описание |\\n|---|---|---|---|\\n| contactId | string(36) | 1 | Идентификатор созданного контакта |\\n\\n## Интеграции\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\n\\n## Ошибки\\nBAD_REQUEST, UNAUTHORIZED\\n\\n## Связанный код\\nUfsBaseResponseContactDGRCreateRsDto\\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": 5627, + "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": 5627, + "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": 5627, + "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": 5627, + "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": 5627, + "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: FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-04\\n---\\n\\n# FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\n\\n## Summary\\n\\n- Назначение: создание новой карточки контакта ДГР.\\n- Действие пользователя: заполнение атрибутов и нажатие кнопки «Добавить».\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\\n- Ответственный компонент: ufs.contacts_dgr.\\n- Результат: push-уведомление о результате создания контакта.\\n\\n## Details\\n\\n### Назначение страницы\\n\\nСтраница предназначена для создания новых карточек контактов ДГР пользователями системы.\\n\\n### Пользовательский сценарий\\n\\nПользователь заполняет необходимые атрибуты контактной карточки и инициирует процесс создания, нажимая кнопку «Добавить».\\n\\n### Основные блоки интерфейса\\n\\n- Форма ввода атрибутов контакта.\\n- Кнопка подтверждения добавления («Добавить»).\\n\\n### Связанные API и сущности\\n\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\\n- Ответственный сервис: ufs.contacts_dgr.\\n\\n### Функциональные требования\\n\\nFR-1: Отправка корректно заполненной формы на сервер через endpoint POST /api/v1/clients/contacts-dgr.\\n\\n### Нефункциональные требования\\n\\nNFR-1: Время отклика сервера на создание нового контакта не превышает 3 секунд.\\n\\n### Ограничения и граничные случаи\\n\\n- Обязательность заполнения всех обязательных полей перед отправкой.\\n- Валидность введённых данных.\\n\\n### Ошибки и валидации\\n\\nВ случае некорректности данных или сетевых проблем отображается соответствующее уведомление пользователю.\\n\\n### Связанный код\\n\\nКод реализации формы и логики отправки находится в модуле `clients_contacts`.\\n\\n### Связанные документы\\n\\nОтсутствуют.\\n\\n### История изменений\\n\\nДата: 04.10.2023 - Первоначальная версия документа.\",\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\\ndoc_type: api_method\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\ntags: []\\nentities: []\\nlinks: {}\\n---\\n\\n# Сервис создания контактов CLIENTS. Метод POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nЦель данного API-метода – создать новый контакт клиента в системе CLIENTS.\\n\\n**Purpose**: Создание нового контакта клиента.\\n**Method**: POST\\n**URL**: `/api/v1/clients/contacts-dgr`\\n**Auth required**: Да\\n**Errors**: BAD_REQUEST, UNAUTHORIZED\\n\\n## Details\\n\\n## Описание\\nМетод предназначен для создания новых индивидуальных или групповых контактов клиентов в системе CLIENTS.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта\\n\\n**Предусловия:**\\n- Запрос содержит корректную схему JSON.\\n- Пользователь имеет пермишен CI02792632.ContactsDGR.Create.\\n\\n**Триггер:**\\nОтправка POST-запроса на URL `/api/v1/clients/contacts-dgr`.\\n\\n**Основной сценарий:**\\n1. Проверяется валидность JSON-схемы запроса.\\n2. Производится авторизация пользователя.\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr.\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- Если схема JSON некорректна, завершается сценарий с ошибкой BAD_REQUEST.\\n- Если пользователь не обладает необходимым пермишеном, завершается сценарий с ошибкой UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- Пошагово описаны выше.\\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**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| client | 1 | object | Данные клиента |\\n(и далее атрибуты объектов contact и client)\\n\\n### Выходные параметры\\n\\n| Поле | Тип | Обязательность | Описание |\\n|---|---|---|---|\\n| contactId | string(36) | 1 | Идентификатор созданного контакта |\\n\\n## Интеграции\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\n\\n## Ошибки\\nBAD_REQUEST, UNAUTHORIZED\\n\\n## Связанный код\\nUfsBaseResponseContactDGRCreateRsDto\\n\\n## История изменений\\n(Пока пуста)\",\n \"reason\": \"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T10:57:23.636071+00:00" +} +``` + +## request +```json +{ + "request_id": "req_d7cd2138f2ee4e7c83c7e3492fc43952", + "session_id": "as_ce21456f5ea547cd948b7ecbe1a64e09", + "active_rag_session_id": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa", + "process_version": "v2", + "created_at": "2026-04-10T10:57:32.557791+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": "1ff8d654-a8a5-4a66-aaf5-341eb1cf5caa" +} +``` + +## 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-10T10:57:34.481617+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-105744-60a847d31356.md b/runtime_traces/agent_requests/20260410-105744-60a847d31356.md new file mode 100644 index 0000000..e6d15ca --- /dev/null +++ b/runtime_traces/agent_requests/20260410-105744-60a847d31356.md @@ -0,0 +1,649 @@ +# Runtime Trace: 20260410-105744-60a847d31356 + +- active_rag_session_id: ff0b0f32-4d2a-48dc-9774-60a847d31356 + +## request +```json +{ + "request_id": "req_584447665c2241b09898744020bd6e94", + "session_id": "as_192902d97ee44c569ab45fd508890092", + "active_rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356", + "process_version": "v2", + "created_at": "2026-04-10T10:57:44.691409+00:00", + "message": "Какие методы апи есть в проекте?" +} +``` + +## process.v2 +```json +{ + "event": "intent_routed", + "routing_domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "normalized_query": "Какие методы апи есть в проекте?", + "target_terms": [], + "anchors": { + "entity_names": [], + "file_names": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "process_domain": null, + "process_subdomain": null, + "scope_type": "global", + "candidate_domains": [], + "candidate_subdomains": [], + "candidate_entities": [], + "candidate_apis": [], + "signal_types": [] + }, + "confidence": 0.8500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно касается списка доступных API-методов.", + "rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "confidence": 0.8500000000000001 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "target_terms": [] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_started", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "require_rag_session", + "title": "Проверка RAG-сессии" + }, + "input": {}, + "output": { + "has_rag_session": true + } +} +``` + +## process.v2.retrieval_policy +```json +{ + "event": "retrieval_plan_resolved", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "limit": 400, + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## process.v2.pipeline +```json +{ + "event": "retrieval_profile_selected", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана" + }, + "input": {}, + "output": { + "profile": "api_exposed" + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "fetch_rag_rows", + "title": "Получение строк из RAG" + }, + "input": {}, + "output": { + "retrieved_row_count": 3 + } +} +``` + +## process.v2.evidence +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2, + "endpoints": [ + "GET /api/v1/clients/contacts-dgr", + "GET /api/v1/clients/contacts-dgr/{contactid}" + ] +} +``` + +## process.v2.pipeline +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2 +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "build_api_exposed_evidence", + "title": "Сборка списка API" + }, + "input": {}, + "output": { + "endpoint_count": 2 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API" + }, + "input": {}, + "output": { + "answer_length": 77 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_trace_flushed", + "workflow_id": "v2.docs_explain.api_exposed", + "steps": [ + { + "step_id": "require_rag_session", + "title": "Проверка RAG-сессии", + "input": {}, + "output": { + "has_rag_session": true + } + }, + { + "step_id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана", + "input": {}, + "output": { + "profile": "api_exposed" + } + }, + { + "step_id": "fetch_rag_rows", + "title": "Получение строк из RAG", + "input": {}, + "output": { + "retrieved_row_count": 3 + } + }, + { + "step_id": "build_api_exposed_evidence", + "title": "Сборка списка API", + "input": {}, + "output": { + "endpoint_count": 2 + } + }, + { + "step_id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API", + "input": {}, + "output": { + "answer_length": 77 + } + } + ] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_completed", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## process.v2.pipeline +```json +{ + "event": "answer_generated", + "answer_mode": "deterministic", + "answer_length": 77 +} +``` + +## result +```json +{ + "status": "done", + "answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}", + "completed_at": "2026-04-10T10:57:46.741492+00:00" +} +``` + +## request +```json +{ + "request_id": "req_c4c41fc4dfe34104a2d6a23dc9b5a5af", + "session_id": "as_192902d97ee44c569ab45fd508890092", + "active_rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356", + "process_version": "v2", + "created_at": "2026-04-10T10:57:51.052891+00:00", + "message": "Какие методы апи есть в проекте?" +} +``` + +## process.v2 +```json +{ + "event": "intent_routed", + "routing_domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "normalized_query": "Какие методы апи есть в проекте?", + "target_terms": [], + "anchors": { + "entity_names": [], + "file_names": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "process_domain": null, + "process_subdomain": null, + "scope_type": "global", + "candidate_domains": [], + "candidate_subdomains": [], + "candidate_entities": [], + "candidate_apis": [], + "signal_types": [] + }, + "confidence": 0.8500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно касается списка доступных API-методов.", + "rag_session_id": "ff0b0f32-4d2a-48dc-9774-60a847d31356" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "confidence": 0.8500000000000001 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "target_terms": [] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_started", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "require_rag_session", + "title": "Проверка RAG-сессии" + }, + "input": {}, + "output": { + "has_rag_session": true + } +} +``` + +## process.v2.retrieval_policy +```json +{ + "event": "retrieval_plan_resolved", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "limit": 400, + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## process.v2.pipeline +```json +{ + "event": "retrieval_profile_selected", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана" + }, + "input": {}, + "output": { + "profile": "api_exposed" + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "fetch_rag_rows", + "title": "Получение строк из RAG" + }, + "input": {}, + "output": { + "retrieved_row_count": 3 + } +} +``` + +## process.v2.evidence +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2, + "endpoints": [ + "GET /api/v1/clients/contacts-dgr", + "GET /api/v1/clients/contacts-dgr/{contactid}" + ] +} +``` + +## process.v2.pipeline +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2 +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "build_api_exposed_evidence", + "title": "Сборка списка API" + }, + "input": {}, + "output": { + "endpoint_count": 2 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API" + }, + "input": {}, + "output": { + "answer_length": 77 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_trace_flushed", + "workflow_id": "v2.docs_explain.api_exposed", + "steps": [ + { + "step_id": "require_rag_session", + "title": "Проверка RAG-сессии", + "input": {}, + "output": { + "has_rag_session": true + } + }, + { + "step_id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана", + "input": {}, + "output": { + "profile": "api_exposed" + } + }, + { + "step_id": "fetch_rag_rows", + "title": "Получение строк из RAG", + "input": {}, + "output": { + "retrieved_row_count": 3 + } + }, + { + "step_id": "build_api_exposed_evidence", + "title": "Сборка списка API", + "input": {}, + "output": { + "endpoint_count": 2 + } + }, + { + "step_id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API", + "input": {}, + "output": { + "answer_length": 77 + } + } + ] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_completed", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## process.v2.pipeline +```json +{ + "event": "answer_generated", + "answer_mode": "deterministic", + "answer_length": 77 +} +``` + +## result +```json +{ + "status": "done", + "answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}", + "completed_at": "2026-04-10T10:57:52.887621+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-112313-5e81a827ea36.md b/runtime_traces/agent_requests/20260410-112313-5e81a827ea36.md new file mode 100644 index 0000000..1d316cd --- /dev/null +++ b/runtime_traces/agent_requests/20260410-112313-5e81a827ea36.md @@ -0,0 +1,326 @@ +# Runtime Trace: 20260410-112313-5e81a827ea36 + +- active_rag_session_id: eaded8e6-68f4-41b4-a4ac-5e81a827ea36 + +## request +```json +{ + "request_id": "req_4c84fafeba0b4b1eaa7f8a30442b1281", + "session_id": "as_b47105603b6640b28577ab27083b1499", + "active_rag_session_id": "eaded8e6-68f4-41b4-a4ac-5e81a827ea36", + "process_version": "v2", + "created_at": "2026-04-10T11:23:13.818952+00:00", + "message": "какие методы апи есть в проекте?" +} +``` + +## process.v2 +```json +{ + "event": "intent_routed", + "routing_domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "normalized_query": "какие методы апи есть в проекте?", + "target_terms": [], + "anchors": { + "entity_names": [], + "file_names": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "process_domain": null, + "process_subdomain": null, + "scope_type": "global", + "candidate_domains": [], + "candidate_subdomains": [], + "candidate_entities": [], + "candidate_apis": [], + "signal_types": [] + }, + "confidence": 0.8500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно касается перечисления доступных API-методов проекта.", + "rag_session_id": "eaded8e6-68f4-41b4-a4ac-5e81a827ea36" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "confidence": 0.8500000000000001 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "target_terms": [] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_started", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "require_rag_session", + "title": "Проверка RAG-сессии" + }, + "input": {}, + "output": { + "has_rag_session": true + } +} +``` + +## process.v2.retrieval_policy +```json +{ + "event": "retrieval_plan_resolved", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "limit": 400, + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## process.v2.pipeline +```json +{ + "event": "retrieval_profile_selected", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана" + }, + "input": {}, + "output": { + "profile": "api_exposed" + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "fetch_rag_rows", + "title": "Получение строк из RAG" + }, + "input": {}, + "output": { + "retrieved_row_count": 3 + } +} +``` + +## process.v2.evidence +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2, + "endpoints": [ + "GET /api/v1/clients/contacts-dgr", + "GET /api/v1/clients/contacts-dgr/{contactid}" + ] +} +``` + +## process.v2.pipeline +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 2 +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "build_api_exposed_evidence", + "title": "Сборка списка API" + }, + "input": {}, + "output": { + "endpoint_count": 2 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API" + }, + "input": {}, + "output": { + "answer_length": 77 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_trace_flushed", + "workflow_id": "v2.docs_explain.api_exposed", + "steps": [ + { + "step_id": "require_rag_session", + "title": "Проверка RAG-сессии", + "input": {}, + "output": { + "has_rag_session": true + } + }, + { + "step_id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана", + "input": {}, + "output": { + "profile": "api_exposed" + } + }, + { + "step_id": "fetch_rag_rows", + "title": "Получение строк из RAG", + "input": {}, + "output": { + "retrieved_row_count": 3 + } + }, + { + "step_id": "build_api_exposed_evidence", + "title": "Сборка списка API", + "input": {}, + "output": { + "endpoint_count": 2 + } + }, + { + "step_id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API", + "input": {}, + "output": { + "answer_length": 77 + } + } + ] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_completed", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## process.v2.pipeline +```json +{ + "event": "answer_generated", + "answer_mode": "deterministic", + "answer_length": 77 +} +``` + +## result +```json +{ + "status": "done", + "answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}", + "completed_at": "2026-04-10T11:23:16.382407+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-115411-d8eee7186d3c.md b/runtime_traces/agent_requests/20260410-115411-d8eee7186d3c.md new file mode 100644 index 0000000..7103b9f --- /dev/null +++ b/runtime_traces/agent_requests/20260410-115411-d8eee7186d3c.md @@ -0,0 +1,1566 @@ +# Runtime Trace: 20260410-115411-d8eee7186d3c + +- active_rag_session_id: 6728976c-0af8-426c-8de7-d8eee7186d3c + +## request +```json +{ + "request_id": "req_83d42364a2ea4ed194378093e87f046b", + "session_id": "as_4130dced39a64c3d854a52e38cce0971", + "active_rag_session_id": "6728976c-0af8-426c-8de7-d8eee7186d3c", + "process_version": "v2", + "created_at": "2026-04-10T11:54:11.381669+00:00", + "message": "Опиши документаци по аналитике /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": "Запрос содержит указание на конкретный файл с аналитикой и требует описания документации.", + "rag_session_id": "6728976c-0af8-426c-8de7-d8eee7186d3c" +} +``` + +## 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### Пользовательский сценарий\\\\n1. Пользователь заполняет форму с данными контакта.\\\\n2. Нажимает кнопку «Добавить».\\\\n3. Вызывается API-метод POST /api/v1/clients/contacts-dgr.\\\\n4. Отображается push-уведомление о результате операции.\\\\n### Связанные API и сущности\\\\n- **API**: POST /api/v1/clients/contacts-dgr\\\\n### Функциональные требования\\\\nFR-1: При нажатии кнопки «Добавить» осуществляется вызов API-метода POST /api/v1/clients/contacts-dgr с переданными параметрами формы.\\\\n### Нефункциональные требования\\\\nNFR-1: Время отклика API не превышает 3 секунд.\\\\n### Ограничения и граничные случаи\\\\n- Недопустимы пустые значения обязательных полей.\\\\n### Ошибки и валидации\\\\n- Проверяется корректность введенных данных.\\\\n- При ошибке возвращается сообщение об ошибке.\\\\n### Связанный код\\\\n- ufs.contacts_dgr (обработка запросов)\\\\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\": \"Реализация сервиса 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: CREATE КОНТАКТА CONTACTS_DGR API\\nmodule: contacts_dgr\\nlayer: ufservice\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nendpoint: POST /api/v1/clients/contacts-dgr\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-10\\ntags: [clients, contact]\\nentities: []\\nlinks: {}\\n---\\n\\n# CREATE КОНТАКТА CONTACTS_DGR API\\n\\n## Summary\\n\\nЦель метода: создание нового контакта клиентов в системе Contacts DGR.\\n\\n**Purpose**: Создание контакта.\\n**Actor**: Клиенты системы.\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\n\\n## Details\\n\\n## Описание\\n\\nМетод позволяет создавать новый контакт клиента в системе Contacts DGR.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта\\n\\n**Предусловия:**\\n- Пользователь аутентифицирован в системе.\\n- Имеются корректные данные о контакте и клиенте.\\n\\n**Триггер:**\\n- Отправлен HTTP-запрос POST /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется валидность входящего запроса (FR-1).\\n2. Выполняется проверка прав доступа пользователя (FR-2).\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr (FR-3).\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\nНет.\\n\\n**Обработка ошибок:**\\n- В случае ошибки проверки схемы запроса – завершение сценария с кодом BAD_REQUEST.\\n- При отсутствии необходимого пермишена – завершение сценария с кодом UNAUTHORIZED.\\n\\n**Постусловие:**\\nСоздан контакт клиента в системе Contacts DGR.\\n\\n## Функциональные требования\\n\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr.\\n\\n## Нефункциональные требования\\nОтсутствуют.\\n\\n## Контракт\\n\\n### Входные параметры\\n\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |\\n|---------|----------------|------------------|---------------|---------------------|---------------------------------------------------------------------------------------------|---------------------------------|\\n| headers | header | | | | Хедеры запроса | |\\n| X-Request-Id | header | uuid | 1 | | Сквозной идентификатор вызова | e8b6e5c2-f8f7-4a6c-bd1e-c97b811d5b26 |\\n| X-Client-Ident-Id | header | string(50) | 1 | | Идентификатор системы потребителя | client1 |\\n| X-Employee-Number | header | string(8) | 0..1 | | Табельный номер пользователя, вызвавшего сервис | 12345678 |\\n| body | body | object | | | Тело запроса с данными контакта и клиента | |\\n| contact | body | object | 1 | | Данные контакта ДГР | |\\n| lastName | body | string(100) | 0..1 | | Фамилия контакта | Иванов |\\n| firstName | body | string(100) | 0..1 | | Имя контакта | Иван |\\n| middleName | body | string(100) | 0..1 | | Отчество контакта | Иванович |\\n| name | body | string(100) | 0..1 | | Название группового контакта | Группа 1 |\\n| description | body | string(1000) | 0..1 | | Описание группового контакта | Тестовое описание группы контактов |\\n| position | body | string(100) | 0..1 | | Должность контакта у клиента | Менеджер |\\n| comment | body | string(1000) | 0..1 | | Комментарий к контакту | Дополнительная информация |\\n| contactType | body | enum(string) | 1 | Individual, Group | Тип контакта | Individual |\\n| crossboarding | body | boolean | 1 | | Признак принадлежности контакта к процессу онбординга | true |\\n| createdBy | body | string(8) | 1 | | Табельный номер пользователя, создавшего контакт | 12345678 |\\n| emails | body | array(object) | 0..1 | | Массив электронных адресов контакта | |\\n| value | body | string(100) | 1 | внутри массива emails | Электронный адрес | ivan.ivanov@example.com |\\n| main | body | boolean | 1 | внутри массива emails | Признак основной почты | true |\\n| phones | body | array(object) | 0..1 | | Массив телефонных номеров контакта | |\\n| value | body | string(20) | 1 | внутри массива phones | Телефонный номер контакта | +79998887766 |\\n| extValue | body | string(10) | 0..1 | внутри массива phones | Добавочный номер | 123 |\\n| main | body | boolean | 1 | внутри массива phones | Признак основного телефона | true |\\n| mobile | body | boolean | 1 | внутри массива phones | Признак мобильного телефона | false |\\n| client | body | object | 1 | | Данные клиента | |\\n| ucpId | body | string(36) | 0..1 | | Идентификатор клиента ПАО | 123e4567-e89b-12d3-a456-426614174000 |\\n| sbpId | body | string(36) | 0..1 | | Идентификатор клиента АО | 123e4567-e89b-12d3-a456-426614174001 |\\n| inn | body | string(12) | 0..1 | | ИНН клиента | 123456789012 |\\n| kpp | body | string(9) | 0..1 | | КПП клиента | 123456789 |\\n\\n### Выходные параметры\\n\\n| Атрибут | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |\\n|------------|----------------|---------------|--------------|-----------------------------------------|-----------------|----------------------|\\n| contactId | string(36) | 1 | UUID format | Идентификатор созданного контакта | system generated | 123e4567-e89b-12d3-a456-426614174000 |\\n\\n## Интеграции\\n\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\n\\n## Ошибки\\n\\nHTTP-код 400 BAD_REQUEST – неверный формат запроса.\\nHTTP-код 401 UNAUTHORIZED – отсутствует необходимый пермишен.\"\n}\"" +} +``` + +## workflow.v2.docs_update.from_feature.llm +```json +{ + "event": "changeset_json_parse_failed", + "path": "docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md", + "raw_chars": 10165 +} +``` + +## workflow.v2.docs_update.from_feature.llm +```json +{ + "event": "request", + "prompt_name": "v2_docs_update.repair_doc_changeset_json", + "system_prompt": "Ты ремонтируешь невалидный ответ модели и должен вернуть строго валидный JSON changeset.\n\nВход содержит:\n- expected_contract: ожидаемые поля и ограничения.\n- raw_llm_output: исходный (возможно невалидный) ответ.\n\nЗадача:\n- Извлеки максимально полный смысл из raw_llm_output.\n- Верни ровно один JSON-объект, соответствующий expected_contract.\n- Если часть данных отсутствует, используй безопасные значения по умолчанию:\n - reason: \"generated by repair\"\n - proposed_content: только если op=create/update, иначе не добавляй.\n\nОграничения вывода:\n- Только JSON-объект, без markdown/code fences/комментариев.\n- Двойные кавычки, без trailing commas.\n- Внутри строк (особенно proposed_content) все переносы строк должны быть экранированы как \\\\n, не literal newline.", + "user_prompt": "{\n \"expected_contract\": {\n \"op\": \"create\",\n \"path\": \"docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md\",\n \"required_keys\": [\n \"op\",\n \"path\",\n \"reason\"\n ],\n \"proposed_content_required_for\": [\n \"create\",\n \"update\"\n ]\n },\n \"raw_llm_output\": \"{\\n \\\"op\\\": \\\"create\\\",\\n \\\"path\\\": \\\"docs/contacts_dgr/ufs/api/ufs.contacts_dgr_api_create.md\\\",\\n \\\"reason\\\": \\\"Реализация сервиса 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: CREATE КОНТАКТА CONTACTS_DGR API\\\\nmodule: contacts_dgr\\\\nlayer: ufservice\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\nendpoint: POST /api/v1/clients/contacts-dgr\\\\nrelated_docs: []\\\\nstatus: draft\\\\nupdated_at: 2023-10-10\\\\ntags: [clients, contact]\\\\nentities: []\\\\nlinks: {}\\\\n---\\\\n\\\\n# CREATE КОНТАКТА CONTACTS_DGR API\\\\n\\\\n## Summary\\\\n\\\\nЦель метода: создание нового контакта клиентов в системе Contacts DGR.\\\\n\\\\n**Purpose**: Создание контакта.\\\\n**Actor**: Клиенты системы.\\\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\\\n\\\\n## Details\\\\n\\\\n## Описание\\\\n\\\\nМетод позволяет создавать новый контакт клиента в системе Contacts DGR.\\\\n\\\\n## Сценарий\\\\n\\\\n**Название:** Создание контакта\\\\n\\\\n**Предусловия:**\\\\n- Пользователь аутентифицирован в системе.\\\\n- Имеются корректные данные о контакте и клиенте.\\\\n\\\\n**Триггер:**\\\\n- Отправлен HTTP-запрос POST /api/v1/clients/contacts-dgr.\\\\n\\\\n**Основной сценарий:**\\\\n1. Проверяется валидность входящего запроса (FR-1).\\\\n2. Выполняется проверка прав доступа пользователя (FR-2).\\\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr (FR-3).\\\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\\\n\\\\n**Альтернативный сценарий:**\\\\nНет.\\\\n\\\\n**Обработка ошибок:**\\\\n- В случае ошибки проверки схемы запроса – завершение сценария с кодом BAD_REQUEST.\\\\n- При отсутствии необходимого пермишена – завершение сценария с кодом UNAUTHORIZED.\\\\n\\\\n**Постусловие:**\\\\nСоздан контакт клиента в системе Contacts DGR.\\\\n\\\\n## Функциональные требования\\\\n\\\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr.\\\\n\\\\n## Нефункциональные требования\\\\nОтсутствуют.\\\\n\\\\n## Контракт\\\\n\\\\n### Входные параметры\\\\n\\\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |\\\\n|---------|----------------|------------------|---------------|---------------------|---------------------------------------------------------------------------------------------|---------------------------------|\\\\n| headers | header | | | | Хедеры запроса | |\\\\n| X-Request-Id | header | uuid | 1 | | Сквозной идентификатор вызова | e8b6e5c2-f8f7-4a6c-bd1e-c97b811d5b26 |\\\\n| X-Client-Ident-Id | header | string(50) | 1 | | Идентификатор системы потребителя | client1 |\\\\n| X-Employee-Number | header | string(8) | 0..1 | | Табельный номер пользователя, вызвавшего сервис | 12345678 |\\\\n| body | body | object | | | Тело запроса с данными контакта и клиента | |\\\\n| contact | body | object | 1 | | Данные контакта ДГР | |\\\\n| lastName | body | string(100) | 0..1 | | Фамилия контакта | Иванов |\\\\n| firstName | body | string(100) | 0..1 | | Имя контакта | Иван |\\\\n| middleName | body | string(100) | 0..1 | | Отчество контакта | Иванович |\\\\n| name | body | string(100) | 0..1 | | Название группового контакта | Группа 1 |\\\\n| description | body | string(1000) | 0..1 | | Описание группового контакта | Тестовое описание группы контактов |\\\\n| position | body | string(100) | 0..1 | | Должность контакта у клиента | Менеджер |\\\\n| comment | body | string(1000) | 0..1 | | Комментарий к контакту | Дополнительная информация |\\\\n| contactType | body | enum(string) | 1 | Individual, Group | Тип контакта | Individual |\\\\n| crossboarding | body | boolean | 1 | | Признак принадлежности контакта к процессу онбординга | true |\\\\n| createdBy | body | string(8) | 1 | | Табельный номер пользователя, создавшего контакт | 12345678 |\\\\n| emails | body | array(object) | 0..1 | | Массив электронных адресов контакта | |\\\\n| value | body | string(100) | 1 | внутри массива emails | Электронный адрес | ivan.ivanov@example.com |\\\\n| main | body | boolean | 1 | внутри массива emails | Признак основной почты | true |\\\\n| phones | body | array(object) | 0..1 | | Массив телефонных номеров контакта | |\\\\n| value | body | string(20) | 1 | внутри массива phones | Телефонный номер контакта | +79998887766 |\\\\n| extValue | body | string(10) | 0..1 | внутри массива phones | Добавочный номер | 123 |\\\\n| main | body | boolean | 1 | внутри массива phones | Признак основного телефона | true |\\\\n| mobile | body | boolean | 1 | внутри массива phones | Признак мобильного телефона | false |\\\\n| client | body | object | 1 | | Данные клиента | |\\\\n| ucpId | body | string(36) | 0..1 | | Идентификатор клиента ПАО | 123e4567-e89b-12d3-a456-426614174000 |\\\\n| sbpId | body | string(36) | 0..1 | | Идентификатор клиента АО | 123e4567-e89b-12d3-a456-426614174001 |\\\\n| inn | body | string(12) | 0..1 | | ИНН клиента | 123456789012 |\\\\n| kpp | body | string(9) | 0..1 | | КПП клиента | 123456789 |\\\\n\\\\n### Выходные параметры\\\\n\\\\n| Атрибут | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |\\\\n|------------|----------------|---------------|--------------|-----------------------------------------|-----------------|----------------------|\\\\n| contactId | string(36) | 1 | UUID format | Идентификатор созданного контакта | system generated | 123e4567-e89b-12d3-a456-426614174000 |\\\\n\\\\n## Интеграции\\\\n\\\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\\\n\\\\n## Ошибки\\\\n\\\\nHTTP-код 400 BAD_REQUEST – неверный формат запроса.\\\\nHTTP-код 401 UNAUTHORIZED – отсутствует необходимый пермишен.\\\"\\n}\\\"\"\n}", + "log_context": "workflow.v2.docs_update.from_feature.changeset_repair" +} +``` + +## workflow.v2.docs_update.from_feature.llm +```json +{ + "event": "response", + "text": "{\"op\":\"create\",\"path\":\"docs/contacts_dgr/ufs/api/ufs.contacts_dgr.api.create.md\",\"reason\":\"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\"proposed_content\":\"---\\\\nid: ufs.contacts_dgr.api.create\\\\ntype: api_method\\\\ndoc_type: api_method\\\\nname: create_contact\\\\ntitle: CREATE КОНТАКТА CONTACTS_DGR API\\\\nmodule: contacts_dgr\\\\nlayer: ufservice\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\nendpoint: POST /api/v1/clients/contacts-dgr\\\\nrelated_docs: []\\\\nstatus: draft\\\\nupdated_at: 2023-10-10\\\\ntags: [clients, contact]\\\\nentities: []\\\\nlinks: {}\\\\n---\\\\n\\\\n# CREATE КОНТАКТА CONTACTS_DGR API\\\\n\\\\n## Summary\\\\n\\\\nЦель метода: создание нового контакта клиентов в системе Contacts DGR.\\\\n\\\\n**Purpose**: Создание контакта.\\\\n**Actor**: Клиенты системы.\\\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\\\n\\\\n## Details\\\\n\\\\n## Описание\\\\n\\\\nМетод позволяет создавать новый контакт клиента в системе Contacts DGR.\\\\n\\\\n## Сценарий\\\\n\\\\n**Название:** Создание контакта\\\\n\\\\n**Предусловия:**\\\\n- Пользователь аутентифицирован в системе.\\\\n- Имеются корректные данные о контакте и клиенте.\\\\n\\\\n**Триггер:**\\\\n- Отправлен HTTP-запрос POST /api/v1/clients/contacts-dgr.\\\\n\\\\n**Основной сценарий:**\\\\n1. Проверяется валидность входящего запроса (FR-1).\\\\n2. Выполняется проверка прав доступа пользователя (FR-2).\\\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr (FR-3).\\\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\\\n\\\\n**Альтернативный сценарий:**\\\\nНет.\\\\n\\\\n**Обработка ошибок:**\\\\n- В случае ошибки проверки схемы запроса – завершение сценария с кодом BAD_REQUEST.\\\\n- При отсутствии необходимого пермишена – завершение сценария с кодом UNAUTHORIZED.\\\\n\\\\n**Постусловие:**\\\\nСоздан контакт клиента в системе Contacts DGR.\\\\n\\\\n## Функциональные требования\\\\n\\\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr.\\\\n\\\\n## Нефункциональные требования\\\\nОтсутствуют.\\\\n\\\\n## Контракт\\\\n\\\\n### Входные параметры\\\\n\\\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |\\\\n|---------|----------------|------------------|---------------|---------------------|---------------------------------------------------------------------------------------------|--------------------------------|\\\\n| headers | header | | | | Хедеры запроса | |\\\\n| X-Request-Id | header | uuid | 1 | | Сквозной идентификатор вызова | e8b6e5c2-f8f7-4a6c-bd1e-c97b811d5b26 |\\\\n| X-Client-Ident-Id | header | string(50) | 1 | | Идентификатор системы потребителя | client1 |\\\\n| X-Employee-Number | header | string(8) | 0..1 | | Табельный номер пользователя, вызвавшего сервис | 12345678 |\\\\n| body | body | object | | | Тело запроса с данными контакта и клиента | |\\\\n| contact | body | object | 1 | | Данные контакта ДГР | |\\\\n| lastName | body | string(100) | 0..1 | | Фамилия контакта | Иванов |\\\\n| firstName | body | string(100) | 0..1 | | Имя контакта | Иван |\\\\n| middleName | body | string(100) | 0..1 | | Отчество контакта | Иванович |\\\\n| name | body | string(100) | 0..1 | | Название группового контакта | Группа 1 |\\\\n| description | body | string(1000) | 0..1 | | Описание группового контакта | Тестовое описание группы контактов |\\\\n| position | body | string(100) | 0..1 | | Должность контакта у клиента | Менеджер |\\\\n| comment | body | string(1000) | 0..1 | | Комментарий к контакту | Дополнительная информация |\\\\n| contactType | body | enum(string) | 1 | Individual, Group | Тип контакта | Individual |\\\\n| crossboarding | body | boolean | 1 | | Признак принадлежности контакта к процессу онбординга | true |\\\\n| createdBy | body | string(8) | 1 | | Табельный номер пользователя, создавшего контакт | 12345678 |\\\\n| emails | body | array(object) | 0..1 | | Массив электронных адресов контакта | |\\\\n| value | body | string(100) | 1 | внутри массива emails | Электронный адрес | ivan.ivanov@example.com |\\\\n| main | body | boolean | 1 | внутри массива emails | Признак основной почты | true |\\\\n| phones | body | array(object) | 0..1 | | Массив телефонных номеров контакта | |\\\\n| value | body | string(20) | 1 | внутри массива phones | Телефонный номер контакта | +79998887766 |\\\\n| extValue | body | string(10) | 0..1 | внутри массива phones | Добавочный номер | 123 |\\\\n| main | body | boolean | 1 | внутри массива phones | Признак основного телефона | true |\\\\n| mobile | body | boolean | 1 | внутри массива phones | Признак мобильного телефона | false |\\\\n| client | body | object | 1 | | Данные клиента | |\\\\n| ucpId | body | string(36) | 0..1 | | Идентификатор клиента ПАО | 123e4567-e89b-12d3-a456-426614174000 |\\\\n| sbpId | body | string(36) | 0..1 | | Идентификатор клиента АО | 123e4567-e89b-12d3-a456-426614174001 |\\\\n| inn | body | string(12) | 0..1 | | ИНН клиента | 123456789012 |\\\\n| kpp | body | string(9) | 0..1 | | КПП клиента | 123456789 |\\\\n\\\\n### Выходные параметры\\\\n\\\\n| Атрибут | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |\\\\n|------------|----------------|---------------|--------------|-----------------------------------------|-----------------|----------------------|\\\\n| contactId | string(36) | 1 | UUID format | Идентификатор созданного контакта | system generated | 123e4567-e89b-12d3-a456-426614174000 |\\\\n\\\\n## Интеграции\\\\n\\\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\\\n\\\\n## Ошибки\\\\n\\\\nHTTP-код 400 BAD_REQUEST – неверный формат запроса.\\\\nHTTP-код 401 UNAUTHORIZED – отсутствует необходимый пермишен.\"}" +} +``` + +## 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": 12237, + "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": 12237, + "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": 12237, + "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": 12237, + "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": 12237, + "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### Пользовательский сценарий\\\\n1. Пользователь заполняет форму с данными контакта.\\\\n2. Нажимает кнопку «Добавить».\\\\n3. Вызывается API-метод POST /api/v1/clients/contacts-dgr.\\\\n4. Отображается push-уведомление о результате операции.\\\\n### Связанные API и сущности\\\\n- **API**: POST /api/v1/clients/contacts-dgr\\\\n### Функциональные требования\\\\nFR-1: При нажатии кнопки «Добавить» осуществляется вызов API-метода POST /api/v1/clients/contacts-dgr с переданными параметрами формы.\\\\n### Нефункциональные требования\\\\nNFR-1: Время отклика API не превышает 3 секунд.\\\\n### Ограничения и граничные случаи\\\\n- Недопустимы пустые значения обязательных полей.\\\\n### Ошибки и валидации\\\\n- Проверяется корректность введенных данных.\\\\n- При ошибке возвращается сообщение об ошибке.\\\\n### Связанный код\\\\n- ufs.contacts_dgr (обработка запросов)\\\\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: CREATE КОНТАКТА CONTACTS_DGR API\\\\nmodule: contacts_dgr\\\\nlayer: ufservice\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\nendpoint: POST /api/v1/clients/contacts-dgr\\\\nrelated_docs: []\\\\nstatus: draft\\\\nupdated_at: 2023-10-10\\\\ntags: [clients, contact]\\\\nentities: []\\\\nlinks: {}\\\\n---\\\\n\\\\n# CREATE КОНТАКТА CONTACTS_DGR API\\\\n\\\\n## Summary\\\\n\\\\nЦель метода: создание нового контакта клиентов в системе Contacts DGR.\\\\n\\\\n**Purpose**: Создание контакта.\\\\n**Actor**: Клиенты системы.\\\\n**Trigger**: Запрос POST /api/v1/clients/contacts-dgr.\\\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\\\n\\\\n## Details\\\\n\\\\n## Описание\\\\n\\\\nМетод позволяет создавать новый контакт клиента в системе Contacts DGR.\\\\n\\\\n## Сценарий\\\\n\\\\n**Название:** Создание контакта\\\\n\\\\n**Предусловия:**\\\\n- Пользователь аутентифицирован в системе.\\\\n- Имеются корректные данные о контакте и клиенте.\\\\n\\\\n**Триггер:**\\\\n- Отправлен HTTP-запрос POST /api/v1/clients/contacts-dgr.\\\\n\\\\n**Основной сценарий:**\\\\n1. Проверяется валидность входящего запроса (FR-1).\\\\n2. Выполняется проверка прав доступа пользователя (FR-2).\\\\n3. Вызывается endpoint POST /contacts в prpb.contacts_dgr (FR-3).\\\\n4. Формируется и возвращается ответ в формате UfsBaseResponseContactDGRCreateRsDto.\\\\n\\\\n**Альтернативный сценарий:**\\\\nНет.\\\\n\\\\n**Обработка ошибок:**\\\\n- В случае ошибки проверки схемы запроса – завершение сценария с кодом BAD_REQUEST.\\\\n- При отсутствии необходимого пермишена – завершение сценария с кодом UNAUTHORIZED.\\\\n\\\\n**Постусловие:**\\\\nСоздан контакт клиента в системе Contacts DGR.\\\\n\\\\n## Функциональные требования\\\\n\\\\n**FR-1.** Проверить входящий запрос на соответствие JSON-схеме.\\\\n**FR-2.** Авторизовать запрос по наличию пермишена CI02792632.ContactsDGR.Create.\\\\n**FR-3.** Вызвать endpoint POST /contacts в prpb.contacts_dgr.\\\\n\\\\n## Нефункциональные требования\\\\nОтсутствуют.\\\\n\\\\n## Контракт\\\\n\\\\n### Входные параметры\\\\n\\\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание | Пример |\\\\n|---------|----------------|------------------|---------------|---------------------|---------------------------------------------------------------------------------------------|--------------------------------|\\\\n| headers | header | | | | Хедеры запроса | |\\\\n| X-Request-Id | header | uuid | 1 | | Сквозной идентификатор вызова | e8b6e5c2-f8f7-4a6c-bd1e-c97b811d5b26 |\\\\n| X-Client-Ident-Id | header | string(50) | 1 | | Идентификатор системы потребителя | client1 |\\\\n| X-Employee-Number | header | string(8) | 0..1 | | Табельный номер пользователя, вызвавшего сервис | 12345678 |\\\\n| body | body | object | | | Тело запроса с данными контакта и клиента | |\\\\n| contact | body | object | 1 | | Данные контакта ДГР | |\\\\n| lastName | body | string(100) | 0..1 | | Фамилия контакта | Иванов |\\\\n| firstName | body | string(100) | 0..1 | | Имя контакта | Иван |\\\\n| middleName | body | string(100) | 0..1 | | Отчество контакта | Иванович |\\\\n| name | body | string(100) | 0..1 | | Название группового контакта | Группа 1 |\\\\n| description | body | string(1000) | 0..1 | | Описание группового контакта | Тестовое описание группы контактов |\\\\n| position | body | string(100) | 0..1 | | Должность контакта у клиента | Менеджер |\\\\n| comment | body | string(1000) | 0..1 | | Комментарий к контакту | Дополнительная информация |\\\\n| contactType | body | enum(string) | 1 | Individual, Group | Тип контакта | Individual |\\\\n| crossboarding | body | boolean | 1 | | Признак принадлежности контакта к процессу онбординга | true |\\\\n| createdBy | body | string(8) | 1 | | Табельный номер пользователя, создавшего контакт | 12345678 |\\\\n| emails | body | array(object) | 0..1 | | Массив электронных адресов контакта | |\\\\n| value | body | string(100) | 1 | внутри массива emails | Электронный адрес | ivan.ivanov@example.com |\\\\n| main | body | boolean | 1 | внутри массива emails | Признак основной почты | true |\\\\n| phones | body | array(object) | 0..1 | | Массив телефонных номеров контакта | |\\\\n| value | body | string(20) | 1 | внутри массива phones | Телефонный номер контакта | +79998887766 |\\\\n| extValue | body | string(10) | 0..1 | внутри массива phones | Добавочный номер | 123 |\\\\n| main | body | boolean | 1 | внутри массива phones | Признак основного телефона | true |\\\\n| mobile | body | boolean | 1 | внутри массива phones | Признак мобильного телефона | false |\\\\n| client | body | object | 1 | | Данные клиента | |\\\\n| ucpId | body | string(36) | 0..1 | | Идентификатор клиента ПАО | 123e4567-e89b-12d3-a456-426614174000 |\\\\n| sbpId | body | string(36) | 0..1 | | Идентификатор клиента АО | 123e4567-e89b-12d3-a456-426614174001 |\\\\n| inn | body | string(12) | 0..1 | | ИНН клиента | 123456789012 |\\\\n| kpp | body | string(9) | 0..1 | | КПП клиента | 123456789 |\\\\n\\\\n### Выходные параметры\\\\n\\\\n| Атрибут | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример |\\\\n|------------|----------------|---------------|--------------|-----------------------------------------|-----------------|----------------------|\\\\n| contactId | string(36) | 1 | UUID format | Идентификатор созданного контакта | system generated | 123e4567-e89b-12d3-a456-426614174000 |\\\\n\\\\n## Интеграции\\\\n\\\\nИнтеграция с сервисом prpb.contacts_dgr через endpoint POST /contacts.\\\\n\\\\n## Ошибки\\\\n\\\\nHTTP-код 400 BAD_REQUEST – неверный формат запроса.\\\\nHTTP-код 401 UNAUTHORIZED – отсутствует необходимый пермишен.\",\n \"reason\": \"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T11:55:43.958091+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-120145-6928a618382d.md b/runtime_traces/agent_requests/20260410-120145-6928a618382d.md new file mode 100644 index 0000000..51bd007 --- /dev/null +++ b/runtime_traces/agent_requests/20260410-120145-6928a618382d.md @@ -0,0 +1,1538 @@ +# Runtime Trace: 20260410-120145-6928a618382d + +- active_rag_session_id: 24bca5cf-5b10-41f6-838f-6928a618382d + +## request +```json +{ + "request_id": "req_29a806a470f8490bbba594f41d5ed02a", + "session_id": "as_d8f7d860f6304887b6b25c0ef349c224", + "active_rag_session_id": "24bca5cf-5b10-41f6-838f-6928a618382d", + "process_version": "v2", + "created_at": "2026-04-10T12:01:45.493323+00:00", + "message": "Сделай документацию по аналитике из /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.9500000000000001, + "routing_mode": "llm_default", + "llm_router_used": true, + "reason_short": "Запрос явно указывает на создание документации из существующего файла с анализом feature.", + "rag_session_id": "24bca5cf-5b10-41f6-838f-6928a618382d" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_UPDATE", + "subintent": "FROM_FEATURE", + "confidence": 0.9500000000000001 +} +``` + +## 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: Создание карточки контакта ДГР\\nmodule: contacts_dgr\\nlayer: presentation\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-05\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [UI, создание контакта]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: реализация функционала создания новой карточки контакта ДГР.\\n- Actor: пользователь системы.\\n- Trigger: заполнение формы создания контакта и нажатие кнопки «Добавить».\\n- Errors: возможные ошибки интеграции с backend-сервисами.\\n- Related API: POST /api/v1/clients/contacts-dgr.\\n\\n## Details\\n\\n### Назначение страницы\\nСтраница предназначена для создания новых карточек контактов ДГР пользователями системы.\\n\\n### Пользовательский сценарий\\nПользователь заполняет форму, система отправляет данные на сервер и уведомляет о результате операции.\\n\\n### Основные блоки интерфейса\\n- Форма ввода атрибутов контакта.\\n- Кнопка «Добавить» для отправки данных.\\n- Блок уведомления об успешности операции.\\n\\n### Связанные API и сущности\\nИнтеграция с ufs.contacts_dgr через API-эндпоинт POST /api/v1/clients/contacts-dgr.\\n\\n### Функциональные требования\\nFR-1: Отправка данных нового контакта ДГР в систему ufs.contacts_dgr.\\nFR-2: Отображение результата операции пользователю в виде push-уведомления.\\n\\n### Нефункциональные требования\\nNFR-1: Высокая доступность сервиса.\\nNFR-2: Защита данных пользователя.\\n\\n### Ограничения и граничные случаи\\nОграничения вводимых данных согласно требованиям системы ufs.contacts_dgr.\\n\\n### Ошибки и валидации\\nОбработка возможных ошибок API и уведомление пользователя.\\n\\n### Связанный код\\nНет.\\n\\n### Связанные документы\\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\": \"Реализация сервиса 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_contacts_dgr\\nmodule: clients\\ndomain: contacts_dgr\\nsub_domain: create_contact\\ntitle: Создание контакта ДГР через API\\nendpoint: POST /api/v1/clients/contacts-dgr\\nstatus: draft\\nupdated_at: 2023-10-10\\nsource_of_truth: system_analytics\\nsystem_analytics_refs: [\\\"section: 5. Функциональные требования\\\"]\\n---\\n\\n# Создание контакта ДГР через API\\n\\n## Summary\\n\\nМетод предназначен для создания контакта ДГР в системе клиентов.\\n\\n**Purpose**: Создание нового контакта ДГР.\\n**Actors**: Клиенты, пользователи с правами CI02792632.ContactsDGR.Create.\\n**Trigger**: POST-запрос на `/api/v1/clients/contacts-dgr`.\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\n\\n## Details\\n\\n## Описание\\n\\nAPI-метод позволяет создавать контактные записи ДГР для клиентов через HTTP-запрос POST к `/api/v1/clients/contacts-dgr`.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь аутентифицирован и имеет доступ к ресурсу.\\n\\n**Триггер:**\\n- Приходит 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- При ошибке проверки схемы запроса происходит завершение сценария с кодом BAD_REQUEST.\\n- При отсутствии необходимого пермишена завершается сценарий с кодом UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- В случае ошибки интеграции с prpb.contacts_dgr сценарий завершает работу с соответствующим кодом ошибки.\\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(NFR здесь отсутствуют)\\n\\n## Контракт\\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) | Индивидуальный или групповой контакт |\\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}" +} +``` + +## 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": 8465, + "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": 8465, + "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": 8465, + "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": 8465, + "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": 8465, + "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: Создание карточки контакта ДГР\\nmodule: contacts_dgr\\nlayer: presentation\\ndomain: contacts_dgr\\nsub_domain: create_contact\\nrelated_docs: []\\nstatus: draft\\nupdated_at: 2023-10-05\\nsource_of_truth: system_analytics\\nparent: null\\nchildren: []\\ntags: [UI, создание контакта]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создание карточки контакта ДГР\\n\\n## Summary\\n\\n- Назначение: реализация функционала создания новой карточки контакта ДГР.\\n- Actor: пользователь системы.\\n- Trigger: заполнение формы создания контакта и нажатие кнопки «Добавить».\\n- Errors: возможные ошибки интеграции с backend-сервисами.\\n- Related API: POST /api/v1/clients/contacts-dgr.\\n\\n## Details\\n\\n### Назначение страницы\\nСтраница предназначена для создания новых карточек контактов ДГР пользователями системы.\\n\\n### Пользовательский сценарий\\nПользователь заполняет форму, система отправляет данные на сервер и уведомляет о результате операции.\\n\\n### Основные блоки интерфейса\\n- Форма ввода атрибутов контакта.\\n- Кнопка «Добавить» для отправки данных.\\n- Блок уведомления об успешности операции.\\n\\n### Связанные API и сущности\\nИнтеграция с ufs.contacts_dgr через API-эндпоинт POST /api/v1/clients/contacts-dgr.\\n\\n### Функциональные требования\\nFR-1: Отправка данных нового контакта ДГР в систему ufs.contacts_dgr.\\nFR-2: Отображение результата операции пользователю в виде push-уведомления.\\n\\n### Нефункциональные требования\\nNFR-1: Высокая доступность сервиса.\\nNFR-2: Защита данных пользователя.\\n\\n### Ограничения и граничные случаи\\nОграничения вводимых данных согласно требованиям системы ufs.contacts_dgr.\\n\\n### Ошибки и валидации\\nОбработка возможных ошибок API и уведомление пользователя.\\n\\n### Связанный код\\nНет.\\n\\n### Связанные документы\\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_contacts_dgr\\nmodule: clients\\ndomain: contacts_dgr\\nsub_domain: create_contact\\ntitle: Создание контакта ДГР через API\\nendpoint: POST /api/v1/clients/contacts-dgr\\nstatus: draft\\nupdated_at: 2023-10-10\\nsource_of_truth: system_analytics\\nsystem_analytics_refs: [\\\"section: 5. Функциональные требования\\\"]\\n---\\n\\n# Создание контакта ДГР через API\\n\\n## Summary\\n\\nМетод предназначен для создания контакта ДГР в системе клиентов.\\n\\n**Purpose**: Создание нового контакта ДГР.\\n**Actors**: Клиенты, пользователи с правами CI02792632.ContactsDGR.Create.\\n**Trigger**: POST-запрос на `/api/v1/clients/contacts-dgr`.\\n**Errors**: BAD_REQUEST, UNAUTHORIZED.\\n\\n## Details\\n\\n## Описание\\n\\nAPI-метод позволяет создавать контактные записи ДГР для клиентов через HTTP-запрос POST к `/api/v1/clients/contacts-dgr`.\\n\\n## Сценарий\\n\\n**Название:** Создание контакта ДГР\\n\\n**Предусловия:**\\n- Пользователь аутентифицирован и имеет доступ к ресурсу.\\n\\n**Триггер:**\\n- Приходит 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- При ошибке проверки схемы запроса происходит завершение сценария с кодом BAD_REQUEST.\\n- При отсутствии необходимого пермишена завершается сценарий с кодом UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- В случае ошибки интеграции с prpb.contacts_dgr сценарий завершает работу с соответствующим кодом ошибки.\\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(NFR здесь отсутствуют)\\n\\n## Контракт\\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) | Индивидуальный или групповой контакт |\\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 \"reason\": \"Реализация сервиса CLIENTS. Создание контакта ДГР через POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T12:02:32.543441+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-121324-7cbccb7c5840.md b/runtime_traces/agent_requests/20260410-121324-7cbccb7c5840.md new file mode 100644 index 0000000..6138ad0 --- /dev/null +++ b/runtime_traces/agent_requests/20260410-121324-7cbccb7c5840.md @@ -0,0 +1,1861 @@ +# Runtime Trace: 20260410-121324-7cbccb7c5840 + +- active_rag_session_id: 79ac0f0b-72a3-4b0a-8251-7cbccb7c5840 + +## request +```json +{ + "request_id": "req_710c8f2449fd4979a9faafc39b67f0b4", + "session_id": "as_340d7bd4e4ef4c59b5c381c51779fd34", + "active_rag_session_id": "79ac0f0b-72a3-4b0a-8251-7cbccb7c5840", + "process_version": "v2", + "created_at": "2026-04-10T12:13:24.428329+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": "79ac0f0b-72a3-4b0a-8251-7cbccb7c5840" +} +``` + +## 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-10T12:13:28.508118+00:00" +} +``` + +## request +```json +{ + "request_id": "req_346208a33edf4c02831c33b5baada3f0", + "session_id": "as_340d7bd4e4ef4c59b5c381c51779fd34", + "active_rag_session_id": "79ac0f0b-72a3-4b0a-8251-7cbccb7c5840", + "process_version": "v2", + "created_at": "2026-04-10T12:13:43.879180+00:00", + "message": "Собери документацию по аналитике /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": "Запрос содержит указание на конкретный файл с аналитикой и требует сбора документации.", + "rag_session_id": "79ac0f0b-72a3-4b0a-8251-7cbccb7c5840" +} +``` + +## 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\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\ntitle: FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\\\nrelated_docs: []\\\\nstatus: draft\\\\n---\\\\n# FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\\\n## Summary\\\\n- Основная цель: реализация функционала создания карточки контакта ДГР.\\\\n- Актор: пользователь.\\\\n- Триггер: заполнение атрибутов карточки и нажатие кнопки «Добавить».\\\\n- Результат: отображение результата создания контакта ДГР в виде push-уведомления.\\\\n## Details\\\\n### Назначение страницы\\\\nСтраница предназначена для создания новой карточки контакта ДГР пользователем.\\\\n### Пользовательский сценарий\\\\n- Пользователь заполняет необходимые атрибуты карточки контакта.\\\\n- Нажимая кнопку «Добавить», инициируется вызов endpoint-а POST /api/v1/clients/contacts-dgr.\\\\n- После обработки запроса ufs.contacts_dgr страница отображает результат операции пользователю.\\\\n### Основные блоки интерфейса\\\\n- Форма ввода атрибутов контакта.\\\\n- Кнопка «Добавить».\\\\n- Блок уведомлений о результате операции.\\\\n### Связанные API и сущности\\\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\\\\n- Обрабатывающая сущность: ufs.contacts_dgr.\\\\n### Функциональные требования\\\\nFR-1: При успешном создании контакта отображается push-уведомление.\\\\n### Нефункциональные требования\\\\nNFR-1: Время отклика endpoint-а POST /api/v1/clients/contacts-dgr не превышает 3 секунд.\\\\n### Ограничения и граничные случаи\\\\nНе указаны.\\\\n### Ошибки и валидации\\\\nВ случае ошибки создается уведомление об ошибке.\\\\n### Связанный код\\\\nКод реализации формы и логики отправки данных.\\\\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\": \"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\n \"proposed_content\": \"---\\nid: ufs.contacts_dgr.api.create\\ntype: api_method\\ndoc_type: api_method\\nname: contacts_dgr_api_create\\ntitle: Создать контакт методом POST /api/v1/clients/contacts-dgr\\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: [clients, contact_dgr]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создать контакт методом POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nМетод предназначен для создания нового контакта клиента в системе Contacts DGR.\\n\\n**Purpose**: создание контакта клиента.\\n**Actor**: клиентская система.\\n**Trigger**: вызов POST /api/v1/clients/contacts-dgr.\\n**Errors**: см. раздел Ошибки.\\n**Related**: UI контакты DGR.\\n\\n## Details\\n\\n### Описание\\n\\nМетод создает новый контакт клиента в системе Contacts DGR. Он проверяет входящие данные, авторизирует запрос и передает информацию в систему прpb.contacts_dgr для дальнейшей обработки.\\n\\n### Сценарий\\n\\n**Название:** создание контакта клиента\\n\\n**Предусловия:**\\n- Наличие валидного токена аутентификации.\\n- Наличие необходимых прав доступа.\\n\\n**Триггер:**\\n- Вызов метода POST /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется входящий запрос на соответствие JSON-схеме.\\n2. Авторизация запроса по наличию пермишена CI02792632.ContactsDGR.Create.\\n3. Вызов endpoint POST /contacts в системе прpb.contacts_dgr.\\n4. Возврат результата операции в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- Отсутствие необходимого пермишена приводит к завершению сценария с ошибкой UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- В случае неверного формата запроса возвращается ошибка BAD_REQUEST.\\n\\n**Постусловие:**\\n- Новый контакт создан и доступен в системе.\\n\\n### Функциональные требования\\n\\n**FR-1.** Проверка входящих данных на соответствие JSON-схеме.\\n**FR-2.** Авторизация запроса по пермишену CI02792632.ContactsDGR.Create.\\n**FR-3.** Передача данных контакта в систему прpb.contacts_dgr.\\n**FR-4.** Формирование и возврат ответа в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n### Нефункциональные требования\\n\\n**NFR-1.** Метод должен обеспечивать высокую доступность и производительность.\\n**NFR-2.** Метод должен соответствовать требованиям безопасности и защиты персональных данных.\\n\\n### Контракт\\n\\n#### Входные параметры\\n\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание |\\n|---------|----------------|----------------|---------------|------------------|-----------------------------------------|\\n| X-Request-Id | header | uuid | да | | сквозной идентификатор вызова |\\n| X-Client-Ident-Id | header | string(50) | да | | идентификатор системы потребителя |\\n| X-Employee-Number | header | string(8) | нет | | табельный номер пользователя |\\n| contact | body | object | да | | данные контакта |\\n| client | body | object | да | | данные клиента |\\n| ... | | | | | дополнительные атрибуты контакта |\\n\\n#### Выходные параметры\\n\\n| Поле | Тип | Обязательность | Ограничения | Описание |\\n|-------------|-----------------|---------------|--------------|----------------------------------|\\n| contactId | string(36) | да | | идентификатор созданного контакта |\\n\\n### Интеграции\\n\\nИнтеграция с системой прpb.contacts_dgr через endpoint POST /contacts.\\n\\n### Ошибки\\n\\n- **BAD_REQUEST**: некорректный формат запроса.\\n- **UNAUTHORIZED**: отсутствие необходимого пермишена.\\n\\n### Связанный код\\n\\nСвязан с реализацией UFS модуля контактов DGR.\\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": 6694, + "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": 6694, + "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": 6694, + "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": 6694, + "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": 6694, + "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\\\\ndomain: contacts_dgr\\\\nsub_domain: create_contact\\\\ntitle: FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\\\nrelated_docs: []\\\\nstatus: draft\\\\n---\\\\n# FR1. Реализовать сценарий «Контакты ДГР. Создание карточки контакта ДГР»\\\\n## Summary\\\\n- Основная цель: реализация функционала создания карточки контакта ДГР.\\\\n- Актор: пользователь.\\\\n- Триггер: заполнение атрибутов карточки и нажатие кнопки «Добавить».\\\\n- Результат: отображение результата создания контакта ДГР в виде push-уведомления.\\\\n## Details\\\\n### Назначение страницы\\\\nСтраница предназначена для создания новой карточки контакта ДГР пользователем.\\\\n### Пользовательский сценарий\\\\n- Пользователь заполняет необходимые атрибуты карточки контакта.\\\\n- Нажимая кнопку «Добавить», инициируется вызов endpoint-а POST /api/v1/clients/contacts-dgr.\\\\n- После обработки запроса ufs.contacts_dgr страница отображает результат операции пользователю.\\\\n### Основные блоки интерфейса\\\\n- Форма ввода атрибутов контакта.\\\\n- Кнопка «Добавить».\\\\n- Блок уведомлений о результате операции.\\\\n### Связанные API и сущности\\\\n- Вызываемый endpoint: POST /api/v1/clients/contacts-dgr.\\\\n- Обрабатывающая сущность: ufs.contacts_dgr.\\\\n### Функциональные требования\\\\nFR-1: При успешном создании контакта отображается push-уведомление.\\\\n### Нефункциональные требования\\\\nNFR-1: Время отклика endpoint-а POST /api/v1/clients/contacts-dgr не превышает 3 секунд.\\\\n### Ограничения и граничные случаи\\\\nНе указаны.\\\\n### Ошибки и валидации\\\\nВ случае ошибки создается уведомление об ошибке.\\\\n### Связанный код\\\\nКод реализации формы и логики отправки данных.\\\\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: contacts_dgr_api_create\\ntitle: Создать контакт методом POST /api/v1/clients/contacts-dgr\\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: [clients, contact_dgr]\\nentities: []\\nlinks: {}\\n---\\n\\n# Создать контакт методом POST /api/v1/clients/contacts-dgr\\n\\n## Summary\\n\\nМетод предназначен для создания нового контакта клиента в системе Contacts DGR.\\n\\n**Purpose**: создание контакта клиента.\\n**Actor**: клиентская система.\\n**Trigger**: вызов POST /api/v1/clients/contacts-dgr.\\n**Errors**: см. раздел Ошибки.\\n**Related**: UI контакты DGR.\\n\\n## Details\\n\\n### Описание\\n\\nМетод создает новый контакт клиента в системе Contacts DGR. Он проверяет входящие данные, авторизирует запрос и передает информацию в систему прpb.contacts_dgr для дальнейшей обработки.\\n\\n### Сценарий\\n\\n**Название:** создание контакта клиента\\n\\n**Предусловия:**\\n- Наличие валидного токена аутентификации.\\n- Наличие необходимых прав доступа.\\n\\n**Триггер:**\\n- Вызов метода POST /api/v1/clients/contacts-dgr.\\n\\n**Основной сценарий:**\\n1. Проверяется входящий запрос на соответствие JSON-схеме.\\n2. Авторизация запроса по наличию пермишена CI02792632.ContactsDGR.Create.\\n3. Вызов endpoint POST /contacts в системе прpb.contacts_dgr.\\n4. Возврат результата операции в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n**Альтернативный сценарий:**\\n- Отсутствие необходимого пермишена приводит к завершению сценария с ошибкой UNAUTHORIZED.\\n\\n**Обработка ошибок:**\\n- В случае неверного формата запроса возвращается ошибка BAD_REQUEST.\\n\\n**Постусловие:**\\n- Новый контакт создан и доступен в системе.\\n\\n### Функциональные требования\\n\\n**FR-1.** Проверка входящих данных на соответствие JSON-схеме.\\n**FR-2.** Авторизация запроса по пермишену CI02792632.ContactsDGR.Create.\\n**FR-3.** Передача данных контакта в систему прpb.contacts_dgr.\\n**FR-4.** Формирование и возврат ответа в формате UfsBaseResponseContactDGRCreateRsDto.\\n\\n### Нефункциональные требования\\n\\n**NFR-1.** Метод должен обеспечивать высокую доступность и производительность.\\n**NFR-2.** Метод должен соответствовать требованиям безопасности и защиты персональных данных.\\n\\n### Контракт\\n\\n#### Входные параметры\\n\\n| Атрибут | Где передается | Тип | Обязательность | Ограничения | Описание |\\n|---------|----------------|----------------|---------------|------------------|-----------------------------------------|\\n| X-Request-Id | header | uuid | да | | сквозной идентификатор вызова |\\n| X-Client-Ident-Id | header | string(50) | да | | идентификатор системы потребителя |\\n| X-Employee-Number | header | string(8) | нет | | табельный номер пользователя |\\n| contact | body | object | да | | данные контакта |\\n| client | body | object | да | | данные клиента |\\n| ... | | | | | дополнительные атрибуты контакта |\\n\\n#### Выходные параметры\\n\\n| Поле | Тип | Обязательность | Ограничения | Описание |\\n|-------------|-----------------|---------------|--------------|----------------------------------|\\n| contactId | string(36) | да | | идентификатор созданного контакта |\\n\\n### Интеграции\\n\\nИнтеграция с системой прpb.contacts_dgr через endpoint POST /contacts.\\n\\n### Ошибки\\n\\n- **BAD_REQUEST**: некорректный формат запроса.\\n- **UNAUTHORIZED**: отсутствие необходимого пермишена.\\n\\n### Связанный код\\n\\nСвязан с реализацией UFS модуля контактов DGR.\\n\\n### История изменений\\n\\nНет.\",\n \"reason\": \"Реализация сервиса CLIENTS. Создание контакта методом POST /api/v1/clients/contacts-dgr\",\n \"hunks\": []\n }\n]\n```\n\napply_changeset: true", + "completed_at": "2026-04-10T12:14:20.937787+00:00" +} +``` diff --git a/runtime_traces/agent_requests/20260410-121449-0ddfbe598bd9.md b/runtime_traces/agent_requests/20260410-121449-0ddfbe598bd9.md new file mode 100644 index 0000000..9fcc814 --- /dev/null +++ b/runtime_traces/agent_requests/20260410-121449-0ddfbe598bd9.md @@ -0,0 +1,327 @@ +# Runtime Trace: 20260410-121449-0ddfbe598bd9 + +- active_rag_session_id: 87655eaf-302b-409d-946c-0ddfbe598bd9 + +## request +```json +{ + "request_id": "req_299f353019a2465e84c88909c8903a31", + "session_id": "as_31564e5fcf6e4048b5cb0496f53b8fee", + "active_rag_session_id": "87655eaf-302b-409d-946c-0ddfbe598bd9", + "process_version": "v2", + "created_at": "2026-04-10T12:14:49.260081+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": "87655eaf-302b-409d-946c-0ddfbe598bd9" +} +``` + +## process.v2.pipeline +```json +{ + "event": "router_resolved", + "domain": "DOCS", + "intent": "DOC_EXPLAIN", + "subintent": "API_EXPOSED", + "confidence": 0.8500000000000001 +} +``` + +## process.v2.pipeline +```json +{ + "event": "anchors_extracted", + "signal_types": [], + "endpoint_paths": [], + "target_doc_hints": [], + "matched_aliases": [], + "target_terms": [] +} +``` + +## process.v2.pipeline +```json +{ + "event": "alias_resolution", + "resolved_aliases": [], + "target_doc_hints": [] +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_started", + "workflow_id": "v2.docs_explain.api_exposed" +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "require_rag_session", + "title": "Проверка RAG-сессии" + }, + "input": {}, + "output": { + "has_rag_session": true + } +} +``` + +## process.v2.retrieval_policy +```json +{ + "event": "retrieval_plan_resolved", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "limit": 400, + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## process.v2.pipeline +```json +{ + "event": "retrieval_profile_selected", + "profile": "api_exposed", + "layers": [ + "D1_DOCUMENT_CATALOG" + ], + "filters": { + "metadata.type": "api_method", + "prefer_path_prefixes": [ + "docs/api/", + "docs/endpoints/", + "docs/methods/", + "api/", + "endpoints/", + "methods/" + ], + "target_doc_hints": [], + "prefer_like_patterns": [ + "%api%", + "%endpoint%", + "%method%", + "%эндпоинт%", + "%метод%" + ] + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана" + }, + "input": {}, + "output": { + "profile": "api_exposed" + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_step_traced", + "workflow_id": "v2.docs_explain.api_exposed", + "step": { + "id": "fetch_rag_rows", + "title": "Получение строк из RAG" + }, + "input": {}, + "output": { + "retrieved_row_count": 3 + } +} +``` + +## process.v2.evidence +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 3, + "endpoints": [ + "GET /api/v1/clients/contacts-dgr", + "GET /api/v1/clients/contacts-dgr/{contactid}", + "POST /api/v1/clients/contacts-dgr" + ] +} +``` + +## process.v2.pipeline +```json +{ + "event": "evidence_assembled", + "mode": "api_exposed", + "endpoint_count": 3 +} +``` + +## 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": 3 + } +} +``` + +## 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": 111 + } +} +``` + +## workflow.v2.api_exposed +```json +{ + "event": "workflow_trace_flushed", + "workflow_id": "v2.docs_explain.api_exposed", + "steps": [ + { + "step_id": "require_rag_session", + "title": "Проверка RAG-сессии", + "input": {}, + "output": { + "has_rag_session": true + } + }, + { + "step_id": "resolve_retrieval_plan", + "title": "Выбор retrieval-плана", + "input": {}, + "output": { + "profile": "api_exposed" + } + }, + { + "step_id": "fetch_rag_rows", + "title": "Получение строк из RAG", + "input": {}, + "output": { + "retrieved_row_count": 3 + } + }, + { + "step_id": "build_api_exposed_evidence", + "title": "Сборка списка API", + "input": {}, + "output": { + "endpoint_count": 3 + } + }, + { + "step_id": "finalize_api_exposed_answer", + "title": "Формирование ответа со списком API", + "input": {}, + "output": { + "answer_length": 111 + } + } + ] +} +``` + +## 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": 111 +} +``` + +## result +```json +{ + "status": "done", + "answer": "GET /api/v1/clients/contacts-dgr\nGET /api/v1/clients/contacts-dgr/{contactid}\nPOST /api/v1/clients/contacts-dgr", + "completed_at": "2026-04-10T12:14:51.286117+00:00" +} +``` diff --git a/src/app/core/agent/processes/v2/doc_rules/README.md b/src/app/core/agent/processes/v2/doc_rules/README.md index 7d5472f..db15670 100644 --- a/src/app/core/agent/processes/v2/doc_rules/README.md +++ b/src/app/core/agent/processes/v2/doc_rules/README.md @@ -42,7 +42,8 @@ ### Sections - `sections/summary.md` - `sections/details.md` -- `sections/api-scenario.md` +- `sections/tech-use-case.md` +- `sections/fr.md` - `sections/api-contract.md` - `sections/requirements-format.md` diff --git a/src/app/core/agent/processes/v2/doc_rules/artifact-types/api_method.md b/src/app/core/agent/processes/v2/doc_rules/artifact-types/api_method.md index bfc6428..3f62fb5 100644 --- a/src/app/core/agent/processes/v2/doc_rules/artifact-types/api_method.md +++ b/src/app/core/agent/processes/v2/doc_rules/artifact-types/api_method.md @@ -25,6 +25,7 @@ ## Особые правила +- Во frontmatter обязательно указывать `endpoint` (например: `POST /api/v1/clients/contacts-dgr`). - Сценарий оформляется как технический use case. - Функциональные требования маркируются `FR-*`. - Нефункциональные требования маркируются `NFR-*`. diff --git a/src/app/core/agent/processes/v2/doc_rules/global/frontmatter.md b/src/app/core/agent/processes/v2/doc_rules/global/frontmatter.md index 2b4dee5..47b7d1a 100644 --- a/src/app/core/agent/processes/v2/doc_rules/global/frontmatter.md +++ b/src/app/core/agent/processes/v2/doc_rules/global/frontmatter.md @@ -47,6 +47,7 @@ system_analytics_refs: [] - `module` — модуль или подсистема. - `layer` — слой системы. - `updated_at` хранится в формате `YYYY-MM-DD`. +- Для документов с `doc_type: api_method` поле `endpoint` является обязательным. ## Связи и навигация diff --git a/src/app/core/agent/processes/v2/doc_rules/sections/api-scenario.md b/src/app/core/agent/processes/v2/doc_rules/sections/api-scenario.md deleted file mode 100644 index c9066af..0000000 --- a/src/app/core/agent/processes/v2/doc_rules/sections/api-scenario.md +++ /dev/null @@ -1,21 +0,0 @@ -# API Scenario Rules - -## Назначение - -Этот файл описывает, как оформлять подраздел `### Сценарий` в API-документах. - -## Обязательные части - -- название -- предусловия -- триггер -- основной сценарий -- альтернативный сценарий -- обработка ошибок -- постусловие - -## Правила - -- Сценарий должен быть лаконичным. -- Сценарий должен отражать суть шага. -- Сложные технические детали надо выносить в `FR-*`. diff --git a/src/app/core/agent/processes/v2/doc_rules/sections/fr.md b/src/app/core/agent/processes/v2/doc_rules/sections/fr.md new file mode 100644 index 0000000..f212330 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules/sections/fr.md @@ -0,0 +1,37 @@ +# Functional requrements rules + +## Назначение + +Этот файл описывает, как оформлять функциональные требования в подраздел `### Функциональные требования` в документах. + +## Правила +- Функциональное требование (FR) расширяет и дополняет шаги, описанные в сценарии. +- Функциональное требование (FR) не должно копировать шаг сценария не неся дополнительной информации. +- Название функционального требования формируется следующим образом - "FR.<номер>. <Название>", где + - <номер> идет инкрементально внутри конкретного документа, начинается с 1. + - <Название> - кратко описывает что делает требование, суть действий (от 3 до 7 слов) + + + +## Пример целевого описания сценария + +### Примеры названия FR + - Получение данных клиента из АС ЕПК + - Проверка уровня доступа + - Сценарий построения списка связанных предложений + + + ### Примеры описания FR +FR.1. Получение данных клиента из АС ЕПК +1. Сформировать запрос к эндпоинту POST /api/v1/path/to/resourse в АС ЕПК + - Заголовки + - <тут идет описание заголовков и того как они формируются> + - Параметры запроса + - <тут идет описание параметров и того как они формируются> + - Тело запроса + - <тут идет описание структуры объекта JSON или payload в другмо формате так как это задано требованиями> + +2. Обработать ответ от АС ЕПК + Успешный ответ - <взять из описания вызываеого api критерии успешного ответа > + Ничего не найдено - <взять из описания вызываеого api критерии успешного овтета, опционально (если применимо)> + Ошибка - <взять из описания вызываеого api критерии успешного ответа > \ No newline at end of file diff --git a/src/app/core/agent/processes/v2/doc_rules/sections/tech-use-case.md b/src/app/core/agent/processes/v2/doc_rules/sections/tech-use-case.md new file mode 100644 index 0000000..572d52f --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules/sections/tech-use-case.md @@ -0,0 +1,66 @@ +# Scenario Rules + +## Назначение + +Этот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах. + +## Обязательные части + +- название +- предусловия +- триггер +- основной сценарий +- альтернативный сценарий +- обработка ошибок +- постусловие + +## Правила +- Основной и альтернативные сценарии состоят из шагов. + +- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>. + +- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование FR.<номер>. <Название> и описать в нем технические детали. А в шаге сослаться на это требование через "Описание приведено в FR.<номер>. <Название>" + +- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки. +- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки. +- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию. + +- Название "FR.<номер>. <Название>" формируется следующим образом: + - <номер> идет инкрементально внутри конкретного документа, начинается с 1. + - <Название> - кратко описывает что делает требование, суть действий. + +- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий. + +- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев. + + - Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке + + - Функциональные требования "FR.<номер>. <Название>" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно. + + - FR обязательно описывается для шага с интеграцией + - FR Не описывается для шага авторизации. + + + + + + +## Пример целевого описания сценария + +### Примеры шагов сценария + +Пример 1 +- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail + - В случае ошибки - завершить сценарий с кодом UNAUTHORIZED + +Пример 2 +- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info + - В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL + +Пример 3 +- Возвращает ответ в формате <название DTO> + +### Примеры названия FR + - Получение данных клиента из АС ЕПК + - Проверка уровня доступа + - Сценарий построения списка связанных предложений \ No newline at end of file diff --git a/src/app/core/agent/processes/v2/doc_rules/templates/api_method.template.md b/src/app/core/agent/processes/v2/doc_rules/templates/api_method.template.md index ba2ac07..3f5a79e 100644 --- a/src/app/core/agent/processes/v2/doc_rules/templates/api_method.template.md +++ b/src/app/core/agent/processes/v2/doc_rules/templates/api_method.template.md @@ -8,6 +8,7 @@ module: example_module layer: application domain: example_domain sub_domain: example_subdomain +endpoint: POST /api/v1/example related_docs: [] status: draft updated_at: 2026-03-20 diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/README.md b/src/app/core/agent/processes/v2/doc_rules_v2/README.md new file mode 100644 index 0000000..1a3ed4b --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/README.md @@ -0,0 +1,27 @@ +# Documentation Rules V2 + +Этот каталог — новая структура правил для DOC_UPDATE/FROM_FEATURE. + +## Цель + +Разделить инструкции на 2 независимых блока: + +1. `types/` — инструкции по структуре конкретных типов документов (`ui_page`, `api_method`, и т.д.). +2. `common-elements/` — инструкции по структуре общих элементов страницы (`tech-use-case`, `fr`, и др.). + +## Структура каталога + +- `documentation-rules.md` — верхнеуровневые правила. +- `global/` — общие правила оформления и frontmatter. +- `types/` — правила по типам документов (вместо `artifact-types/`). +- `common-elements/` — правила по общим секциям (вместо `sections/`). +- `templates/` — шаблоны документов. + +## Переключение профиля + +Загрузчик поддерживает переключение через env: + +- `DOC_RULES_PROFILE=v2` (по умолчанию) — использовать `doc_rules_v2`. +- `DOC_RULES_PROFILE=legacy` — использовать старый каталог `doc_rules`. + +Если `v2` не содержит валидных пар `type + template`, загрузчик автоматически fallback на `doc_rules`. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/api-contract.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/api-contract.md new file mode 100644 index 0000000..fc313ea --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/api-contract.md @@ -0,0 +1,24 @@ +# API Contract Rules + +## Назначение + +Этот файл описывает, как оформлять подраздел `## Контракт` в API-документах. + +## Что должно быть описано + +- входные параметры +- выходные параметры +- JSON-структуры запросов и ответов +- обязательность полей +- типы полей +- ограничения +- описание назначения полей +- примеры данных +- auth +- idempotency +- timeout +- ошибки и их HTTP-коды + +## Правило качества + +Контракт должен быть достаточно формальным, чтобы по нему можно было собрать OpenAPI-спецификацию. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/details.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/details.md new file mode 100644 index 0000000..33ed824 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/details.md @@ -0,0 +1,13 @@ +# Details Section Rules + +## Назначение + +Этот файл задает общие правила для секции `## Details`. + +## Правила + +- `Details` оформляется как `## Details`. +- Внутри `Details` используются заголовки уровня `###` и ниже. +- Структура Details зависит от типа документа. +- В Details не нужно повторно дублировать навигацию и связи, если они уже есть во frontmatter. +- Интеграции, ошибки и кодовые привязки должны быть выделены в отдельные подразделы, если они существенны для понимания документа. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/fr.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/fr.md new file mode 100644 index 0000000..f212330 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/fr.md @@ -0,0 +1,37 @@ +# Functional requrements rules + +## Назначение + +Этот файл описывает, как оформлять функциональные требования в подраздел `### Функциональные требования` в документах. + +## Правила +- Функциональное требование (FR) расширяет и дополняет шаги, описанные в сценарии. +- Функциональное требование (FR) не должно копировать шаг сценария не неся дополнительной информации. +- Название функционального требования формируется следующим образом - "FR.<номер>. <Название>", где + - <номер> идет инкрементально внутри конкретного документа, начинается с 1. + - <Название> - кратко описывает что делает требование, суть действий (от 3 до 7 слов) + + + +## Пример целевого описания сценария + +### Примеры названия FR + - Получение данных клиента из АС ЕПК + - Проверка уровня доступа + - Сценарий построения списка связанных предложений + + + ### Примеры описания FR +FR.1. Получение данных клиента из АС ЕПК +1. Сформировать запрос к эндпоинту POST /api/v1/path/to/resourse в АС ЕПК + - Заголовки + - <тут идет описание заголовков и того как они формируются> + - Параметры запроса + - <тут идет описание параметров и того как они формируются> + - Тело запроса + - <тут идет описание структуры объекта JSON или payload в другмо формате так как это задано требованиями> + +2. Обработать ответ от АС ЕПК + Успешный ответ - <взять из описания вызываеого api критерии успешного ответа > + Ничего не найдено - <взять из описания вызываеого api критерии успешного овтета, опционально (если применимо)> + Ошибка - <взять из описания вызываеого api критерии успешного ответа > \ No newline at end of file diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/requirements-format.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/requirements-format.md new file mode 100644 index 0000000..14eb0c3 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/requirements-format.md @@ -0,0 +1,16 @@ +# Requirements Format Rules + +## Назначение + +Этот файл задает формат для функциональных и нефункциональных требований. + +## Функциональные требования + +- Использовать коды `FR-1`, `FR-2`, `FR-3` и так далее. +- Каждое требование должно описывать отдельный обязательный аспект поведения. +- Идентификаторы локальны в пределах одного документа. + +## Нефункциональные требования + +- Использовать коды `NFR-1`, `NFR-2`, `NFR-3` и так далее. +- Требования должны описывать характеристики качества, ограничения и эксплуатационные свойства. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/summary.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/summary.md new file mode 100644 index 0000000..7f7fa7b --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/summary.md @@ -0,0 +1,13 @@ +# Summary Section Rules + +## Назначение + +Этот файл задает правила для секции `## Summary`. + +## Правила + +- Summary должен быть коротким explain-слоем быстрого контекста. +- Summary должен объяснять суть документа без лишних деталей. +- Summary должен быть пригоден для explain и быстрого чтения. +- Предпочтительный формат: список ключевых фактов `Purpose`, `Actor`, `Trigger`, `Errors`, `Related ...` и т.д. +- Для крупных документов допустим более длинный summary, если он остается структурированным. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/tech-use-case.md b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/tech-use-case.md new file mode 100644 index 0000000..572d52f --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/common-elements/tech-use-case.md @@ -0,0 +1,66 @@ +# Scenario Rules + +## Назначение + +Этот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах. + +## Обязательные части + +- название +- предусловия +- триггер +- основной сценарий +- альтернативный сценарий +- обработка ошибок +- постусловие + +## Правила +- Основной и альтернативные сценарии состоят из шагов. + +- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>. + +- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование FR.<номер>. <Название> и описать в нем технические детали. А в шаге сослаться на это требование через "Описание приведено в FR.<номер>. <Название>" + +- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки. +- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки. +- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию. + +- Название "FR.<номер>. <Название>" формируется следующим образом: + - <номер> идет инкрементально внутри конкретного документа, начинается с 1. + - <Название> - кратко описывает что делает требование, суть действий. + +- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий. + +- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев. + + - Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке + + - Функциональные требования "FR.<номер>. <Название>" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно. + + - FR обязательно описывается для шага с интеграцией + - FR Не описывается для шага авторизации. + + + + + + +## Пример целевого описания сценария + +### Примеры шагов сценария + +Пример 1 +- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail + - В случае ошибки - завершить сценарий с кодом UNAUTHORIZED + +Пример 2 +- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info + - В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL + +Пример 3 +- Возвращает ответ в формате <название DTO> + +### Примеры названия FR + - Получение данных клиента из АС ЕПК + - Проверка уровня доступа + - Сценарий построения списка связанных предложений \ No newline at end of file diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/documentation-rules.md b/src/app/core/agent/processes/v2/doc_rules_v2/documentation-rules.md new file mode 100644 index 0000000..1be0884 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/documentation-rules.md @@ -0,0 +1,71 @@ +# Documentation Rules + +Этот каталог оформляет MVP документации проекта в атомарном формате. + +## Базовая структура + +- Каждый документ содержит YAML frontmatter. +- В документе должен быть один `H1`, совпадающий с `title`. +- Основные разделы оформляются как `## Summary` и `## Details`. +- Внутри `Details` используются заголовки уровня `###` и ниже. +- Связи, сущности и навигация описываются во frontmatter через `related_docs`, `links`, `entities`, `parent`, `children`. + +## Summary + +- Краткий explain-слой быстрого контекста. +- Должен позволять быстро понять назначение документа без чтения `Details`. +- Предпочтительный формат: компактный список ключевых фактов без длинных абзацев. + +## Details + +- Раскрывает полное описание объекта. +- Структура `Details` зависит от типа документа. +- Сценарии, ограничения, интеграции, ошибки и кодовые привязки должны быть разнесены по отдельным подразделам. + +## API documents + +Для `api_method` внутри `## Details` обязательны разделы: +- `### Описание` +- `### Сценарий` +- `### Функциональные требования` +- `### Нефункциональные требования` +- `### Контракт` + +Если у метода есть интеграции и ошибки, также обязательны: +- `### Интеграции` +- `### Ошибки` +- `### Связанный код` +- `### История изменений` + +### Сценарий + +Сценарий оформляется как технический use case и содержит: +- название +- предусловия +- триггер +- основной сценарий +- альтернативный сценарий +- обработку ошибок +- постусловие + +### Требования + +- Функциональные требования маркируются как `FR-1`, `FR-2`, ... +- Нефункциональные требования маркируются как `NFR-1`, `NFR-2`, ... +- Идентификаторы требований локальны в рамках одного документа. + +### Контракт + +Контракт должен быть пригоден для последующей сборки OpenAPI-спецификации и включать: +- входные параметры +- выходные параметры +- структуру JSON-сообщений +- обязательность полей +- типы и ограничения +- описание полей +- правила заполнения +- примеры данных +- auth +- idempotency +- timeout +- ошибки и их HTTP-коды diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/global/documentation-system.md b/src/app/core/agent/processes/v2/doc_rules_v2/global/documentation-system.md new file mode 100644 index 0000000..656b569 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/global/documentation-system.md @@ -0,0 +1,38 @@ +# Documentation System + +## Назначение + +Этот файл задает общую модель документации проекта. + +## Базовая модель + +Каждый документ должен состоять из двух слоев: +- YAML frontmatter +- контент + +Контент всегда состоит из двух обязательных разделов: +- `## Summary` +- `## Details` + +Над ними должен быть один заголовок `# <title>`, совпадающий со значением `title` во frontmatter. + +## Принципы + +- Документы должны быть атомарными. +- Один документ описывает одну тему. +- Вместо дублирования между документами используются явные ссылки. +- Связи и навигация должны быть формализованы. +- Документы должны быть пригодны для чтения человеком и для RAG. +- Документы должны быть пригодны для частичного обновления без деградации структуры. + +## Типы документов + +На уровне проекта поддерживаются типы: +- `api_method` +- `logic_block` +- `architecture_overview` +- `domain_entity` +- `ui_page` +- `integration_doc` +- `index_page` +- `glossary_item` diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/global/frontmatter.md b/src/app/core/agent/processes/v2/doc_rules_v2/global/frontmatter.md new file mode 100644 index 0000000..2b4dee5 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/global/frontmatter.md @@ -0,0 +1,67 @@ +# Frontmatter Rules + +## Назначение + +Этот файл описывает единый контракт YAML frontmatter для всех документов. + +## Обязательные поля + +```yaml +id: string +title: string +doc_type: string +domain: string +sub_domain: string +related_docs: [] +status: string +``` + +## Поля совместимости и рекомендуемые поля + +```yaml +type: string +name: string +module: string +layer: string +updated_at: YYYY-MM-DD +tags: [] +entities: [] +parent: string | null +children: [] +links: {} +source_of_truth: string +related_code: [] +system_analytics_refs: [] +``` + +## Правила + +- `id` должен быть стабильным и уникальным в пределах документации проекта. +- `title` — человекочитаемый заголовок. +- `doc_type` — канонический тип документа. +- `domain` и `sub_domain` определяют бизнес-контекст документа. +- `related_docs` хранит явные связи с другими markdown-документами. +- `status` хранит жизненный цикл документа: например `draft`, `approved`, `active`. +- `type` допустимо дублировать как alias для tooling-совместимости с индексаторами. +- `name` — короткое системное имя документа. +- `module` — модуль или подсистема. +- `layer` — слой системы. +- `updated_at` хранится в формате `YYYY-MM-DD`. + +## Связи и навигация + +- `entities` описывает сущности, связанные с документом. +- `parent` и `children` описывают иерархию. +- `links` описывает typed graph связей между документами, кодом и интеграциями. + +## Формат links + +```yaml +links: + called_by: + - ext.health_probe + uses_logic: + - logic.some_flow + integrates_with: + - ext.some_system +``` diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/global/linking.md b/src/app/core/agent/processes/v2/doc_rules_v2/global/linking.md new file mode 100644 index 0000000..6e49171 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/global/linking.md @@ -0,0 +1,33 @@ +# Linking Rules + +## Назначение + +Этот файл описывает, как связывать документы между собой. + +## Иерархия + +- `parent` используется для родительского документа. +- `children` используется для прямых дочерних документов. +- Иерархия должна быть осмысленной и стабильной. +- Для общей точки входа допустим `index_page`. + +## Графовые связи + +Для `related_docs` используются ссылки на соседние документы. + +Для `links` рекомендуется использовать typed-ключи: +- `called_by` +- `uses_logic` +- `reads_db` +- `writes_db` +- `integrates_with` +- `used_by` +- `exposes_api` +- `uses_entities` + +## Правила использования + +- Если документ логически входит в другой, использовать `parent`/`children`. +- Если связь нужна для навигации между равноправными документами, дублировать ее в `related_docs`. +- Если связь отражает поведение, интеграции или переиспользование, фиксировать ее в `links`. +- Детальное описание интеграций хранить в body документа, а не только во frontmatter. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/global/naming.md b/src/app/core/agent/processes/v2/doc_rules_v2/global/naming.md new file mode 100644 index 0000000..c722416 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/global/naming.md @@ -0,0 +1,24 @@ +# Naming Rules + +## Назначение + +Этот файл описывает правила именования документов, файлов и идентификаторов. + +## Правила для файлов + +- Имена файлов должны быть в kebab-case. +- Имя файла должно отражать одну тему. +- Для шаблонов использовать суффикс `.template.md`. + +## Правила для id + +- `id` строится в формате `<type-group>.<name>`. +- Примеры: + - `api.send_message_endpoint` + - `logic.telegram_notification_loop` + - `architecture.telegram_notify_app` + +## Правила для title + +- `title` должен быть кратким и человекочитаемым. +- В `title` допускаются пробелы и естественный язык. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/global/writing-style.md b/src/app/core/agent/processes/v2/doc_rules_v2/global/writing-style.md new file mode 100644 index 0000000..6c1caec --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/global/writing-style.md @@ -0,0 +1,19 @@ +# Writing Style + +## Назначение + +Этот файл задает правила стиля для текстового наполнения документации. + +## Правила стиля + +- Текст должен быть лаконичным. +- Формулировки должны быть точными и техническими. +- Summary должен быть кратким explain-слоем. +- Details должен раскрывать суть без лишней воды. +- Нежелательно смешивать несколько тем в одном документе. +- Если детали относятся к другому артефакту, их нужно выносить в отдельный документ. + +## Язык + +- Основной язык документации — русский. +- Технические термины, названия классов, API, RAG, OpenAPI, runtime и другие устоявшиеся identifiers можно оставлять на английском. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/templates/api_method.template.md b/src/app/core/agent/processes/v2/doc_rules_v2/templates/api_method.template.md new file mode 100644 index 0000000..ba2ac07 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/templates/api_method.template.md @@ -0,0 +1,84 @@ +--- +id: api.example_method +type: api_method +doc_type: api_method +name: example_method +title: HTTP API /example +module: example_module +layer: application +domain: example_domain +sub_domain: example_subdomain +related_docs: [] +status: draft +updated_at: 2026-03-20 +source_of_truth: code +parent: null +children: [] +tags: [] +entities: [] +links: {} +--- + +# HTTP API /example + +## Summary + +Краткое описание метода. + +## Details + +## Описание + +Короткое описание сути метода. + +## Сценарий + +**Название:** + +**Предусловия:** +- + +**Триггер:** +- + +**Основной сценарий:** +1. + +**Альтернативный сценарий:** +1. + +**Обработка ошибок:** +1. + +**Постусловие:** +- + +## Функциональные требования + +**FR-1.** + +## Нефункциональные требования + +**NFR-1.** + +## Контракт + +### Входные параметры + +| Параметр | Где передается | Тип | Обязательность | Ограничения | Описание | Пример | +|---|---|---|---|---|---|---| +| | | | | | | | + +### Выходные параметры + +| Поле | Тип | Обязательность | Ограничения | Описание | Заполнение | Пример | +|---|---|---|---|---|---|---| +| | | | | | | | + +### Интеграции + +### Ошибки + +### Связанный код + +### История изменений diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/templates/architecture_overview.template.md b/src/app/core/agent/processes/v2/doc_rules_v2/templates/architecture_overview.template.md new file mode 100644 index 0000000..21c7319 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/templates/architecture_overview.template.md @@ -0,0 +1,48 @@ +--- +id: architecture.example_system +type: architecture_overview +doc_type: architecture_overview +name: example_system +title: Обзор архитектуры Example System +module: example_module +layer: system +domain: example_domain +sub_domain: example_subdomain +related_docs: [] +status: draft +updated_at: 2026-03-20 +source_of_truth: mixed +parent: null +children: [] +tags: [] +entities: [] +links: {} +--- + +# Обзор архитектуры Example System + +## Summary + +Краткое описание архитектуры. + +## Details + +### Описание + +### Контекст + +### Границы системы + +### Компоненты + +### Интеграционные сценарии + +### Интеграции + +### Ограничения + +### Связанный код + +### Связанные документы + +### История изменений diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/templates/domain_entity.template.md b/src/app/core/agent/processes/v2/doc_rules_v2/templates/domain_entity.template.md new file mode 100644 index 0000000..f8fd65e --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/templates/domain_entity.template.md @@ -0,0 +1,48 @@ +--- +id: domain.example_entity +type: domain_entity +doc_type: domain_entity +name: example_entity +title: Пример доменной сущности +module: example_module +layer: domain +domain: example_domain +sub_domain: example_subdomain +related_docs: [] +status: draft +updated_at: 2026-03-20 +source_of_truth: code +parent: null +children: [] +tags: [] +entities: [] +links: {} +--- + +# Пример доменной сущности + +## Summary + +Краткое описание сущности. + +## Details + +### Описание + +### Модель данных + +### Состояния и инварианты + +### Технический use case + +### Функциональные требования + +### Нефункциональные требования + +### Интеграции + +### Связанный код + +### Связанные документы + +### История изменений diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/templates/logic_block.template.md b/src/app/core/agent/processes/v2/doc_rules_v2/templates/logic_block.template.md new file mode 100644 index 0000000..36e1d5d --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/templates/logic_block.template.md @@ -0,0 +1,50 @@ +--- +id: logic.example_block +type: logic_block +doc_type: logic_block +name: example_block +title: Пример блока логики +module: example_module +layer: application +domain: example_domain +sub_domain: example_subdomain +related_docs: [] +status: draft +updated_at: 2026-03-20 +source_of_truth: code +parent: null +children: [] +tags: [] +entities: [] +links: {} +--- + +# Пример блока логики + +## Summary + +Краткое описание блока логики. + +## Details + +### Описание + +### Контекст + +### Технический use case + +### Функциональные требования + +### Нефункциональные требования + +### Интеграции + +### Ограничения и условия вызова + +### Ошибки и деградации + +### Связанные API + +### Связанный код + +### История изменений diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/templates/ui_page.template.md b/src/app/core/agent/processes/v2/doc_rules_v2/templates/ui_page.template.md new file mode 100644 index 0000000..5bd32fe --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/templates/ui_page.template.md @@ -0,0 +1,50 @@ +--- +id: ui.example_page +type: ui_page +doc_type: ui_page +name: example_page +title: Пример UI-страницы +module: example_module +layer: presentation +domain: example_domain +sub_domain: example_subdomain +related_docs: [] +status: draft +updated_at: 2026-03-20 +source_of_truth: mixed +parent: null +children: [] +tags: [] +entities: [] +links: {} +--- + +# Пример UI-страницы + +## Summary + +Краткое описание страницы и её назначения. + +## Details + +### Назначение страницы + +### Пользовательский сценарий + +### Основные блоки интерфейса + +### Связанные API и сущности + +### Функциональные требования + +### Нефункциональные требования + +### Ограничения и граничные случаи + +### Ошибки и валидации + +### Связанный код + +### Связанные документы + +### История изменений diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/api_method.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/api_method.md new file mode 100644 index 0000000..bfc6428 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/api_method.md @@ -0,0 +1,39 @@ +# API Method Rules + +## Назначение + +Этот файл задает правила для документов типа `api_method`. + +## Когда использовать + +Использовать для описания одного HTTP endpoint или одного отдельного API метода. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +Внутри `## Details` обязательны: +- `### Описание` +- `### Сценарий` +- `### Функциональные требования` +- `### Нефункциональные требования` +- `### Контракт` + +## Особые правила + +- Сценарий оформляется как технический use case. +- Функциональные требования маркируются `FR-*`. +- Нефункциональные требования маркируются `NFR-*`. +- Контракт должен быть пригоден для последующей сборки OpenAPI. +- Если у метода есть интеграции, они выносятся в `### Интеграции`. +- Ошибки и HTTP-коды либо описываются в `### Ошибки`, либо ссылаются на централизованный каталог ошибок. + +## Ошибки оформления + +- Нельзя заменять контракт общим текстовым описанием. +- Нельзя смешивать несколько endpoint в одном документе. +- Нельзя хранить связи и навигацию вне frontmatter. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/architecture_overview.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/architecture_overview.md new file mode 100644 index 0000000..e4b146e --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/architecture_overview.md @@ -0,0 +1,31 @@ +# Architecture Overview Rules + +## Назначение + +Этот файл задает правила для документов типа `architecture_overview`. + +## Когда использовать + +Использовать как входной документ для понимания системы, модуля или сервиса. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +## Что описывать в Details + +- границы системы +- основные компоненты +- ключевые взаимодействия +- интеграционные сценарии +- главные ограничения +- ссылки на дочерние документы по API, logic, domain и другим артефактам + +## Ошибки оформления + +- Нельзя дублировать в архитектурном обзоре полные API-контракты. +- Нельзя делать архитектурный обзор единственным документом на всю систему без декомпозиции. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/domain_entity.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/domain_entity.md new file mode 100644 index 0000000..c533266 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/domain_entity.md @@ -0,0 +1,30 @@ +# Domain Entity Rules + +## Назначение + +Этот файл задает правила для документов типа `domain_entity`. + +## Когда использовать + +Использовать для описания одной доменной сущности, ее смысла, состояния и роли в системе. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +## Что описывать в Details + +- смысл сущности +- ключевые атрибуты +- состояния или инварианты +- использование сущности в системе +- интеграции с API, workflow или внешними потребителями, если они важны для понимания модели + +## Ошибки оформления + +- Нельзя смешивать несколько независимых сущностей в одном документе. +- Нельзя подменять доменную сущность описанием endpoint или workflow. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/integration_doc.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/integration_doc.md new file mode 100644 index 0000000..7f1fe35 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/integration_doc.md @@ -0,0 +1,25 @@ +# Integration Doc Rules + +## Назначение + +Этот файл задает правила для документов типа `integration_doc`. + +## Когда использовать + +Использовать для описания интеграции между системами, сервисами или внешними провайдерами. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +## Что описывать в Details + +- цель интеграции +- участвующие стороны +- направление обмена +- ключевой сценарий взаимодействия +- ограничения и риски diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/logic_block.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/logic_block.md new file mode 100644 index 0000000..788e4f7 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/logic_block.md @@ -0,0 +1,31 @@ +# Logic Block Rules + +## Назначение + +Этот файл задает правила для документов типа `logic_block`. + +## Когда использовать + +Использовать для описания одного законченного блока логики, workflow или процесса. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +## Что описывать в Details + +- назначение логического блока +- входы и выходы +- последовательность выполнения +- интеграции +- ключевые ограничения +- состояние и ошибки, если они важны для понимания блока + +## Ошибки оформления + +- Нельзя описывать весь модуль целиком, если логика распадается на несколько независимых блоков. +- Нельзя превращать документ в пересказ исходного кода построчно. diff --git a/src/app/core/agent/processes/v2/doc_rules_v2/types/ui_page.md b/src/app/core/agent/processes/v2/doc_rules_v2/types/ui_page.md new file mode 100644 index 0000000..9640671 --- /dev/null +++ b/src/app/core/agent/processes/v2/doc_rules_v2/types/ui_page.md @@ -0,0 +1,24 @@ +# UI Page Rules + +## Назначение + +Этот файл задает правила для документов типа `ui_page`. + +## Когда использовать + +Использовать для описания одной пользовательской страницы, экрана или отдельного UI-сценария. + +## Обязательная структура + +Документ должен содержать: +- YAML frontmatter +- `# <title>` +- `## Summary` +- `## Details` + +## Что описывать в Details + +- назначение страницы +- пользовательский сценарий +- основные блоки интерфейса +- связанные API и сущности diff --git a/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/loader.py b/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/loader.py index 20dc788..857572d 100644 --- a/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/loader.py +++ b/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/loader.py @@ -1,5 +1,6 @@ from __future__ import annotations +import os from pathlib import Path from app.core.agent.processes.v2.workflows.doc_update_from_feature.doc_rules_pipeline.models import DocRulesBundle @@ -7,20 +8,45 @@ from app.core.agent.processes.v2.workflows.doc_update_from_feature.doc_rules_pip class DocRulesLoader: def __init__(self, root: Path | None = None) -> None: - base = root or (Path(__file__).resolve().parents[3] / "doc_rules") - self._root = base + base_dir = Path(__file__).resolve().parents[3] + if root is not None: + self._root = root + return + profile = os.getenv("DOC_RULES_PROFILE", "legacy").strip().lower() + if profile == "legacy": + self._root = base_dir / "doc_rules" + return + self._root = base_dir / "doc_rules_v2" @property def root(self) -> Path: return self._root def load(self) -> DocRulesBundle: + bundle = self._load_from_root(self._root) + if bundle.supported_doc_types: + return bundle + # Safe fallback for quick rollback or incomplete v2 setup. + fallback = self._root.parent / "doc_rules" + if fallback != self._root: + fallback_bundle = self._load_from_root(fallback) + if fallback_bundle.supported_doc_types: + return fallback_bundle + return bundle + + def _load_from_root(self, root: Path) -> DocRulesBundle: + artifact_rules = self._read_folder(root / "artifact-types", suffix=".md") + if not artifact_rules: + artifact_rules = self._read_folder(root / "types", suffix=".md") + sections = self._read_folder(root / "sections", suffix=".md") + if not sections: + sections = self._read_folder(root / "common-elements", suffix=".md") return DocRulesBundle( - documentation_rules=self._read_file(self._root / "documentation-rules.md"), - global_rules=self._read_folder(self._root / "global", suffix=".md"), - artifact_rules=self._read_folder(self._root / "artifact-types", suffix=".md"), - templates=self._read_templates(self._root / "templates"), - sections=self._read_folder(self._root / "sections", suffix=".md"), + documentation_rules=self._read_file(root / "documentation-rules.md"), + global_rules=self._read_folder(root / "global", suffix=".md"), + artifact_rules=artifact_rules, + templates=self._read_templates(root / "templates"), + sections=sections, ) def _read_templates(self, folder: Path) -> dict[str, str]: diff --git a/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/selector.py b/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/selector.py index 44930ab..0a254e1 100644 --- a/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/selector.py +++ b/src/app/core/agent/processes/v2/workflows/doc_update_from_feature/doc_rules_pipeline/selector.py @@ -5,14 +5,14 @@ from app.core.agent.processes.v2.workflows.doc_update_from_feature.doc_rules_pip class DocRulesSelector: - _DEFAULT_SECTIONS: tuple[str, ...] = ("summary", "details", "requirements-format") + _DEFAULT_SECTIONS: tuple[str, ...] = ("summary", "details", "tech-use-case", "fr", "requirements-format") _SECTIONS_BY_TYPE: dict[str, tuple[str, ...]] = { - "api_method": ("summary", "details", "api-scenario", "api-contract", "requirements-format"), - "integration_doc": ("summary", "details", "api-contract", "requirements-format"), - "ui_page": ("summary", "details", "requirements-format"), - "logic_block": ("summary", "details", "requirements-format"), - "architecture_overview": ("summary", "details", "requirements-format"), - "domain_entity": ("summary", "details", "requirements-format"), + "api_method": ("summary", "details", "tech-use-case", "fr", "api-contract", "requirements-format"), + "integration_doc": ("summary", "details", "tech-use-case", "fr", "api-contract", "requirements-format"), + "ui_page": ("summary", "details", "tech-use-case", "fr", "requirements-format"), + "logic_block": ("summary", "details", "tech-use-case", "fr", "requirements-format"), + "architecture_overview": ("summary", "details", "tech-use-case", "fr", "requirements-format"), + "domain_entity": ("summary", "details", "tech-use-case", "fr", "requirements-format"), } def select(self, bundle: DocRulesBundle, doc_type: str) -> SelectedDocRules | None: diff --git a/src/app/core/rag/indexing/job_store.py b/src/app/core/rag/indexing/job_store.py index 8aeeaff..0f99269 100644 --- a/src/app/core/rag/indexing/job_store.py +++ b/src/app/core/rag/indexing/job_store.py @@ -61,8 +61,8 @@ class IndexJobStore: cache_miss_files=row.cache_miss_files, error=payload, ) - stale_timeout_sec = max(1, int(os.getenv("RAG_RUNNING_STALE_TIMEOUT_SEC", "8"))) - if job.status == IndexJobStatus.RUNNING and self._is_stale(row.updated_at, stale_timeout_sec): + stale_timeout_sec = int(os.getenv("RAG_RUNNING_STALE_TIMEOUT_SEC", "0")) + if stale_timeout_sec > 0 and job.status == IndexJobStatus.RUNNING and self._is_stale(row.updated_at, stale_timeout_sec): payload = ErrorPayload( code="index_stalled", desc="Indexing stalled in running state; likely blocked network call during embedding/auth.", diff --git a/src/app/core/rag/indexing/orchestrator.py b/src/app/core/rag/indexing/orchestrator.py index 28f0744..98ea332 100644 --- a/src/app/core/rag/indexing/orchestrator.py +++ b/src/app/core/rag/indexing/orchestrator.py @@ -117,7 +117,7 @@ class IndexingOrchestrator: }, ) - timeout_sec = max(1, int(os.getenv("RAG_INDEX_JOB_TIMEOUT_SEC", "15"))) + timeout_sec = max(1, int(os.getenv("RAG_INDEX_JOB_TIMEOUT_SEC", "180"))) indexed, failed, cache_hits, cache_misses = await asyncio.wait_for( operation(progress_cb), timeout=timeout_sec, diff --git a/src/app/core/rag/indexing/service.py b/src/app/core/rag/indexing/service.py index 70a2513..c4db0b1 100644 --- a/src/app/core/rag/indexing/service.py +++ b/src/app/core/rag/indexing/service.py @@ -217,11 +217,23 @@ class RagService: batch_size = max(1, int(os.getenv("RAG_EMBED_BATCH_SIZE", "16"))) request_timeout_sec = max(1, int(os.getenv("RAG_EMBED_REQUEST_TIMEOUT_SEC", "5"))) request_retries = max(1, int(os.getenv("RAG_EMBED_REQUEST_MAX_RETRIES", "1"))) + max_chars = max(200, int(os.getenv("RAG_EMBED_MAX_CHARS", "1200"))) + overlap_chars = max(0, int(os.getenv("RAG_EMBED_OVERLAP_CHARS", "120"))) + prepared = self._prepare_docs_for_embedding(docs, max_chars=max_chars, overlap_chars=overlap_chars) + if len(prepared) != len(docs): + LOGGER.warning( + "rag embed doc split: path=%s original_docs=%s prepared_docs=%s max_chars=%s overlap_chars=%s", + file.get("path", ""), + len(docs), + len(prepared), + max_chars, + overlap_chars, + ) metadata = self._document_metadata(file, repo_id, blob_sha) - for doc in docs: + for doc in prepared: doc.metadata.update(metadata) - for start in range(0, len(docs), batch_size): - batch = docs[start : start + batch_size] + for start in range(0, len(prepared), batch_size): + batch = prepared[start : start + batch_size] LOGGER.warning( "rag embed batch start: path=%s batch_start=%s batch_size=%s timeout_sec=%s retries=%s", file.get("path", ""), @@ -243,7 +255,67 @@ class RagService: ) for doc, vector in zip(batch, vectors): doc.embedding = vector - return docs + return prepared + + def _prepare_docs_for_embedding( + self, + docs: list[RagDocument], + *, + max_chars: int, + overlap_chars: int, + ) -> list[RagDocument]: + prepared: list[RagDocument] = [] + for doc in docs: + text = str(doc.text or "") + if len(text) <= max_chars: + prepared.append(doc) + continue + parts = self._split_text_for_embedding(text, max_chars=max_chars, overlap_chars=overlap_chars) + if len(parts) <= 1: + prepared.append(doc) + continue + for idx, part in enumerate(parts, start=1): + metadata = dict(doc.metadata) + metadata["embed_part_index"] = idx + metadata["embed_part_total"] = len(parts) + if doc.doc_id: + metadata["embed_original_doc_id"] = doc.doc_id + prepared.append( + RagDocument( + layer=doc.layer, + source=doc.source, + title=f"{doc.title} [part {idx}/{len(parts)}]", + text=part, + metadata=metadata, + links=list(doc.links), + span=doc.span, + doc_id=f"{doc.doc_id}:part:{idx}" if doc.doc_id else None, + lang=doc.lang, + ) + ) + return prepared + + def _split_text_for_embedding(self, text: str, *, max_chars: int, overlap_chars: int) -> list[str]: + normalized = text.replace("\r\n", "\n").replace("\r", "\n") + parts: list[str] = [] + start = 0 + length = len(normalized) + while start < length: + hard_end = min(length, start + max_chars) + end = hard_end + if hard_end < length: + soft_start = min(length, start + max_chars // 2) + pivot = normalized.rfind("\n", soft_start, hard_end) + if pivot > start: + end = pivot + 1 + chunk = normalized[start:end].strip() + if chunk: + parts.append(chunk) + if end >= length: + break + next_start = max(start + 1, end - overlap_chars) + start = next_start + return parts or [normalized] def _with_file_metadata(self, docs: list[RagDocument], file: dict, repo_id: str, blob_sha: str) -> list[RagDocument]: metadata = self._document_metadata(file, repo_id, blob_sha) diff --git a/src/app/core/shared/gigachat/token_provider.py b/src/app/core/shared/gigachat/token_provider.py index 98df2cf..804ca4e 100644 --- a/src/app/core/shared/gigachat/token_provider.py +++ b/src/app/core/shared/gigachat/token_provider.py @@ -35,7 +35,7 @@ class GigaChatTokenProvider: def _fetch_token(self) -> tuple[str, float]: if not self._settings.credentials: raise GigaChatError("GIGACHAT_TOKEN is not set") - timeout_sec = max(1, int(os.getenv("GIGACHAT_AUTH_TIMEOUT_SEC", "5"))) + timeout_sec = max(1, int(os.getenv("GIGACHAT_AUTH_TIMEOUT_SEC", "20"))) headers = { "Content-Type": "application/x-www-form-urlencoded", "Accept": "application/json",