Алексей Уколов

where('price', '>', "%{ $p1 }%")
P.S. зачем по вашему тут нужен знак процента?

Класс, который реализует эту логику принимает объект работы с БД и объект работы с кэшем в качестве зависимостей.
В тесте вы вместо зависимостей передаёте моки и описываете для них требования по вызванным методам.
Всё - в проекте хорошая архитектура, тесты писать легко и приятно.

В документации есть ответы (с примерами) на все ваши базовые вопросы:
Querying Relations
Inserting & Updating Related Models

{!! !!}
Раздел документации называется зе бейсикс aka основы, почему бы вам с ним не ознакомиться?

Есть простой вариант:

dump(array_keys(\Illuminate\Support\Facades\Gate::abilities()));

Вариант посложнее: найти в своём коде вызовы Gate::define(), а потом в документации используемых библиотек посмотреть определяют ли они какие-нибудь гейты.

'paid_back_at' => [
    function (string $attribute, mixed $value, Closure $fail) {
        if ($value !== null) {
            $fail("The {$attribute} is invalid.");
        }
    },
],

https://laravel.com/docs/10.x/validation#using-closures

{!! !!}, не {{ }}
https://laravel.com/docs/9.x/blade#html-entity-encoding

Знаю про метод firstWhere

Это далеко не единственный доступный метод. В частности есть несколько методов сортировки. Вам даже уже давали пример их использования.

Нет, невозможно. Во-первых, когда вы вызываете where, возвращается уже объект QueryBuilder, который ничего про Eloquent не знает. Во-вторых, откуда Laravel знать, какие строки были реально обновлены, а какие этого не требовали? В-третьих, под капотом используется объект PDO, который сам по себе имеет доступ лишь к количеству реально обновлённых строк.

Вы в запрос вместо id передаёте объект.
"id" = { "id": 5,

Очевидно, у вас на сервере PHP 7.3, а нужна восьмая версия.

Нужно просто для всех команд списания с баланса использовать мьютекс, внутри которого:
1. Получать текущий баланс.
2. Проверять, что он больше, либо равен сумме списания.
3. Вносить изменения в БД, если всё ок.
Третий шаг можно реализовать по-разному - через таблицу транзакций, через единственное поле баланса, как у вас сейчас или ещё как угодно. Эта часть совершенно не важна.
Важно только то, что функционал списания с баланса в целом становится однопоточным за счёт блокировки.
Нужно только учитывать, что блокировка должна быть распределённой. Стандартом является использование алгоритма Redlock, реализованном на базе Redis.
Ещё важно использовать один блокировщик именно для всех типов списаний. Если вы в buyProduct будете использовать один мьютекс, а в каком-нибудь buyService другой, то работать это правильно не будет.

верно ли я понимаю, что для связки lara/vue про vagrant и homestead можно забыть?

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

теперь нужно вникать в docker?

Можно сказать, что на данный момент это промышленный стандарт.

или забить на все и на старом добром openservere? или может denwer?))

Нам фиолетово, забьёте вы или нет и на чём вы будете делать свои проекты.

Вместо провайдера можно использовать глобальный middleware. Не очень красиво, но технически - это самый прямой способ добиться нужного результата.

Зависит от конкретного поведения, которое вам нужно.
Если хотите, чтобы скрипт выполнялся не чаще, чем раз в три минуты, но при этом всегда в один поток, то есть withoutOverlapping.
Если хотите, чтобы скрипт выполнялся ровно каждые три минуты, но при этом не брал уже обрабатываемые записи, то просто добавьте поле со статусом для каждой из них (он может быть как булевым, так и более сложным) и в самом начале помечайте взятые, а выбирайте только невзятые.

Ну так и делать — миграции и нужны для случаев, когда «в БД меняются поля».

return Task::query()
    ->where('user_id', Auth::id())
    ->orderBy('when')
    ->pluck('when')
    ->map(fn(string $date): string => \Carbon\Carbon::parse($date)->format('d/m/Y H:i:s'));