D3lphi

А чему он, собственно, противоречит? Вот у вас есть какой-нибудь произвольный PostService, который вы инжектите в PostController. PostService зависит, например, от PostRepository и CommentRepository (которые являются интерфейсами). У PostRepository имеется конкретная реализация, например, DoctrinePostRepository. Тоже самое и у репозитория комментариев. Сервис контейнер об этом знает, ибо мы все это забиндили в сервис провайдере:

$container->singleton(PostRepository::class, DoctrinePostRepository::class);
$container->singleton(CommentRepository ::class, DoctrineCommentRepository ::class);

То есть, контейнер сумеет разрешить зависимости PostService. Теперь вопрос к вам: для чего нам явно указывать что-то в сервис провайдере, если контейнер и так в состоянии самостоятельно создать объект, передав ему нужные зависимости?

Дабы пользователь не использовал какой-либо url в корыстных целях, все параметры запроса хэшируются с использованием секретного ключа, который есть только у сервиса оплаты (mysite1.com) и у сервиса-клиента (mysite.com). Когда происходит запрос, хэш вычисляется повторно и сверяется с тем, который пришел в запросе. При попытке всячески изменить значения параметров контрольные сумма будут не совпадать.

Есть подозрение что этот подход не верный

Абсолютно. Не понятно, чем вы руководствовались, когда писали статику, да ещё и в контроллере. Читаем, чтобы впредь не делать такого.

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

Вся работа с БД должна производиться в репозиториях.
Репозиторий работает с сущностями, так что, в случае использования active record ORM, из ar модели нужно будет создавать сущность и возвращать ее из репозитория. Не даем подключению к БД "гулять" по проекту. Entity это обычный popo в котором нет какой-либо логики, а есть лишь набор полей, геттеры, ну и методы для обновления состояния.

Например:

class EloquentUserRepository implements UserRepository
{
    public function findBySomething(string $something): ?UserEntity
    {
          $user = User::where('something', $something)->first();

          if ($user !== null) {
              return new UserEntity($user->id, $user->something);
          }

          return null;
    }
}

Может в строну доктрина копать?

Верное решение. Лучше откажитесь от eloquent и возьмите doctrine, если проект требует серьезной ORM.

Весь js и css код, который пишите вы складываете в директорию resources/assets/js и resources/assets/css. Затем, при помощи таких инструментов как gulp или webpack, вы собираете весь js-код и стили в 2 файла public/js/app.js и public/css/app.css.

$table->foreign('user_id')
          ->references('id')
          ->on('users')
          ->onDelete('cascade');

Это не создание поля, а создание внешнего ключа.

Illuminate\Filesystem\Filesystem::delete()

app(Illuminate\Filesystem\Filesystem::class)->delete(public_path('uploads/example.png'));

Судя по скриншоту, IDE (и, предполагаю, php) не знает, что такое оператор ??.
Очевидно, у вас стоит php < 7. В то время как для работы Laravel 5.5 требуется php >= 7.

$id = Example::insertGetId([
    'key1' => 'value1',
    'key2' => 'value2'
    // ...
]);

Или

$id = Example::create([
    'key1' => 'value1',
    'key2' => 'value2'
    // ...
])->id;

Где Example - модель Active record.

Да, по реализации все верно вы себе представляете.

Как все это смотрится с AR?

Откровенно скажу, с AR это смотрится хреново. В том смысле, что вы не используете основные "преимущества" (Да, да, в кавычках, потому что эти самые преимущества облегчают и ускоряют разработку, но никак не способствуют улучшению качества кода и его поддержке) этого паттерна.

В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

Создать базовый интерфейс для всех репозиториев и в нем описать эти методы, затем расширить интерфейс каждого конкретного репозитория. Можете плюсом ко всему написать абстрактный класс репозиторий и в нем написать универсальную реализацию этих самых общих методов (Для каждого типа репозиториев, разумеется). Но лично я бы так делать не стал.

Правильно ли я размышляю вообще?

Да, по реализации все верно вы себе представляете.

$auto = Auto::create([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::create([
    // ...
    'auto_id' => $auto->id, // Ох уж это магия... Создайте лучше геттер.
    // ...
]);

Или

$id= Auto::insertGetId([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::insert([
    // ...
    'auto_id' => $id,
    // ...
]);

Можно связать "модели" отношениями и делать так:
$user->auto()->attach($auto);

Добавить правило nullable.

Ну что тут думать? Написано же, класс Symfony\Component\Console\Input\ArgvInput не найден. Идете в vendor/symfony/console/Input, смотрите, все ли в порядке с файлом ArgvInput.php. Если да, то скорее всего, проблема решится выполнением
composer dump-autoload
Если файл действительно отсутствует, то выполните установку зависимостей повторно.

Добавьте правила sometimes и nullable.

sometimes|nullable|url|max:40