Squashed commit message
Some checks failed
Telegram Mini App Shop Builder / Compute version metadata (push) Has been cancelled
Telegram Mini App Shop Builder / Run Frontend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run Backend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run PHP_CodeSniffer (push) Has been cancelled
Telegram Mini App Shop Builder / Build module. (push) Has been cancelled
Telegram Mini App Shop Builder / release (push) Has been cancelled
Some checks failed
Telegram Mini App Shop Builder / Compute version metadata (push) Has been cancelled
Telegram Mini App Shop Builder / Run Frontend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run Backend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run PHP_CodeSniffer (push) Has been cancelled
Telegram Mini App Shop Builder / Build module. (push) Has been cancelled
Telegram Mini App Shop Builder / release (push) Has been cancelled
This commit is contained in:
128
.cursor/prompts/api-generation.md
Normal file
128
.cursor/prompts/api-generation.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Промпты для генерации API
|
||||
|
||||
## Создание нового API endpoint
|
||||
|
||||
```
|
||||
Создай новый API endpoint [ENDPOINT_NAME] для [DESCRIPTION]:
|
||||
|
||||
1. Handler в [HANDLER_PATH]:
|
||||
- Метод handle() принимает Request
|
||||
- Валидация входных данных
|
||||
- Использование Service для бизнес-логики
|
||||
- Возврат JsonResponse с правильной структурой
|
||||
- Обработка ошибок с логированием
|
||||
|
||||
2. Service в [SERVICE_PATH]:
|
||||
- Бизнес-логика
|
||||
- Работа с Model
|
||||
- Валидация данных
|
||||
- Обработка исключений
|
||||
|
||||
3. Model в [MODEL_PATH] (если нужен):
|
||||
- Методы для работы с БД
|
||||
- Использование Query Builder
|
||||
- Типизация методов
|
||||
|
||||
4. Route в routes.php:
|
||||
- Добавь маршрут с правильным именем
|
||||
|
||||
5. Миграция (если нужна новая таблица):
|
||||
- Создай миграцию в database/migrations/
|
||||
- Используй фиксированный префикс megapay_
|
||||
- Добавь индексы где необходимо
|
||||
|
||||
Следуй архитектуре MVC-L проекта и используй существующие паттерны.
|
||||
```
|
||||
|
||||
## Создание CRUD API
|
||||
|
||||
```
|
||||
Создай полный CRUD API для сущности [ENTITY_NAME]:
|
||||
|
||||
1. Handler с методами:
|
||||
- list() - список с пагинацией и фильтрацией
|
||||
- get() - получение одной записи
|
||||
- create() - создание
|
||||
- update() - обновление
|
||||
- delete() - удаление
|
||||
|
||||
2. Service с бизнес-логикой для всех операций
|
||||
|
||||
3. Model с методами:
|
||||
- findAll() - список
|
||||
- findById() - по ID
|
||||
- create() - создание
|
||||
- update() - обновление
|
||||
- delete() - удаление
|
||||
|
||||
4. DTO для валидации данных
|
||||
|
||||
5. Миграция для таблицы [TABLE_NAME]
|
||||
|
||||
6. Routes для всех endpoints
|
||||
|
||||
Используй серверную пагинацию, фильтрацию и сортировку для list().
|
||||
```
|
||||
|
||||
## Создание Admin API endpoint
|
||||
|
||||
```
|
||||
Создай Admin API endpoint [ENDPOINT_NAME] в bastion/Handlers/:
|
||||
|
||||
1. Handler в bastion/Handlers/[HANDLER_NAME].php:
|
||||
- Используй Request для получения параметров
|
||||
- Валидация данных
|
||||
- Работа через Service
|
||||
- Возврат JsonResponse с структурой { data: { data: [...], totalRecords: ... } }
|
||||
- Обработка ошибок
|
||||
|
||||
2. Service в bastion/Services/ (если нужен):
|
||||
- Бизнес-логика для админки
|
||||
- Работа с Models
|
||||
|
||||
3. Route в bastion/routes.php
|
||||
|
||||
4. Frontend компонент (если нужен UI):
|
||||
- Vue компонент в frontend/admin/src/views/
|
||||
- Используй PrimeVue компоненты
|
||||
- Серверная пагинация/фильтрация
|
||||
- Обработка ошибок с toast уведомлениями
|
||||
|
||||
Следуй существующим паттернам проекта.
|
||||
```
|
||||
|
||||
## Создание Frontend API клиента
|
||||
|
||||
```
|
||||
Создай функцию для работы с API endpoint [ENDPOINT_NAME]:
|
||||
|
||||
1. В frontend/[admin|spa]/src/utils/http.js:
|
||||
- Функция api[Method] для вызова endpoint
|
||||
- Правильная обработка ошибок
|
||||
- Возврат структурированного ответа
|
||||
|
||||
2. Использование:
|
||||
- В компонентах через import
|
||||
- Обработка loading states
|
||||
- Toast уведомления для ошибок
|
||||
|
||||
Следуй существующим паттернам в http.js.
|
||||
```
|
||||
|
||||
## Создание миграции
|
||||
|
||||
```
|
||||
Создай миграцию для таблицы [TABLE_NAME]:
|
||||
|
||||
1. Файл: database/migrations/[TIMESTAMP]_[DESCRIPTION].php
|
||||
2. Используй фиксированный префикс megapay_ для таблицы
|
||||
3. Добавь все необходимые поля с правильными типами
|
||||
4. Добавь индексы для часто используемых полей
|
||||
5. Используй utf8mb4_unicode_ci collation
|
||||
6. Используй InnoDB engine
|
||||
7. Добавь created_at и updated_at timestamps
|
||||
8. Не создавай foreign keys (используй только индексы)
|
||||
|
||||
Следуй структуре существующих миграций.
|
||||
```
|
||||
|
||||
106
.cursor/prompts/changelog.md
Normal file
106
.cursor/prompts/changelog.md
Normal file
@@ -0,0 +1,106 @@
|
||||
# Правила оформления Changelog для документации
|
||||
|
||||
## Общие требования
|
||||
|
||||
- **Формат**: Markdown
|
||||
- **Структура**: Одна версия = одна страница
|
||||
- **Стиль**: Профессиональный, лаконичный, без маркетинговых лозунгов
|
||||
- **Язык**: Русский
|
||||
- **Целевая аудитория**: Разработчики и владельцы магазинов
|
||||
- **Содержимое**: Только ключевые изменения, без лишних технических деталей
|
||||
|
||||
## Структура страницы
|
||||
|
||||
### Вводный абзац
|
||||
- Краткое описание релиза (1-2 предложения)
|
||||
- Дополнить 1-2 предложениями о ключевых изменениях
|
||||
- Упоминать основные фичи и улучшения
|
||||
|
||||
### Разделы (строго в этом порядке)
|
||||
|
||||
1. **🚀 Добавлено** - новые функции и возможности
|
||||
2. **✨ Улучшено** - улучшения существующих функций
|
||||
3. **🐞 Исправлено** - исправленные ошибки
|
||||
4. **⚠️ Несовместимые изменения** - изменения без обратной совместимости
|
||||
5. **🔧 Технические изменения** - технические изменения (отдельный раздел)
|
||||
|
||||
### Правила для разделов
|
||||
|
||||
- Раздел **НЕ** добавлять, если в нём нет пунктов
|
||||
- Использовать маркдаун-списки, без нумерации
|
||||
- Не добавлять ссылок, если они явно не указаны
|
||||
- Не добавлять лишних пояснений, выводов и заключений
|
||||
- Выводить только содержимое Markdown-файла, без комментариев
|
||||
|
||||
## Разделение изменений
|
||||
|
||||
### Бизнес-логика и процессы
|
||||
Разделы "Добавлено", "Улучшено", "Исправлено", "Несовместимые изменения" содержат только изменения, связанные с:
|
||||
- Бизнес-процессами магазина
|
||||
- Пользовательским опытом
|
||||
- Функциональностью для владельцев магазинов
|
||||
- Продающими фичами
|
||||
|
||||
### Технические изменения
|
||||
Все технические изменения выносятся в отдельный раздел **🔧 Технические изменения**:
|
||||
- Без подразделов, всё в одном списке
|
||||
- Только самые ключевые технические изменения
|
||||
- Не расписывать детали, которые не интересны пользователю
|
||||
|
||||
## Стиль написания
|
||||
|
||||
### Терминология
|
||||
- Английские термины писать по-английски (например: "navbar", а не "навбар")
|
||||
- Избегать технических терминов в бизнес-разделах (например: "customer_id" → "автоматическое связывание покупателей")
|
||||
|
||||
### Описания
|
||||
|
||||
**Для ключевых продающих фич:**
|
||||
- Давать подробное описание с деталями
|
||||
- Указывать возможности и преимущества
|
||||
- Подчеркивать ценность для пользователя
|
||||
|
||||
**Для технических изменений:**
|
||||
- Кратко, только ключевое
|
||||
- Без лишних деталей
|
||||
|
||||
**Для обычных функций:**
|
||||
- Лаконично, но информативно
|
||||
- Фокус на пользе для пользователя
|
||||
|
||||
## Порядок размещения
|
||||
|
||||
### В разделе "Добавлено"
|
||||
Ключевые продающие фичи размещать **первыми**:
|
||||
1. Система конфигурации главной страницы через блоки
|
||||
2. Конструктор форм на базе FormKit
|
||||
3. Интеграция с Яндекс.Метрикой
|
||||
4. Политика конфиденциальности
|
||||
5. Поддержка купонов и подарочных сертификатов
|
||||
6. Остальные функции
|
||||
|
||||
## Примеры правильных формулировок
|
||||
|
||||
### ✅ Хорошо
|
||||
- "Автоматическое связывание покупателей Telegram с покупателями OpenCart: система автоматически находит и связывает покупателей из Telegram-магазина с существующими покупателями в OpenCart по email или номеру телефона, создавая единую базу клиентов"
|
||||
|
||||
### ❌ Плохо
|
||||
- "Сохранение customer_id вместе с заказом для связи с клиентами OpenCart: автоматическая связь заказов из Telegram с покупателями в OpenCart, единая база клиентов"
|
||||
|
||||
### ✅ Хорошо
|
||||
- "Navbar с логотипом и названием приложения"
|
||||
|
||||
### ❌ Плохо
|
||||
- "Навбар с логотипом и названием приложения"
|
||||
|
||||
## Что не включать
|
||||
|
||||
- Внутренние детали разработки (тесты, статический анализ, обфускация)
|
||||
- Технические детали, не интересные пользователям
|
||||
- Избыточные технические описания
|
||||
- Маркетинговые лозунги и призывы
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
62
.cursor/prompts/documentation.md
Normal file
62
.cursor/prompts/documentation.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Промпты для документирования
|
||||
|
||||
## Документирование класса
|
||||
|
||||
```
|
||||
Добавь PHPDoc документацию для класса [CLASS_NAME]:
|
||||
1. Описание класса и его назначения
|
||||
2. @package тег
|
||||
3. @author тег
|
||||
4. Документация для всех публичных методов
|
||||
5. Документация для публичных свойств
|
||||
6. Примеры использования где уместно
|
||||
```
|
||||
|
||||
## Документирование метода
|
||||
|
||||
```
|
||||
Добавь PHPDoc для метода [METHOD_NAME]:
|
||||
1. Описание метода
|
||||
2. @param для всех параметров с типами
|
||||
3. @return с типом возвращаемого значения
|
||||
4. @throws для всех исключений
|
||||
5. Примеры использования если сложная логика
|
||||
```
|
||||
|
||||
## Документирование API endpoint
|
||||
|
||||
```
|
||||
Создай документацию для API endpoint [ENDPOINT_NAME]:
|
||||
1. Описание назначения
|
||||
2. HTTP метод и путь
|
||||
3. Параметры запроса (query/body)
|
||||
4. Формат ответа (JSON структура)
|
||||
5. Коды ошибок
|
||||
6. Примеры запросов/ответов
|
||||
7. Требования к авторизации
|
||||
```
|
||||
|
||||
## Документирование Vue компонента
|
||||
|
||||
```
|
||||
Добавь документацию для Vue компонента [COMPONENT_NAME]:
|
||||
1. Описание компонента
|
||||
2. Props с типами и описаниями
|
||||
3. Emits с описаниями
|
||||
4. Slots если есть
|
||||
5. Примеры использования
|
||||
6. Зависимости от других компонентов
|
||||
```
|
||||
|
||||
## Создание README
|
||||
|
||||
```
|
||||
Создай README.md для [MODULE/COMPONENT]:
|
||||
1. Описание назначения
|
||||
2. Установка/настройка
|
||||
3. Использование с примерами
|
||||
4. API документация
|
||||
5. Конфигурация
|
||||
6. Troubleshooting
|
||||
```
|
||||
|
||||
88
.cursor/prompts/refactoring.md
Normal file
88
.cursor/prompts/refactoring.md
Normal file
@@ -0,0 +1,88 @@
|
||||
# Промпты для рефакторинга
|
||||
|
||||
## Общий рефакторинг
|
||||
|
||||
```
|
||||
Проанализируй код в файле [FILE_PATH] и выполни рефакторинг:
|
||||
1. Убери дублирование кода
|
||||
2. Улучши читаемость
|
||||
3. Примени принципы SOLID
|
||||
4. Добавь обработку ошибок где необходимо
|
||||
5. Улучши типизацию
|
||||
6. Добавь документацию для публичных методов
|
||||
7. Убедись что код следует архитектуре MVC-L проекта
|
||||
8. Используй существующие утилиты и сервисы проекта вместо создания новых
|
||||
```
|
||||
|
||||
## Рефакторинг Handler
|
||||
|
||||
```
|
||||
Рефакторинг Handler [HANDLER_NAME]:
|
||||
1. Вынеси бизнес-логику в отдельный Service
|
||||
2. Добавь валидацию входных данных
|
||||
3. Улучши обработку ошибок с логированием
|
||||
4. Используй DTO для передачи данных
|
||||
5. Добавь PHPDoc комментарии
|
||||
6. Убедись что используется Dependency Injection
|
||||
7. Оптимизируй запросы к БД если необходимо
|
||||
```
|
||||
|
||||
## Рефакторинг Model
|
||||
|
||||
```
|
||||
Рефакторинг Model [MODEL_NAME]:
|
||||
1. Убедись что все запросы используют Query Builder
|
||||
2. Добавь методы для частых операций (findBy, findAll, create, update)
|
||||
3. Добавь валидацию данных перед сохранением
|
||||
4. Улучши типизацию методов
|
||||
5. Добавь PHPDoc комментарии
|
||||
6. Используй транзакции для сложных операций
|
||||
```
|
||||
|
||||
## Рефакторинг Vue компонента
|
||||
|
||||
```
|
||||
Рефакторинг Vue компонента [COMPONENT_NAME]:
|
||||
1. Вынеси логику в composable функции
|
||||
2. Улучши типизацию props и emits
|
||||
3. Оптимизируй computed properties
|
||||
4. Добавь обработку ошибок
|
||||
5. Улучши структуру template
|
||||
6. Добавь loading states
|
||||
7. Используй существующие утилиты проекта
|
||||
```
|
||||
|
||||
## Удаление дублирования
|
||||
|
||||
```
|
||||
Найди и устрани дублирование кода в:
|
||||
- [FILE_PATH_1]
|
||||
- [FILE_PATH_2]
|
||||
- [FILE_PATH_3]
|
||||
|
||||
Создай общие утилиты/сервисы где необходимо, следуя архитектуре проекта.
|
||||
```
|
||||
|
||||
## Улучшение производительности
|
||||
|
||||
```
|
||||
Проанализируй производительность кода в [FILE_PATH]:
|
||||
1. Оптимизируй запросы к БД (используй индексы, избегай N+1)
|
||||
2. Добавь кэширование где уместно
|
||||
3. Оптимизируй алгоритмы
|
||||
4. Уменьши количество запросов к API
|
||||
5. Используй ленивую загрузку на фронтенде
|
||||
```
|
||||
|
||||
## Улучшение безопасности
|
||||
|
||||
```
|
||||
Улучши безопасность кода в [FILE_PATH]:
|
||||
1. Добавь валидацию всех входных данных
|
||||
2. Используй prepared statements (Query Builder)
|
||||
3. Добавь CSRF защиту где необходимо
|
||||
4. Валидируй права доступа
|
||||
5. Санитизируй выходные данные
|
||||
6. Добавь rate limiting где необходимо
|
||||
```
|
||||
|
||||
53
.cursor/prompts/testing.md
Normal file
53
.cursor/prompts/testing.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Промпты для тестирования
|
||||
|
||||
## Создание unit теста
|
||||
|
||||
```
|
||||
Создай unit тест для [CLASS_NAME] в tests/Unit/:
|
||||
|
||||
1. Используй PHPUnit
|
||||
2. Покрой все публичные методы
|
||||
3. Тестируй успешные сценарии
|
||||
4. Тестируй обработку ошибок
|
||||
5. Используй моки для зависимостей
|
||||
6. Следуй структуре существующих тестов
|
||||
7. Используй TestCase базовый класс проекта
|
||||
```
|
||||
|
||||
## Создание integration теста
|
||||
|
||||
```
|
||||
Создай integration тест для [FEATURE_NAME] в tests/Integration/:
|
||||
|
||||
1. Тестируй полный flow от запроса до ответа
|
||||
2. Используй тестовую БД
|
||||
3. Очищай данные после тестов
|
||||
4. Тестируй реальные сценарии использования
|
||||
5. Проверяй валидацию данных
|
||||
6. Проверяй обработку ошибок
|
||||
```
|
||||
|
||||
## Создание Vue компонент теста
|
||||
|
||||
```
|
||||
Создай тест для Vue компонента [COMPONENT_NAME] в frontend/[admin|spa]/tests/:
|
||||
|
||||
1. Используй Vitest
|
||||
2. Тестируй рендеринг компонента
|
||||
3. Тестируй props
|
||||
4. Тестируй события (emits)
|
||||
5. Тестируй пользовательские взаимодействия
|
||||
6. Используй моки для API вызовов
|
||||
7. Следуй структуре существующих тестов
|
||||
```
|
||||
|
||||
## Покрытие тестами
|
||||
|
||||
```
|
||||
Проанализируй покрытие тестами для [FILE_PATH]:
|
||||
1. Определи какие методы не покрыты тестами
|
||||
2. Создай тесты для критичных методов
|
||||
3. Убедись что тестируются граничные случаи
|
||||
4. Добавь тесты для обработки ошибок
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user