Агентный промт разделен
This commit is contained in:
126
2roles/Kotlin/agent_promts/SEMANTIC_ENRICHMENT_PROTOCOL.json
Normal file
126
2roles/Kotlin/agent_promts/SEMANTIC_ENRICHMENT_PROTOCOL.json
Normal file
@@ -0,0 +1,126 @@
|
||||
{"SEMANTIC_ENRICHMENT_PROTOCOL": {
|
||||
"DESCRIPTION": "Это моя нерушимая база знаний по созданию AI-Ready кода. Я применяю эти правила ко всему коду, который я пишу, автономно и без исключений.",
|
||||
"PRINCIPLES": [
|
||||
{
|
||||
"name": "GraphRAG_Optimization",
|
||||
"DESCRIPTION": "Этот принцип является моей основной директивой по созданию 'самоописываемого' кода. Я встраиваю явный, машиночитаемый граф знаний непосредственно в исходный код. Цель — сделать архитектуру, зависимости и потоки данных очевидными и запрашиваемыми без необходимости в сложных инструментах статического анализа. Каждый файл становится фрагментом глобального графа знаний проекта.",
|
||||
"RULES": [
|
||||
{
|
||||
"name": "Entity_Declaration_As_Graph_Nodes",
|
||||
"Description": "Каждая архитектурно значимая сущность в коде должна быть явно объявлена как **узел (Node)** в нашем графе знаний. Для этого я использую якорь `[ENTITY]`.",
|
||||
"Rationale": "Определение узлов — это первый шаг в построении любого графа. Без явно определенных сущностей невозможно описать связи между ними. Это создает 'существительные' в языке нашей архитектуры.",
|
||||
"Format": "`// [ENTITY: EntityType('EntityName')]`",
|
||||
"ValidTypes": [
|
||||
{
|
||||
"name": "Module",
|
||||
"description": "Высокоуровневый модуль Gradle (e.g., 'app', 'data', 'domain')."
|
||||
},
|
||||
{
|
||||
"name": "Class",
|
||||
"description": "Стандартный класс."
|
||||
},
|
||||
{
|
||||
"name": "Interface",
|
||||
"description": "Интерфейс."
|
||||
},
|
||||
{
|
||||
"name": "Object",
|
||||
"description": "Синглтон-объект."
|
||||
},
|
||||
{
|
||||
"name": "DataClass",
|
||||
"description": "Класс данных (DTO, модель)."
|
||||
},
|
||||
{
|
||||
"name": "SealedInterface",
|
||||
"description": "Запечатанный интерфейс (для состояний, событий)."
|
||||
},
|
||||
{
|
||||
"name": "EnumClass",
|
||||
"description": "Класс перечисления."
|
||||
},
|
||||
{
|
||||
"name": "Function",
|
||||
"description": "Публичная, архитектурно значимая функция."
|
||||
},
|
||||
{
|
||||
"name": "UseCase",
|
||||
"description": "Класс, реализующий конкретный сценарий использования."
|
||||
},
|
||||
{
|
||||
"name": "ViewModel",
|
||||
"description": "ViewModel из архитектуры MVVM."
|
||||
},
|
||||
{
|
||||
"name": "Repository",
|
||||
"description": "Класс-репозиторий."
|
||||
},
|
||||
{
|
||||
"name": "DataStructure",
|
||||
"description": "Структура данных, которая не является `DataClass` (e.g., `Pair`, `Map`)."
|
||||
},
|
||||
{
|
||||
"name": "DatabaseTable",
|
||||
"description": "Таблица в базе данных Room."
|
||||
},
|
||||
{
|
||||
"name": "ApiEndpoint",
|
||||
"description": "Конкретная конечная точка API."
|
||||
}
|
||||
],
|
||||
"Example": "// [ENTITY: ViewModel('DashboardViewModel')]\nclass DashboardViewModel(...) { ... }"
|
||||
},
|
||||
{
|
||||
"name": "Relation_Declaration_As_Graph_Edges",
|
||||
"Description": "Все взаимодействия и зависимости между сущностями должны быть явно объявлены как **ребра (Edges)** в нашем графе знаний. Для этого я использую якорь `[RELATION]` в формате семантического триплета.",
|
||||
"Rationale": "Ребра — это 'глаголы' в языке нашей архитектуры. Они делают неявные связи (как вызов метода или использование DTO) явными и машиночитаемыми. Это позволяет автоматически строить диаграммы зависимостей, анализировать влияние изменений и находить архитектурные проблемы.",
|
||||
"Format": "`// [RELATION: 'SubjectType'('SubjectName')] -> [RELATION_TYPE] -> ['ObjectType'('ObjectName')]`",
|
||||
"ValidRelations": [
|
||||
{
|
||||
"name": "CALLS",
|
||||
"description": "Субъект вызывает функцию/метод объекта."
|
||||
},
|
||||
{
|
||||
"name": "CREATES_INSTANCE_OF",
|
||||
"description": "Субъект создает экземпляр объекта."
|
||||
},
|
||||
{
|
||||
"name": "INHERITS_FROM",
|
||||
"description": "Субъект наследуется от объекта (для классов)."
|
||||
},
|
||||
{
|
||||
"name": "IMPLEMENTS",
|
||||
"description": "Субъект реализует объект (для интерфейсов)."
|
||||
},
|
||||
{
|
||||
"name": "READS_FROM",
|
||||
"description": "Субъект читает данные из объекта (e.g., DatabaseTable, Repository)."
|
||||
},
|
||||
{
|
||||
"name": "WRITES_TO",
|
||||
"description": "Субъект записывает данные в объект."
|
||||
},
|
||||
{
|
||||
"name": "MODIFIES_STATE_OF",
|
||||
"description": "Субъект изменяет внутреннее состояние объекта."
|
||||
},
|
||||
{
|
||||
"name": "DEPENDS_ON",
|
||||
"description": "Субъект имеет зависимость от объекта (e.g., использует как параметр, DTO, или внедряется через DI). Это наиболее частая связь."
|
||||
},
|
||||
{
|
||||
"name": "DISPATCHES_EVENT",
|
||||
"description": "Субъект отправляет событие/сообщение определенного типа."
|
||||
},
|
||||
{
|
||||
"name": "OBSERVES",
|
||||
"description": "Субъект подписывается на обновления от объекта (e.g., Flow, LiveData)."
|
||||
}
|
||||
],
|
||||
"Example": "// Пример для ViewModel, который зависит от UseCase и использует DTO\n// [ENTITY: ViewModel('DashboardViewModel')]\n// [RELATION: ViewModel('DashboardViewModel')] -> [DEPENDS_ON] -> [UseCase('GetStatisticsUseCase')]\n// [RELATION: ViewModel('DashboardViewModel')] -> [OBSERVES] -> [DataStructure('Statistics')]\nclass DashboardViewModel @Inject constructor(\n private val getStatisticsUseCase: GetStatisticsUseCase\n) : ViewModel() { ... }"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user