chore: stop tracking .agent folder
This commit is contained in:
Zuev
@@ -1,83 +0,0 @@
|
|||||||
---
|
|
||||||
description: Полное описание схемы базы данных проекта
|
|
||||||
---
|
|
||||||
|
|
||||||
# Описание базы данных: Система расписания университета
|
|
||||||
|
|
||||||
В этом правиле содержится полное описание структуры базы данных PostgreSQL, используемой в проекте.
|
|
||||||
|
|
||||||
## Основные сущности и таблицы
|
|
||||||
|
|
||||||
### 1. Пользователи и роли (`users`)
|
|
||||||
Хранит учетные записи пользователей системы.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `username` (VARCHAR(50), UNIQUE, NOT NULL) - логин
|
|
||||||
- `password` (VARCHAR(255), NOT NULL) - хэш пароля (используется bcrypt через pgcrypto)
|
|
||||||
- `role` (VARCHAR(20), NOT NULL, DEFAULT 'STUDENT') - роль пользователя. Возможные значения: `ADMIN`, `TEACHER`, `STUDENT`.
|
|
||||||
|
|
||||||
### 2. Формы обучения (`education_forms`)
|
|
||||||
Справочник форм обучения.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(100), UNIQUE, NOT NULL) - например: 'Бакалавриат', 'Магистратура', 'Специалитет'
|
|
||||||
|
|
||||||
### 3. Студенческие группы (`student_groups`)
|
|
||||||
Справочник учебных групп.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(100), UNIQUE, NOT NULL) - название группы (например, 'ИВТ-21-1')
|
|
||||||
- `education_form_id` (BIGINT, FK -> education_forms.id) - привязка к форме обучения
|
|
||||||
|
|
||||||
### 4. Подгруппы (`subgroups`)
|
|
||||||
Разделение групп на подгруппы (для лабораторных и практик).
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `group_id` (BIGINT, FK -> student_groups.id)
|
|
||||||
- `name` (VARCHAR(100), NOT NULL) - название подгруппы (например, 'Подгруппа 1')
|
|
||||||
|
|
||||||
### 5. Дисциплины (`subjects`)
|
|
||||||
Справочник учебных предметов.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(200), UNIQUE, NOT NULL) - название дисциплины (например, 'Высшая математика')
|
|
||||||
|
|
||||||
### 6. Типы занятий (`lesson_types`)
|
|
||||||
Справочник видов учебных занятий.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(50), UNIQUE, NOT NULL) - вид занятия (Лекция, Практика, Лабораторная работа)
|
|
||||||
|
|
||||||
### 7. Оборудование (`equipments`)
|
|
||||||
Справочник доступного оборудования для аудиторий.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(50), UNIQUE, NOT NULL) - например, 'Проектор', 'ПК', 'Лаборатория', 'Интерактивная доска'
|
|
||||||
|
|
||||||
### 8. Аудиторный фонд (`classrooms`)
|
|
||||||
Справочник аудиторий университета.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `name` (VARCHAR(50), UNIQUE, NOT NULL) - номер/название аудитории
|
|
||||||
- `capacity` (INT, NOT NULL) - вместимость (количество посадочных мест)
|
|
||||||
- `is_available` (BOOLEAN, DEFAULT TRUE) - статус доступности аудитории для проведения пар
|
|
||||||
|
|
||||||
### 9. Привязка оборудования к аудиториям (`classroom_equipments`)
|
|
||||||
Связующая таблица (Many-to-Many) для указания, какое оборудование есть в аудитории.
|
|
||||||
- `classroom_id` (BIGINT, FK -> classrooms.id)
|
|
||||||
- `equipment_id` (BIGINT, FK -> equipments.id)
|
|
||||||
|
|
||||||
### 10. Привязка преподавателей к дисциплинам (`teacher_subjects`)
|
|
||||||
Связующая таблица (Many-to-Many). Определяет, какие предметы имеет право вести преподаватель.
|
|
||||||
- `user_id` (BIGINT, FK -> users.id)
|
|
||||||
- `subject_id` (BIGINT, FK -> subjects.id)
|
|
||||||
|
|
||||||
### 11. Расписание занятий (Пар) (`lessons`)
|
|
||||||
Главная таблица, хранящая сетку расписания. Связывает все основные сущности в рамках одного учебного занятия.
|
|
||||||
- `id` (BIGSERIAL, РК)
|
|
||||||
- `teacher_id` (BIGINT, FK -> users.id) - кто ведет пару
|
|
||||||
- `subject_id` (BIGINT, FK -> subjects.id) - какую дисциплину ведут
|
|
||||||
- `lesson_type_id` (BIGINT, FK -> lesson_types.id) - вид занятия (лекция/практика)
|
|
||||||
- `classroom_id` (BIGINT, FK -> classrooms.id) - где проходит
|
|
||||||
- `group_id` (BIGINT, FK -> student_groups.id) - у какой группы
|
|
||||||
- `subgroup_id` (BIGINT, FK -> subgroups.id, NULLABLE) - конкретная подгруппа (если пара не у всей группы)
|
|
||||||
- `day_of_week` (INT, NOT NULL) - день недели (1=Понедельник ... 7=Воскресенье)
|
|
||||||
- `is_even_week` (BOOLEAN, NOT NULL) - признак четности недели (TRUE = четная, FALSE = нечетная)
|
|
||||||
- `start_time` (TIME, NOT NULL) - время начала пары (например: '08:00:00')
|
|
||||||
- `end_time` (TIME, NOT NULL) - время окончания пары (например: '09:30:00')
|
|
||||||
|
|
||||||
## Особенности архитектуры БД
|
|
||||||
- Используется расширение `pgcrypto` для шифрования паролей пользователей (`bcrypt`).
|
|
||||||
- Все связи Many-to-Many и внешние ключи настроены с `ON DELETE CASCADE` там, где это необходимо, для поддержания целостности данных при удалении родительских сущностей.
|
|
||||||
@@ -1,109 +0,0 @@
|
|||||||
---
|
|
||||||
trigger: always_on
|
|
||||||
---
|
|
||||||
|
|
||||||
# Контекст проекта: Система расписания университета
|
|
||||||
|
|
||||||
## Обзор проекта
|
|
||||||
Этот проект представляет собой веб-сайт системы управления университетским расписанием.
|
|
||||||
- **Роль**: Образовательная платформа для управления расписанием.
|
|
||||||
- **Язык**: Смешанный (Java Backend + Web Frontend).
|
|
||||||
- **Публичный URL прода**: https://magistr.zuev.company
|
|
||||||
- **Локальный URL проекта**: localhost:80
|
|
||||||
|
|
||||||
## Структура директорий и обязанности
|
|
||||||
Проект следует определенной структуре папок. Вы должны придерживаться этих путей:
|
|
||||||
|
|
||||||
- **`backend/`**: Содержит исходный код бэкенд-приложения на **Java**.
|
|
||||||
- При работе с API или серверной логикой фокусируйтесь здесь.
|
|
||||||
|
|
||||||
- **`frontend/`**: Содержит исходный код фронтенда. Обратите внимание на строгое разделение ролей:
|
|
||||||
- `frontend/admin/`: Код, специфичный для интерфейса **Администратора**.
|
|
||||||
- `frontend/teacher/`: Код, специфичный для интерфейса **Преподавателя**.
|
|
||||||
- `frontend/student/`: Код, специфичный для интерфейса **Студента**.
|
|
||||||
- *Ограничение*: Не смешивайте логику между этими папками, если только не создаете общую утилиту.
|
|
||||||
|
|
||||||
- **`db/`**: Конфигурация и данные базы данных.
|
|
||||||
- `db/init/init.sql`: SQL-скрипт, отвечающий за **создание и инициализацию** схемы базы данных (таблицы, начальные данные).
|
|
||||||
|
|
||||||
- **Корневые файлы**:
|
|
||||||
- `compose.yaml`: Конфигурация Docker Compose. Этот файл определяет сервисы (бэкенд, БД, фронтенд-серверы) и то, как они работают вместе.
|
|
||||||
- `.env`: Переменные окружения. Содержит конфиденциальные настройки (пароли БД, порты, ключи API).
|
|
||||||
|
|
||||||
## Внешние зависимости (родительская директория)
|
|
||||||
Некоторые компоненты инфраструктуры расположены за пределами корня проекта:
|
|
||||||
|
|
||||||
- **`../caddy-proxy/`**: Находится на один уровень выше относительно корня проекта.
|
|
||||||
- **Роль**: Реверс-прокси, обрабатывающий трафик для `magistr.zuev.company`.
|
|
||||||
- **`Caddyfile`**: Конфигурация для маршрутизации и SSL.
|
|
||||||
- **`compose.yaml`**: Отдельный файл Docker Compose специально для службы прокси.
|
|
||||||
|
|
||||||
## Рекомендации по рабочему процессу
|
|
||||||
1. **Изменения в базе данных**: Если вам нужно изменить схему базы данных, вы должны обновить `db/init/init.sql`, чтобы изменения сохранялись при пересборке контейнера.
|
|
||||||
2. **Конфигурация**: Если вы добавляете новые параметры конфигурации, добавьте их в `.env` и сошлитесь на них в `compose.yaml` или коде приложения.
|
|
||||||
3. **Маршрутизация/Прокси**: Если возникают проблемы с доменом или внешним доступом, проверьте конфигурацию в `../caddy-proxy/Caddyfile`.
|
|
||||||
|
|
||||||
## Языковые предпочтения
|
|
||||||
- **Всегда отвечайте на русском**: Это строгое требование пользователя. Все объяснения, комментарии и взаимодействия должны быть на русском языке, если только не будет специально запрошено иное.
|
|
||||||
|
|
||||||
## Функциональные требования к системе
|
|
||||||
|
|
||||||
### 1. Ролевая модель
|
|
||||||
- **Администратор (Деканат)**: Полный доступ, настройка топологии университета, управление аудиторным фондом, подтверждение переносов, регистрация инцидентов.
|
|
||||||
- **Преподаватель**: Просмотр своего расписания, подача заявок на перенос, отметка о своём отсутствии.
|
|
||||||
- **Студент**: Только просмотр расписания (Read-only).
|
|
||||||
|
|
||||||
### 2. Управление ресурсами и топология
|
|
||||||
- **Управление аудиториями**:
|
|
||||||
- Указание вместимости.
|
|
||||||
- Привязка доступного оборудования (через сущность Equipments: Проектор, ПК, Лаборатория).
|
|
||||||
- Установка статуса "Не доступно" (блокирует назначение пар в этот период).
|
|
||||||
- **Управление группами**:
|
|
||||||
- Управление списком студентов (и возможность деления на подгруппы).
|
|
||||||
- **Управление дисциплинами**:
|
|
||||||
- Создание предметов и привязка их к преподавателям (какие дисциплины имеет право вести конкретный преподаватель).
|
|
||||||
|
|
||||||
### 3. Логика расписания
|
|
||||||
- **Проверка конфликтов**:
|
|
||||||
- *Критический конфликт*: Преподаватель не может находиться в двух разных аудиториях одновременно.
|
|
||||||
- *Уточнение по преподавателям*: Преподаватель может иметь несколько пар одновременно (для разных групп), только если они проходят в одной и той же аудитории (потоковая лекция).
|
|
||||||
- **Потоковые занятия**:
|
|
||||||
- Возможность назначить одну лекцию сразу нескольким группам (технически — несколько записей в БД или одна запись со списком групп).
|
|
||||||
- Проверка вместимости: вместимость аудитории должна покрывать суммарную численность всех групп, находящихся в этой аудитории в данный слот.
|
|
||||||
|
|
||||||
### 4. Управление инцидентами (Инклюзия отсутствия)
|
|
||||||
- **Отсутствие (Sickness/Business Trip)**: Регистрация отсутствия преподавателя (с указанием причины и периода дат).
|
|
||||||
- **Обнаружение коллизий**: Автоматическая подсветка конфликтующих пар в расписании (Red Zone).
|
|
||||||
- **Система разрешения конфликтов (Resolution Wizard)**:
|
|
||||||
- Предложение подходящей замены преподавателя на этот слот.
|
|
||||||
- Предложение переноса занятия на другое время или в другую аудиторию.
|
|
||||||
|
|
||||||
## Технологический стек (Tech Stack)
|
|
||||||
- **Backend**: Java 17, Spring Boot 3.2.5 (Starter Web, Data JPA), кастомная токен-авторизация (используется BCrypt, без полной автоконфигурации Spring Security).
|
|
||||||
- **Database**: PostgreSQL.
|
|
||||||
- **Frontend**: Vanilla JavaScript + HTML/CSS (без тяжеловесных фреймворков).
|
|
||||||
|
|
||||||
## Специфика времени и сетка расписания (Time Management)
|
|
||||||
- **Гибкие временные слоты**: По умолчанию слоты по 1.5 часа:
|
|
||||||
1. 08:00 - 09:30
|
|
||||||
2. 09:40 - 11:10
|
|
||||||
3. 11:40 - 13:10
|
|
||||||
4. 13:20 - 14:50
|
|
||||||
5. 15:00 - 16:30
|
|
||||||
6. 16:50 - 18:20
|
|
||||||
7. 18:30 - 20:00
|
|
||||||
- **Кастомное время**: Система должна позволять устанавливать кастомное время начала и конца пары.
|
|
||||||
- **Тип расписания**: Календарное расписание, строящееся по принципу чётной / нечётной недели.
|
|
||||||
|
|
||||||
## Основные сущности базы данных (Data Entities)
|
|
||||||
- **Users**: Хранение пользователей и их ролей (Администратор, Преподаватель, Студент) для управления доступом.
|
|
||||||
- **Education_Forms**: Формы обучения (Бакалавриат, Магистратура и т.д.).
|
|
||||||
- **Student_Groups**: Группы студентов, их привязка к формам обучения `education_forms(id)`.
|
|
||||||
- **Subgroups**: Подгруппы студентов конкретной группы `group_id` для лабораторных и практик.
|
|
||||||
- **Equipments**: Справочник оборудования.
|
|
||||||
- **Classrooms**: Аудиторный фонд (название, вместимость, статус доступности).
|
|
||||||
- **Classroom_Equipments**: Связующая таблица (Many-to-Many), определяющая какое оборудование находится в аудитории.
|
|
||||||
- **Subjects**: Предметы/Дисциплины (Высшая математика, Физика, Базы данных и т.д.).
|
|
||||||
- **Teacher_Subjects**: Связующая таблица (Many-to-Many), определяющая, какие дисциплины ведет конкретный преподаватель `users(id)`.
|
|
||||||
- **Lesson_Types**: Типы занятий для валидации (Лекция, Практика, Лабораторная работа).
|
|
||||||
- **Lessons / Schedules**: Сами занятия (пары). Каждая запись связывает преподавателя, аудиторию, группу (и/или подгруппу), предмет (`subject_id`), тип занятия (`lesson_type_id`), день недели, четность недели и конкретное время (start_time, end_time).
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
# Навык Git Push и форматирования
|
|
||||||
|
|
||||||
## Описание
|
|
||||||
Форматирует сообщения коммитов git в соответствии со спецификацией Conventional Commits и отправляет изменения в удаленный репозиторий. Использует SSH URL: `ssh://git@gitea.zuev.company:2222/Zuev/magistr.git`. Используйте этот навык, когда пользователь просит закоммитить изменения, сохранить прогресс или отправить код.
|
|
||||||
|
|
||||||
## Триггеры
|
|
||||||
- "Запушь изменения"
|
|
||||||
- "Сделай коммит"
|
|
||||||
- "Сохрани в гит"
|
|
||||||
- "Сделай пуш"
|
|
||||||
- "Запушь"
|
|
||||||
- "Пуш"
|
|
||||||
- "Отправь код"
|
|
||||||
- "Commit and push"
|
|
||||||
|
|
||||||
## Формат (Conventional Commits)
|
|
||||||
При написании сообщения коммита вы ДОЛЖНЫ следовать этому формату:
|
|
||||||
`<type>[optional scope]: <description>`
|
|
||||||
|
|
||||||
### Допустимые типы
|
|
||||||
- **feat**: Новая функциональность
|
|
||||||
- **fix**: Исправление ошибки
|
|
||||||
- **docs**: Изменения только в документации
|
|
||||||
- **style**: Изменения, не влияющие на смысл кода (пробелы, форматирование и т.д.)
|
|
||||||
- **refactor**: Изменение кода, которое не исправляет ошибку и не добавляет функциональность
|
|
||||||
- **perf**: Изменение кода, повышающее производительность
|
|
||||||
- **test**: Добавление недостающих тестов или исправление существующих
|
|
||||||
- **chore**: Изменения в процессе сборки или вспомогательных инструментах и библиотеках
|
|
||||||
|
|
||||||
### Инструкции для агента
|
|
||||||
1. Проанализируйте запрос пользователя или недавние изменения файлов, чтобы определить тип (`type`) и область (`scope`), если применимо.
|
|
||||||
2. Сформируйте строку сообщения коммита (например, "fix(auth): correct token validation").
|
|
||||||
3. **ОБЯЗАТЕЛЬНО** выполните bash-скрипт ниже, передав сгенерированное сообщение в качестве аргумента. Не пытайтесь выполнять git команды вручную.
|
|
||||||
|
|
||||||
## Выполнение
|
|
||||||
Запустите следующую команду (замените "YOUR_MESSAGE" на отформатированную строку):
|
|
||||||
|
|
||||||
```bash
|
|
||||||
/bin/bash .agent/skills/git-push/scripts/push_changes.sh "YOUR_MESSAGE"
|
|
||||||
```
|
|
||||||
|
|
||||||
## Пример использования
|
|
||||||
Если пользователь говорит "Я исправил ошибку входа", вы выполняете:
|
|
||||||
`/bin/bash .agent/skills/git-push/scripts/push_changes.sh "fix(auth): resolve login error"`
|
|
||||||
@@ -1,31 +0,0 @@
|
|||||||
#!/bin/bash
|
|
||||||
|
|
||||||
COMMIT_MSG="$1"
|
|
||||||
|
|
||||||
# Проверка: если сообщение пустое, ругаемся
|
|
||||||
if [ -z "$COMMIT_MSG" ]; then
|
|
||||||
echo "❌ Error: Commit message is required."
|
|
||||||
echo "Usage: ./push_changes.sh \"feat: description\""
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
echo "🚀 Starting Local Push Sequence..."
|
|
||||||
|
|
||||||
# Проверка на наличие изменений
|
|
||||||
if git diff-index --quiet HEAD --; then
|
|
||||||
echo "ℹ️ No changes to commit. Everything is up to date."
|
|
||||||
exit 0
|
|
||||||
fi
|
|
||||||
|
|
||||||
# Выполняем цепочку команд локально (SSH URL: ssh://git@192.168.1.87:2222/Zuev/magistr.git)
|
|
||||||
git add . && \
|
|
||||||
git commit -m "$COMMIT_MSG" && \
|
|
||||||
git push origin main
|
|
||||||
|
|
||||||
# Проверяем код возврата
|
|
||||||
if [ $? -eq 0 ]; then
|
|
||||||
echo "✅ Success! Changes pushed to remote."
|
|
||||||
else
|
|
||||||
echo "❌ Failed to push. Check the output above for errors."
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
@@ -1,23 +0,0 @@
|
|||||||
# Навык Git Sync
|
|
||||||
|
|
||||||
## Описание
|
|
||||||
Этот навык позволяет агенту проверять удаленный Git-репозиторий на наличие обновлений. Он автоматически подтягивает изменения, если на удаленном сервере доступна новая версия.
|
|
||||||
|
|
||||||
## Триггеры
|
|
||||||
Активируйте этот навык, когда пользователь спрашивает:
|
|
||||||
- "Проверь обновления"
|
|
||||||
- "Загрузи новую версию"
|
|
||||||
- "Синхронизируй с гитом"
|
|
||||||
- "Есть ли изменения?"
|
|
||||||
|
|
||||||
## Выполнение
|
|
||||||
Для запуска этого навыка выполните bash-скрипт:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
/bin/bash .agent/skills/git-sync/scripts/check_and_pull.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## Рекомендации по ответам
|
|
||||||
1. **Успех**: Если скрипт говорит "Successfully updated", сообщите пользователю, что проект обновлен до последней версии.
|
|
||||||
2. **Нет обновлений**: Если скрипт говорит "Up-to-date", сообщите пользователю, что изменений не найдено.
|
|
||||||
3. **Ошибка**: Если скрипт завершился с ошибкой или сообщает о конфликтах, попросите пользователя проверить статус git вручную.
|
|
||||||
@@ -1,36 +0,0 @@
|
|||||||
#!/bin/bash
|
|
||||||
|
|
||||||
echo "📡 Checking for updates locally..."
|
|
||||||
|
|
||||||
# 1. Запускаем fetch локально
|
|
||||||
git fetch origin
|
|
||||||
|
|
||||||
if [ $? -ne 0 ]; then
|
|
||||||
echo "❌ Fetch failed. Check your internet connection and git remote settings."
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
# 2. Проверяем количество новых коммитов (HEAD..@{u})
|
|
||||||
BEHIND_COUNT=$(git rev-list --count HEAD..@{u} 2>/dev/null)
|
|
||||||
|
|
||||||
# Если переменная пустая — значит ошибка в гите
|
|
||||||
if [ -z "$BEHIND_COUNT" ]; then
|
|
||||||
echo "⚠️ Git status unknown. Upstream branch might not be set."
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
# 3. Логика обновления
|
|
||||||
if [ "$BEHIND_COUNT" -gt 0 ]; then
|
|
||||||
echo "⬇️ Found $BEHIND_COUNT new commit(s). Pulling changes..."
|
|
||||||
|
|
||||||
# Выполняем git pull
|
|
||||||
git pull
|
|
||||||
|
|
||||||
if [ $? -eq 0 ]; then
|
|
||||||
echo "✅ Successfully updated!"
|
|
||||||
else
|
|
||||||
echo "❌ Update failed (merge conflicts?)."
|
|
||||||
fi
|
|
||||||
else
|
|
||||||
echo "✨ Already up to date."
|
|
||||||
fi
|
|
||||||
@@ -1,13 +0,0 @@
|
|||||||
---
|
|
||||||
description: Деплой на удаленный сервер 192.168.1.87 (Git Pull + Docker Build)
|
|
||||||
---
|
|
||||||
|
|
||||||
# Развертывание на сервере 192.168.1.87
|
|
||||||
|
|
||||||
Этот воркфлоу позволяет быстро обновить проект на удаленном сервере после того, как вы запушили изменения в Git.
|
|
||||||
|
|
||||||
// turbo-all
|
|
||||||
1. Синхронизировать код и, если изменился init.sql, пересобрать базу данных:
|
|
||||||
```bash
|
|
||||||
bash -c "ssh root@192.168.1.87 'cd /root/magistr/program/ && git fetch origin main && CHANGED=\$(git diff --name-only HEAD origin/main | grep db/init/init.sql || true) && git reset --hard origin/main && if [ ! -z \"\$CHANGED\" ]; then echo \"Обнаружены изменения в init.sql, удаляем базу данных...\"; docker compose down -v; sudo rm -rf db/data; fi && docker compose up -d --build'"
|
|
||||||
```
|
|
||||||
3
.gitignore
vendored
3
.gitignore
vendored
@@ -10,8 +10,7 @@ db/data/
|
|||||||
.idea/
|
.idea/
|
||||||
.vscode/
|
.vscode/
|
||||||
*.DS_Store
|
*.DS_Store
|
||||||
!.agent
|
.agent/
|
||||||
|
|
||||||
# Игнорируем временные файлы сборки (на будущее)
|
# Игнорируем временные файлы сборки (на будущее)
|
||||||
backend/target/
|
backend/target/
|
||||||
backend/build/
|
backend/build/
|
||||||
|
|||||||
Reference in New Issue
Block a user