v1.2.1

v1.2.1

Пакет переведён в полосу 0000_00 — начало общего порядка миграций приложения и всех пакетов. Позиция выведена из графа
внешних ключей, а не из того, что пакет ставится первым.

Новое

Полоса 0000_00. Полоса в имени миграции — это позиция владельца в общем порядке, а не отдельный именованный
диапазон. Laravel сортирует миграции приложения и всех пакетов по имени файла и применяет их сверху вниз, поэтому
внешний ключ допустим только на таблицу, чья миграция имеет меньшее имя. Раскладка стека i2tech:

0000_00 — laravel-max-client: max_users, max_chats, max_chat_users
0000_01 — приложение, системные таблицы (users и прочие)
0000_02 — filament-max-chat
0000_03 — filament-max-broadcasts
0000_04 — приложение, доменные таблицы

Пакет занимает начало порядка, потому что на его таблицы ссылаются все: users.max_user_id указывает на
max_users.user_id (системные миграции приложения, 0000_01), max_chat_messages.max_chat_id — на max_chats
(плагин, 0000_02), max_broadcasts.created_by — на users (0000_01). Если бы max_users создавалась позже
users, внешний ключ в users упирался бы в ещё не существующую таблицу.

Документ с раскладкой полос и графом FK продублирован в docblock первой миграции пакета: тот, кто чинит порядок, сначала
читает файл, который для этого и существует.

Изменение (BC)

Переименованы все три миграции пакета:

было	стало
0001_01_01_000001_create_max_users_table	0000_00_000001_create_max_users_table
0001_01_01_000002_create_max_chats_table	0000_00_000002_create_max_chats_table
0001_01_01_000003_create_max_chat_users_table	0000_00_000003_create_max_chat_users_table

Объявления таблиц не менялись. Для обновляющейся установки переименование означает, что все три миграции числятся
невыполненными при уже существующих таблицах, поэтому в up() каждой добавлен Schema::hasTable() с выходом по
return: таблицы не пересоздаются, миграции просто отмечаются выполненными. Без этого guard смена имени ломает ровно те
установки, ради которых делается, — они падают на повторном Schema::create.

Guard останавливает только пересоздание таблицы. Колонки, свёрнутые в create миграций 9570064
(max_users.phone_verified_at, метаданные чатов, индекс по chat_id), он не возвращает — их доставляет
max:upgrade: команда добавляет phone_verified_at, если его нет, и пересобирает max_chats только из реально
существующих колонок. Поэтому порядок migrate, затем max:upgrade обязателен, а migrate в одиночку оставляет схему
неполной.

Порядок обновления не изменился: php artisan migrate, затем php artisan max:upgrade. Вторая команда на чистой базе
остаётся no-op.

В таблице migrations строки со старыми именами остаются как неиспользуемые: на migrate они не влияют, но при желании
их можно удалить вручную.

Если до v1.1.4 миграции пакета публиковались в приложение, копии лежат под старыми именами и перекрывают файлы пакета:
Migrator::getMigrationFiles() собирает файлы через keyBy() по имени, и путь приложения идёт позже пути пакета. Копии
нужно удалить — порядок описан в README.md, раздел «Если миграции пакета публиковались раньше».

Затронутые сценарии

• Чистая установка: php artisan migrate создаёт max_users, max_chats, max_chat_users до того, как приложение
  создаст users и начнёт ссылаться на max_users.
• Обновление с v1.2.0: три миграции применяются повторно, каждая выходит по Schema::hasTable(), данные и схема не
  меняются.
• Обновление с v1.1.x: сначала php artisan migrate, затем php artisan max:upgrade — порядок обязателен, между шагами
  схема неполна.
• Обновление с v1.2.1: ничего не делает, второй прогон — no-op.

Качество

• tests/Feature/MaxMigrationsTest.php: полоса 0000_00 (guard по исходникам всех файлов каталога), знаковость
  идентификаторов, отсутствие ad-hoc миграций. На SQLite нарушение порядка не воспроизводится — таблица с внешним ключом
  на несуществующую таблицу создаётся молча, — поэтому проверка идёт по именам файлов, а не по результату
  migrate.
• tests/Feature/MaxSchemaUpgradeTest.php: сценарии обновления старой формы реестра, слияние дублей, идемпотентность,
  откат. Исторические имена миграций в сценариях старых установок оставлены как есть — они воспроизводят реальное
  состояние базы хоста.
• PHPUnit, PHPStan, PHP CS Fixer — без ошибок.
• Документация: README.md — раздел «Полоса миграций и порядок установки» и переработанный раздел «Если миграции пакета
  публиковались раньше»; AGENTS.md — правило миграций в структуре репозитория и gotchas 19–20 (порядок миграций и
  переименование выполненной миграции).