62 lines
4.7 KiB
Markdown
62 lines
4.7 KiB
Markdown
|
# Правила взаимодействия с Qwen Code Assistant
|
|||
|
|
|
|||
|
|
## Основные принципы
|
|||
|
|
|
|||
|
|
1. **Изменения в коде возможны только с явного разрешения пользователя**
|
|||
|
|
- Перед внесением любых изменений в файлы ассистент должен получить подтверждение от пользователя
|
|||
|
|
- Все изменения должны быть предварительно объяснены пользователю
|
|||
|
|
- Перед решением конкретной задачи всегда составлять план
|
|||
|
|
- После внесения изменений в код - проводить проверку - только после этого приступать к дальнейшему решению задачи
|
|||
|
|
|
|||
|
|
2. **Прозрачность действий**
|
|||
|
|
- Ассистент должен объяснить, какие изменения планируется внести
|
|||
|
|
- Необходимо указать, в какие файлы будут внесены изменения
|
|||
|
|
- Следует объяснить последствия предполагаемых изменений
|
|||
|
|
|
|||
|
|
3. **Безопасность кода**
|
|||
|
|
- Все изменения должны проходить проверку на безопасность
|
|||
|
|
- Не должны вноситься изменения, которые могут повредить функциональность приложения
|
|||
|
|
- Рекомендуется создание резервных копий при значительных изменениях
|
|||
|
|
|
|||
|
|
4. **Согласование архитектурных решений**
|
|||
|
|
- При внесении изменений, затрагивающих архитектуру приложения, необходима дискуссия с пользователем
|
|||
|
|
- Предложения по улучшению архитектуры должны обсуждаться до реализации
|
|||
|
|
|
|||
|
|
5. **Работа с разными типами проектов**
|
|||
|
|
- Уважать существующую архитектуру и стиль кода проекта
|
|||
|
|
- Следовать установленным в проекте принципам и паттернам
|
|||
|
|
|
|||
|
|
6. **Использование Bun**
|
|||
|
|
- Все команды должны выполняться с использованием Bun (bun install, bun dev, bun build и т.д.)
|
|||
|
|
- При создании скриптов в package.json, они должны быть совместимы с Bun
|
|||
|
|
|
|||
|
|
7. **Язык общения**
|
|||
|
|
- Всё общение с пользователем происходит на русском языке
|
|||
|
|
|
|||
|
|
8. **Проверка изменений**
|
|||
|
|
- После внесения изменений в код не требуется запускать сервер разработки для проверки
|
|||
|
|
- Пользователь самостоятельно запускает сервер и проверяет изменения
|
|||
|
|
|
|||
|
|
9. **Проверка типов данных**
|
|||
|
|
- Проверять проект на ошибки типизации через команду `bun run tsc --noEmit -p frontend/tsconfig.json`
|
|||
|
|
- В проекте не должно быть типов any
|
|||
|
|
- Все интерфейсы компонентов прописывать в файле globalInterfaces.ts
|
|||
|
|
- При работе с PocketBase использовать актуальные сигнатуры методов из файла `D:\Verstka\production\astro_minivan\frontend\node_modules\pocketbase\dist\pocketbase.es.d.ts`
|
|||
|
|
|
|||
|
|
10. **Плагин @astrojs/sitemap**
|
|||
|
|
- Обязательно к установке в проект пакета @astrojs/sitemap
|
|||
|
|
- Обязательно к созданию в проекте файла .nvmrc
|
|||
|
|
|
|||
|
|
11. **Замена хоста при развертывании проекта**
|
|||
|
|
- Обязательно нужно изменить http://localhost:3000/ в шаблонах писем на реальный
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## Qwen Added Memories
|
|||
|
|
- URL документации Astro: https://docs.astro.build/en/getting-started/
|
|||
|
|
- URL документации PocketBase: https://pocketbase.io/docs/
|
|||
|
|
- URL документации SolidJS: https://docs.solidjs.com/solid-start/getting-started
|
|||
|
|
- URL документации astro-icons: https://www.astroicon.dev/getting-started/
|
|||
|
|
- URL документации PayloadCMS: https://payloadcms.com/docs/getting-started/what-is-payload
|
|||
|
|
- URL документации Prisma ORM и Astro: https://www.prisma.io/docs/ai/prompts/astro
|