а как быть с апдейт?

Чувак, контракт не даёт права, а определяет кто что должен делать. Контракт начинается со слова interfelace, так что не надо тут ля-ля.
А вот юзать постфикс Interface... Либо используй Contract, либо вообще не юзай - App\Contracts\Rule.

Создание и обновление записей - разная логика.
В одном месте массово создаёшь, а обновлять 146% надо по-штучно и точно в другом месте.

обнови поштучно 1000+ рекордов...

ясненько

Опять же, если есть обсерверы или эвенты, то поштучно, а если массово, то никто не запрещает через релейшен обращаться без фильтрации по уникальному идентификатору.
Вот только что это за логика такая, в которой нужно свыше 1к дочерних записей обновлять из родительской...

Ещё непонятно что делает пакет. Может, он под капотом тот же форыч запускает, в чем я очень уверен. Но, в таком случае, зачем пакет?.. Непонятно.

interface Saleable {} - пустой интерфейс, является контрактом, говорит о том что экземпляр класса реализующего контракт может быть продан, контракт может не иметь интерфейса вообще, от него важен тип

Интерфейс описывает API (сигнатуру) реализующего класса

interface Rule {
 public function validate(): bool;
 public function getError(): string;
}

а вообще это всё игра слов, по сути и то и то интерфейс. Но Rule у меня не контракт это уж точно, от интерфейса Rule мне важно быть уверенным в сигнатуре

по итогу пришёл к этому, может и не очень, но понятнее всего для меня

Пустой?..
Некогда объяснять: собирайся и иди к кузнецам. По дороге нагугли схему гильотины. Как закончат, клади руки и руби нахер.

Он-рашн, у тебя класс ради класса. Если интерфейс не объявляет реализацию, то толку от него нет никакого ибо сейчас это мусор в коде.

ShouldQueue...

@Adelf32 как раз вчера писал, что контракты нужно держать в той же папке. На твоем скрине. Но лично я против такого размещения, так как они получаются разбросаны по приложению. Куда логичнее хранить их в одном месте, например, App\Contracts.

ShouldQueue, окей, согласен это имеет место быть, так как твой контракт расширяет его и он может быть пустым при семантически понятном виде (namespace имею ввиду). В этом случае не ходи к кузнецам))

Нубский вопрос, но: объект валидатора (мой, не лары) возвращает в случае непрохождения некоторых проверок массив ошибок. Если валидация не прошло, то я бросаю исключение в котором есть метод report (т.к. мне нужно логировать ошибки которые вернул валидатор). Как мне в моё кастомное исключение передать массив ошибок? ничего если 1 аргументом конструктора (как message)? Это норм?

или лучше сразу собрать из массива строку?

🌚

а какая цель?

if (!$this->validator->validate($order)) {
    throw new AutoCheckoutException($this->validator->getErrors());
}

В свой эксепшен ты может и засунешь массив, но при дальнейшем прохождении должна быть одна строка

сделай так, как сделано в ексепшене лары

В каком именно?)