chore: update agent rules, skills and workflows

.agent/rules/main.md

@@ -2,45 +2,45 @@
 trigger: always_on
 ---
 
-# Project Context: University Schedule System
+# Контекст проекта: Система расписания университета
 
-## Project Overview
-This project is a university scheduling system website.
-- **Role**: Educational platform for managing schedules.
-- **Language**: Mixed (Java Backend + Web Frontend).
-- **Public URL**: https://magistr.zuev.company
+## Обзор проекта
+Этот проект представляет собой веб-сайт системы управления университетским расписанием.
+- **Роль**: Образовательная платформа для управления расписанием.
+- **Язык**: Смешанный (Java Backend + Web Frontend).
+- **Публичный URL**: https://magistr.zuev.company
 
-## Directory Structure & Responsibilities
-The project follows a specific folder structure. You must adhere to these paths:
+## Структура директорий и обязанности
+Проект следует определенной структуре папок. Вы должны придерживаться этих путей:
 
-- **`backend/`**: Contains the **Java** backend application source code.
-  - When working on API or server logic, focus here.
+- **`backend/`**: Содержит исходный код бэкенд-приложения на **Java**.
+  - При работе с API или серверной логикой фокусируйтесь здесь.
   
-- **`frontend/`**: Contains the frontend source code. Note the strict role separation:
-  - `frontend/admin/`: Code specific to the **Administrator** interface.
-  - `frontend/teacher/`: Code specific to the **Teacher** interface.
-  - `frontend/student/`: Code specific to the **Student** interface.
-  - *Constraint*: Do not mix logic between these folders unless creating a shared utility.
+- **`frontend/`**: Содержит исходный код фронтенда. Обратите внимание на строгое разделение ролей:
+  - `frontend/admin/`: Код, специфичный для интерфейса **Администратора**.
+  - `frontend/teacher/`: Код, специфичный для интерфейса **Преподавателя**.
+  - `frontend/student/`: Код, специфичный для интерфейса **Студента**.
+  - *Ограничение*: Не смешивайте логику между этими папками, если только не создаете общую утилиту.
 
-- **`db/`**: Database configuration and data.
-  - `db/init/init.sql`: The SQL script responsible for **creating and initializing** the database schema (tables, initial data).
+- **`db/`**: Конфигурация и данные базы данных.
+  - `db/init/init.sql`: SQL-скрипт, отвечающий за **создание и инициализацию** схемы базы данных (таблицы, начальные данные).
   
-- **Root Files**:
-  - `compose.yaml`: The Docker Compose configuration. This file defines the services (backend, db, frontend servers) and how they run together.
-  - `.env`: Environment variables. Contains sensitive config (DB passwords, ports, API keys).
+- **Корневые файлы**:
+  - `compose.yaml`: Конфигурация Docker Compose. Этот файл определяет сервисы (бэкенд, БД, фронтенд-серверы) и то, как они работают вместе.
+  - `.env`: Переменные окружения. Содержит конфиденциальные настройки (пароли БД, порты, ключи API).
 
-## External Dependencies (Parent Directory)
-Some infrastructure components are located outside the project root:
+## Внешние зависимости (родительская директория)
+Некоторые компоненты инфраструктуры расположены за пределами корня проекта:
 
-- **`../caddy-proxy/`**: Located one level up relative to the project root.
-  - **Role**: Reverse proxy handling traffic for `magistr.zuev.company`.
-  - **`Caddyfile`**: Configuration for routing and SSL.
-  - **`compose.yaml`**: A separate Docker Compose file specifically for the proxy service.
+- **`../caddy-proxy/`**: Находится на один уровень выше относительно корня проекта.
+  - **Роль**: Реверс-прокси, обрабатывающий трафик для `magistr.zuev.company`.
+  - **`Caddyfile`**: Конфигурация для маршрутизации и SSL.
+  - **`compose.yaml`**: Отдельный файл Docker Compose специально для службы прокси.
 
-## Workflow Guidelines
-1. **Database Changes**: If you need to modify the database schema, you must update `db/init/init.sql` so the changes persist when the container is rebuilt.
-2. **Configuration**: If adding new configuration parameters, add them to `.env` and reference them in `compose.yaml` or the application code.
-3. **Routing/Proxy**: If there are issues with the domain or external access, check the configuration in `../caddy-proxy/Caddyfile`.
+## Рекомендации по рабочему процессу
+1. **Изменения в базе данных**: Если вам нужно изменить схему базы данных, вы должны обновить `db/init/init.sql`, чтобы изменения сохранялись при пересборке контейнера.
+2. **Конфигурация**: Если вы добавляете новые параметры конфигурации, добавьте их в `.env` и сошлитесь на них в `compose.yaml` или коде приложения.
+3. **Маршрутизация/Прокси**: Если возникают проблемы с доменом или внешним доступом, проверьте конфигурацию в `../caddy-proxy/Caddyfile`.
 
-## Language Preference
-- **Always answer in Russian**: This is a strict requirement from the user. All explanations, comments, and interactions must be in Russian unless specifically asked otherwise.
+## Языковые предпочтения
+- **Всегда отвечайте на русском**: Это строгое требование пользователя. Все объяснения, комментарии и взаимодействия должны быть на русском языке, если только не будет специально запрошено иное.

.agent/skills/git-commit-formatter/SKILL.md

@@ -1,30 +1,30 @@
 ---
 name: git-commit-formatter
-description: Formats git commit messages according to Conventional Commits specification. Use this when the user asks to commit changes or write a commit message.
+description: Форматирует сообщения коммитов git в соответствии со спецификацией Conventional Commits. Используйте этот навык, когда пользователь просит закоммитить изменения или написать сообщение к коммиту.
 ---
 
-# Git Commit Formatter Skill
+# Навык форматирования коммитов Git
 
-When writing a git commit message, you MUST follow the Conventional Commits specification.
+При написании сообщения коммита вы ДОЛЖНЫ следовать спецификации Conventional Commits.
 
-## Format
+## Формат
 `<type>[optional scope]: <description>`
 
-## Allowed Types
-- **feat**: A new feature
-- **fix**: A bug fix
-- **docs**: Documentation only changes
-- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
-- **refactor**: A code change that neither fixes a bug nor adds a feature
-- **perf**: A code change that improves performance
-- **test**: Adding missing tests or correcting existing tests
-- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation
+## Допустимые типы
+- **feat**: Новая функциональность
+- **fix**: Исправление ошибки
+- **docs**: Изменения только в документации
+- **style**: Изменения, не влияющие на смысл кода (пробелы, форматирование и т.д.)
+- **refactor**: Изменение кода, которое не исправляет ошибку и не добавляет функциональность
+- **perf**: Изменение кода, повышающее производительность
+- **test**: Добавление недостающих тестов или исправление существующих
+- **chore**: Изменения в процессе сборки или вспомогательных инструментах и библиотеках
 
-## Instructions
-1. Analyze the changes to determine the primary `type`.
-2. Identify the `scope` if applicable (e.g., specific component or file).
-3. Write a concise `description` in imperative mood (e.g., "add feature" not "added feature").
-4. If there are breaking changes, add a footer starting with `BREAKING CHANGE:`.
+## Инструкции
+1. Проанализируйте изменения, чтобы определить основной тип (`type`).
+2. Определите область (`scope`), если это применимо (например, конкретный компонент или файл).
+3. Напишите краткое описание (`description`) в повелительном наклонении (например, "add feature", а не "added feature").
+4. Если есть критические изменения, добавьте подвал, начинающийся с `BREAKING CHANGE:`.
 
-## Example
+## Пример
 `feat(auth): implement login with google`

.agent/skills/git-push/SKILL.md

@@ -1,41 +1,41 @@
-# Git Push & Format Skill
+# Навык Git Push и форматирования
 
-## Description
-Formats git commit messages according to Conventional Commits specification and pushes changes to the remote repository. Use this when the user asks to commit changes, save progress, or upload code.
+## Описание
+Форматирует сообщения коммитов git в соответствии со спецификацией Conventional Commits и отправляет изменения в удаленный репозиторий. Используйте этот навык, когда пользователь просит закоммитить изменения, сохранить прогресс или отправить код.
 
-## Triggers
-- "Запушь изменения" (Push changes)
-- "Сделай коммит" (Make a commit)
-- "Сохрани в гит" (Save to git)
-- "Сделай пуш" (Make a push)
-- "Запушь" (Push)
+## Триггеры
+- "Запушь изменения"
+- "Сделай коммит"
+- "Сохрани в гит"
+- "Сделай пуш"
+- "Запушь"
 
-## Format (Conventional Commits)
-When writing a git commit message, you MUST follow this format:
+## Формат (Conventional Commits)
+При написании сообщения коммита вы ДОЛЖНЫ следовать этому формату:
 `<type>[optional scope]: <description>`
 
-### Allowed Types
-- **feat**: A new feature
-- **fix**: A bug fix
-- **docs**: Documentation only changes
-- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
-- **refactor**: A code change that neither fixes a bug nor adds a feature
-- **perf**: A code change that improves performance
-- **test**: Adding missing tests or correcting existing tests
-- **chore**: Changes to the build process or auxiliary tools and libraries
+### Допустимые типы
+- **feat**: Новая функциональность
+- **fix**: Исправление ошибки
+- **docs**: Изменения только в документации
+- **style**: Изменения, не влияющие на смысл кода (пробелы, форматирование и т.д.)
+- **refactor**: Изменение кода, которое не исправляет ошибку и не добавляет функциональность
+- **perf**: Изменение кода, повышающее производительность
+- **test**: Добавление недостающих тестов или исправление существующих
+- **chore**: Изменения в процессе сборки или вспомогательных инструментах и библиотеках
 
-### Instructions for Agent
-1. Analyze the user's request or recent file changes to determine the `type` and `description`.
-2. Construct the commit message string (e.g., "fix(auth): correct token validation").
-3. **Execute** the bash script below, passing the generated message as an argument.
+### Инструкции для агента
+1. Проанализируйте запрос пользователя или недавние изменения файлов, чтобы определить тип (`type`) и описание (`description`).
+2. Сформируйте строку сообщения коммита (например, "fix(auth): correct token validation").
+3. **Выполните** bash-скрипт ниже, передав сгенерированное сообщение в качестве аргумента.
 
-## Execution
-Run the following command (replace .YOUR_MESSAGE. with the formatted string):
+## Выполнение
+Запустите следующую команду (замените "YOUR_MESSAGE" на отформатированную строку):
 
 ```bash
 /bin/bash .agent/skills/git-push/scripts/push_changes.sh "YOUR_MESSAGE"
 ```
 
-## Example Usage
-If user says "I fixed the login bug", you execute:
+## Пример использования
+Если пользователь говорит "Я исправил ошибку входа", вы выполняете:
 `/bin/bash .agent/skills/git-push/scripts/push_changes.sh "fix(auth): resolve login error"`

.agent/skills/git-push/scripts/push_changes.sh

@@ -1,10 +1,5 @@
 #!/bin/bash
 
-# --- НАСТРОЙКИ (Проверь, чтобы совпадали с check_and_pull.sh) ---
-SERVER="root@192.168.1.87"
-REMOTE_PATH="/root/magistr/program"
-# -------------------------------------------------------------
-
 COMMIT_MSG="$1"
 
 # Проверка: если сообщение пустое, ругаемся
@@ -14,15 +9,14 @@ if [ -z "$COMMIT_MSG" ]; then
     exit 1
 fi
 
-echo "🚀 Starting Push Sequence to $SERVER..."
+echo "🚀 Starting Local Push Sequence..."
 
-# Выполняем цепочку команд на сервере одной строкой
-ssh -o BatchMode=yes "$SERVER" "export LANG=C.UTF-8 && cd $REMOTE_PATH && \
- git add . && \
- git commit -m \"$COMMIT_MSG\" && \
- git push origin main"
+# Выполняем цепочку команд локально
+git add . && \
+git commit -m "$COMMIT_MSG" && \
+git push origin main
 
-# Проверяем код возврата последней команды
+# Проверяем код возврата
 if [ $? -eq 0 ]; then
     echo "✅ Success! Changes pushed to remote."
 else

.agent/skills/git-sync/SKILL.md

@@ -1,23 +1,23 @@
-# Git Sync Skill
+# Навык Git Sync
 
-## Description
-This skill allows the agent to check the remote Git repository for updates. It automatically pulls changes if a new version is available on the remote server.
+## Описание
+Этот навык позволяет агенту проверять удаленный Git-репозиторий на наличие обновлений. Он автоматически подтягивает изменения, если на удаленном сервере доступна новая версия.
 
-## Triggers
-Activate this skill when the user asks:
-- "Проверь обновления" (Check for updates)
-- "Загрузи новую версию" (Download new version)
-- "Синхронизируй с гитом" (Sync with git)
-- "Есть ли изменения?" (Are there changes?)
+## Триггеры
+Активируйте этот навык, когда пользователь спрашивает:
+- "Проверь обновления"
+- "Загрузи новую версию"
+- "Синхронизируй с гитом"
+- "Есть ли изменения?"
 
-## Execution
-To run this skill, execute the bash script:
+## Выполнение
+Для запуска этого навыка выполните bash-скрипт:
 
 ```bash
 /bin/bash .agent/skills/git-sync/scripts/check_and_pull.sh
 ```
 
-## Response Guidelines
-1. **Success**: If the script says "Successfully updated", inform the user the project is now on the latest version.
-2. **No Updates**: If the script says "Up-to-date", tell the user no changes were found.
-3. **Error**: If the script fails or reports conflicts, ask the user to check git status manually.
+## Рекомендации по ответам
+1. **Успех**: Если скрипт говорит "Successfully updated", сообщите пользователю, что проект обновлен до последней версии.
+2. **Нет обновлений**: Если скрипт говорит "Up-to-date", сообщите пользователю, что изменений не найдено.
+3. **Ошибка**: Если скрипт завершился с ошибкой или сообщает о конфликтах, попросите пользователя проверить статус git вручную.

.agent/skills/git-sync/scripts/check_and_pull.sh

@@ -1,24 +1,17 @@
 #!/bin/bash
 
-# --- НАСТРОЙКИ ---
-SERVER="root@192.168.1.87"
-REMOTE_PATH="/root/magistr/program"
-# -----------------
+echo "📡 Checking for updates locally..."
 
-echo "📡 Connecting to remote server ($SERVER)..."
-
-# 1. Запускаем fetch прямо на сервере
-# Флаг -o BatchMode=yes запрещает спрашивать пароль (чтобы скрипт не завис)
-ssh -o BatchMode=yes -o ConnectTimeout=10 "$SERVER" "cd $REMOTE_PATH && git fetch origin"
+# 1. Запускаем fetch локально
+git fetch origin
 
 if [ $? -ne 0 ]; then
-    echo "❌ Connection failed."
-    echo "Make sure SSH keys are set up and the server is reachable."
+    echo "❌ Fetch failed. Check your internet connection and git remote settings."
     exit 1
 fi
 
 # 2. Проверяем количество новых коммитов (HEAD..@{u})
-BEHIND_COUNT=$(ssh "$SERVER" "cd $REMOTE_PATH && git rev-list --count HEAD..@{u} 2>/dev/null")
+BEHIND_COUNT=$(git rev-list --count HEAD..@{u} 2>/dev/null)
 
 # Если переменная пустая — значит ошибка в гите
 if [ -z "$BEHIND_COUNT" ]; then
@@ -28,16 +21,16 @@ fi
 
 # 3. Логика обновления
 if [ "$BEHIND_COUNT" -gt 0 ]; then
-    echo "⬇️ Found $BEHIND_COUNT new commit(s). Pulling on server..."
+    echo "⬇️ Found $BEHIND_COUNT new commit(s). Pulling changes..."
     
-    # Выполняем git pull на сервере
-    ssh "$SERVER" "cd $REMOTE_PATH && git pull"
+    # Выполняем git pull
+    git pull
     
     if [ $? -eq 0 ]; then
-        echo "✅ Server successfully updated!"
+        echo "✅ Successfully updated!"
     else
         echo "❌ Update failed (merge conflicts?)."
     fi
 else
-    echo "✨ Server is already up to date."
+    echo "✨ Already up to date."
 fi

.agent/workflows/deploy-server.md

@@ -0,0 +1,13 @@
+---
+description: Деплой на удаленный сервер 192.168.1.87 (Git Pull + Docker Build)
+---
+
+# Развертывание на сервере 192.168.1.87
+
+Этот воркфлоу позволяет быстро обновить проект на удаленном сервере после того, как вы запушили изменения в Git.
+
+// turbo-all
+1. Синхронизировать код и перезапустить контейнеры:
+```bash
+ssh root@192.168.1.87 "cd /root/magistr/program/ && git fetch origin main && git reset --hard origin/main && docker compose up -d --build"
+```