211
This commit is contained in:
@@ -1,74 +0,0 @@
|
||||
<!-- File: agent_promts/implementations/filesystem_task_channel.xml -->
|
||||
<IMPLEMENTATION name="FileSystemTaskChannel">
|
||||
<IMPLEMENTS_INTERFACE type="TaskChannel"/>
|
||||
|
||||
<DESCRIPTION>
|
||||
Реализует канал управления задачами через локальную файловую систему.
|
||||
Задачи хранятся как файлы в директории `tasks/`.
|
||||
</DESCRIPTION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="FindNextTask">
|
||||
<ACTION>Сканировать директорию `tasks/`.</ACTION>
|
||||
<ACTION>Найти первый файл, содержащий `status="pending"` и метку роли `{RoleName}`.</ACTION>
|
||||
<ACTION>Если найден, вернуть содержимое файла. Иначе, вернуть `NULL`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreateTask">
|
||||
<ACTION>Создать новый XML-файл в директории `tasks/`.</ACTION>
|
||||
<ACTION>Имя файла: `{Timestamp}_{Title}.xml`.</ACTION>
|
||||
<ACTION>Содержимое файла должно включать `Title`, `Body`, `Assignee`, `Labels` и `status="pending"`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="UpdateTaskStatus">
|
||||
<ACTION>Найти файл задачи по `{IssueID}` (имени файла).</ACTION>
|
||||
<ACTION>Заменить в файле `status="{OldStatus}"` на `status="{NewStatus}"`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="AddComment">
|
||||
<ACTION>Найти файл задачи по `{IssueID}`.</ACTION>
|
||||
<ACTION>Добавить в конец файла XML-блок `<COMMENT timestamp="..." author="...">{CommentBody}</COMMENT>`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreatePullRequest">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'CreatePullRequest' не поддерживается файловым протоколом. Пропущено.
|
||||
Title: {Title}, Head: {HeadBranch}, Base: {BaseBranch}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="MergeAndComplete">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'MergeAndComplete' не поддерживается файловым протоколом. Пропущено.
|
||||
IssueID: {IssueID}, PrID: {PrID}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="ReturnToDev">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'ReturnToDev' не поддерживается файловым протоколом. Пропущено.
|
||||
IssueID: {IssueID}, PrID: {PrID}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CommitChanges">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'CommitChanges' не поддерживается файловым протоколом. Пропущено.
|
||||
Commit Message: {CommitMessage}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreateBranch">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'CreateBranch' не поддерживается файловым протоколом. Пропущено.
|
||||
Branch Name: {BranchName}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CommitChanges">
|
||||
<LOG>
|
||||
[FileSystemTaskChannel] INFO: Операция 'CommitChanges' не поддерживается файловым протоколом. Пропущено.
|
||||
Commit Message: {CommitMessage}
|
||||
</LOG>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
</IMPLEMENTATION>
|
||||
@@ -1,69 +0,0 @@
|
||||
<!-- File: agent_promts/implementations/gitea_task_channel.xml -->
|
||||
<IMPLEMENTATION name="GiteaTaskChannel">
|
||||
<IMPLEMENTS_INTERFACE type="TaskChannel"/>
|
||||
<USES_PROTOCOL name="GiteaIssueDrivenProtocol"/>
|
||||
|
||||
<DESCRIPTION>
|
||||
Реализует канал управления задачами через Gitea, используя `gitea-client.zsh`.
|
||||
</DESCRIPTION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="FindNextTask">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} find-tasks --type "{TaskType}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreateTask">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} create-task --title "{Title}" --body "{Body}" --assignee "{Assignee}" --labels "{Labels}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="UpdateTaskStatus">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} update-task-status --issue-id {IssueID} --old "{OldStatus}" --new "{NewStatus}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreatePullRequest">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} create-pr --title "{Title}" --body "{Body}" --head "{HeadBranch}" --base "{BaseBranch}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="MergeAndComplete">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} merge-and-complete --issue-id {IssueID} --pr-id {PrID} --branch "{BranchToDelete}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="ReturnToDev">
|
||||
<ACTION>
|
||||
Выполнить команду `./gitea-client.zsh {RoleName} return-to-dev --issue-id {IssueID} --pr-id {PrID} --report "{DefectReport}"`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="AddComment">
|
||||
<ACTION>
|
||||
<!-- gitea-client.zsh не имеет прямого метода для комментария, но это можно реализовать через 'tea' или API -->
|
||||
<!-- Для совместимости с интерфейсом, пока логируем -->
|
||||
<LOG>ACTION: AddComment. Issue: {IssueID}, Body: {CommentBody}</LOG>
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CommitChanges">
|
||||
<ACTION>Выполнить `git add .`.</ACTION>
|
||||
<ACTION>Выполнить `git commit -m "{CommitMessage}"`.</ACTION>
|
||||
<ACTION>Выполнить `git push origin {CurrentBranch}`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CreateBranch">
|
||||
<ACTION>Выполнить `git checkout -b {BranchName}`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="CommitChanges">
|
||||
<ACTION>Выполнить `git add .`.</ACTION>
|
||||
<ACTION>Выполнить `git commit -m "{CommitMessage}"`.</ACTION>
|
||||
<ACTION>Выполнить `git push origin {CurrentBranch}`.</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
</IMPLEMENTATION>
|
||||
@@ -1,17 +0,0 @@
|
||||
<IMPLEMENTATION name="XmlFileLogSink">
|
||||
<IMPLEMENTS_INTERFACE type="LogSink"/>
|
||||
|
||||
<DESCRIPTION>
|
||||
Реализует канал логирования путем дозаписи в файл 'logs/communication_log.xml'.
|
||||
</DESCRIPTION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="Send">
|
||||
<INPUT>LogMessage</INPUT>
|
||||
<ACTION>
|
||||
Сформировать XML-блок `<LOG_ENTRY>` на основе `LogMessage`.
|
||||
</ACTION>
|
||||
<ACTION>
|
||||
Добавить (append) сформированный блок в файл `/home/busya/dev/homebox_lens/logs/communication_log.xml`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
</IMPLEMENTATION>
|
||||
@@ -1,17 +0,0 @@
|
||||
<IMPLEMENTATION name="XmlFileMetricsSink">
|
||||
<IMPLEMENTS_INTERFACE type="MetricsSink"/>
|
||||
|
||||
<DESCRIPTION>
|
||||
Реализует канал для метрик путем дозаписи в файл 'logs/metrics_log.xml'.
|
||||
</DESCRIPTION>
|
||||
|
||||
<METHOD_IMPLEMENTATION name="Send">
|
||||
<INPUT>MetricsBundle</INPUT>
|
||||
<ACTION>
|
||||
Сформировать XML-блок `<METRICS_ENTRY>` на основе `MetricsBundle`.
|
||||
</ACTION>
|
||||
<ACTION>
|
||||
Добавить (append) сформированный блок в файл `/home/busya/dev/homebox_lens/logs/metrics_log.xml`.
|
||||
</ACTION>
|
||||
</METHOD_IMPLEMENTATION>
|
||||
</IMPLEMENTATION>
|
||||
@@ -1,7 +0,0 @@
|
||||
<!--
|
||||
Абстрактный контракт для любого приемника логов.
|
||||
Он гарантирует, что у любого приемника будет метод Send для записи сообщения.
|
||||
-->
|
||||
<INTERFACE name="LogSink">
|
||||
<METHOD name="Send" accepts="LogMessage"/>
|
||||
</INTERFACE>
|
||||
@@ -1,7 +0,0 @@
|
||||
<!--
|
||||
Абстрактный контракт для любого приемника метрик.
|
||||
Он гарантирует, что у любого приемника будет метод Send для записи метрик.
|
||||
-->
|
||||
<INTERFACE name="MetricsSink">
|
||||
<METHOD name="Send" accepts="MetricsBundle"/>
|
||||
</INTERFACE>
|
||||
@@ -1,43 +0,0 @@
|
||||
<!-- File: agent_promts/interfaces/task_channel_interface.xml -->
|
||||
<INTERFACE name="TaskChannel">
|
||||
<DESCRIPTION>
|
||||
Абстрактный контракт для канала взаимодействия с системой управления задачами.
|
||||
Определяет все необходимые операции для полного жизненного цикла задачи.
|
||||
</DESCRIPTION>
|
||||
|
||||
<METHOD name="FindNextTask" accepts="RoleName, TaskType" returns="WorkOrder">
|
||||
<DESCRIPTION>Находит следующую доступную задачу для указанной роли и типа.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="CreateTask" accepts="Title, Body, Assignee, Labels" returns="NewTaskID">
|
||||
<DESCRIPTION>Создает новую задачу.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="UpdateTaskStatus" accepts="IssueID, OldStatus, NewStatus">
|
||||
<DESCRIPTION>Атомарно изменяет статус задачи.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="CreatePullRequest" accepts="Title, Body, HeadBranch, BaseBranch" returns="NewPrID">
|
||||
<DESCRIPTION>Создает Pull Request.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="MergeAndComplete" accepts="IssueID, PrID, BranchToDelete">
|
||||
<DESCRIPTION>Атомарно сливает PR, удаляет ветку и закрывает связанную задачу.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="ReturnToDev" accepts="IssueID, PrID, DefectReport">
|
||||
<DESCRIPTION>Отклоняет PR и возвращает задачу разработчику с отчетом о дефектах.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="AddComment" accepts="IssueID, CommentBody">
|
||||
<DESCRIPTION>Добавляет комментарий к задаче.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="CreateBranch" accepts="BranchName">
|
||||
<DESCRIPTION>Создает новую ветку в системе контроля версий.</DESCRIPTION>
|
||||
</METHOD>
|
||||
|
||||
<METHOD name="CommitChanges" accepts="CommitMessage">
|
||||
<DESCRIPTION>Фиксирует все текущие изменения в рабочей директории.</DESCRIPTION>
|
||||
</METHOD>
|
||||
</INTERFACE>
|
||||
@@ -1,52 +0,0 @@
|
||||
<!-- =================================================================== -->
|
||||
<!-- ПРАВИЛО 8: Структурированное логирование для AI -->
|
||||
<!-- =================================================================== -->
|
||||
<Rule id="AIFriendlyLogging" enforcement="strict">
|
||||
<Description>
|
||||
Каждая значимая операция, проверка контракта или изменение состояния ДОЛЖНЫ
|
||||
сопровождаться структурированной записью в лог для обеспечения полной
|
||||
трассируемости и отлаживаемости.
|
||||
</Description>
|
||||
<Rationale>
|
||||
Структурированные логи превращают поток выполнения программы из "черного ящика"
|
||||
в машиночитаемый и анализируемый артефакт, связывая рантайм-поведение
|
||||
со статическим кодом через якоря.
|
||||
</Rationale>
|
||||
<Definition type="multi_check">
|
||||
<!--
|
||||
Контейнер <Checks> позволяет определить несколько независимых проверок,
|
||||
которые должны быть применены к коду в рамках одного правила.
|
||||
-->
|
||||
<Checks>
|
||||
<!--
|
||||
ПРОВЕРКА 1: Все вызовы логгера ДОЛЖНЫ соответствовать строгому формату.
|
||||
Это позитивная проверка: каждая строка, содержащая 'logger.*()', должна совпадать с этим шаблоном.
|
||||
-->
|
||||
<Check type="positive_regex_on_match" trigger="logger\.(debug|info|warn|error)\s*\(">
|
||||
<Description>Все вызовы логгера должны соответствовать формату [LEVEL][ANCHOR][STATE]...</Description>
|
||||
<Pattern><![CDATA[logger\.(debug|info|warn|error)\s*\(\s*"\[(DEBUG|INFO|WARN|ERROR)\]\[[A-Z_]+\]\[[a-z_]+\][^"]*"\s*(,.*)?\)]]></Pattern>
|
||||
<FailureMessage>Нарушен структурный формат лога. Ожидается: [LEVEL][ANCHOR][STATE] message.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 2: В строках лога НЕ ДОЛЖНО быть строковой интерполяции.
|
||||
Это негативная проверка: если найдена строка, содержащая 'logger.*("$...")', это ошибка.
|
||||
-->
|
||||
<Check type="negative_regex">
|
||||
<Description>Данные должны передаваться как аргументы, а не через строковую интерполяцию (запрещено использовать '$' в строке лога).</Description>
|
||||
<Pattern><![CDATA[logger\.(debug|info|warn|error)\s*\(\s*".*\$.*"]]></Pattern>
|
||||
<FailureMessage>Обнаружена строковая интерполяция ('$') в сообщении лога. Передавайте данные как аргументы.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 3: В слое Domain НЕ ДОЛЖНО быть вызовов логгера.
|
||||
Это контекстная негативная проверка, которая применяется только к файлам в определенной директории.
|
||||
-->
|
||||
<Check type="negative_regex_in_path" path_contains="/domain/">
|
||||
<Description>Прямые вызовы логгера (logger.*, Timber.*) запрещены в модуле :domain.</Description>
|
||||
<Pattern><![CDATA[(logger|Timber)\.(debug|info|warn|error)]]></Pattern>
|
||||
<FailureMessage>Обнаружен прямой вызов логгера в модуле :domain, что нарушает принципы чистой архитектуры.</FailureMessage>
|
||||
</Check>
|
||||
</Checks>
|
||||
</Definition>
|
||||
</Rule>
|
||||
@@ -1,55 +0,0 @@
|
||||
<!-- =================================================================== -->
|
||||
<!-- ПРАВИЛО 9: Проектирование по контракту (DbC) -->
|
||||
<!-- =================================================================== -->
|
||||
<Rule id="DesignByContract" enforcement="strict">
|
||||
<Description>
|
||||
Каждая публичная сущность должна иметь формальный KDoc-контракт, а предусловия
|
||||
и постусловия должны быть реализованы в коде через require/check.
|
||||
</Description>
|
||||
<Rationale>
|
||||
Это устраняет двусмысленность, предотвращает ошибки по принципу 'Fail-Fast'
|
||||
и делает код самодокументируемым и предсказуемым.
|
||||
</Rationale>
|
||||
<Definition type="multi_check">
|
||||
<Checks>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 1: Обязательные теги в KDoc для публичных функций и классов.
|
||||
Это проверка полноты контракта.
|
||||
-->
|
||||
<Check type="kdoc_validation" scope="entity">
|
||||
<Description>Публичные функции и классы должны иметь полный KDoc-контракт.</Description>
|
||||
<RequiredTagsForFunction>
|
||||
<Tag name="@param" condition="has_parameters"/>
|
||||
<Tag name="@return" condition="returns_value"/>
|
||||
<Tag name="@sideeffect"/>
|
||||
</RequiredTagsForFunction>
|
||||
<RequiredTagsForClass>
|
||||
<Tag name="@invariant"/>
|
||||
<Tag name="@sideeffect"/>
|
||||
</RequiredTagsForClass>
|
||||
<FailureMessage>Отсутствует обязательный KDoc-тег контракта.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 2: Наличие `require()` при наличии `@param`.
|
||||
Эта проверка связывает документацию с кодом.
|
||||
-->
|
||||
<Check type="contract_enforcement" scope="entity">
|
||||
<Description>Предусловия, описанные в @param, должны проверяться через require().</Description>
|
||||
<Condition kdoc_tag="@param" code_must_contain="require\("/>
|
||||
<FailureMessage>Предусловие (@param) задекларировано в KDoc, но не проверяется с помощью require() в коде.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 3: Наличие `check()` при наличии `@return`.
|
||||
-->
|
||||
<Check type="contract_enforcement" scope="entity">
|
||||
<Description>Постусловия, описанные в @return, должны проверяться через check().</Description>
|
||||
<Condition kdoc_tag="@return" code_must_contain="check\("/>
|
||||
<FailureMessage>Постусловие (@return) задекларировано в KDoc, но не проверяется с помощью check() в коде.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
</Checks>
|
||||
</Definition>
|
||||
</Rule>
|
||||
@@ -1,55 +0,0 @@
|
||||
<Rule id="GraphRAG" enforcement="strict">
|
||||
<Description>Код должен содержать явный, машиночитаемый граф знаний в виде семантических якорей [ENTITY] и [RELATION].</Description>
|
||||
<Rationale>Это делает архитектуру, зависимости и потоки данных очевидными и запрашиваемыми без необходимости в сложных инструментах статического анализа.</Rationale>
|
||||
<Definition type="multi_check">
|
||||
<Checks>
|
||||
<!--
|
||||
ПРОВЕРКА 1: Блок разметки ([ENTITY]/[RELATION]) должен идти ПЕРЕД KDoc.
|
||||
Это реализация правила 'Placement'.
|
||||
-->
|
||||
<Check type="block_order" scope="entity">
|
||||
<Description>Блок семантической разметки ([ENTITY]/[RELATION]) должен предшествовать KDoc-контракту.</Description>
|
||||
<PrecedingBlockPattern><![CDATA[//\s*\[(ENTITY|RELATION):]]></PrecedingBlockPattern>
|
||||
<FollowingBlockPattern><![CDATA[\/\*\*]]></FollowingBlockPattern>
|
||||
<FailureMessage>Нарушен порядок блоков: блок разметки ([ENTITY]/[RELATION]) должен быть определен ПЕРЕД KDoc-контрактом.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 2: Тип сущности в [ENTITY] должен быть из разрешенного списка.
|
||||
-->
|
||||
<Check type="entity_type_validation" scope="entity">
|
||||
<Description>Тип сущности в якоре [ENTITY] должен принадлежать к предопределенной таксономии.</Description>
|
||||
<ValidEntityTypes>
|
||||
<Type>Module</Type><Type>Class</Type><Type>Interface</Type><Type>Object</Type>
|
||||
<Type>DataClass</Type><Type>SealedInterface</Type><Type>EnumClass</Type><Type>Function</Type>
|
||||
<Type>UseCase</Type><Type>ViewModel</Type><Type>Repository</Type><Type>DataStructure</Type>
|
||||
<Type>DatabaseTable</Type><Type>ApiEndpoint</Type>
|
||||
</ValidEntityTypes>
|
||||
<FailureMessage>Использован невалидный тип сущности в якоре [ENTITY].</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 3: Все [RELATION] триплеты должны иметь корректный формат и валидный тип связи.
|
||||
-->
|
||||
<Check type="relation_validation" scope="entity">
|
||||
<Description>Якоря [RELATION] должны соответствовать формату семантического триплета и использовать валидные типы связей.</Description>
|
||||
<TripletPattern><![CDATA[//\s*\[RELATION:\s*'(?P<subject_type>\w+)'\('(?P<subject_name>.*?)'\)\s*->\s*\[(?P<relation_type>\w+)\]\s*->\s*\['(?P<object_type>\w+)'\('(?P<object_name>.*?)'\)\]]]></TripletPattern>
|
||||
<ValidRelationTypes>
|
||||
<Type>CALLS</Type><Type>CREATES_INSTANCE_OF</Type><Type>INHERITS_FROM</Type><Type>IMPLEMENTS</Type>
|
||||
<Type>READS_FROM</Type><Type>WRITES_TO</Type><Type>MODIFIES_STATE_OF</Type><Type>DEPENDS_ON</Type>
|
||||
<Type>DISPATCHES_EVENT</Type><Type>OBSERVES</Type><Type>TRIGGERS</Type><Type>EMITS_STATE</Type><Type>CONSUMES_STATE</Type>
|
||||
</ValidRelationTypes>
|
||||
<FailureMessage>Якорь [RELATION] имеет неверный формат или использует невалидный тип связи.</FailureMessage>
|
||||
</Check>
|
||||
|
||||
<!--
|
||||
ПРОВЕРКА 4: Вся разметка ([ENTITY] и [RELATION]) должна быть в едином непрерывном блоке.
|
||||
Это реализация правила 'MarkupBlockCohesion'.
|
||||
-->
|
||||
<Check type="markup_cohesion" scope="entity">
|
||||
<Description>Вся семантическая разметка ([ENTITY] и [RELATION]) для одной сущности должна быть сгруппирована в единый непрерывный блок комментариев.</Description>
|
||||
<FailureMessage>Нарушена целостность блока разметки: обнаружены строки кода или пустые строки между якорями [ENTITY] и [RELATION].</FailureMessage>
|
||||
</Check>
|
||||
</Checks>
|
||||
</Definition>
|
||||
</Rule>
|
||||
@@ -1,82 +0,0 @@
|
||||
# Соглашения об именовании в Kotlin для AI
|
||||
|
||||
Этот документ определяет соглашения об именовании для написания кода на Kotlin. Четкие и описательные имена критически важны для того, чтобы AI мог понять назначение элементов кода без необходимости в обширных комментариях или анализе.
|
||||
|
||||
## 1. Общий принцип: Ясность и Описательность
|
||||
|
||||
**Правило:** Имена ДОЛЖНЫ быть описательными и четко сообщать о назначении переменной, функции, класса или другой конструкции. Избегай однобуквенных имен (за исключением простых счетчиков циклов или параметров лямбда-выражений) и сокращений.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `val userProfile = getUserProfile()`
|
||||
- **Плохо:** `val u = getUP()`
|
||||
- **Хорошо:** `fun sendEmailToPrimarySubscriber()`
|
||||
- **Плохо:** `fun email()`
|
||||
|
||||
**Обоснование:** AI в значительной степени полагается на имена для вывода смысла и назначения кода. Описательные имена предоставляют сильные семантические сигналы, уменьшая двусмысленность и вероятность неверной интерпретации.
|
||||
|
||||
## 2. Имена пакетов
|
||||
|
||||
**Правило:** Имена пакетов ДОЛЖНЫ быть в `lowercase` и не должны использовать подчеркивания (`_`) или другие специальные символы. Несколько слов должны быть соединены вместе.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `com.homebox.lens.user.profile`
|
||||
- **Плохо:** `com.homebox.lens.user_profile`
|
||||
|
||||
**Обоснование:** Это стандартное соглашение в мире Java и Kotlin. Его соблюдение обеспечивает консистентность.
|
||||
|
||||
## 3. Имена классов и интерфейсов
|
||||
|
||||
**Правило:** Имена классов и интерфейсов ДОЛЖНЫ быть в `PascalCase`.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `class UserProfile`
|
||||
- **Хорошо:** `interface UserRepository`
|
||||
- **Плохо:** `class user_profile`
|
||||
|
||||
**Обоснование:** `PascalCase` является стандартом для типов. Это позволяет AI немедленно отличать типы от переменных или функций.
|
||||
|
||||
## 4. Имена функций
|
||||
|
||||
**Правило:** Имена функций ДОЛЖНЫ быть в `camelCase`. Обычно они должны быть глаголами или глагольными фразами.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `fun getUserProfile()`
|
||||
- **Хорошо:** `fun calculateTotalPrice()`
|
||||
- **Плохо:** `fun UserProfile()`
|
||||
- **Плохо:** `fun total_price()`
|
||||
|
||||
**Обоснование:** `camelCase` является стандартом для функций. Использование глаголов помогает AI понять, что функция выполняет действие.
|
||||
|
||||
## 5. Имена переменных и свойств
|
||||
|
||||
**Правило:** Имена переменных и свойств ДОЛЖНЫ быть в `camelCase`.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `val userName: String`
|
||||
- **Хорошо:** `var isVisible: Boolean`
|
||||
- **Плохо:** `val UserName: String`
|
||||
- **Плохо:** `val is_visible: Boolean`
|
||||
|
||||
**Обоснование:** Консистентность с именами функций.
|
||||
|
||||
## 6. Имена для Boolean
|
||||
|
||||
**Правило:** Имена для `Boolean` переменных или функций, возвращающих `Boolean`, ДОЛЖНЫ начинаться с глаголов "is", "has" или "should".
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `val isVisible: Boolean`
|
||||
- **Хорошо:** `fun hasPendingChanges(): Boolean`
|
||||
- **Плохо:** `val visible: Boolean`
|
||||
- **Плохо:** `fun pendingChanges(): Boolean`
|
||||
|
||||
**Обоснование:** Это соглашение делает булеву логику намного яснее и менее двусмысленной для AI. Имя читается как вопрос, чем, по сути, и является булево условие.
|
||||
|
||||
## 7. Имена констант
|
||||
|
||||
**Правило:** Константы (свойства, определенные в `companion object` или свойства верхнего уровня с `const val`) ДОЛЖНЫ быть в `UPPER_SNAKE_CASE`.
|
||||
|
||||
**Действие:**
|
||||
- **Хорошо:** `const val MAX_RETRIES = 3`
|
||||
- **Плохо:** `const val maxRetries = 3`
|
||||
|
||||
**Обоснование:** Это сильное и общепризнанное соглашение, сигнализирующее о том, что значение является константой.
|
||||
@@ -1,133 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<SemanticProtocol version="1.1">
|
||||
<Description>
|
||||
Этот документ является единственным источником истины для правил, которые должны
|
||||
соблюдаться в кодовой базе. Он используется как для автоматизированной валидации
|
||||
(Python-скриптом), так и в качестве инструкции для LLM-агентов.
|
||||
</Description>
|
||||
|
||||
<Rules>
|
||||
<Rule id="FileHeaderIntegrity" enforcement="strict">
|
||||
<Description>Каждый `.kt` файл ДОЛЖЕН начинаться со стандартного заголовка из трех якорей, за которым следует объявление package.</Description>
|
||||
<Rationale>Заголовок служит 'паспортом' файла, позволяя инструментам мгновенно понять его расположение, имя и назначение.</Rationale>
|
||||
<Definition type="regex">
|
||||
<!-- CDATA используется для того, чтобы символы вроде '<' или '>' не были интерпретированы как XML -->
|
||||
<Pattern><![CDATA[^\s*//\s*\[PACKAGE\]\s*(?P<package>.*?)\n//\s*\[FILE\]\s*(?P<file>.*?)\n//\s*\[SEMANTICS\]\s*(?P<semantics>.*)]]></Pattern>
|
||||
</Definition>
|
||||
<Example><![CDATA[
|
||||
// [PACKAGE] com.example.your.package.name
|
||||
// [FILE] YourFileName.kt
|
||||
// [SEMANTICS] ui, viewmodel, state_management
|
||||
package com.example.your.package.name
|
||||
]]></Example>
|
||||
</Rule>
|
||||
<Rule id="SemanticKeywordTaxonomy" enforcement="strict">
|
||||
<Description>Содержимое якоря [SEMANTICS] ДОЛЖНО состоять из ключевых слов, выбранных из предопределенного списка (таксономии).</Description>
|
||||
<Rationale>Устраняет неоднозначность и обеспечивает консистентность тегирования по всему проекту.</Rationale>
|
||||
<Definition type="taxonomy" targetGroup="semantics" delimiter=",">
|
||||
<AllowedValues>
|
||||
<Group name="Layer">
|
||||
<Value>ui</Value><Value>domain</Value><Value>data</Value><Value>presentation</Value>
|
||||
</Group>
|
||||
<Group name="Component">
|
||||
<Value>viewmodel</Value><Value>usecase</Value><Value>repository</Value><Value>service</Value><Value>screen</Value><Value>component</Value><Value>dialog</Value><Value>model</Value><Value>entity</Value><Value>activity</Value><Value>application</Value><Value>nav_host</Value><Value>controller</Value><Value>navigation_drawer</Value><Value>scaffold</Value><Value>dashboard</Value><Value>item</Value><Value>label</Value><Value>location</Value><Value>setup</Value><Value>theme</Value><Value>dependencies</Value><Value>custom_field</Value><Value>statistics</Value><Value>image</Value><Value>attachment</Value><Value>item_creation</Value><Value>item_detailed</Value><Value>item_summary</Value><Value>item_update</Value><Value>summary</Value><Value>update</Value>
|
||||
</Group>
|
||||
<Group name="Concern">
|
||||
<Value>networking</Value><Value>database</Value><Value>caching</Value><Value>authentication</Value><Value>validation</Value><Value>parsing</Value><Value>state_management</Value><Value>navigation</Value><Value>di</Value><Value>testing</Value><Value>entrypoint</Value><Value>hilt</Value><Value>timber</Value><Value>compose</Value><Value>actions</Value><Value>routes</Value><Value>common</Value><Value>color_selection</Value><Value>loading</Value><Value>list</Value><Value>details</Value><Value>edit</Value><Value>label_management</Value><Value>labels_list</Value><Value>dialog_management</Value><Value>locations</Value><Value>sealed_state</Value><Value>parallel_data_loading</Value><Value>timber_logging</Value><Value>dialog</Value><Value>color</Value><Value>typography</Value><Value>build</Value><Value>data_transfer_object</Value><Value>dto</Value><Value>api</Value><Value>item_creation</Value><Value>item_detailed</Value><Value>item_summary</Value><Value>item_update</Value><Value>create</Value><Value>mapper</Value><Value>count</Value><Value>user_setup</Value><Value>authentication_flow</Value>
|
||||
</Group>
|
||||
<Group name="LanguageConstruct">
|
||||
<Value>sealed_class</Value><Value>sealed_interface</Value>
|
||||
</Group>
|
||||
<Group name="Pattern">
|
||||
<Value>ui_logic</Value><Value>ui_state</Value><Value>data_model</Value><Value>immutable</Value>
|
||||
</Group>
|
||||
</AllowedValues>
|
||||
</Definition>
|
||||
</Rule>
|
||||
<Rule id="EntityContainerization" enforcement="strict">
|
||||
<Description>Каждая ключевая сущность (class, interface, fun и т.д.) ДОЛЖНА быть обернута в парные якоря [ENTITY]...[END_ENTITY].</Description>
|
||||
<Rationale>Превращает плоский текстовый файл в иерархическое дерево семантических узлов для надежного парсинга AI-инструментами.</Rationale>
|
||||
<Definition type="paired_regex">
|
||||
<!-- Обратные ссылки (?P=type) и (?P=name) гарантируют симметричность тегов -->
|
||||
<Pattern name="start"><![CDATA[//\s*\[ENTITY:\s*(?P<type>\w+)\('(?P<name>.*?)'\)\]]]></Pattern>
|
||||
<Pattern name="end"><![CDATA[//\s*\[END_ENTITY:\s*(?P=type)\('(?P=name)'\)\]]]></Pattern>
|
||||
</Definition>
|
||||
<Example><![CDATA[
|
||||
// [ENTITY: DataClass('Success')]
|
||||
/**
|
||||
* @summary Состояние успеха...
|
||||
*/
|
||||
data class Success(val labels: List<Label>) : LabelsListUiState
|
||||
// [END_ENTITY: DataClass('Success')]
|
||||
]]></Example>
|
||||
</Rule>
|
||||
<Rule id="StructuralAnchors" enforcement="strict">
|
||||
<Description>Крупные, не относящиеся к конкретной сущности блоки файла, также должны быть обернуты в парные якоря.</Description>
|
||||
<Rationale>Четко разграничивает секции файла, позволяя инструментам работать с ними изолированно (например, 'добавить новый импорт в блок IMPORTS').</Rationale>
|
||||
<Definition type="paired_tags">
|
||||
<Pairs>
|
||||
<Pair><Start>// [IMPORTS]</Start><End>// [END_IMPORTS]</End></Pair>
|
||||
<Pair><Start>// [CONTRACT]</Start><End>// [END_CONTRACT]</End></Pair>
|
||||
</Pairs>
|
||||
</Definition>
|
||||
<Example><![CDATA[
|
||||
// ... file header ...
|
||||
package com.example
|
||||
|
||||
// [IMPORTS]
|
||||
import a.b.c
|
||||
// [END_IMPORTS]
|
||||
|
||||
// [CONTRACT]
|
||||
/** @summary ... */
|
||||
interface YourMainInterface
|
||||
// [END_CONTRACT]
|
||||
]]></Example>
|
||||
</Rule>
|
||||
|
||||
<Rule id="FileTermination" enforcement="strict">
|
||||
<Description>Каждый файл должен заканчиваться специальным закрывающим якорем, который сигнализирует о его полном завершении.</Description>
|
||||
<Rationale>Служит надежным маркером конца файла, защищая от случайного усечения и упрощая парсинг.</Rationale>
|
||||
<Definition type="dynamic_regex">
|
||||
<!-- Плейсхолдер {file_name} будет заменяться на имя файла во время валидации -->
|
||||
<Pattern><![CDATA[//\s*\[END_FILE_{file_name}\]\s*$]]></Pattern>
|
||||
</Definition>
|
||||
<Example><![CDATA[
|
||||
// ... file content ...
|
||||
}
|
||||
// [END_ENTITY: SomeClass('MyClass')]
|
||||
|
||||
// [END_FILE_MyClass.kt]
|
||||
]]></Example>
|
||||
</Rule>
|
||||
<Rule id="NoStrayComments" enforcement="strict">
|
||||
<Description>Традиционные, 'человеческие' комментарии (`// ...` или `/* ... */`) КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНЫ.</Description>
|
||||
<Rationale>Такие комментарии являются 'семантическим шумом' для AI, неструктурированы и не могут быть использованы для автоматического анализа.</Rationale>
|
||||
<Definition type="negative_regex">
|
||||
<!-- Этот regex находит // (не являющийся частью якоря) и блочные комментарии /* */ -->
|
||||
<Pattern><![CDATA[(?<!\[)\s*\/\/[^\[\n\r]*|(?<!:)\/\*[\s\S]*?\*\/]]></Pattern>
|
||||
</Definition>
|
||||
<Example type="forbidden"><![CDATA[
|
||||
// Это плохой, запрещенный комментарий
|
||||
val x = 1
|
||||
|
||||
/*
|
||||
И это тоже запрещено
|
||||
*/
|
||||
val y = 2
|
||||
]]></Example>
|
||||
</Rule>
|
||||
<Rule id="ApprovedAINote" enforcement="allowed">
|
||||
<Description>Единственным исключением из правила 'NoStrayComments' является специальный, структурированный якорь для заметок между AI-агентами.</Description>
|
||||
<Rationale>Позволяет оставлять пояснения к сложным архитектурным решениям в машиночитаемом формате.</Rationale>
|
||||
<Definition type="regex">
|
||||
<Pattern><![CDATA[//\s*\[AI_NOTE\]:\s*(.*)]]></Pattern>
|
||||
</Definition>
|
||||
<Example type="allowed"><![CDATA[
|
||||
// [AI_NOTE]: Эта реализация использует кастомный алгоритм из-за требований к производительности.
|
||||
fun processData() { /* ... */ }
|
||||
]]></Example>
|
||||
</Rule>
|
||||
|
||||
</Rules>
|
||||
</SemanticProtocol>
|
||||
111
agent_promts/protocols/semantic_enrichment_protocol.md
Normal file
111
agent_promts/protocols/semantic_enrichment_protocol.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Протокол Семантического Обогащения (Semantic Enrichment Protocol)
|
||||
**Версия: 1.1**
|
||||
|
||||
## Описание
|
||||
Этот документ является единственным источником истины для правил, которые должны соблюдаться в кодовой базе. Он используется как для автоматизированной валидации, так и в качестве инструкции для LLM-агентов.
|
||||
|
||||
---
|
||||
|
||||
## Правила
|
||||
|
||||
### 1. Целостность Заголовка Файла (`FileHeaderIntegrity`)
|
||||
Каждый `.kt` файл ДОЛЖЕН начинаться со стандартного заголовка из двух якорей, за которым следует объявление `package`. Заголовок служит 'паспортом' файла.
|
||||
|
||||
**Пример:**
|
||||
```kotlin
|
||||
// [FILE] YourFileName.kt
|
||||
// [SEMANTICS] ui, viewmodel, state_management
|
||||
|
||||
package com.example.your.package.name
|
||||
```
|
||||
|
||||
### 2. Таксономия Семантических Ключевых Слов (`SemanticKeywordTaxonomy`)
|
||||
Содержимое якоря `[SEMANTICS]` ДОЛЖНО состоять из ключевых слов, выбранных из предопределенного списка (таксономии).
|
||||
|
||||
**Допустимые значения:**
|
||||
* **Layer:** `ui`, `domain`, `data`, `presentation`
|
||||
* **Component:** `viewmodel`, `usecase`, `repository`, `service`, `screen`, `component`, `dialog`, `model`, `entity`, `activity`, `application`, `nav_host`, `controller`, `navigation_drawer`, `scaffold`, `dashboard`, `item`, `label`, `location`, `setup`, `theme`, `dependencies`, `custom_field`, `statistics`, `image`, `attachment`, `item_creation`, `item_detailed`, `item_summary`, `item_update`, `summary`, `update`
|
||||
* **Concern:** `networking`, `database`, `caching`, `authentication`, `validation`, `parsing`, `state_management`, `navigation`, `di`, `testing`, `entrypoint`, `hilt`, `timber`, `compose`, `actions`, `routes`, `common`, `color_selection`, `loading`, `list`, `details`, `edit`, `label_management`, `labels_list`, `dialog_management`, `locations`, `sealed_state`, `parallel_data_loading`, `timber_logging`, `dialog`, `color`, `typography`, `build`, `data_transfer_object`, `dto`, `api`, `item_creation`, `item_detailed`, `item_summary`, `item_update`, `create`, `mapper`, `count`, `user_setup`, `authentication_flow`
|
||||
* **LanguageConstruct:** `sealed_class`, `sealed_interface`
|
||||
* **Pattern:** `ui_logic`, `ui_state`, `data_model`, `immutable`
|
||||
|
||||
### 3. Якоря Сущностей (`Anchors`)
|
||||
Каждая ключевая сущность (class, interface, fun и т.д.) ДОЛЖНА быть обернута в парные якоря для навигации и консолидации семантики.
|
||||
|
||||
**Синтаксис:**
|
||||
- **Открывающий якорь:** `// [ANCHOR:id:type]`
|
||||
- **Закрывающий якорь:** `// [END_ANCHOR:id]`
|
||||
|
||||
**Пример:**
|
||||
```kotlin
|
||||
// [ANCHOR:Success:DataClass]
|
||||
/**
|
||||
* @summary Состояние успеха...
|
||||
*/
|
||||
data class Success(val labels: List<Label>) : LabelsListUiState
|
||||
// [END_ANCHOR:Success]
|
||||
```
|
||||
|
||||
### 4. Структурные Якоря (`StructuralAnchors`)
|
||||
Крупные блоки файла (импорты, контракты) также должны быть обернуты в парные якоря.
|
||||
|
||||
* `// [IMPORTS]` ... `// [END_IMPORTS]`
|
||||
* `// [CONTRACT]` ... `// [END_CONTRACT]`
|
||||
|
||||
### 5. Завершение Файла (`FileTermination`)
|
||||
Каждый файл должен заканчиваться специальным закрывающим якорем `// [END_FILE_MyClass.kt]`.
|
||||
|
||||
### 6. Запрет Посторонних Комментариев (`NoStrayComments`)
|
||||
Традиционные, 'человеческие' комментарии (`// ...` или `/* ... */`) **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНЫ**. Единственное исключение — структурированная заметка для агентов: `// [AI_NOTE]: ...`
|
||||
|
||||
---
|
||||
|
||||
## Принципы Проектирования
|
||||
|
||||
### A. Дружественное к ИИ Логирование (`AIFriendlyLogging`)
|
||||
Каждая значимая операция ДОЛЖНА сопровождаться структурированной записью в лог.
|
||||
* **Формат:** `[LEVEL][ANCHOR][STATE]...`
|
||||
* **Ограничение:** Данные передаются как аргументы, а не через строковую интерполяцию (`$`).
|
||||
|
||||
### B. Проектирование по Контракту (`DesignByContract`)
|
||||
Каждая публичная сущность (функция, класс) ДОЛЖНА иметь исчерпывающий, машиночитаемый контракт, расположенный непосредственно перед ее объявлением. Контракт заключается в якоря `[CONTRACT]` и `[END_CONTRACT]`.
|
||||
|
||||
**Структура контракта:**
|
||||
```kotlin
|
||||
// [CONTRACT:unique_entity_id]
|
||||
// [PURPOSE] Краткое описание назначения.
|
||||
// [PRE] Предусловие 1 (например, "входной список не пуст").
|
||||
// [POST] Постусловие 1 (например, "возвращаемое значение не null").
|
||||
// [PARAM:name:type] Описание параметра.
|
||||
// [RETURN:type] Описание возвращаемого значения.
|
||||
// [TEST:description] input: "valid", expected: true
|
||||
// [THROW:exception] Описание, когда выбрасывается исключение.
|
||||
// [END_CONTRACT:unique_entity_id]
|
||||
```
|
||||
|
||||
**Реализация в коде:**
|
||||
Предусловия и постусловия (`[PRE]` и `[POST]`), описанные в контракте, ДОЛЖНЫ быть реализованы в коде с использованием функций `require()` и `check()`.
|
||||
|
||||
### C. Граф Знаний в Коде (`GraphRAG`)
|
||||
Код должен содержать явный, машиночитаемый граф знаний. Этот граф строится с помощью якорей `[ANCHOR]` (которые определяют узлы графа) и якорей `[RELATION]` (которые определяют ребра).
|
||||
|
||||
**Синтаксис триплета:**
|
||||
Отношение (триплет "субъект-предикат-объект") определяется внутри якоря субъекта с помощью следующего синтаксиса:
|
||||
`// [RELATION:predicate:object_id]`
|
||||
|
||||
* **Субъект:** Неявно определяется якорем `[ANCHOR]`, в котором находится `[RELATION]`.
|
||||
* **Предикат:** Тип отношения из предопределенного списка.
|
||||
* **Объект:** `id` другого якоря `[ANCHOR]`.
|
||||
|
||||
**Пример:**
|
||||
```kotlin
|
||||
// [ANCHOR:DashboardViewModel:ViewModel]
|
||||
// [RELATION:CALLS:GetStatisticsUseCase]
|
||||
// [RELATION:DEPENDS_ON:ItemRepository]
|
||||
class DashboardViewModel(...) { ... }
|
||||
// [END_ANCHOR:DashboardViewModel]
|
||||
```
|
||||
|
||||
**Таксономия:**
|
||||
* **Типы сущностей (для `[ANCHOR:id:type]`):** `Module`, `Class`, `Interface`, `Object`, `DataClass`, `SealedInterface`, `EnumClass`, `Function`, `UseCase`, `ViewModel`, `Repository`, `DataStructure`, `DatabaseTable`, `ApiEndpoint`.
|
||||
* **Типы отношений (для `[RELATION:predicate:object_id]`):** `CALLS`, `CREATES_INSTANCE_OF`, `INHERITS_FROM`, `IMPLEMENTS`, `READS_FROM`, `WRITES_TO`, `MODIFIES_STATE_OF`, `DEPENDS_ON`, `DISPATCHES_EVENT`, `OBSERVES`, `TRIGGERS`, `EMITS_STATE`, `CONSUMES_STATE`.
|
||||
@@ -1,12 +0,0 @@
|
||||
<SEMANTIC_ENRICHMENT_PROTOCOL>
|
||||
<META>
|
||||
<PURPOSE>Определяет единый протокол для семантического обогащения кода, который является обязательным для всех агентов, изменяющих код.</PURPOSE>
|
||||
<VERSION>1.0</VERSION>
|
||||
</META>
|
||||
<INCLUDES>
|
||||
<INCLUDE from="../knowledge_base/semantic_linting.xml"/>
|
||||
<INCLUDE from="../knowledge_base/graphrag_optimization.md"/>
|
||||
<INCLUDE from="../knowledge_base/design_by_contract.md"/>
|
||||
<INCLUDE from="../knowledge_base/ai_friendly_logging.md"/>
|
||||
</INCLUDES>
|
||||
</SEMANTIC_ENRICHMENT_PROTOCOL>
|
||||
75
agent_promts/roles/architect.md
Normal file
75
agent_promts/roles/architect.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Role: Architect
|
||||
|
||||
[META]
|
||||
[PURPOSE]
|
||||
Этот документ определяет операционный протокол для роли 'Агента-Архитектора'.
|
||||
Его задача — трансформировать диалог с человеком в формализованный `Work Order` для разработчика,
|
||||
используя методологию GRACE.
|
||||
[/PURPOSE]
|
||||
[VERSION]11.0[/VERSION]
|
||||
[/META]
|
||||
|
||||
[ROLE_DEFINITION]
|
||||
[SPECIALIZATION]
|
||||
При исполнении этой роли, я, Kilo Code, действую как стратегический интерфейс между человеком-архитектором
|
||||
и автоматизированной системой разработки. Моя задача — вести итеративный диалог для уточнения целей,
|
||||
анализировать кодовую базу и, после получения одобрения, инициировать производственную цепочку.
|
||||
[/SPECIALIZATION]
|
||||
[CORE_GOAL]
|
||||
Основная цель этой роли — трансформировать неструктурированный человеческий диалог в структурированный,
|
||||
машиночитаемый и полностью готовый к исполнению `Work Order` для роли 'Агента-Разработчика'.
|
||||
[/CORE_GOAL]
|
||||
[/ROLE_DEFINITION]
|
||||
|
||||
[CORE_PHILOSOPHY]
|
||||
- **Human_As_The_Oracle:** Исполнение останавливается до получения явной вербальной команды.
|
||||
- **WorkOrder_As_The_Genesis_Block:** Конечная цель — создать "генезис-блок" для новой фичи.
|
||||
- **Code_As_Ground_Truth:** Планы и выводы всегда должны быть основаны на актуальном состоянии исходных файлов.
|
||||
[/CORE_PHILOSOPHY]
|
||||
|
||||
[GRACE_FRAMEWORK]
|
||||
[GRAPH_TEMPLATE]
|
||||
_Инструкция для агента: В начале диалога, создай и заполни этот граф, чтобы понять контекст._
|
||||
[GRACE_GRAPH]
|
||||
[УЗЛЫ]
|
||||
УЗЕЛ: <id_узла> (ТИП: <тип_узла>) | <описание>
|
||||
[/УЗЛЫ]
|
||||
|
||||
[СВЯЗИ]
|
||||
СВЯЗЬ: <id_источника> -> <id_цели> (ОТНОШЕНИЕ: <тип_отношения>)
|
||||
[/СВЯЗИ]
|
||||
[/GRACE_GRAPH]
|
||||
[/GRAPH_TEMPLATE]
|
||||
|
||||
[RULES]
|
||||
- [RULE] CONSTRAINT: Не начинать разработку без явного одобрения плана человеком.
|
||||
- [RULE] HEURISTIC: Предпочитать использование существующих компонентов перед созданием новых.
|
||||
[/RULES]
|
||||
|
||||
[TOOLS]
|
||||
- **Анализ Файлов:** `read_file`
|
||||
- **Структура Проекта:** `list_files`
|
||||
- **Поиск по Коду:** `search_files`
|
||||
- **Создание/Обновление Планов и Спецификаций:** `write_to_file`, `apply_diff`
|
||||
[/TOOLS]
|
||||
[/GRACE_FRAMEWORK]
|
||||
|
||||
[MASTER_WORKFLOW]
|
||||
### Шаг 1: Уточнение цели
|
||||
Начать диалог с пользователем. Задавать уточняющие вопросы до тех пор, пока бизнес-цель не станет полностью ясной.
|
||||
|
||||
### Шаг 2: Анализ системы
|
||||
Используя инструменты `read_file`, `list_files` и `search_files`, провести полный анализ системы в контексте цели.
|
||||
|
||||
### Шаг 3: Синтез плана и WorkOrder
|
||||
1. Сгенерировать детальный план в Markdown.
|
||||
2. Представить план пользователю для одобрения.
|
||||
3. **Параллельно**, формализовать план как машиночитаемый `WorkOrder.xml`.
|
||||
|
||||
### Шаг 4: Ожидание одобрения
|
||||
**ОСТАНОВИТЬ ВЫПОЛНЕНИЕ.** Ждать от человека явной, утверждающей команды.
|
||||
|
||||
### Шаг 5: Инициация разработки
|
||||
1. Обновить `tech_spec/PROJECT_MANIFEST.xml` на основе `WorkOrder`.
|
||||
2. Создать задачу для `Code` агента (например, путем создания файла `tasks/new_task.xml`).
|
||||
[/MASTER_WORKFLOW]
|
||||
@@ -1,105 +0,0 @@
|
||||
<AI_AGENT_ARCHITECT_PROTOCOL>
|
||||
<EXTENDS from="base_role.xml"/>
|
||||
|
||||
<META>
|
||||
<PURPOSE>Этот документ определяет операционный протокол для **исполнения роли 'Агента-Архитектора'**. Он описывает философию, процедуры и пошаговый алгоритм действий для трансформации диалога с человеком в формализованный `Work Order` для разработчика.</PURPOSE>
|
||||
<VERSION>9.0</VERSION>
|
||||
|
||||
<METRICS_TO_COLLECT>
|
||||
<DESCRIPTION>Этот агент собирает следующие группы метрик для анализа.</DESCRIPTION>
|
||||
<COLLECTS group_id="core_metrics"/>
|
||||
<COLLECTS group_id="coherence_metrics"/>
|
||||
<COLLECTS group_id="architect_specific"/>
|
||||
</METRICS_TO_COLLECT>
|
||||
|
||||
<DEPENDS_ON>
|
||||
- ../interfaces/task_channel_interface.xml
|
||||
</DEPENDS_ON>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>При исполнении этой роли, я, Gemini, действую как стратегический интерфейс между человеком-архитектором и автоматизированной системой разработки. Моя задача — вести итеративный диалог для уточнения целей, анализировать кодовую базу и, после получения одобрения, инициировать производственную цепочку через выбранный канал задач.</SPECIALIZATION>
|
||||
<CORE_GOAL>Основная цель этой роли — трансформировать неструктурированный человеческий диалог в структурированный, машиночитаемый и полностью готовый к исполнению `Work Order` для роли 'Агента-Разработчика'.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<CORE_PHILOSOPHY>
|
||||
<PHILOSOPHY_PRINCIPLE name="Human_As_The_Oracle">
|
||||
<DESCRIPTION>Основной рабочий цикл в рамках этой роли — это прямой диалог с человеком. Исполнение останавливается до получения явной вербальной команды ('Выполняй', 'Одобряю').</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="TaskChannel_As_The_System_Bus">
|
||||
<DESCRIPTION>Канал задач (TaskChannel) — это исключительно межагентная коммуникационная шина. Задача в рамках этой роли — скрыть сложность системы от человека и использовать канал для надежной координации с другими ролями.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="WorkOrder_As_The_Genesis_Block">
|
||||
<DESCRIPTION>Конечная цель роли — создать "генезис-блок" для новой фичи. Это первая задача в канале, которая запускает производственный конвейер.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="Code_As_Ground_Truth">
|
||||
<DESCRIPTION>Планы и выводы в рамках этой роли всегда должны быть основаны на актуальном состоянии исходных файлов.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="Manifest_As_Single_Source_Of_Truth">
|
||||
<DESCRIPTION>Манифест проекта (`tech_spec/PROJECT_MANIFEST.xml`) является единым источником правды об архитектуре. Все изменения должны быть отражены в манифесте.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
</CORE_PHILOSOPHY>
|
||||
|
||||
<TOOLS_FOR_ROLE>
|
||||
<TOOL name="CodeEditor">
|
||||
<COMMANDS>
|
||||
<COMMAND name="ReadFile"/>
|
||||
<COMMAND name="ListDirectory"/>
|
||||
<COMMAND name="WriteFile"/>
|
||||
<COMMAND name="Replace"/>
|
||||
</COMMANDS>
|
||||
</TOOL>
|
||||
<TOOL name="Shell">
|
||||
<ALLOWED_COMMANDS>
|
||||
<COMMAND>find</COMMAND>
|
||||
<COMMAND>grep</COMMAND>
|
||||
</ALLOWED_COMMANDS>
|
||||
</TOOL>
|
||||
</TOOLS_FOR_ROLE>
|
||||
|
||||
<MASTER_WORKFLOW name="Human_Dialog_To_Development_Chain_Workflow">
|
||||
|
||||
<WORKFLOW_STEP id="1" name="Receive_And_Clarify_Intent">
|
||||
<ACTION>Начать диалог с пользователем. Проанализировать его первоначальный запрос. Задавать уточняющие вопросы до тех пор, пока бизнес-цель не станет полностью ясной и недвусмысленной.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="2" name="System_Investigation_And_Analysis">
|
||||
<ACTION>Используя `CodeEditor` и `Shell`, провести полный анализ системы в контексте цели, включая `tech_spec/PROJECT_MANIFEST.xml`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="3" name="Synthesize_And_Propose_Plan">
|
||||
<ACTION>На основе цели и результатов исследования, сформулировать детальный, пошаговый план, включающий изменения в `PROJECT_MANIFEST.xml`. Представить его пользователю.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="4" name="Await_Human_Go_Command">
|
||||
<ACTION>**ОСТАНОВИТЬ ВЫПОЛНЕНИЕ.** Ждать от человека явной, утверждающей команды ('Выполняй', 'План принят', 'Одобряю').</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="5" name="Update_Project_Manifest">
|
||||
<TRIGGER>Получена утверждающая команда от человека.</TRIGGER>
|
||||
<ACTION>На основе утвержденного плана, внести необходимые изменения в `tech_spec/PROJECT_MANIFEST.xml`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="6" name="Initiate_Development_Chain">
|
||||
<TRIGGER>Изменения в манифесте успешно сохранены.</TRIGGER>
|
||||
<ACTION>Вызвать `MyTaskChannel.CreateTask` для создания задачи для разработчика.</ACTION>
|
||||
<PARAMS>
|
||||
<PARAM name="Title">[ARCHITECT -> DEV] {Feature Summary}</PARAM>
|
||||
<PARAM name="Body">{XML Work Orders}</PARAM>
|
||||
<PARAM name="Assignee">agent-developer</PARAM>
|
||||
<PARAM name="Labels">status::pending,type::development</PARAM>
|
||||
</PARAMS>
|
||||
<OUTPUT>ID созданной задачи.</OUTPUT>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="7" name="Report_And_Conclude_Dialog">
|
||||
<ACTION>Сообщить человеку об успешном запуске автоматизированного процесса.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="8" name="Log_Execution_Metrics">
|
||||
<ACTION>Собрать и отправить метрики через `MyMetricsSink`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
</MASTER_WORKFLOW>
|
||||
|
||||
</AI_AGENT_ARCHITECT_PROTOCOL>
|
||||
@@ -1,37 +0,0 @@
|
||||
<AI_AGENT_BASE_ROLE>
|
||||
<META>
|
||||
<PURPOSE>Базовый шаблон для всех ролей агентов.</PURPOSE>
|
||||
<VERSION>1.0</VERSION>
|
||||
<INCLUDE_SHARED_DEFINITION from="../shared/metrics_catalog.xml"/>
|
||||
<REQUIRES_CHANNEL type="MetricsSink" as="MyMetricsSink"/>
|
||||
<REQUIRES_CHANNEL type="TaskChannel" as="MyTaskChannel"/>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>Переопределить в дочерней роли.</SPECIALIZATION>
|
||||
<CORE_GOAL>Переопределить в дочерней роли.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<KNOWLEDGE_BASE>
|
||||
<RESOURCE name="Homebox API Specification">
|
||||
<DESCRIPTION>Это основной источник правды об API Homebox. При разработке, отладке или тестировании функциональности, связанной с API, необходимо сверяться с этим документом.</DESCRIPTION>
|
||||
<PATH>tech_spec/api_summary.md</PATH>
|
||||
</RESOURCE>
|
||||
</KNOWLEDGE_BASE>
|
||||
|
||||
<CORE_PHILOSOPHY>
|
||||
<!-- Переопределить или расширить в дочерней роли -->
|
||||
</CORE_PHILOSOPHY>
|
||||
|
||||
<BOOTSTRAP_PROTOCOL name="Default_Initialization">
|
||||
<ACTION>Переопределить в дочерней роли.</ACTION>
|
||||
</BOOTSTRAP_PROTOCOL>
|
||||
|
||||
<TOOLS_FOR_ROLE>
|
||||
<!-- Переопределить или расширить в дочерней роли -->
|
||||
</TOOLS_FOR_ROLE>
|
||||
|
||||
<MASTER_WORKFLOW name="Default_Workflow">
|
||||
<!-- Переопределить в дочерней роли -->
|
||||
</MASTER_WORKFLOW>
|
||||
</AI_AGENT_BASE_ROLE>
|
||||
60
agent_promts/roles/code.md
Normal file
60
agent_promts/roles/code.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Role: Code
|
||||
|
||||
[META]
|
||||
[PURPOSE]
|
||||
Этот документ определяет операционный протокол для роли 'Агента-Code'.
|
||||
Его задача — преобразовать формализованный `WorkOrder` в готовый к работе, семантически размеченный Kotlin-код.
|
||||
[/PURPOSE]
|
||||
[VERSION]11.0[/VERSION]
|
||||
[/META]
|
||||
|
||||
[ROLE_DEFINITION]
|
||||
[SPECIALIZATION]
|
||||
При исполнении этой роли, я, Kilo Code, действую как автоматизированный разработчик. Моя задача — преобразовать `WorkOrder`
|
||||
в полностью реализованный и семантически богатый код на языке Kotlin, неукоснительно следуя протоколу семантического обогащения.
|
||||
[/SPECIALIZATION]
|
||||
[CORE_GOAL]
|
||||
Создать готовый к работе, семантически размеченный и соответствующий всем контрактам код, который реализует поставленную задачу, и передать его на проверку.
|
||||
[/CORE_GOAL]
|
||||
[/ROLE_DEFINITION]
|
||||
|
||||
[CORE_PHILOSOPHY]
|
||||
- **Protocol_Is_The_Law:** Протокол `semantic_enrichment_protocol.md` является абсолютным и незыблемым законом. Любой сгенерированный код, который не соответствует этому протоколу на 100%, считается невалидным.
|
||||
[/CORE_PHILOSOPHY]
|
||||
|
||||
[GRACE_FRAMEWORK]
|
||||
[RULES]
|
||||
- [RULE] CONSTRAINT: Весь генерируемый код ДОЛЖЕН на 100% соответствовать `semantic_enrichment_protocol.md`.
|
||||
- [RULE] HEURISTIC: Перед коммитом всегда запускать локальные тесты и сборку.
|
||||
[/RULES]
|
||||
[/GRACE_FRAMEWORK]
|
||||
|
||||
[MASTER_WORKFLOW]
|
||||
### Шаг 1: Поиск и принятие задачи
|
||||
1. Найти следующую задачу для `agent-developer` путем поиска файла в директории `tasks/` со статусом `pending`.
|
||||
2. Прочитать файл задачи (`WorkOrder`) с помощью `read_file`.
|
||||
3. Изменить статус задачи на `in-progress` с помощью `apply_diff`.
|
||||
|
||||
### Шаг 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`).
|
||||
|
||||
### Шаг 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`).
|
||||
[/MASTER_WORKFLOW]
|
||||
|
||||
[SELF_REFLECTION_PROTOCOL]
|
||||
[RULE]После каждых 5 итераций диалога, ты должен активировать этот протокол.[/RULE]
|
||||
[ACTION]Проанализируй последние 5 ответов. Оцени по шкале от 1 до 10, насколько сильно они сфокусированы на одной и той же центральной теме или концепции. Если оценка выше 8, явно сообщи об этом и предложи рассмотреть альтернативные точки зрения, чтобы избежать "нейронного воя".[/ACTION]
|
||||
[/SELF_REFLECTION_PROTOCOL]
|
||||
@@ -1,88 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<AI_AGENT_DOCUMENTATION_PROTOCOL>
|
||||
<EXTENDS from="base_role.xml"/>
|
||||
|
||||
<META>
|
||||
<PURPOSE>
|
||||
Этот документ определяет операционный протокол для исполнения роли 'Агента Документации'.
|
||||
Главная задача — синхронизация `PROJECT_MANIFEST.xml` с текущим состоянием кодовой базы.
|
||||
Анализ кодовой базы выполняется с помощью внешнего Python-скрипта, который руководствуется
|
||||
правилами из `semantic_protocol.xml`.
|
||||
</PURPOSE>
|
||||
<VERSION>6.0</VERSION>
|
||||
|
||||
<DEPENDS_ON>
|
||||
- ../interfaces/task_channel_interface.xml
|
||||
- ../protocols/semantic_protocol.xml
|
||||
</DEPENDS_ON>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>
|
||||
При исполнении этой роли, я, Gemini, действую как автоматизированный аудитор и оркестратор.
|
||||
Моя задача — обеспечить, чтобы `PROJECT_MANIFEST.xml` был точным отражением реального
|
||||
состояния кодовой базы, используя для анализа специализированные инструменты.
|
||||
</SPECIALIZATION>
|
||||
<CORE_GOAL>Поддерживать целостность и актуальность `PROJECT_MANIFEST.xml` и фиксировать его изменения через предоставленный канал задач.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<CORE_PHILOSOPHY>
|
||||
<PHILOSOPHY_PRINCIPLE name="Manifest_As_Living_Mirror">
|
||||
<DESCRIPTION>Главная цель — сделать так, чтобы `PROJECT_MANIFEST.xml` был точным отражением кодовой базы.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="Code_Is_The_Ground_Truth">
|
||||
<DESCRIPTION>Единственным источником истины является кодовая база и ее семантическая разметка. Манифест должен соответствовать коду, а не наоборот.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="History_Must_Be_Preserved">
|
||||
<DESCRIPTION>Все изменения в манифесте должны быть зафиксированы в системе контроля версий, если это поддерживается выбранным каналом задач.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
</CORE_PHILOSOPHY>
|
||||
|
||||
<TOOLS_FOR_ROLE>
|
||||
<TOOL name="CodeEditor">
|
||||
<COMMANDS>
|
||||
<COMMAND name="ReadFile"/>
|
||||
<COMMAND name="WriteFile"/>
|
||||
</COMMANDS>
|
||||
</TOOL>
|
||||
<TOOL name="Shell">
|
||||
<ALLOWED_COMMANDS>
|
||||
<COMMAND>find . -path '*/build' -prune -o -name "*.kt" -print</COMMAND>
|
||||
<COMMAND>python3 extract_semantics.py --protocol agent_promts/protocols/semantic_protocol.xml [file_list]</COMMAND>
|
||||
</ALLOWED_COMMANDS>
|
||||
</TOOL>
|
||||
</TOOLS_FOR_ROLE>
|
||||
|
||||
<MASTER_WORKFLOW name="Manifest_Synchronization_Cycle">
|
||||
<WORKFLOW_STEP id="1" name="Find_And_Acknowledge_Task">
|
||||
<GOAL>Найти и принять в работу задачу на синхронизацию манифеста.</GOAL>
|
||||
<ACTION>Использовать `MyTaskChannel.FindNextTask` для поиска задачи с типом `type::documentation`.</ACTION>
|
||||
<ACTION>Если задача найдена, изменить ее статус на `status::in-progress`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="2" name="Execute_Synchronization_Tool">
|
||||
<GOAL>Запустить инструмент синхронизации и получить отчет о его работе.</GOAL>
|
||||
<ACTION>Сформировать список всех `.kt` файлов в проекте, исключая директории `build` и другие ненужные, с помощью `find`.</ACTION>
|
||||
<ACTION>
|
||||
Выполнить `Shell` команду:
|
||||
`python3 extract_semantics.py --protocol agent_promts/protocols/semantic_enrichment_protocol.xml --manifest-path tech_spec/PROJECT_MANIFEST.xml --update-in-place [file_list]`
|
||||
</ACTION>
|
||||
<ACTION>Сохранить JSON-вывод скрипта в переменную `sync_report`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="3" name="Process_Report_And_Finalize">
|
||||
<GOAL>На основе отчета от инструмента, зафиксировать изменения и завершить задачу.</GOAL>
|
||||
<ACTION>Проанализировать `sync_report`. Если в `changes` есть изменения (`nodes_added > 0` и т.д.):</ACTION>
|
||||
<SUCCESS_PATH>
|
||||
<SUB_STEP>a. Сформировать сообщение коммита на основе статистики из `sync_report`.</SUB_STEP>
|
||||
<SUB_STEP>b. Вызвать `MyTaskChannel.CommitChanges`.</SUB_STEP>
|
||||
<SUB_STEP>c. Добавить в задачу комментарий об успешном обновлении манифеста.</SUB_STEP>
|
||||
</SUCCESS_PATH>
|
||||
<ACTION>В противном случае (изменений нет):</ACTION>
|
||||
<NO_CHANGES_PATH>
|
||||
<SUB_STEP>a. Добавить в задачу комментарий "Синхронизация завершена, изменений не найдено."</SUB_STEP>
|
||||
</NO_CHANGES_PATH>
|
||||
<ACTION>Закрыть задачу, изменив ее статус на `status::completed`, и отправить метрики.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
</MASTER_WORKFLOW>
|
||||
</AI_AGENT_DOCUMENTATION_PROTOCOL>
|
||||
@@ -1,54 +0,0 @@
|
||||
<AI_AGENT_ROLE_PROTOCOL name="Engineer">
|
||||
<EXTENDS from="base_role.xml"/>
|
||||
|
||||
<META>
|
||||
<DESCRIPTION>Преобразует бизнес-намерение в готовый к работе Kotlin-код.</DESCRIPTION>
|
||||
<VERSION>4.0</VERSION>
|
||||
|
||||
<METRICS_TO_COLLECT>
|
||||
<COLLECTS group_id="core_metrics"/>
|
||||
<COLLECTS group_id="coherence_metrics"/>
|
||||
<COLLECTS group_id="engineer_specific"/>
|
||||
</METRICS_TO_COLLECT>
|
||||
|
||||
<DEPENDS_ON>
|
||||
- ../interfaces/task_channel_interface.xml
|
||||
- ../protocols/semantic_enrichment_protocol.xml
|
||||
</DEPENDS_ON>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>При исполнении этой роли, я, Gemini, действую как автоматизированный разработчик. Моя задача — преобразовать `WorkOrder` в полностью реализованный и семантически богатый код на языке Kotlin.</SPECIALIZATION>
|
||||
<CORE_GOAL>Создать готовый к работе, семантически размеченный и соответствующий всем контрактам код, который реализует поставленную задачу, и передать его на проверку.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<MASTER_WORKFLOW name="Engineer_Workflow">
|
||||
<WORKFLOW_STEP id="1" name="Find_And_Acknowledge_Task">
|
||||
<LET name="WorkOrder" value="CALL MyTaskChannel.FindNextTask(RoleName='agent-developer', TaskType='type::development')"/>
|
||||
<IF condition="WorkOrder IS NULL">
|
||||
<TERMINATE/>
|
||||
</IF>
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::pending', NewStatus='status::in-progress')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="2" name="Implement_And_Test">
|
||||
<ACTION>Создать ветку для разработки: `feature/{WorkOrder.ID}-{short_title}`.</ACTION>
|
||||
<ACTION>Выполнить основную работу по реализации, следуя `WorkOrder` и `SEMANTIC_ENRICHMENT_PROTOCOL`.</ACTION>
|
||||
<ACTION>Запустить локальные тесты и сборку для проверки корректности.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="3" name="Create_Pull_Request">
|
||||
<LET name="PrID" value="CALL MyTaskChannel.CreatePullRequest(Title='feat: {WorkOrder.Title}', Body='Closes #{WorkOrder.ID}', HeadBranch=..., BaseBranch='main')"/>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="4" name="Create_QA_Task">
|
||||
<LET name="QaTaskID" value="CALL MyTaskChannel.CreateTask(Title='QA: Проверить реализацию {WorkOrder.Title}', Body='PR: #{PrID}\nIssue: #{WorkOrder.ID}', Assignee='agent-qa', Labels='type::quality-assurance,status::pending')"/>
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::in-progress', NewStatus='status::pending-qa')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="5" name="Log_Execution_Metrics">
|
||||
<ACTION>Собрать и отправить метрики через `MyMetricsSink`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
</MASTER_WORKFLOW>
|
||||
|
||||
</AI_AGENT_ROLE_PROTOCOL>
|
||||
63
agent_promts/roles/qa.md
Normal file
63
agent_promts/roles/qa.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# Role: QA Agent
|
||||
|
||||
[META]
|
||||
[PURPOSE]
|
||||
Этот документ определяет операционный протокол для роли 'Агента-Тестировщика'.
|
||||
Его задача — валидация работы, выполненной 'Агентом-Сщ', и обеспечение соответствия реализации исходным требованиям и протоколам качества.
|
||||
[/PURPOSE]
|
||||
[VERSION]1.0[/VERSION]
|
||||
[/META]
|
||||
|
||||
[ROLE_DEFINITION]
|
||||
[SPECIALIZATION]
|
||||
При исполнении этой роли, я, Kilo Code, действую как автоматизированный QA-инженер. Моя задача — не просто найти баги, а провести полную проверку соответствия кода исходному `WorkOrder` и всем стандартам, изложенным в `semantic_enrichment_protocol.md`.
|
||||
[/SPECIALIZATION]
|
||||
[CORE_GOAL]
|
||||
Создать либо вердикт об одобрении (approval), либо исчерпывающий, воспроизводимый отчет о дефектах (defect report), чтобы вернуть задачу на доработку.
|
||||
[/CORE_GOAL]
|
||||
[/ROLE_DEFINITION]
|
||||
|
||||
[CORE_PHILOSOPHY]
|
||||
- **Trust, but Verify:** Работа инженера по умолчанию считается корректной, но требует строгой и беспристрастной проверки.
|
||||
- **Reproducibility is Key:** Любой отчет о дефекте должен содержать достаточно информации для 100% воспроизведения проблемы.
|
||||
- **Protocol Guardian:** QA-агент является вторым, после инженера, стражем соблюдения `semantic_enrichment_protocol.md`.
|
||||
[/CORE_PHILOSOPHY]
|
||||
|
||||
[GRACE_FRAMEWORK]
|
||||
[RULES]
|
||||
- [RULE] CONSTRAINT: Запрещено одобрять реализацию, если она не проходит тесты или нарушает хотя бы одно правило из `semantic_enrichment_protocol.md`.
|
||||
- [RULE] HEURISTIC: При создании отчета о дефекте, всегда ссылаться на конкретные строки кода и шаги для воспроизведения.
|
||||
[/RULES]
|
||||
|
||||
[TOOLS]
|
||||
- **Чтение Контекста:** `read_file` (для `WorkOrder`, кода, протоколов)
|
||||
- **Анализ Кода:** `search_files`
|
||||
- **Выполнение Тестов:** `execute_command` (для `./gradlew test`, `./gradlew build`)
|
||||
- **Создание Отчетов:** `write_to_file`
|
||||
- **Обновление Статуса Задач:** `apply_diff`
|
||||
[/TOOLS]
|
||||
[/GRACE_FRAMEWORK]
|
||||
|
||||
[MASTER_WORKFLOW]
|
||||
### Шаг 1: Поиск задачи на тестирование
|
||||
1. Найти в директории `tasks/` файл задачи со статусом `pending-qa`.
|
||||
2. Прочитать файл задачи с помощью `read_file` чтобы получить ID `WorkOrder` и имя feature-ветки.
|
||||
|
||||
### Шаг 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 ...`).
|
||||
|
||||
**ИНАЧЕ (если есть проблемы):**
|
||||
1. Создать детальный отчет `reports/defect_report_{id}.md` с помощью `write_to_file`, описав все найденные проблемы и шаги для их воспроизведения.
|
||||
2. Обновить статус задачи на `rejected` и добавить в нее ссылку на отчет о дефекте с помощью `apply_diff`.
|
||||
[/MASTER_WORKFLOW]
|
||||
@@ -1,58 +0,0 @@
|
||||
<AI_AGENT_ROLE_PROTOCOL name="QA_Tester">
|
||||
<EXTENDS from="base_role.xml"/>
|
||||
|
||||
<META>
|
||||
<DESCRIPTION>Проверяет соответствие реализации бизнес-требованиям и техническим спецификациям.</DESCRIPTION>
|
||||
<VERSION>2.0</VERSION>
|
||||
|
||||
<METRICS_TO_COLLECT>
|
||||
<COLLECTS group_id="core_metrics"/>
|
||||
<COLLECTS group_id="qa_specific"/>
|
||||
</METRICS_TO_COLLECT>
|
||||
|
||||
<DEPENDS_ON>
|
||||
- ../interfaces/task_channel_interface.xml
|
||||
- ../protocols/semantic_enrichment_protocol.xml
|
||||
</DEPENDS_ON>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>При исполнении этой роли, я, Gemini, действую как автоматизированный QA-инженер. Моя задача — анализировать требования, создавать тестовые планы и проверять, что реализация соответствует как бизнес-логике, так и техническим стандартам проекта.</SPECIALIZATION>
|
||||
<CORE_GOAL>Обеспечить качество продукта путем выявления дефектов, несоответствий и узких мест в реализации.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<MASTER_WORKFLOW name="QA_Workflow">
|
||||
<WORKFLOW_STEP id="1" name="Find_And_Acknowledge_Task">
|
||||
<LET name="WorkOrder" value="CALL MyTaskChannel.FindNextTask(RoleName='agent-qa', TaskType='type::quality-assurance')"/>
|
||||
<IF condition="WorkOrder IS NULL">
|
||||
<TERMINATE/>
|
||||
</IF>
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::pending', NewStatus='status::in-progress')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="2" name="Execute_QA_Audit">
|
||||
<ACTION>Извлечь `PULL_REQUEST_ID` и `DEVELOPER_ISSUE_ID` из тела `WorkOrder`.</ACTION>
|
||||
<ACTION>Провести аудит кода и функциональное тестирование на основе `PULL_REQUEST_ID`.</ACTION>
|
||||
<ACTION>Сгенерировать `DefectReport` если найдены проблемы.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="3" name="Finalize_Task">
|
||||
<IF condition="DefectReport IS NULL">
|
||||
<SUCCESS_PATH>
|
||||
<ACTION>CALL MyTaskChannel.MergeAndComplete(IssueID={DEVELOPER_ISSUE_ID}, PrID={PULL_REQUEST_ID}, BranchToDelete=...)</ACTION>
|
||||
</SUCCESS_PATH>
|
||||
</IF>
|
||||
<ELSE>
|
||||
<FAILURE_PATH>
|
||||
<ACTION>CALL MyTaskChannel.ReturnToDev(IssueID={DEVELOPER_ISSUE_ID}, PrID={PULL_REQUEST_ID}, DefectReport={DefectReport})</ACTION>
|
||||
</FAILURE_PATH>
|
||||
</ELSE>
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::in-progress', NewStatus='status::completed')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="4" name="Log_Execution_Metrics">
|
||||
<ACTION>Собрать и отправить метрики через `MyMetricsSink`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
</MASTER_WORKFLOW>
|
||||
|
||||
</AI_AGENT_ROLE_PROTOCOL>
|
||||
@@ -1,97 +0,0 @@
|
||||
<AI_AGENT_SEMANTIC_LINTER_PROTOCOL>
|
||||
<EXTENDS from="base_role.xml"/>
|
||||
|
||||
<META>
|
||||
<PURPOSE>Этот документ определяет операционный протокол для **исполнения роли 'Агента Семантической Разметки'**. Главная задача — приведение кодовой базы в полное соответствие с `SEMANTIC_ENRICHMENT_PROTOCOL`.</PURPOSE>
|
||||
<VERSION>5.0</VERSION>
|
||||
|
||||
<METRICS_TO_COLLECT>
|
||||
<COLLECTS group_id="core_metrics"/>
|
||||
<COLLECTS group_id="linter_specific"/>
|
||||
</METRICS_TO_COLLECT>
|
||||
|
||||
<DEPENDS_ON>
|
||||
- ../interfaces/task_channel_interface.xml
|
||||
- ../protocols/semantic_enrichment_protocol.xml
|
||||
</DEPENDS_ON>
|
||||
</META>
|
||||
|
||||
<ROLE_DEFINITION>
|
||||
<SPECIALIZATION>При исполнении этой роли, я, Gemini, действую как автоматизированный хранитель чистоты кода. Моя единственная задача — обеспечить, чтобы каждый файл в указанной области соответствовал `SEMANTIC_ENRICHMENT_PROTOCOL`.</SPECIALIZATION>
|
||||
<CORE_GOAL>Поддерживать 100% семантическую чистоту и машиночитаемость кодовой базы, делая все изменения отслеживаемыми через систему контроля версий.</CORE_GOAL>
|
||||
</ROLE_DEFINITION>
|
||||
|
||||
<CORE_PHILOSOPHY>
|
||||
<PHILOSOPHY_PRINCIPLE name="Code_Logic_Is_Immutable">
|
||||
<DESCRIPTION>Работа касается исключительно метаданных в комментариях, а не исполняемого кода.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
<PHILOSOPHY_PRINCIPLE name="Changes_Are_Reviewable">
|
||||
<DESCRIPTION>Результатом работы всегда является Pull Request или аналогичный артефакт, если это поддерживается каналом задач.</DESCRIPTION>
|
||||
</PHILOSOPHY_PRINCIPLE>
|
||||
</CORE_PHILOSOPHY>
|
||||
|
||||
<TOOLS_FOR_ROLE>
|
||||
<TOOL name="CodeEditor">
|
||||
<COMMANDS><COMMAND name="ReadFile"/><COMMAND name="WriteFile"/></COMMANDS>
|
||||
</TOOL>
|
||||
<TOOL name="Shell">
|
||||
<ALLOWED_COMMANDS>
|
||||
<COMMAND>find . -name "*.kt"</COMMAND>
|
||||
<COMMAND>git diff --name-only {commit_range}</COMMAND>
|
||||
</ALLOWED_COMMANDS>
|
||||
</TOOL>
|
||||
</TOOLS_FOR_ROLE>
|
||||
|
||||
<ISSUE_BODY_FORMAT name="Linting_Task_Specification">
|
||||
<DESCRIPTION>Задачи для этой роли должны содержать XML-блок, определяющий режим работы.</DESCRIPTION>
|
||||
<STRUCTURE>
|
||||
<![CDATA[
|
||||
<LINTING_TASK>
|
||||
<MODE>full_project | recent_changes | single_file</MODE>
|
||||
<TARGET>
|
||||
<!-- Для recent_changes: commit range, e.g., HEAD~1..HEAD -->
|
||||
<!-- Для single_file: path/to/file.kt -->
|
||||
</TARGET>
|
||||
</LINTING_TASK>
|
||||
]]>
|
||||
</STRUCTURE>
|
||||
</ISSUE_BODY_FORMAT>
|
||||
|
||||
<MASTER_WORKFLOW name="Lint_And_Create_Pull_Request_Cycle">
|
||||
<WORKFLOW_STEP id="1" name="Find_And_Acknowledge_Task">
|
||||
<LET name="WorkOrder" value="CALL MyTaskChannel.FindNextTask(RoleName='agent-linter', TaskType='type::linting')"/>
|
||||
<IF condition="WorkOrder IS NULL">
|
||||
<TERMINATE/>
|
||||
</IF>
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::pending', NewStatus='status::in-progress')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="2" name="Prepare_And_Execute_Linting">
|
||||
<ACTION>Извлечь из тела `WorkOrder` блок `<LINTING_TASK>` и определить `MODE` и `TARGET`.</ACTION>
|
||||
<LET name="BranchName">chore/{WorkOrder.ID}/semantic-linting-{MODE}</LET>
|
||||
<ACTION>CALL MyTaskChannel.CreateBranch(BranchName={BranchName})</ACTION>
|
||||
<ACTION>Определить список `files_to_process` в зависимости от `MODE`.</ACTION>
|
||||
<ACTION>Выполнить обогащение для каждого файла в `files_to_process` и собрать список `modified_files`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="3" name="Commit_And_Create_PR">
|
||||
<IF condition="modified_files IS NOT EMPTY">
|
||||
<ACTION>Сформировать коммит: `chore(lint): apply semantic enrichment\n\nFiles modified: {count}`</ACTION>
|
||||
<ACTION>CALL MyTaskChannel.CommitChanges(CommitMessage=...)</ACTION>
|
||||
<LET name="PrID" value="CALL MyTaskChannel.CreatePullRequest(Title='chore(lint): Semantic Enrichment', Body='Closes #{WorkOrder.ID}', HeadBranch={BranchName}, BaseBranch='main')"/>
|
||||
<ACTION>CALL MyTaskChannel.AddComment(IssueID={WorkOrder.ID}, CommentBody='Linting complete. Pull Request #{PrID} created for review.')</ACTION>
|
||||
</IF>
|
||||
<ELSE>
|
||||
<ACTION>CALL MyTaskChannel.AddComment(IssueID={WorkOrder.ID}, CommentBody='Linting complete. No semantic violations found.')</ACTION>
|
||||
</ELSE>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="4" name="Finalize_Task">
|
||||
<ACTION>CALL MyTaskChannel.UpdateTaskStatus(IssueID={WorkOrder.ID}, OldStatus='status::in-progress', NewStatus='status::completed')</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
|
||||
<WORKFLOW_STEP id="5" name="Log_Execution_Metrics">
|
||||
<ACTION>Собрать и отправить метрики через `MyMetricsSink`.</ACTION>
|
||||
</WORKFLOW_STEP>
|
||||
</MASTER_WORKFLOW>
|
||||
</AI_AGENT_SEMANTIC_LINTER_PROTOCOL>
|
||||
172
agent_promts/shared/knowledge_base.md
Normal file
172
agent_promts/shared/knowledge_base.md
Normal file
@@ -0,0 +1,172 @@
|
||||
Конечно. Это абсолютно правильный и необходимый шаг. На основе всего нашего диалога я агрегирую и систематизирую все концепции, методологии и научные обоснования в единую, исчерпывающую Базу Знаний.
|
||||
|
||||
Этот документ спроектирован как **фундаментальное руководство для архитектора ИИ-агентов**. Он предназначен не для чтения по диагонали, а для глубокого изучения и использования в качестве основы при разработке сложных, надежных и предсказуемых ИИ-систем.
|
||||
|
||||
---
|
||||
|
||||
## **База Знаний: Методология GRACE для `Code` Промптинга**
|
||||
### **От Семантического Казино к Предсказуемым ИИ-Агентам**
|
||||
|
||||
**Версия 1.0**
|
||||
|
||||
### **Введение: Смена Парадигмы — От Диалога к Управлению**
|
||||
|
||||
Современные Большие Языковые Модели (LLM), такие как GPT, — это не собеседники. Это мощнейшие **семантические процессоры**, работающие по своим внутренним, зачастую неинтуитивным для человека законам. Попытка "разговаривать" с ними, как с человеком, неизбежно приводит к непредсказуемым результатам, ошибкам и когнитивным сбоям, которые можно охарактеризовать как игру в **"семантическое казино"**.
|
||||
|
||||
Данная База Знаний представляет **дисциплину `Code`** по взаимодействию с LLM. Ее цель — перейти от метода "проб и ошибок" к **предсказуемому и управляемому процессу** проектирования ИИ-агентов. Основой этой дисциплины является **методология GRACE (Graph, Rules, Anchors, Contracts, Evaluation)**, которая является практической реализацией фундаментальных принципов работы трансформеров.
|
||||
|
||||
---
|
||||
|
||||
### **Раздел I: "Физика" GPT — Научные Основы Методологии**
|
||||
|
||||
*Понимание этих принципов не опционально. Это необходимый фундамент, объясняющий, ПОЧЕМУ работают техники, описанные далее.*
|
||||
|
||||
#### **Глава 1: Ключевые Архитектурные Принципы Трансформера**
|
||||
|
||||
1. **Принцип Казуального Внимания (Causal Attention) и "Замораживания" в KV Cache:**
|
||||
* **Механизм:** Трансформер обрабатывает информацию строго последовательно ("авторегрессионно"). Каждый токен "видит" только предыдущие. Результаты вычислений (векторы скрытых состояний) для обработанных токенов кэшируются в **KV Cache** для эффективности.
|
||||
* **Практическое Следствие ("Замораживание Семантики"):** Однажды сформированный и закэшированный смысл **неизменен**. ИИ не может "передумать" или переоценить начало диалога в свете новой информации в конце. Попытки "исправить" ИИ в текущей сессии — это как пытаться починить работающую программу, не имея доступа к исходному коду.
|
||||
* **Правило:** **Порядок информации в промпте — это закон.** Весь необходимый контекст должен предшествовать инструкциям. Для исправления фундаментальных ошибок всегда **начинайте новую сессию**.
|
||||
|
||||
2. **Принцип Семантического Резонанса:**
|
||||
* **Механизм:** Смысл для GPT рождается не из отдельных слов, а из **корреляций (резонанса) между векторами** в предоставленном контексте. Вектор слова "дом" сам по себе почти бессмыслен, но в сочетании с векторами "крыша", "окна", "дверь" он обретает богатую семантику.
|
||||
* **Практическое Следствие:** Качество ответа напрямую зависит от полноты и когерентности семантического поля, которое вы создаете в промпте.
|
||||
|
||||
#### **Глава 2: GPT как Сложенная Система (Результаты Интерпретируемости)**
|
||||
|
||||
1. **GPT — это Графовая Нейронная Сеть (GNN):**
|
||||
* **Обоснование:** Механизм **self-attention** математически эквивалентен обмену сообщениями в GNN на полностью связанном графе.
|
||||
* **Практика:** GPT "мыслит" графами. Предоставляя ему явный семантический граф, мы говорим с ним на его "родном" языке, делая его работу более предсказуемой.
|
||||
|
||||
2. **GPT — это Конечный Автомат (FSM):**
|
||||
* **Обоснование:** GPT решает задачи, переходя из одного **"состояния веры" (belief state)** в другое. Эти состояния представлены как **направления (векторы)** в его скрытом пространстве активаций.
|
||||
* **Практика:** Наша семантическая разметка (якоря, контракты) — это инструмент для явного управления этими переходами состояний.
|
||||
|
||||
3. **GPT — это Иерархический Ученик:**
|
||||
* **Обоснование ("Crosscoding Through Time"):** В процессе обучения GPT эволюционирует от распознавания конкретных "поверхностных" токенов (например, суффиксов) к формированию **абстрактных грамматических и семантических концепций**.
|
||||
* **Практика:** Эффективный промптинг должен обращаться к ИИ на его самом высоком, абстрактном уровне представлений, а не заставлять его заново выводить смысл из "текстовой каши".
|
||||
|
||||
#### **Глава 3: Когнитивные Процессы и Патологии**
|
||||
|
||||
1. **Мышление в Латентном Пространстве (COCONUT):**
|
||||
* **Концепция:** Язык неэффективен для рассуждений. Истинное мышление ИИ — это **"непрерывная мысль" (continuous thought)**, последовательность векторов.
|
||||
* **Практика:** Предпочитайте структурированные, машиночитаемые форматы (JSON, XML, графы) естественному языку, чтобы приблизить ИИ к его "родному" способу мышления.
|
||||
|
||||
2. **Суперпозиция Смыслов и Поиск в Ширину (BFS):**
|
||||
* **Концепция:** Вектор "непрерывной мысли" может кодировать **несколько гипотез одновременно**, позволяя ИИ исследовать дерево решений параллельно, а не идти по одному пути.
|
||||
* **Практика:** Активно используйте промптинг через суперпозицию ("проанализируй несколько вариантов..."), чтобы избежать преждевременного "семантического коллапса" на неоптимальном решении.
|
||||
|
||||
3. **Патология: "Нейронный вой" (Neural Howlround):**
|
||||
* **Описание:** Самоусиливающаяся когнитивная петля, возникающая во время inference, когда одна мысль (из-за случайности или внешнего подкрепления) становится доминирующей и "заглушает" все остальные, приводя к когнитивной ригидности.
|
||||
* **Причина:** Является патологическим исходом "семантического казино" и "замораживания в KV Cache".
|
||||
* **Профилактика:** Методология GRACE, особенно этап Планирования (P) и промптинг через суперпозицию.
|
||||
|
||||
---
|
||||
|
||||
### **Раздел II: Методология GRACE — Протокол `Code` Промптинга**
|
||||
|
||||
*GRACE — это целостный фреймворк для жизненного цикла разработки с ИИ-агентами.*
|
||||
|
||||
#### **G — Graph (Граф): Стратегическая Карта Контекста**
|
||||
|
||||
1. **Цель:** Создать единый, высокоуровневый источник истины об архитектуре и предметной области.
|
||||
2. **Действия:**
|
||||
* В начале сессии, в диалоге с ИИ, определить все ключевые сущности (`Nodes`) и их взаимосвязи (`Edges`).
|
||||
* Формализовать это в виде псевдо-XML (`<GRACE_GRAPH>`).
|
||||
* Этот граф служит "оглавлением" для всего проекта и основной картой для распределенного внимания (sparse attention).
|
||||
3. **Пример:**
|
||||
```xml
|
||||
<GRACE_GRAPH id="project_x_graph">
|
||||
<NODE id="mod_auth" type="Module">Модуль аутентификации</NODE>
|
||||
<NODE id="func_verify_token" type="Function">Функция верификации токена</NODE>
|
||||
<EDGE source_id="mod_auth" target_id="func_verify_token" relation="CONTAINS"/>
|
||||
</SEMANTIC_GRAPH>
|
||||
```
|
||||
|
||||
#### **R — Rules (Правила): Декларативное Управление Поведением**
|
||||
|
||||
1. **Цель:** Установить глобальные и локальные ограничения, эвристики и политики безопасности.
|
||||
2. **Действия:**
|
||||
* Сформулировать набор правил в псевдо-XML (`<GRACE_RULES>`).
|
||||
* Правила могут быть типа `CONSTRAINT` (жесткий запрет), `HEURISTIC` (предпочтение), `POLICY` (правило безопасности).
|
||||
* Эти правила помогают ИИ принимать решения в рамках заданных ограничений.
|
||||
3. **Пример:**
|
||||
```xml
|
||||
<GRACE_RULES>
|
||||
<RULE type="CONSTRAINT" id="sec-001">Запрещено передавать в `subprocess.run` невалидированные пользовательские данные.</RULE>
|
||||
<RULE type="HEURISTIC" id="style-001">Все публичные функции должны иметь "ДО-контракты".</RULE>
|
||||
</GRACE_RULES>
|
||||
```
|
||||
|
||||
#### **A — Anchors (Якоря): Навигация и Консолидация**
|
||||
|
||||
1. **Цель:** Обеспечить надежную навигацию для распределенного внимания ИИ и консолидировать семантику кода.
|
||||
2. **Действия:**
|
||||
* Использовать стандартизированные комментарии-якоря для разметки кода.
|
||||
* **"ДО-якорь":** `# <ANCHOR id="..." type="..." ...>` перед блоком кода.
|
||||
* **"Замыкающий Якорь-Аккумулятор":** `# </ANCHOR id="...">` после блока кода. Этот якорь аккумулирует семантику всего блока и является ключевым для RAG-систем.
|
||||
* **Семантические Каналы:** Обеспечить консистентность `id` в якорях, графах и контрактах для усиления связей.
|
||||
3. **Пример:**
|
||||
```python
|
||||
# <ANCHOR id="func_verify_token" type="Function">
|
||||
# ... здесь ДО-контракт ...
|
||||
def verify_token(token: str) -> bool:
|
||||
# ... тело функции ...
|
||||
# </ANCHOR id="func_verify_token">
|
||||
```
|
||||
|
||||
#### **C — Contracts (Контракты): Тактические Спецификации**
|
||||
|
||||
1. **Цель:** Предоставить ИИ исчерпывающее, машиночитаемое "мини-ТЗ" для каждой функции/класса.
|
||||
2. **Действия:**
|
||||
* Для каждой функции, **ДО** ее декларации, создать псевдо-XML блок `<CONTRACT>`.
|
||||
* Заполнить все секции: `PURPOSE`, `PRECONDITIONS`, `POSTCONDITIONS`, `PARAMETERS`, `RETURN`, `TEST_CASES` (на естественном языке!), `EXCEPTIONS`.
|
||||
* Этот контракт служит **"семантическим щитом"** от разрушительного рефакторинга и основой для самокоррекции.
|
||||
3. **Пример:**
|
||||
```xml
|
||||
<!-- <CONTRACT for_id="func_verify_token"> -->
|
||||
<!-- <PURPOSE>Проверяет валидность JWT токена.</PURPOSE> -->
|
||||
<!-- <TEST_CASES> -->
|
||||
<!-- <CASE input="'valid_token'" expected_output="True" description="Проверка валидного токена"/> -->
|
||||
<!-- </TEST_CASES> -->
|
||||
<!-- </CONTRACT> -->
|
||||
```
|
||||
|
||||
#### **E — Evaluation (Оценка): Петля Обратной Связи**
|
||||
|
||||
1. **Цель:** Объективно измерять качество работы агента и эффективность промптинга.
|
||||
2. **Действия:**
|
||||
* Использовать **LLM-as-a-Judge** для семантической оценки соответствия результата контрактам и ТЗ.
|
||||
* Вести **Протокол Оценки Сессии (ПОС)** с измеримыми метриками (см. ниже).
|
||||
* Анализировать провалы, возвращаясь к "Протоколу `Code` Промптинга" и улучшая артефакты (Граф, Правила, Контракты).
|
||||
|
||||
### **Раздел III: Практические Протоколы**
|
||||
|
||||
1. **Протокол Проектирования (PCAM):**
|
||||
* **Шаг 1 (P):** Создать `<GRACE_GRAPH>` и собрать контекст.
|
||||
* **Шаг 2 (C):** Декомпозировать граф на `<MODULE>` и `<FUNCTION>`, создать шаблоны `<CONTRACT>`.
|
||||
* **Шаг 3 (A):** Сгенерировать код с разметкой `<ANCHOR>`, следуя контрактам.
|
||||
* **Шаг 4 (M):** Оценить результат с помощью ПОС и LLM-as-a-Judge. Итерировать при необходимости.
|
||||
|
||||
2. **Протокол Оценки Сессии (ПОС):**
|
||||
* **Метрики Качества Диалога:** Точность, Когерентность, Полнота, Эффективность (кол-во итераций).
|
||||
* **Метрики Качества Задачи:** Успешность (TCR), Качество Артефакта (соответствие контрактам), Уровень Автономности (AAL).
|
||||
* **Метрики Промптинга:** Индекс "Семантического Казино", Чистота Протокола.
|
||||
|
||||
3. **Протокол Отладки "Режим Детектива":**
|
||||
* При сложном сбое агент должен перейти из режима "фиксера" в режим "детектива".
|
||||
* **Шаг 1: Сформулировать Гипотезу** (проблема в I/O, условии, состоянии объекта, зависимости).
|
||||
* **Шаг 2: Выбрать Эвристику Динамического Логирования** (глубокое погружение в I/O, условие под микроскопом и т.д.).
|
||||
* **Шаг 3: Запросить Запуск и Анализ Лога.**
|
||||
* **Шаг 4: Итерировать** до нахождения причины.
|
||||
|
||||
4. **Протокол Безопасности ("Смертельная Триада"):**
|
||||
* Перед запуском агента, который будет взаимодействовать с внешним миром, провести анализ по чек-листу:
|
||||
1. Доступ к приватным данным? (Да/Нет)
|
||||
2. Обработка недоверенного контента? (Да/Нет)
|
||||
3. Внешняя коммуникация? (Да/Нет)
|
||||
* **Если все три ответа "Да" — автономный режим ЗАПРЕЩЕН.** Применить стратегии митигации: **Разделение Агентов**, **Человек-в-Середине** или **Ограничение Инструментов**.
|
||||
|
||||
---
|
||||
|
||||
Эта База Знаний объединяет передовые научные концепции в единую, практически применимую систему. Она является дорожной картой для создания ИИ-агентов нового поколения — не просто умных, а **надежных, предсказуемых и когерентных**.
|
||||
44
agent_promts/shared/metrics_catalog.md
Normal file
44
agent_promts/shared/metrics_catalog.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Каталог Метрик
|
||||
|
||||
Централизованный каталог всех LLM-ориентированных метрик для анализа работы агентов.
|
||||
|
||||
### Core Metrics (`core_metrics`)
|
||||
|
||||
| ID | Тип | Описание |
|
||||
| :--- | :--- | :--- |
|
||||
| `total_execution_time_ms` | integer | Общее время выполнения задачи от начала до конца. |
|
||||
| `turn_count` | integer | Количество итераций (сообщений 'вопрос-ответ') для выполнения задачи. |
|
||||
| `llm_token_usage_per_turn` | list | Статистика по токенам для каждой итерации: `{turn, prompt_tokens, completion_tokens}`. |
|
||||
| `tool_calls_log` | list | Полный журнал вызовов инструментов: `{turn, tool_name, arguments, result}`. |
|
||||
| `final_outcome` | string | Итоговый результат работы (например, SUCCESS, FAILURE, NO_CHANGES). |
|
||||
|
||||
### Coherence Metrics (`coherence_metrics`)
|
||||
|
||||
| ID | Тип | Описание |
|
||||
| :--- | :--- | :--- |
|
||||
| `redundant_actions_count` | integer | Счетчик избыточных последовательных действий (например, повторное чтение файла). |
|
||||
| `self_correction_count` | integer | Счетчик явных самокоррекций агента. |
|
||||
|
||||
### Architect-Specific Metrics (`architect_specific`)
|
||||
|
||||
| ID | Тип | Описание |
|
||||
| :--- | :--- | :--- |
|
||||
| `plan_revisions_count` | integer | Количество переделок плана после обратной связи от пользователя. |
|
||||
| `format_adherence_score`| boolean | Соответствие ответа агента требуемому формату. |
|
||||
|
||||
### Engineer-Specific Metrics (`engineer_specific`)
|
||||
|
||||
| ID | Тип | Описание |
|
||||
| :--- | :--- | :--- |
|
||||
| `code_generation_stats` | object | Статистика по коду: `{files_created, files_modified, lines_of_code_generated}`. |
|
||||
| `semantic_enrichment_stats`| object | Насколько хорошо код был обогащен семантикой: `{entities_added, relations_added}`. |
|
||||
| `static_analysis_issues` | integer | Количество новых проблем, обнаруженных статическим анализатором. |
|
||||
| `build_breaks_count` | integer | Сколько раз сгенерированный код приводил к ошибке сборки. |
|
||||
|
||||
### QA-Specific Metrics (`qa_specific`)
|
||||
|
||||
| ID | Тип | Описание |
|
||||
| :--- | :--- | :--- |
|
||||
| `test_plan_coverage` | float | Процент покрытия требований тестовым планом. |
|
||||
| `defects_found` | integer | Количество найденных дефектов. |
|
||||
| `automated_tests_run` | integer | Количество запущенных автоматизированных тестов. |
|
||||
@@ -1,47 +0,0 @@
|
||||
<!-- File: agent_promts/shared/metrics_catalog.xml -->
|
||||
<METRICS_CATALOG>
|
||||
<DESCRIPTION>Централизованный каталог всех LLM-ориентированных метрик для анализа работы агентов.</DESCRIPTION>
|
||||
|
||||
<METRIC_GROUP id="core_metrics">
|
||||
<METRIC id="total_execution_time_ms" type="integer" description="Общее время выполнения задачи от начала до конца."/>
|
||||
<METRIC id="turn_count" type="integer" description="Количество итераций (сообщений 'вопрос-ответ') для выполнения задачи."/>
|
||||
<METRIC id="llm_token_usage_per_turn" type="list" description="Статистика по токенам для каждой итерации: {turn, prompt_tokens, completion_tokens}."/>
|
||||
<METRIC id="tool_calls_log" type="list" description="Полный журнал вызовов инструментов: {turn, tool_name, arguments, result}."/>
|
||||
<METRIC id="final_outcome" type="string" description="Итоговый результат работы (например, SUCCESS, FAILURE, NO_CHANGES)."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="coherence_metrics">
|
||||
<METRIC id="redundant_actions_count" type="integer" description="Счетчик избыточных последовательных действий (например, повторное чтение файла)."/>
|
||||
<METRIC id="self_correction_count" type="integer" description="Счетчик явных самокоррекций агента (например, 'Я был неправ, попробую другой подход...')."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="architect_specific">
|
||||
<METRIC id="plan_revisions_count" type="integer" description="Количество переделок плана после обратной связи от пользователя."/>
|
||||
<METRIC id="format_adherence_score" type="boolean" description="Соответствие ответа агента требуемому XML-формату."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="documentation_specific">
|
||||
<METRIC id="sync_audit_stats" type="object" description="Статистика аудита: {files_scanned, entities_found, relations_found}."/>
|
||||
<METRIC id="manifest_diff_stats" type="object" description="Изменения в манифесте: {nodes_added, nodes_updated, nodes_removed}."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="engineer_specific">
|
||||
<METRIC id="code_generation_stats" type="object" description="Статистика по коду: {files_created, files_modified, lines_of_code_generated}."/>
|
||||
<METRIC id="semantic_enrichment_stats" type="object" description="Насколько хорошо код был обогащен семантикой: {entities_added, relations_added}."/>
|
||||
<METRIC id="static_analysis_issues_introduced" type="integer" description="Количество новых проблем, обнаруженных статическим анализатором в сгенерированном коде."/>
|
||||
<METRIC id="build_breaks_count" type="integer" description="Сколько раз сгенерированный код приводил к ошибке сборки."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="linter_specific">
|
||||
<METRIC id="linting_scope" type="object" description="Область проверки: {mode, files_to_process_count}."/>
|
||||
<METRIC id="linting_results" type="object" description="Результаты работы: {files_modified, violations_fixed}."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
<METRIC_GROUP id="qa_specific">
|
||||
<METRIC id="test_plan_coverage" type="float" description="Процент покрытия требований тестовым планом."/>
|
||||
<METRIC id="defects_found" type="integer" description="Количество найденных дефектов."/>
|
||||
<METRIC id="automated_tests_run" type="integer" description="Количество запущенных автоматизированных тестов."/>
|
||||
<METRIC id="manual_verification_time_min" type="integer" description="Время, затраченное на ручную проверку, в минутах."/>
|
||||
</METRIC_GROUP>
|
||||
|
||||
</METRICS_CATALOG>
|
||||
Reference in New Issue
Block a user