REFACTOR END
This commit is contained in:
@@ -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]
|
||||
|
||||
Reference in New Issue
Block a user