<b>Filament ломается не в CRUD, а в связке форм, policy и действий</b>

<b>Filament ломается не в CRUD, а в связке форм, policy и действий</b>

Если Filament начал вести себя «странно», обычно проблема не в самом админ-UI, а в трёх местах: авторизация, состояние формы и побочные действия. На ровном CRUD это не видно, но как только появляются зависимости между полями, вложенные relation manager и массовые операции — всплывает реальная архитектура.

Проверь базовый порядок:
— доступ к ресурсу и странице отдельно от доступа к записи;
— hidden/disabled поля не должны быть единственным источником бизнес-логики;
— валидация должна жить не только в форме, но и на уровне модели или сервиса.

Частая ошибка — дублировать правила в каждом action. Тогда один create работает, а edit, bulk action или modal action обходят ограничение. В Filament лучше вынести правило в одно место и использовать его везде, где меняется доменная сущность.

Ещё одна зона риска — тяжёлые вычисления в `afterStateUpdated`. Если поле тянет расчёты, запросы или цепочку зависимых обновлений, интерфейс начинает «тупить» и ловить неожиданные циклы. Здесь помогает простой принцип: форма собирает данные, сервис их обрабатывает.

Если админка стала хрупкой, сначала упрости связь между UI и доменом. Filament любит чистые границы — и резко хуже переносит бизнес-логику, размазанную по полям, actions и страницам.