Vitsliputsli

Либо, раз это представление:

<div class="outofstock">
    <span class="meta-name"><?= _e('in stock', 'detail') ?>: </span> 
    <i class="fas fa-times"></i>
    Нет в наличии
</div>

"Математическое обеспечение и администрирование информационных систем" или "Программная инженерия"

Интересно, на что рассчитывают учебные заведения, если по названиям специальностей никто не может понять, кого они готовят. Что выпускники в сопроводительных письмах работадателю сами будут объяснять, кто они... Мне кажется, одно это - показатель оторванности ВУЗов от реальности. А так да, смотрите учебный план.

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

systemd/timer

Так добавьте в Cron, перед командой перезапуска, запись времени. Лог, я так понимаю, прямо из cron пишется?

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

Можно так извратится:

SELECT * 
FROM table 
WHERE (id, make_name) IN (('1995','TOYOTA'),('5015','FIAT'),('1010','BMW'))
ORDER BY CASE 
    WHEN id='1995' THEN 1
    WHEN id='5015' THEN 2
    WHEN id='1010' THEN 3
    END

Либо делать предварительную выборку и джойнить.

Триггеры очень не очевидная вещь, поэтому если хочется в БД перетащить часть логики, то лучше сделать процедуру для этого.

операторами ветвления

Извлекать в контроллере, переводить во вьюхе.

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

Определиться с использованием данных и выбрать наиболее подходящую форму хранения. И конвертировать из другой формы.

Как уже написали, функциональные тесты перед исполнением заливают данные, а после исполнения их вычищают. И это логично, т.к. для разных тестов могут понадобить совершенно противоположные данные.
Почитайте про fixture. А для генерации тестовых данных используют faker.