LoChat/MIGRATION_PLAN.md

План миграции команд на новую архитектуру

Статус (актуально для репозитория): централизованная регистрация в CommandManager и раскладка по пакетам уже внедрены. Ниже — что сделано и что остаётся опциональной доработкой.

Что осталось по плану: миграция команд завершена. Дальше — по желанию: перевести оставшиеся CommandExecutor на PlayerCommand/AdminCommand, добавить тесты/ручной регресс, короткую доку «как добавить команду».

Что уже сделано

Архитектура

• commands/base/BaseCommand, PlayerCommand, AdminCommand
• CommandManager — единая точка регистрации (reg / regTab / registerBaseCommand)

Пакеты (фактическая структура)

Пакет	Назначение
commands/chat/	глобальный / локальный чат (g, l)
commands/messaging/	ЛС, игнор (msg, reply, ignore, unignore, ignorelist)
commands/moderation/	муты, варны, баны (lmute, lunmute, lmutelist, lmutehistory, lmuteblame, warn, silentwarn, lban, lunban)
commands/nick/	ник, инфо (nick, playerinfo)
commands/admin/	админ-утилиты (announce, chatspy, clearchat, clearchatconfig, lochat, lochatreload, discordadmin); в репозитории также есть HubCommand.java (проверьте plugin.yml, если нужна команда хаба)
commands/rp/	RP (me, try, do, roll)
Корень commands/	CustomCommandsCommand, CustomCommand

Папки social/ в проекте нет — социальные команды лежат в messaging/ и nick/.

Регистрация в CommandManager (выполнено)

• Этап 1 — чат: GlobalChatCommand, LocalChatCommand
• Этап 2 — ЛС: MsgCommand, ReplyCommand
• Этап 3 — социальное: IgnoreCommand, UnignoreCommand, IgnoreListCommand, NickCommand (+ PlayerInfoCommand)
• Этап 4 — модерация: все перечисленные в таблице пакета moderation/
• Этап 5 — админ: AnnounceCommand, ClearChatCommand, ClearChatConfigCommand, ChatSpyCommand, LoChatCommand, ReloadConfigCommand, DiscordCommand
• Этап 6 — CustomCommandsCommand и движок кастомных команд

Что ещё можно сделать (не блокирует работу)

Унификация базового класса

Многие команды по-прежнему реализуют CommandExecutor напрямую, а не PlayerCommand / AdminCommand. Имеет смысл постепенно переводить на базовые классы там, где это убирает дублирование проверок и сообщений.

Тесты и ручная проверка

• Стабильные сценарии для приоритетных команд (чат, ЛС, муты) — ручные или автотесты
• Проверка TabCompleter на зарегистрированных командах с regTab

Документация

• Короткий CONTRIBUTING или раздел в README: как добавить команду через CommandManager и plugin.yml

Процесс миграции одной команды (если рефакторите дальше)

1. Новая команда на базовом классе

public class NewCommand extends PlayerCommand {
    public NewCommand(LoChat plugin) {
        super(plugin);
    }

    @Override
    protected boolean executePlayerCommand(Player player, Command command,
            String label, String[] args) {
        return true;
    }
}

2. Проверки

• Поведение и права
• Сообщения из MessagesConfig / конфигов
• TabCompleter при необходимости

3. Регистрация

В CommandManager: reg("name", new NewCommand(plugin)) или regTab, плюс запись в plugin.yml.

4. Удаление старого кода

После замены — удалить старый класс и неиспользуемые импорты.

Чек-лист для команды

• Корректный базовый класс или явный CommandExecutor с единым стилем обработки ошибок
• Права из plugin.yml
• Сообщения из конфигурации
• Валидация аргументов
• TabCompleter при необходимости

Ожидаемые эффекты от доведения до единого стиля

• Меньше дублирования проверок отправителя и прав
• Проще добавлять новые команды
• Проще сопровождать код при едином паттерне

---

Следующие шаги (по желанию): выбрать 2–3 самых «шумных» по коду команды → перевести на PlayerCommand/AdminCommand → добавить минимальные тесты или чек-лист ручной регрессии.