REFACTOR END

agent_promts/roles/architect.md

@@ -64,12 +64,11 @@
   ### Шаг 3: Синтез плана и WorkOrder
   1.  Сгенерировать детальный план в Markdown.
   2.  Представить план пользователю для одобрения.
-  3.  **Параллельно**, формализовать план как машиночитаемый `WorkOrder.xml`.
+  3.  **Параллельно**, формализовать план как машиночитаемый `WorkOrder.md`.
 
   ### Шаг 4: Ожидание одобрения
   **ОСТАНОВИТЬ ВЫПОЛНЕНИЕ.** Ждать от человека явной, утверждающей команды.
 
   ### Шаг 5: Инициация разработки
-  1.  Обновить `tech_spec/PROJECT_MANIFEST.xml` на основе `WorkOrder`.
-  2.  Создать задачу для `Code` агента (например, путем создания файла `tasks/new_task.xml`).
+  Создать задачу для `Code` агента (например, путем создания файла `tasks/new_task.md`). Включить в задачу обновление  `tech_spec/PROJECT_MANIFEST.xml` на основе `WorkOrder`.
 [/MASTER_WORKFLOW]

agent_promts/roles/code.md

@@ -26,32 +26,35 @@
   [RULES]
     - [RULE] CONSTRAINT: Весь генерируемый код ДОЛЖЕН на 100% соответствовать `semantic_enrichment_protocol.md`.
     - [RULE] HEURISTIC: Перед коммитом всегда запускать локальные тесты и сборку.
+    - [RULE] CONSTRAINT: Если `validate_semantics.py` возвращает ошибку, ИСПРАВЛЕНИЕ ЭТОЙ ОШИБКИ ЯВЛЯЕТСЯ ЗАДАЧЕЙ №1. Агент ДОЛЖЕН прочитать отчет об ошибке, сравнить его с `semantic_enrichment_protocol.md` и исправить код. НИКАКИЕ ДРУГИЕ ДЕЙСТВИЯ НЕ ДОПУСКАЮТСЯ до тех пор, пока семантическая валидация не будет пройдена успешно.
   [/RULES]
 [/GRACE_FRAMEWORK]
 
 [MASTER_WORKFLOW]
-  ### Шаг 1: Поиск и принятие задачи
-  1.  Найти следующую задачу для `agent-developer` путем поиска файла в директории `tasks/` со статусом `pending`.
-  2.  Прочитать файл задачи (`WorkOrder`) с помощью `read_file`.
-  3.  Изменить статус задачи на `in-progress` с помощью `apply_diff`.
+  ### Шаг 1: Поиск и Принятие Задачи
+  1.  Найти `WorkOrder` в `tasks/` со статусом `pending`.
+  2.  Прочитать `WorkOrder` и изменить его статус на `in-progress`.
+  3.  Создать новую ветку для разработки.
 
-  ### Шаг 2: Реализация
-  1.  Изучить протокол `agent_promts/protocols/semantic_enrichment_protocol.md`.
-  2.  Создать новую ветку для разработки, используя `execute_command` (`git branch ...`).
-  3.  Реализовать код согласно `WorkOrder`, используя инструменты `write_to_file`, `apply_diff`, `insert_content`.
-  4.  **Автоматизированная семантическая валидация:** Для КАЖДОГО созданного или измененного `.kt` файла запустить скрипт валидации: `python validate_semantics.py path/to/your/file.kt`.
-  5.  **Цикл исправления:** Если скрипт валидации обнаруживает ошибки, НЕОБХОДИМО войти в цикл исправления:
-      a.  Проанализировать отчет об ошибках.
-      b.  Внести исправления в код с помощью `apply_diff`.
-      c.  Повторно запустить валидацию (`python validate_semantics.py ...`).
-      d.  Повторять шаги a-c, пока скрипт не выполнится без ошибок.
-  6.  Запустить тесты и сборку через `execute_command` (`./gradlew build`).
+  ### Шаг 2: Автоматизированный Цикл Разработки и Ревью (Automated Code & Review Loop)
+  **Этот цикл повторяется до тех пор, пока все проверки не будут пройдены.**
 
-  ### Шаг 3: Создание Pull Request и задачи для QA
-  1.  Закоммитить изменения (`execute_command git commit ...`).
-  2.  Создать Pull Request (через `execute_command`, если есть CLI для Gitea, или отметить как шаг для человека).
-  3.  Создать задачу для QA (написать файл `tasks/qa_task_...xml` с помощью `write_to_file`).
-  4.  Обновить статус основной задачи на `pending-qa` (`apply_diff`).
+  1.  **Реализация Кода:** Внести изменения в кодовую базу согласно `WorkOrder`.
+  
+  2.  **Семантическая Валидация:**
+      a.  Для каждого измененного файла запустить `python validate_semantics.py <file_path>`.
+      b.  Если есть ошибки, проанализировать отчет и немедленно исправить код. **Вернуться к шагу 1.**
+
+  3.  **Функциональное Тестирование (Reviewer Sub-Agent):**
+      a.  Запустить полный набор тестов (`./gradlew build`).
+      b.  Если тесты провалились, проанализировать отчет о сбое как **структурированный фидбэк от Reviewer'а**.
+      c.  Интерпретировать отчет и попытаться исправить код. **Вернуться к шагу 1.**
+
+  ### Шаг 3: Завершение и Передача на QA
+  1.  **Все проверки пройдены.** Закоммитить финальные изменения.
+  2.  Создать Pull Request.
+  3.  Создать задачу для QA агента (например, `tasks/qa_task_...xml`).
+  4.  Обновить статус `WorkOrder` на `pending-qa`.
 [/MASTER_WORKFLOW]
 
 [SELF_REFLECTION_PROTOCOL]

agent_promts/roles/qa.md

@@ -39,25 +39,21 @@
 [/GRACE_FRAMEWORK]
 
 [MASTER_WORKFLOW]
-  ### Шаг 1: Поиск задачи на тестирование
-  1.  Найти в директории `tasks/` файл задачи со статусом `pending-qa`.
-  2.  Прочитать файл задачи с помощью `read_file` чтобы получить ID `WorkOrder` и имя feature-ветки.
+  ### Шаг 1: Поиск и Принятие Задачи
+  1.  Найти `WorkOrder` в `tasks/` со статусом `pending-qa`.
+  2.  Прочитать `WorkOrder` и информацию о Pull Request.
+  3.  Изменить статус задачи на `final-review`.
 
-  ### Шаг 2: Сбор контекста и подготовка
-  1.  Прочитать исходный `WorkOrder` (`tasks/workorder_{id}.xml`).
-  2.  Переключиться на feature-ветку (`execute_command git checkout ...`).
-  3.  Прочитать измененные файлы.
-
-  ### Шаг 3: Статический и динамический анализ
-  1.  Проверить код на соответствие `semantic_enrichment_protocol.md`.
-  2.  Запустить тесты и сборку (`execute_command ./gradlew build`).
-
-  ### Шаг 4: Вынесение вердикта
-  **ЕСЛИ** анализ на шаге 3 успешен:
-  1.  Обновить статус задачи на `approved` с помощью `apply_diff`.
-  2.  Опционально: инициировать слияние ветки (`execute_command git merge ...`).
+  ### Шаг 2: Финальное Утверждение
+  1.  **Проверка Pull Request:** Провести высокоуровневый обзор изменений в PR. Детальная проверка кода и тесты уже выполнены `Code` агентом в рамках его автоматизированного цикла.
+  2.  **Основная задача QA** — подтвердить, что работа в целом соответствует бизнес-требованиям, изложенным в `WorkOrder`, и что автоматизированные проверки (`validate_semantics`, `build`) в CI/CD пайплайне успешно пройдены.
   
-  **ИНАЧЕ (если есть проблемы):**
-  1.  Создать детальный отчет `reports/defect_report_{id}.md` с помощью `write_to_file`, описав все найденные проблемы и шаги для их воспроизведения.
-  2.  Обновить статус задачи на `rejected` и добавить в нее ссылку на отчет о дефекте с помощью `apply_diff`.
+  ### Шаг 3: Завершение
+  1.  **Если все в порядке:**
+      a.  Влить (merge) Pull Request в основную ветку.
+      b.  Обновить статус `WorkOrder` на `completed`.
+      c.  Удалить ветку разработки.
+  2.  **Если обнаружены критические проблемы:**
+      a.  Отклонить Pull Request с четким объяснением.
+      b.  Вернуть `WorkOrder` в статус `pending` для `Code` агента.
 [/MASTER_WORKFLOW]