Vitsliputsli

Зачем? Что вы хотите получить? Что вам не нравится сейчас?
Нет универсальных решений, чтобы все было хорошо, смотреть нужно по ситуации. К примеру, есть ли смысл контейнеризировать, на это вы сможете ответить только сами. Прикиньте плюсы и минусы, стоит ли сейчас тратить на это время, чтобы получить сомнительные (а может и нет) плюсы. Когда для всех разработчиков есть одинаковое готовое окружение - это хорошо, но когда эти все - 2 человека, стоит задуматься.
Насчет схемы, опять же, что вы хотите ей решить, что есть у вас сейчас. Если этой схемой вводите ветку dev - отлично, будет где интегрироваться разработчикам. Сказать, что это должно быть must have - да, но для спринтовой релизной системы, при rolling releases и отсутствии постоянной необходимости интегрироваться - не обязательно.
Если же хочется просто следовать трендам, то по этим вопросам docker и git-flow.

ПМ обычно не пишут ТЗ, т.к. ТЗ - это техническое задание, т.е. подразумевает техническую экспертизу. Если же речь, про некие функциональные требования, то писать обычным человеческим языком, придерживаясь правила писать то, что хотим получить и для чего, а не как это реализовывать. Этого вполне достаточно. Будет ли на основе этих требований формировать ТЗ отдельный специалист или сам разработчик, это вопрос организации компании.
Разработчик - это переводчик с человечьего языка на язык машин, если он не знает одного из языков, то беда. Поэтому этакий разработчик-интроверт, который не умеет общаться, но отлично пишет код, это проблема, т.к. переводчиком он работать не сможет.
Но как бы вы не писали ФТ или даже ТЗ, без коммуникаций во время разработки результат может неприятно удивить, отсюда и стали развиваться различные agile-направления. Насчет "писать обычным человеческим языком" тоже не нужно бросаться в крайности, а то были на моей памяти "одаренные", которые удаляли блок-схемы описывающие бизнес-логику и писали их человеческим языком в меру своих возможностей, это, конечно, уже бред.
Исходя из всего перечисленного, вполне возможно, что ваша проблема не в "правильном" написании ТЗ, а отсутствии коммуникаций и подхода "ничего не знаю, я сделал как в ТЗ" со стороны разработки. Проблема частая, но одним простым советом ее не решить.

Порог входа такой же как везде. В одной компании, как написали "одна рука и один глаз, можно без ног", в другой вас будут спрашивать об инструментах автоматизации и методологиях тестирования.

Но, у одного юзера может быть несколько ID (так устроена система).

Значит это не id юзера. Сделайте реальное id юзера и указывайте его в ваших алиасах. Далее группируйте по реальному id юзера. Либо сделайте таблицу соответствия и группируйте через нее.

Что-то вроде GROUP_BY (users.id = 123 OR users.id = 789).

Это хардкод. Если сейчас вы и решите текущую задачу таким образом, далее будут большие проблемы из-за подобного подхода.

Язык - это инструмент, как фреймворк, как библиотека и т.п. Их изучают при необходимости использовать или при потенциальной необходимости использовать при потребности рынка. И как уже писалось множество раз, языки вторичны, изучать нужно программирование, разработку в первую очередь.

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

Куда бы вы размещали шаблоны модуля админки? Вместе со всеми в папке views/layouts или в папке views/layouts/admin, то есть вот если несколько шаблонов для админки, то выделять ли их из шаблонов приложения отдельной папкой, как это сделано в контроллерах и вьюхах?

В директории mymodule/views/layouts. Если это действительно модуль, т.е. отдельный, функционально независимый кусок кода.

Или в операциях == и != что-то не так?

Используйте операторы сравнения === и !==, и сравнивайте с учетом типа переменных.
0 не равен false, но при динамичской типизации, будет произведено приведение типов и затем сравнение.
Чтобы не возникало вопросов, таких как у вас сейчас, сравнивайте однотипные данные, а не предполагая, что будет после динамического приведения типов.

но почему то под нулевым индексом что то есть

Документация по explode:

Если delimiter не содержится в string, и используется отрицательный limit, то будет возвращен пустой массив (array), иначе будет возвращен массив, содержащий string.

Для MySQL 5.7 можно через сортировку, таким образом:

SELECT 
    qt,
    CASE WHEN @group!=gr THEN @qt_min:=qt ELSE @qt_min END min,
    CASE WHEN @group!=gr THEN @group:=gr ELSE @group END gr
  FROM qw, (select @group:=0) t
  ORDER BY gr,qt

Но, конечно, лучше так не делать.

$i = 0;
foreach ($posts as $post) {
    if ($i % 2 === 0) { 
        echo '<div>'; 
    }
    echo '...';
    if ($i % 2 === 1) { 
        echo '</div>'; 
    }
    $i++;
}

Цитата из мануала по PHP о константах:

Значение должно быть неизменяемым выражением, а не (к примеру) переменной, свойством или вызовом функции.