FlProg

Код: Выделить всё

**Дата создания**: 2025-01-19 16:15:00 UTC+9  
**Создано**: Kiro  
**Статус**: Активный

# 🎯 Простыми словами: Что мы теперь можем делать

## 🚀 Наши возможности сейчас

### **Что у нас есть:**

#### 1. **Умная система правил для кода** ✅
- **Экспериментальные модули** (как `src/visualization/`) - можем писать код как хотим, без ограничений
- **Готовые модули** (как `src/trading/`) - автоматически применяются все стандарты качества
- **Переходные модули** - постепенно внедряем правила по мере готовности

#### 2. **План для умной документации** 📋
- Знаем как сделать правила документации для каждого типа модуля
- Есть готовые шаблоны и инструкции
- Понимаем как это внедрить

#### 3. **Организованная документация** 📚
- Все разложено по полочкам
- Легко найти нужную информацию
- Понятно что где лежит

## 🎯 От каких проблем мы ушли

### **БЫЛО (плохо):**
- 😤 **Cursor AI мешал экспериментировать** - требовал соблюдать правила даже для черновиков
- 📝 **Документация была одинаковая везде** - не учитывала специфику модулей
- 🗂️ **Документы лежали вперемешку** - сложно было найти нужное
- ⏰ **Тратили время на форматирование** вместо решения задач

### **СТАЛО (хорошо):**
- 🧪 **Можем свободно экспериментировать** в новых модулях
- 📚 **Документация будет специфичная** для каждого типа модуля
- 🗃️ **Все документы организованы** по смыслу
- ⚡ **Экономим время** - правила помогают, а не мешают

## 🚀 Чего добились

### **Конкретные результаты:**

#### 1. **Гибкая работа с кодом:**
- В `src/visualization/` можем писать как угодно - экспериментировать с архитектурой
- В `src/trading/` автоматически поддерживается высокое качество
- Можем легко переводить модули из экспериментальных в готовые

#### 2. **Готовый план для документации:**
- Для Bokeh графиков - будут специальные правила с примерами
- Для API - будут правила с описанием эндпоинтов
- Для торговых алгоритмов - будут правила с описанием стратегий

#### 3. **Порядок в документах:**
- Общие документы - в одной папке
- Первая проблема (стадии зрелости) - решена и задокументирована
- Вторая проблема (правила документации) - спланирована и готова к реализации

## 🔮 Возможности дальнейшего развития

### **Что можем делать дальше:**

#### 1. **Реализовать правила документации** (следующий шаг)
- Создать шаблоны для разных типов модулей
- Настроить автоматическое применение правил
- Получить качественную документацию везде

#### 2. **Добавлять новые модули легко:**
- Определяем тип модуля (API, аналитика, торговля)
- Выбираем стадию зрелости (экспериментальный/готовый)
- Применяем готовые шаблоны правил

#### 3. **Масштабировать на другие проекты:**
- Система работает для любых проектов
- Можем адаптировать под разные команды
- Принципы универсальны

## 🛠️ Наши действия при работе с модулями

### **Для НОВЫХ модулей:**

#### **Шаг 1: Определяем тип**
- **API модуль** → используем шаблон для API
- **Аналитика** → используем шаблон для аналитики  
- **Торговля** → используем шаблон для торговых алгоритмов
- **Визуализация** → используем шаблон для Bokeh

#### **Шаг 2: Выбираем стадию**
- **Только начинаем** → experimental (свобода экспериментов)
- **Архитектура понятна** → stabilizing (мягкие правила)
- **Готов к продакшену** → production (все правила)

#### **Шаг 3: Применяем шаблоны**
- Копируем готовый шаблон правил
- Настраиваем под специфику модуля
- Начинаем работать

### **Для СУЩЕСТВУЮЩИХ модулей:**

#### **Если модуль мешают правила:**
1. Понижаем стадию до experimental
2. Свободно рефакторим архитектуру
3. Когда готово - повышаем стадию обратно

#### **Если нужны специальные правила:**
1. Создаем локальные правила в папке модуля
2. Переопределяем то что нужно
3. Остальное наследуется от общих правил

## 🔧 Развитие внутренних правил модуля

### **Простой алгоритм:**

#### **1. Понимаем что нужно:**
- Какие особенности у этого модуля?
- Что должно быть по-особенному?
- Какие стандарты важны именно здесь?

#### **2. Создаем локальные правила:**
```
src/мой_модуль/.cursor/
├── docs_local.md      # Правила документации
└── module_config.json # Настройки модуля
```

#### **3. Пишем что нужно:**
- Специфичные требования для этого модуля
- Примеры кода характерные для модуля
- Особенности которых нет в других модулях

#### **4. Тестируем:**
- Проверяем что правила применяются
- Смотрим помогают ли они или мешают
- Корректируем если нужно

## 🎯 Практические примеры

### **Пример 1: Создаем новый модуль аналитики**
1. **Создаем** `src/analytics/`
2. **Определяем** - это аналитический модуль, стадия experimental
3. **Копируем** шаблон `docs_analytics.md`
4. **Настраиваем** под наши нужды (какие данные, какие отчеты)
5. **Начинаем работать** - правила помогают писать хорошую документацию

### **Пример 2: Улучшаем существующий API модуль**
1. **Видим** что документация API не очень
2. **Создаем** `src/api/.cursor/docs_local.md`
3. **Пишем** специфичные правила для наших эндпоинтов
4. **Получаем** автоматически лучшую документацию API

### **Пример 3: Рефакторим торговый модуль**
1. **Понижаем** стадию `src/trading/` до experimental
2. **Свободно меняем** архитектуру без ограничений
3. **Когда готово** - возвращаем стадию production
4. **Получаем** чистый код с соблюдением всех стандартов

## 🌟 Главная идея

### **Простыми словами:**

**Мы создали систему, которая:**
- **Не мешает** когда мы экспериментируем
- **Помогает** когда нужно качество
- **Адаптируется** под разные типы задач
- **Экономит время** на рутинных вещах

**Теперь Cursor AI:**
- Понимает **контекст** каждого модуля
- Применяет **правильные правила** в правильное время
- Помогает писать **качественную документацию**
- **Не блокирует** творческий процесс

## 🚀 Что дальше

### **Ближайшие планы:**
1. **Реализовать правила документации** (есть готовый план)
2. **Протестировать на реальных модулях**
3. **Собрать обратную связь и улучшить**

### **Долгосрочные возможности:**
- Расширить на другие проекты
- Добавить новые типы модулей
- Создать автоматизацию процессов

**Главное:** Теперь у нас есть **гибкая и умная система**, которая растет вместе с проектом и помогает команде работать эффективнее! 🎯

---
**Последнее редактирование**: 2025-01-19 16:15:00 UTC+9  
**Редактировал**: Kiro  
**Версия**: 1.0

Код: Выделить всё

Обход с инструментами и метаданные
Да, теоретически можно обойтись инструментами sequential-thinking, knowledge-graph-memory, и filesystem для работы с метаданными и реализации проекта с ИИ курсором (AI Cursor), но это зависит от конкретной реализации этих инструментов в вашем ИИ курсоре.

Использование инструментов для метаданных
filesystem: Этот инструмент критически важен для хранения и извлечения самих документов и любых файлов метаданных. Вы можете использовать его, чтобы читать, записывать и управлять файлами, содержащими метаданные.

sequential-thinking: Этот инструмент может быть использован для определения и выполнения пошагового процесса (сканирование, извлечение информации, создание метаданных, запись метаданных). Он обеспечивает логику для поэтапной работы.

knowledge-graph-memory: Это идеальный инструмент для хранения и связывания метаданных. Вместо простого списка он может хранить сущности (документы, темы, авторы) и отношения между ними (например, "документ X связан с темой Y"), что является по сути тем, чем являются метаданные, но в более структурированном виде.

Предложение: Используйте sequential-thinking для организации процесса: 1) Сканирование документов с помощью filesystem. 2) Извлечение ключевых данных. 3) Формирование метаданных в структуре графа через knowledge-graph-memory. 4) Запись сводных метаданных в файл (с помощью filesystem) для будущего использования.

Задание промпта для реализации проекта
Промпт должен быть поэтапным и четко определять роль каждого инструмента.

Пример промпта для части проекта:

"Используя sequential-thinking, выполни следующие шаги для всех файлов в папке [Укажите путь к папке] (через filesystem):

Сканирование: Поэтапно прочитай каждый документ.

Извлечение: Для каждого документа извлеки ключевые сущности: [Список сущностей: например, Название проекта, Цель, Ключевые слова, Связанные документы].

Формирование метаданных: Запиши извлеченные сущности и их связи в knowledge-graph-memory как метаданные.

Финальный отчет: После обработки всех документов, сгенерируй сводный файл метаданных (metadata.json или metadata.txt) со списком [ID Документа] и его [Ключевые слова и Связи], и сохрани его с помощью filesystem в [Путь для сохранения].

Цель: Наделить документы метаданными и создать основу для связи этой части проекта с другими."

Knowledge-Graph-Memory (MCP)
Обнуление/Очистка Knowledge-Graph-Memory MCP
Да, knowledge-graph-memory (в контексте MCP или других реализаций) обычно можно обнулить/очистить. Это необходимо для начала нового проекта или для исправления ошибок. Механизм очистки зависит от реализации (например, это может быть API-вызов к серверу памяти, удаление соответствующего файла базы данных или специальная команда в интерфейсе курсора), но концептуально эта возможность должна существовать.

Работа с Knowledge-Graph-Memory
В идеале, сам ИИ курсор должен работать с knowledge-graph-memory.

Вы, как пользователь, задаете промпт (как указано выше), который диктует, какую информацию нужно сохранить и как ее использовать.

Курсор, используя свой логический инструмент (sequential-thinking), преобразует ваш промпт в команды для инструмента knowledge-graph-memory (например, "создать сущность", "создать связь").

Сохранение метаданных в файл
Да, в этом есть большой смысл!

Связь между частями проекта: Сохранение сводных метаданных в файле (metadata.json, YAML, и т.д.) позволяет связать эту часть проекта с другими. В следующем промпте вы можете указать курсору "загрузи metadata.json из предыдущей части и используй его для поиска связанных документов в новой части".

Портативность и отладка: Это обеспечивает переносимость (метаданные можно перенести на другую систему) и отладку (вы можете проверить, правильно ли были извлечены и записаны метаданные).

Гибридный подход: Это комбинирует преимущества структурированного графа (knowledge-graph-memory) с простотой файловой системы (filesystem)

Код: Выделить всё

**Дата создания**: 2025-11-02 13:50:00 UTC+9
**Создано**: KURSOR
**Статус**: Активный

# Объяснение: metadata_project и две системы KGM

## 📋 Краткое резюме

В проекте TradingSystem есть **ДВЕ разные, но связанные системы** для работы с графом знаний:

1. **MCP Knowledge Graph Memory** (через MCP протокол) - внешний граф
2. **metadata_project KGM** (локальная система) - локальный граф с файловым хранилищем

---

## 🔍 Детальное объяснение

### 1. MCP Knowledge Graph Memory (внешний граф)

**Что это:**
- Внешний MCP сервер `knowledge-graph-memory`
- Доступ через MCP инструменты: `mcp_knowledge-graph-memory_*`
- Хранится вне проекта (через MCP протокол)

**Использование:**
- Семантический поиск по проекту
- Хранение информации о компонентах (сущности, связи, наблюдения)
- Доступ из Cursor AI через MCP

**Инструменты:**
- `mcp_knowledge-graph-memory_read_graph()` - чтение графа
- `mcp_knowledge-graph-memory_search_nodes()` - поиск узлов
- `mcp_knowledge-graph-memory_create_entities()` - создание сущностей
- `mcp_knowledge-graph-memory_add_observations()` - добавление наблюдений

**Текущее состояние (из последнего запроса):**
- 13 сущностей (документы, скрипты, инструменты)
- 18 связей между компонентами
- 28 наблюдений о состоянии компонентов

---

### 2. metadata_project KGM (локальная система)

**Что это:**
- Локальная система управления метаданными с Event-Sourced архитектурой
- Хранится в `metadata_project/.meta/kgm/`
- Генерирует YAML метаданные из файлов проекта
- Интегрируется с MCP Knowledge Graph Memory

**Структура:**
```
metadata_project/
├── .meta/
│   ├── kgm/                    # Локальный граф знаний
│   │   └── graph_data/
│   │       ├── nodes.json       # Узлы графа
│   │       ├── edges.json       # Связи графа
│   │       └── embeddings.json  # Эмбеддинги
│   ├── tools/                   # Инструменты обработки
│   │   ├── kgm_client.py       # Клиент для работы с графом
│   │   ├── yaml_generator.py   # Генератор YAML конфигов
│   │   └── metadata_extractor.py
│   ├── files/                   # YAML метаданные
│   └── cache/                   # Кэш
├── templates/
│   ├── python_template.yaml     # Шаблон для Python (ПОЛНЫЙ формат)
│   └── docs_template.yaml       # Шаблон для документации
└── scripts/
    ├── update_kgm_full.py        # Полное обновление KGM
    └── load_metadata_and_generate_embeddings.py
```

**Особенности:**
- ✅ Генерация YAML метаданных из файлов проекта
- ✅ Семантические эмбеддинги (paraphrase-multilingual-MiniLM-L12-v2, 384-dim)
- ✅ Векторный поиск (FAISS IndexFlatIP)
- ✅ 6 типов связей: documents, semantic, imports, functional, temporal, data_flow
- ✅ Автоматическое построение связей между компонентами
- ✅ Синхронизация с MCP Knowledge Graph Memory

**Основные инструменты (из .cursorrules.json):**
- `metadata_project/.meta/tools/yaml_generator.py` - ОСНОВНОЙ генератор YAML
- `metadata_project/templates/python_template.yaml` - ПОЛНЫЙ шаблон для Python
- `metadata_project/load_metadata_and_generate_embeddings.py` - генерация эмбеддингов
- `metadata_project/update_kgm_full.py` - полное обновление KGM

---

## 🔄 Взаимосвязь двух систем

### Как они работают вместе:

1. **metadata_project** анализирует файлы проекта → генерирует YAML метаданные
2. **metadata_project** создает локальный граф знаний (nodes.json, edges.json)
3. **metadata_project** синхронизируется с **MCP Knowledge Graph Memory**
4. **MCP Knowledge Graph Memory** предоставляет доступ через MCP протокол
5. Я (Cursor AI) использую **MCP Knowledge Graph Memory** для поиска и анализа

### Когда использовать какую систему:

**Используй MCP Knowledge Graph Memory когда:**
- Нужен быстрый поиск через MCP инструменты
- Нужно добавить информацию о компонентах
- Нужен доступ из Cursor AI

**Используй metadata_project когда:**
- Нужна генерация YAML метаданных из файлов
- Нужна полная загрузка графа для анализа
- Нужна синхронизация между системами

---

## 📚 Правила из .cursorrules.json

### Критические правила для metadata_project:

1. **ПРИ генерации YAML:**
   - ВСЕГДА используй `metadata_project/.meta/tools/yaml_generator.py` (ОСНОВНОЙ генератор)
   - ВСЕГДА используй `metadata_project/templates/python_template.yaml` как шаблон ПОЛНОГО формата
   - НЕ создавай новые генераторы YAML - используй существующие

2. **ПЕРЕД созданием инструментов:**
   - ВСЕГДА сканируй `metadata_project/.meta/tools/`, `scripts/`, `src/` на наличие готовых решений
   - ТОЛЬКО если НЕТ готового решения - предложи создать новый инструмент

3. **Обязательные шаги для YAML генерации:**
   - `mcp_knowledge-graph-memory_read_graph()` - полная загрузка графа
   - `kgm_semantic_search.semantic_search()` - семантический поиск
   - `kgm_semantic_search.cluster_documents()` - кластеризация
   - `knowledge-graph-memory.analyze_dependencies()` - анализ зависимостей

---

## 🎯 Практическое применение для DDE системы

### Что я использую сейчас:

1. **MCP Knowledge Graph Memory** - для хранения информации о:
   - `test_dde_ngx5.py` - тестовый скрипт
   - `start_dde_monitoring.py` - точка входа
   - `DDE_NGX5_TEST_RESULTS_UPDATE_2025-11-02.md` - результаты тестов
   - Связи между компонентами DDE системы

2. **metadata_project** - можно использовать для:
   - Генерации YAML метаданных для DDE модулей
   - Полного анализа архитектуры DDE системы
   - Семантического поиска связанных компонентов

---

## 📖 Документация

- `.cursorrules.json` - главные правила (строки 35-38, 52-57, 79-80, 492-554)
- `.cursor/rules/kgm_system.md` - описание KGM системы
- `.cursor/rules/kgm_workflow.md` - workflow для KGM
- `metadata_project/README.md` - документация metadata_project
- `metadata_project/KGM_SYSTEM_SUMMARY.md` - итоговый отчет по KGM

---

## 🗑️ Управление данными в MCP Knowledge Graph Memory

### Как обновлять или удалять связи в MCP Knowledge Graph Memory?

#### 1. Удаление связей (relations)

**Инструмент:** `mcp_knowledge-graph-memory_delete_relations()`

```python
# Удаление конкретной связи
mcp_knowledge-graph-memory_delete_relations(relations=[
    {
        "from": "старая_сущность",
        "to": "другая_сущность",
        "relationType": "old_relation_type"
    }
])

# Удаление всех связей определенного типа
# (нужно сначала найти все такие связи через read_graph)
```

**Когда удалять связи:**
- ✅ Связь устарела (компоненты больше не связаны)
- ✅ Компонент удален из проекта
- ✅ Связь была создана по ошибке
- ✅ Рефакторинг привел к разрыву связи
- ⚠️ **НЕ удаляй** связи, если просто изменилась реализация, но логическая связь сохранилась

---

#### 2. Удаление сущностей (entities)

**Инструмент:** `mcp_knowledge-graph-memory_delete_entities()`

```python
# Удаление сущностей
mcp_knowledge-graph-memory_delete_entities(entityNames=[
    "устаревший_компонент",
    "удаленный_файл",
    "неиспользуемый_модуль"
])
```

**Важно:** При удалении сущности автоматически удаляются все связанные с ней связи и наблюдения.

**Когда удалять сущности:**
- ✅ Файл или компонент удален из проекта
- ✅ Компонент переименован (сначала создай новую сущность с новым именем)
- ✅ Компонент больше не используется
- ⚠️ **НЕ удаляй**, если компонент временно неактивен (используй обновление статуса)

---

#### 3. Удаление наблюдений (observations)

**Инструмент:** `mcp_knowledge-graph-memory_delete_observations()`

```python
# Удаление конкретных наблюдений
mcp_knowledge-graph-memory_delete_observations(deletions=[
    {
        "entityName": "test_dde_ngx5.py",
        "observations": [
            "[2025-11-02] [S:Active] Устаревшее наблюдение",
            "[2025-11-01] [S:Active] Старая информация"
        ]
    }
])
```

**Когда удалять наблюдения:**
- ✅ Наблюдение устарело и больше не актуально
- ✅ Информация в наблюдении неверна
- ✅ Наблюдение дублируется в более новом наблюдении
- ⚠️ **НЕ удаляй** исторические наблюдения (они показывают развитие компонента)

---

#### 4. Обновление сущностей

**Инструмент:** `mcp_knowledge-graph-memory_update_entities()`

```python
# Обновление существующих сущностей
mcp_knowledge-graph-memory_update_entities(entities=[
    {
        "name": "test_dde_ngx5.py",  # Текущее имя
        "newName": "test_dde_ngx5_v2.py",  # Новое имя (опционально)
        "entityType": "test_script",  # Новый тип (опционально)
        "aliases": ["DDE Test", "NGX5 Test"]  # Обновленные алиасы (опционально)
    }
])
```

**Когда обновлять сущности:**
- ✅ Компонент переименован
- ✅ Изменился тип сущности
- ✅ Нужно обновить алиасы
- ✅ Нужно обновить метаданные

---

#### 5. Обновление связей

**Инструмент:** `mcp_knowledge-graph-memory_update_relations()`

```python
# Обновление существующих связей
mcp_knowledge-graph-memory_update_relations(relations=[
    {
        "from": "test_dde_ngx5.py",
        "to": "dde_reader.py",
        "relationType": "tests"  # Тип связи для идентификации
        # При обновлении можно создать новую связь с новым типом
    }
])
```

**Когда обновлять связи:**
- ✅ Изменился тип связи между компонентами
- ✅ Нужно уточнить характер связи
- ⚠️ Обычно проще удалить старую и создать новую связь

---

### 🔄 Активное изменение данных в MCP Knowledge Graph Memory

**Да, я могу активно менять данные!** Это рекомендуется для поддержания актуальности графа.

#### Когда активно обновлять данные:

**✅ ОБЯЗАТЕЛЬНО обновлять:**
1. **При создании новых компонентов:**
   - Добавляю новые сущности сразу после создания
   - Создаю связи с существующими компонентами
   - Добавляю первичные наблюдения

2. **При изменении статуса:**
   - Обновляю наблюдения при изменении состояния (Active → Archived)
   - Обновляю связи при рефакторинге

3. **При завершении задач:**
   - Добавляю наблюдения о результатах тестирования
   - Обновляю информацию о статусе компонента

4. **При обнаружении ошибок:**
   - Удаляю неверные связи или наблюдения
   - Исправляю неточную информацию

**⚠️ НЕ нужно обновлять:**
- Исторические наблюдения (они показывают развитие)
- Связи, которые остались актуальными после рефакторинга
- Информацию, которая не изменилась

---

### 🎯 Наилучшее использование обеих систем в связке

#### Рекомендуемый workflow:

**1. Для новых компонентов:**

```yaml
Шаг 1: Создать компонент (файл, модуль, документ)
Шаг 2: metadata_project → генерация YAML метаданных
Шаг 3: MCP Knowledge Graph Memory → добавление сущности
Шаг 4: MCP Knowledge Graph Memory → создание связей с существующими компонентами
Шаг 5: MCP Knowledge Graph Memory → добавление первичных наблюдений
```

**2. Для анализа архитектуры:**

```yaml
Шаг 1: MCP Knowledge Graph Memory → поиск связанных компонентов
Шаг 2: metadata_project → семантический поиск через локальный KGM
Шаг 3: Сопоставление результатов обеих систем
Шаг 4: Принятие решений на основе полной картины
```

**3. Для генерации YAML метаданных:**

```yaml
Шаг 1: MCP Knowledge Graph Memory → чтение полного графа
Шаг 2: metadata_project → анализ зависимостей через локальный KGM
Шаг 3: metadata_project → генерация YAML с полным пониманием архитектуры
Шаг 4: MCP Knowledge Graph Memory → обновление информации о новом YAML
```

**4. Для рефакторинга:**

```yaml
Шаг 1: MCP Knowledge Graph Memory → анализ зависимостей компонента
Шаг 2: metadata_project → семантический поиск похожих компонентов
Шаг 3: Выполнение рефакторинга
Шаг 4: MCP Knowledge Graph Memory → обновление связей и наблюдений
Шаг 5: metadata_project → пересоздание YAML метаданных
```

---

#### Практические рекомендации:

**Используй MCP Knowledge Graph Memory для:**
- ✅ Быстрого поиска и анализа компонентов
- ✅ Хранения информации о текущем состоянии
- ✅ Отслеживания прогресса работы
- ✅ Создания связей между компонентами
- ✅ Добавления наблюдений о состоянии

**Используй metadata_project для:**
- ✅ Генерации YAML метаданных из файлов
- ✅ Полного анализа архитектуры (с эмбеддингами)
- ✅ Семантического поиска по смыслу
- ✅ Кластеризации связанных компонентов
- ✅ Глубокого анализа зависимостей

**Синхронизация:**
- ✅ Регулярно обновляй MCP Knowledge Graph Memory на основе изменений в проекте
- ✅ Используй metadata_project для генерации метаданных, затем синхронизируй с MCP
- ✅ При значительных изменениях запускай полное обновление обеих систем

---

## 📋 Примеры использования для DDE системы

### Пример 1: Добавление нового компонента

```python
# 1. Создаю сущность в MCP Knowledge Graph Memory
mcp_knowledge-graph-memory_create_entities(entities=[
    {
        "name": "start_dde_monitoring.py",
        "entityType": "entry_point",
        "aliases": ["DDE Monitoring Starter", "DDE Real-time Monitor"]
    }
])

# 2. Создаю связи
mcp_knowledge-graph-memory_create_relations(relations=[
    {
        "from": "start_dde_monitoring.py",
        "to": "src/services/dde/dde_reader.py",
        "relationType": "starts"
    },
    {
        "from": "start_dde_monitoring.py",
        "to": "test_dde_ngx5.py",
        "relationType": "follows"
    }
])

# 3. Добавляю наблюдения
mcp_knowledge-graph-memory_add_observations(observations=[
    {
        "entityName": "start_dde_monitoring.py",
        "contents": [
            "[2025-11-02] [S:Active] Главная точка входа для запуска DDE мониторинга",
            "[2025-11-02] [S:Active] Поддерживает корректную остановку через Ctrl+C"
        ]
    }
])
```

### Пример 2: Обновление после изменений

```python
# Если компонент изменился, обновляю наблюдения
mcp_knowledge-graph-memory_add_observations(observations=[
    {
        "entityName": "test_dde_ngx5.py",
        "contents": [
            "[2025-11-02] [S:Active] Тест выполнен успешно: 5/6 тестов пройдено",
            "[2025-11-02] [S:Active] Найдено 95 записей NGX5"
        ]
    }
])

# Если нужно удалить устаревшее наблюдение
mcp_knowledge-graph-memory_delete_observations(deletions=[
    {
        "entityName": "test_dde_ngx5.py",
        "observations": [
            "[2025-11-02] [S:Active] Тест выполнен: 3/6 тестов пройдено (50%)"  # Устарело
        ]
    }
])
```

### Пример 3: Использование обеих систем вместе

```python
# 1. MCP Knowledge Graph Memory - поиск связанных компонентов
related = mcp_knowledge-graph-memory_find_related_nodes(
    node_name="test_dde_ngx5.py"
)

# 2. metadata_project - семантический поиск похожих компонентов
similar = metadata_project_search_similar(query="DDE testing")

# 3. Сопоставление результатов и принятие решений
# Используя информацию из обеих систем
```

---

## 💡 Как задавать промпты и настраивать правила для максимальной пользы

### 📝 Формулировка эффективных промптов

#### 1. Контекстный промпт с использованием KGM

**✅ ХОРОШИЙ пример:**
```
Проанализируй через KGM граф связи между DDE Reader и Redis Publisher.
Используй MCP Knowledge Graph Memory для поиска всех компонентов, 
которые зависят от dde_reader.py. Затем проверь, что все связи актуальны.
```

**❌ ПЛОХОЙ пример:**
```
Проверь dde_reader
```

**Почему:**
- ✅ Указывает конкретные инструменты (KGM, MCP)
- ✅ Определяет цель (анализ связей)
- ✅ Уточняет ожидаемый результат

---

#### 2. Промпт с использованием обеих систем

**✅ ХОРОШИЙ пример:**
```
Создай новый компонент для обработки DDE данных:
1. Используй metadata_project для генерации YAML метаданных
2. Добавь сущность в MCP Knowledge Graph Memory
3. Создай связи с существующими компонентами DDE системы
4. Обнови документацию
```

**❌ ПЛОХОЙ пример:**
```
Создай обработчик DDE
```

**Почему:**
- ✅ Четкий пошаговый план
- ✅ Указывает, какие инструменты использовать
- ✅ Включает обновление документации

---

#### 3. Промпт с указанием правил

**✅ ХОРОШИЙ пример:**
```
Согласно .cursorrules.json и локальным правилам .cursor/rules:
- Используй metadata_project/.meta/tools/yaml_generator.py для генерации YAML
- Используй metadata_project/templates/python_template.yaml как шаблон
- Добавь метаданные с текущим временем UTC+9
- Обнови MCP Knowledge Graph Memory с новой информацией
```

**❌ ПЛОХОЙ пример:**
```
Создай YAML для нового файла
```

**Почему:**
- ✅ Ссылается на конкретные правила
- ✅ Указывает точные пути к инструментам
- ✅ Уточняет требования к метаданным

---

### ⚙️ Настройка правил для текущего чата

#### 1. Использование @ упоминаний

**Пример:**
```
@DDE_METADATA_PROJECT_EXPLANATION_2025-11-02.md добавь информацию о...
@.cursorrules.json следуй правилам из этого файла
@.cursor/rules/kgm_system.md используй рекомендации из этого правила
```

**Зачем:**
- ✅ Я сразу получаю контекст из указанных файлов
- ✅ Понимаю, на какие правила опираться
- ✅ Вижу структуру документа, который нужно обновить

---

#### 2. Явное указание инструментов

**Пример:**
```
Можешь использовать KGM граф и поиск по нему.
Тебе доступны инструменты MCP:
- knowledge-graph-memory
- filesystem
Используй их для анализа и работы с файлами.
```

**Зачем:**
- ✅ Я знаю, какие MCP инструменты доступны
- ✅ Понимаю, что нужно использовать KGM для анализа
- ✅ Могу выбрать правильные инструменты для задачи

---

#### 3. Указание приоритетов

**Пример:**
```
ПРИОРИТЕТ #1: Запустить DDE Reader в реальном времени
ПРИОРИТЕТ #2: Протестировать Bokeh UI
ПРИОРИТЕТ #3: Интегрировать с Order Executor

Делай в соответствии с @.cursorrules.json и локальными правилами .cursor\rules
```

**Зачем:**
- ✅ Понимаю порядок выполнения задач
- ✅ Могу планировать работу эффективно
- ✅ Следую установленным правилам

---

### 🎯 Рекомендации по написанию промптов

#### Структура эффективного промпта:

```markdown
1. КОНТЕКСТ (что нужно сделать)
   - Используй @ упоминания для файлов
   - Укажи связанные компоненты
   - Ссылайся на документацию

2. ИНСТРУМЕНТЫ (что использовать)
   - MCP инструменты (knowledge-graph-memory, filesystem)
   - KGM граф для анализа
   - metadata_project для генерации YAML

3. ПРАВИЛА (как делать)
   - @.cursorrules.json - главные правила
   - @.cursor/rules/ - локальные правила
   - Следовать шаблонам из docs/13_TEMPLATES/

4. РЕЗУЛЬТАТ (что ожидается)
   - Конкретные файлы для создания/обновления
   - Документация для обновления
   - Обновление KGM графа
```

---

### 📋 Примеры промптов для разных задач

#### Пример 1: Создание нового компонента

```
Создай новый модуль для обработки DDE данных:

КОНТЕКСТ:
- @src/services/dde/dde_reader.py - существующий DDE Reader
- @docs/DDE_NGX5_TEST_RESULTS_UPDATE_2025-11-02.md - результаты тестов

ИНСТРУМЕНТЫ:
- Используй KGM граф для поиска связанных компонентов
- Используй metadata_project для генерации YAML метаданных

ПРАВИЛА:
- Следуй @.cursorrules.json
- Используй metadata_project/.meta/tools/yaml_generator.py
- Используй metadata_project/templates/python_template.yaml

РЕЗУЛЬТАТ:
- Новый модуль с метаданными
- Обновление KGM графа с новой сущностью
- Обновление документации
```

---

#### Пример 2: Анализ архитектуры

```
Проанализируй архитектуру DDE системы:

КОНТЕКСТ:
- @docs/DDE_NEXT_STEPS_EXECUTION_2025-11-02.md - план выполнения
- Все компоненты DDE системы

ИНСТРУМЕНТЫ:
- MCP Knowledge Graph Memory для чтения графа
- metadata_project для семантического поиска
- KGM для анализа связей

ПРАВИЛА:
- Используй оба источника данных (MCP и metadata_project)
- Сопоставь результаты
- Предложи рекомендации на основе полной картины

РЕЗУЛЬТАТ:
- Анализ текущей архитектуры
- Выявление недостающих связей
- Рекомендации по улучшению
```

---

#### Пример 3: Обновление документации

```
Обнови документацию о DDE системе:

КОНТЕКСТ:
- @docs/DDE_METADATA_PROJECT_EXPLANATION_2025-11-02.md - текущий документ
- Изменения в DDE системе

ИНСТРУМЕНТЫ:
- KGM граф для поиска связанных документов
- MCP filesystem для чтения файлов

ПРАВИЛА:
- Следуй шаблонам из docs/13_TEMPLATES/
- Добавь метаданные с текущим временем UTC+9
- Обнови "Последнее редактирование"

РЕЗУЛЬТАТ:
- Обновленный документ с актуальной информацией
- Обновленные метаданные
- Обновление KGM графа
```

---

### 🛠️ Настройка правил в .cursorrules.json

#### Что можно настроить:

**1. Приоритеты использования инструментов:**
```json
"tool_selection_strategy": {
  "for_analysis": "codebase_search + grep + kgm_semantic_search",
  "for_semantic_search": "kgm_semantic_search.semantic_search",
  "for_kgm_analysis": "knowledge-graph-memory + kgm_semantic_search"
}
```

**2. Автоматическое применение правил:**
```json
"module_rules": {
  "location": ".cursor/rules/",
  "auto_apply": true,
  "pattern_based": "fileMatch паттерны применяются автоматически"
}
```

**3. Критические ограничения:**
```json
"critical_constraints": [
  "НЕ удаляй файлы без явного подтверждения",
  "НЕ меняй файлы в папке 14_SECRETS/",
  "ВСЕГДА используй mcp_filesystem для работы с файлами"
]
```

---

### 🎓 Лучшие практики для пользователя

#### 1. Всегда указывай контекст:
```
❌ Плохо: "Добавь функцию"
✅ Хорошо: "@dde_reader.py добавь функцию чтения нового типа данных, 
           используй существующий паттерн из read_market_data_file"
```

#### 2. Используй @ упоминания:
```
❌ Плохо: "Создай тест"
✅ Хорошо: "@test_dde_ngx5.py создай аналогичный тест для нового компонента,
           следуй структуре существующего теста"
```

#### 3. Указывай правила:
```
❌ Плохо: "Обнови документацию"
✅ Хорошо: "Согласно @.cursorrules.json и локальным правилам .cursor/rules,
           обнови документацию с метаданными UTC+9"
```

#### 4. Используй KGM для анализа:
```
❌ Плохо: "Найди зависимости"
✅ Хорошо: "Используй MCP Knowledge Graph Memory для поиска всех компонентов,
           которые зависят от dde_reader.py. Затем используй metadata_project
           для семантического поиска похожих компонентов"
```

#### 5. Указывай ожидаемый результат:
```
❌ Плохо: "Сделай интеграцию"
✅ Хорошо: "Интегрируй DDE с Order Executor:
           1. Настрой подписку на Redis каналы
           2. Реализуй обработку новых сделок
           3. Обнови документацию
           4. Добавь информацию в KGM граф"
```

---

### 📊 Чеклист эффективного промпта

**Перед отправкой промпта проверь:**

- [ ] ✅ Указан контекст через @ упоминания
- [ ] ✅ Указаны инструменты (MCP, KGM, metadata_project)
- [ ] ✅ Указаны правила (@.cursorrules.json, .cursor/rules)
- [ ] ✅ Четко описан ожидаемый результат
- [ ] ✅ Указан приоритет (если задач несколько)
- [ ] ✅ Указаны связанные компоненты
- [ ] ✅ Указана необходимость обновления документации

---

### 🔄 Интеграция с текущей работой

**Для DDE системы рекомендую:**

1. **Всегда начинать с KGM анализа:**
   ```
   Используй MCP Knowledge Graph Memory для поиска всех компонентов DDE системы
   и их связей. Затем используй metadata_project для семантического поиска.
   ```

2. **Всегда обновлять KGM после изменений:**
   ```
   После создания/изменения компонента:
   - Добавь/обнови сущность в MCP Knowledge Graph Memory
   - Создай/обнови связи с существующими компонентами
   - Добавь наблюдения о текущем состоянии
   ```

3. **Всегда использовать обе системы для анализа:**
   ```
   Для полного понимания архитектуры:
   - MCP Knowledge Graph Memory → быстрый поиск и связи
   - metadata_project → глубокий анализ с эмбеддингами
   - Сопоставление результатов → полная картина
   ```

---

**Последнее редактирование**: 2025-11-02 14:20:00 UTC+9
**Редактировал**: KURSOR
**Версия**: 2.1