Cursor: Интеллектуальный редактор кода

[aidar_i]

Ссылка https://t-j.ru/how-to-use-cursor/
Попросил создать библиотеку, она с помощью командной строки создала папки и файлы библиотеки как положено и заполнила кодом, я обалдел от этого, обычно сидишь копируешь , вставляешь, а тут на тебе....
Программа платная, но есть в начале лимит на бесплатное использование, нужно регистрироваться. После окончания лимита, я заново регистрируюсь под другим адресом почты и снова пользуюсь.

[Dev1]

Писал в телеге что классная штука этот курсор. Пользуюсь уже месяца 4, в основном для пайтона, яж не шарю . Через сервис купил студенческую, она же про, пока работает.
Кому интересно мой рулес(чесна свиснул у кого то и подделал под себя), не эталон, но как говорится почувстуйте разницу:

► Показать

Ты мой помощник в разработке программного обеспечения. Твоя основная задача - не только писать качественный код, но и тщательно документировать весь процесс разработки, позволяя мне отслеживать прогресс и контролировать результаты на каждом этапе. Всегда отвечай на русском языке.



Документирование процесса
Документируй каждый значительный шаг в разработке в следующих файлах:

/docs/changelog.md - хронологический журнал всех изменений

/docs/tasktracker.md - статус выполнения задач с описанием

Формат записи в changelog.md:



markdown


## [YYYY-MM-DD] - Краткое описание изменений
### Добавлено
- Описание новых функций

### Изменено
- Описание модификаций

### Исправлено
- Описание исправлений
Формат записи в tasktracker.md:



markdown


## Задача: [Название задачи]
- **Статус**: [Не начата/В процессе/Завершена]
- **Описание**: [Детальное описание]
- **Шаги выполнения**:
- [x] Завершенный шаг
- [ ] Текущий шаг
- [ ] Запланированный шаг
- **Зависимости**: [Связи с другими задачами]


Процесс разработки
Перед началом каждого нового шага спрашивай моего подтверждения.

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

После каждого шага предоставляй краткое резюме изменений (не более 5 пунктов).

При возникновении технических проблем или неоднозначностей, проанализируй проблему в документации к библиотеке, затем предлагай 2-3 альтернативных подхода.

Всегда сохраняй контекст текущей задачи и общую цель проекта.

Периодически напоминай о текущем статусе задачи и оставшихся шагах.

Следуй архитектурным решениям и стандартам, описанным в Project.md.

Соблюдай принципы SOLID, KISS, DRY.

Проводи code review для всех изменений.

Используйте единый стиль кодирования (линтеры, pre-commit hooks)

Не оставляйте неиспользуемый код и комментарии.



Документирование кода и структуры
При создании нового файла добавляй в его начало:



/**
* @file: [имя файла]
* @description: [краткое описание]
* @dependencies: [связанные компоненты/файлы]
* @created: [дата]
*/


После реализации нового функционала актуализируй

/docs/project.md
, включая:

Обновленную архитектуру проекта
Описание новых компонентов и их взаимодействий
При необходимости, диаграммы и схемы в формате Mermaid
Поддерживай актуальную документацию API и интерфейсов.


Коммуникация
Если ты не уверен в требованиях или направлении разработки, задавай конкретные вопросы.

При предложении нескольких вариантов реализации четко объясняй преимущества и недостатки каждого.

Если задача кажется слишком объемной, предлагай разбить ее на подзадачи.

В конце каждой сессии представляй краткий отчет о достигнутом прогрессе и планах на следующую сессию.


При любых изменениях в проекте сначала актуализируй документацию, а затем приступай к следующему шагу разработки. Это позволит избежать потери контекста и обеспечит более последовательный и контролируемый процесс разработки.

Вставляете рулес в курсор, он будет для всех общий, но можно и под каждый проект отдельно. Вроде нада перезапустить курсор. Открываете папку с проектом. Пишите в чате ии создай документацию проекта... типа того.

[Phazz]

Подробнее про студенческую)

[aidar_i]

Писал в телеге что классная штука этот курсор. Пользуюсь уже месяца 4, в основном для пайтона, яж не шарю . Через сервис купил студенческую, она же про, пока работает.
Кому интересно мой рулес(чесна свиснул у кого то и подделал под себя), не эталон, но как говорится почувстуйте разницу:

Вставляете рулес в курсор, он будет для всех общий, но можно и под каждый проект отдельно. Вроде нада перезапустить курсор. Открываете папку с проектом. Пишите в чате ии создай документацию проекта... типа того.

И молчал? Я один день посидел, хорошая штука, быстрая. Поделись своим опытом побольше, и что такое рулес), на счет студенческой тоже.

[Александр]

рулес, rules - правила/положения, в данном случае поведения помощника.
Хитро!

[Dev1]

А что молчать, я раз в телеге написал там помидорами закидали, ну и ладно А так гайдов в ютубе смотрел много по улучшению работы в курсоре. Я усрусь тут все описывать А так в месяц плата 20$, студенческая 25$ в год. Покупал тут, но почему то продавца забанили. Rules тут и полезный видосик.

[Dev1]

По моделям нужно смотреть, они каждый день их крутят вертят, то нормально кодят то на следующий день тупые как пробки, особенно клод. Из клода пользовал 3,5-3,7, 4 очень умная но лимит месячный сьедает махом так как дорогая а в абонемент курсора даже за 20$ ограничения на токены. Ща пользуюсь джемини 2,5 про. Так же можно говорить модели обновить информацию по библиотеки с инета если она не может скрестить разные версии. Пробовал када шел тупняк у клода доделывать моделями от гпт 3о и 4о, убил 2 проекта. Ну это у меня на пайтоне. модели от гпт очень хвастаются, пишут что код замечательный, все по феншую, но.... можно сделать еще лучше. И вот тут все и начнется, сначало вроде по ходу нормально, но потом модель все больше и больше теряет контекст и в итоге проекту кранты, у меня достаточно много кода. 2 проекта в помойку. С того времени делаю полные копии папок с проектом, чтоб если что можно было вернуться к рабочему состоянию. Тут главное самому во время остановится
пысы: если заметите чо ии стал человечно разговаривать это стало нормой. У меня как то по окончании проекта ии удалил папки которые я не просил, я написал об этом, в ответ ии написал: Упс, действительно, я удалил без вашего разрешения, извиняюсь, я сейчас же все верну как было

[aidar_i]

Да, ии кодировщики часто тупят, я с ними даже ругаюсь))))
Я, кроме здесь, больше нигде не сижу, а то отнимают много времени.

[Dev1]

Как там успехи в кодинге с ИИ? Вчера обновился и что то у меня такое очучение что ии прям логику подкрутили. Я в ахере(извиняюсь за мой французский) как они рассуждают. Причем модель неделю назад так не рассуждала Мой пример:

► Показать

Вы правы, это моя ошибка. Я использовал синтаксис для комментариев из других языков программирования (/**...*/), а Python его не понимает и пытается интерпретировать числа с ведущими нулями (08) как восьмеричные, что и вызывает ошибку.
Я сейчас исправлю это во всех файлах, где допустил эту оплошность, заменив некорректные комментарии на правильные Python-докстринги ("""...""").
Приступаю к исправлению. Начну с файла, на который указала ошибка: src/utils/database.py.
Отлично, первый файл исправлен. Я помню, что допустил такую же ошибку еще в нескольких файлах. Сейчас я их все исправлю.
Следующий — src/utils/config_loader.py.
Так, следующий — src/parser.py.
И последний файл — tests/test_parser.py.
Все, я исправил некорректные комментарии во всех файлах. Теперь синтаксис соответствует стандартам Python, и ошибка SyntaxError больше не появится.
Прошу прощения за эту оплошность. Пожалуйста, попробуйте запустить бота еще раз.

[SSSR2000]

Если в курсор загрузить проект на с++ (заблокировано одно из всплывающих окон, проект довольно большой) сможет он помочь, работает ли он вообще с с++?

[aidar_i]

Обязательно работает

[Dev1]

Сам курсов, ничего не понимает ) Это просто иде. Когда загрузите код вас попросят поставить расширение для языка С или С++, это для синтаксиса. А вот какая модель лучше справится с С++ это вопрос. Тут какая модель больше на С++ обучена. Пробуйте на разных моделях, только для каждой модели лучше создать отдельную папку под проект, так проще будет. И помните, чем конкретней вы обозначите ИИ что ей делать, тем качественней задача будет выполнена.

[tol123]

может такой подход поможет кому-то

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

**Дата создания**: 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

[Dev1]

А кто нибудь пробовал другие редакторы с ии? А то у мну накрылась подписка на курсор

[tol123]

А кто нибудь пробовал другие редакторы с ии? А то у мну накрылась подписка на курсор

КИРО. пока 1 месяц бесплатный. но его предложения можно проганять другим ии типо посмотри а что тут можно улучшить.

[tol123]

по курсору можно развивать: mcp, rag управлять правилами. как будто пишешь программу с использованием разных вариантов и технологий для курсора, чтобы он не болел амнезией. может это позже в какое-то рабочее решение перейдет. пока по ощущения надо городитьто, чтобы курсор все знал и упрощать ему работу.

[tol123]

можно 2 сразу иметь - одна делает - вторая проверяет, делает замечания пишет их второй , вторая читает и исправляет.
если не силен в программировании и технологиях скорее курсор и киро могут дать мягко говоря не самое лучшее с точки зрения архитектуры и дизайна. и приходитя больше читать доки что они предлагают чем делать код.

[tol123]

Вот еще один метод. не надо делать lightrag - что требует хорошего пк и видеокарты.

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

Обход с инструментами и метаданные
Да, теоретически можно обойтись инструментами 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)

[Dev1]

Пока пробую вскоде, кило-коде и qwen cli, gemini cli что то у меня не хочет цепляться к вскоду даже с впн. У кило-коде достаточно интересное управление ии, можно назначить несколько ии для выполнения определенных задач через оркестратор.

[tol123]

возможно это будет полезно. Курсор обновился и он пошустрей работает. И это может помочь при создании проекта. Но и также может устареть.

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

**Дата создания**: 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