Vitsliputsli

Как вариант, передавать в переменную значения разделенные запятыми, в процедуре IN заменить на FIND_IN_SET, что-то вроде:
select * from test where find_in_set(field, 'var1,var2,var3')>0;

Не хватает, как минимум:

#include <fcntl.h>

char buf[7];

Для MySQL <=5.7

select
    id,
    date,
    @s:=(case when type=1 then 1 else -1 end)*sum + (case when @t<>id then (@t:=id)*0 else @s end) sum
from (
    select * from tt order by id,date
) t, (select @t:=1,@s:=0) t2

Либо 2FA, либо меняйте пароль каждый раз.
Либо что-то извращенное, например, если сайт простой, то авторизовываться у себя, и передавать на удаленную машину куку, и не забывать закрывать сессию.

А в чем сложность? В php целый ворох команд, типа exec, для запуска внешних приложений. Используйте их.
Хотя скорее всего этого и не нужно, но без описания задачи не угадаешь.

Я не понял, какая разница между zero и null?

zero - это ноль;
null - это отсутствие значения.

/dev/zero при чтении генерит поток нулей, при записи игнорирует все что в него попадает.
/dev/null при чтении отправляет конец файла, при записи игнорирует все что в него попадает.

Откуда взялся /etc/cron.daily ? Скрипты оттуда стартуют только 1 раз в сутки в определенное время. Используйте обычный список крона.

Вместо
(`task`.`executor_id` != 5)
нужно написать
(`task`.`executor_id` is null)

откуда взялось 5 совершенно непонятно.

Вы так пишите, будто хотите чтобы вас пожалели и поддержали. Это лучше к близким.

Вы бы стали работать при таких условиях дальше, при том что уже работаете полтора года и такие вещи случается довольно часто?

При условии 30к? Насколько это соответствует вашим навыкам никто здесь не знает.
По поводу просьбы исправить свои косяки в нерабочее время - да, вы не обязаны этого делать в нерабочее время, но и с точки зрения работодателя вы по факту не сделали свою работу в рабочее время. И тем более, если исправление ошибки не ждало рабочего дня. Кто в итоге ее исправил? Вы в рабочий день? Или ваш начальник сам разбирался?
Как вы этот конфликт будете решать зависит от вас, для кого-то это нормально, кому-то это компенсирует зарплата или иные моменты.

Если же хотите не только погрустить, но и что-то делать, то как уже написали, идите на собеседования и от этого уже отталкивайтесь. Менять что-либо всем страшно, но без этого ничего не изменится, подумайте что будет через 5, 10 лет.

Если версия MySQL позволяет, смотрите аналитические функции.
Если нужно на 5.7, то можно применить следующую магию:

select 
        case when @userId<>user_id then @q:=1 else @q:=@q+1 end q,
        case when @q=1 then @userId:=user_id else @userId end user_id
    from (select * users_images order by user_id) t1, (select @userId:=0, @q:=1) t2
    where user_id<>@userId or (user_id=@userId and @q<=2)

Здесь мы получаем из таблицы users_images по 3 элемента в каждой группе по user_id. Лимит установлен в самом конце <=2 - означает 3. Выглядит кошмарно, но решая такие задачи переменными mysql часто получается так.

Исходники проекта, ядра и модулей - это одно. Бизнес-проекты, для которых собираем билды из первых - это иное. Git - это система контроля версий исходного кода, она не занимается решением вопросов бизнеса. Поэтому не стоит через git решать вопросы кому какие модули были проданы.
Если смотреть шире, то пусть разработчики пишут код (в одном репе, в нескольких репах: ядро и модули, как вам удобнее). А в каком виде собирать билд очередному заказчику пусть решают и делают другие люди (а если даже и те же, то все равно в рамках совсем иного процесса).

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

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