holllop

locomotive-scroll
ScrollMagic
scrolltrigger

Берёте и встраиваете экранируя все кавычки как минимум.
"message" => "<div class=\"models\"></div>",

JS код обычно не отдаёт через JSON. 'это какой то дикий костыль получается JS код лучше описать отдельно и отдавать некие условия, чтобы он отработал потом на основе ответа JSON. Например добавить параметр в JSON "status" => "error" и "status" => "success" и в JS через if условия.

Вы обнуляете переменную prev при каждом вызове функции. Используйте замыкание

Метода нет, но полно библиотек, которые это делают. Но можно и самостоятельно вот к такой простой конструкции привести исходную строку: +new Date('2024', +'02' - 1, '01') / 1000.

$tel = '79000000000';
$formatted = preg_replace(
    '/(\d)(\d{3})(\d{3})(\d{2})(\d{2})/',
    '+$1 ($2) ***-**-$5',
    $tel
);
var_dump($formatted);

ps регулярку можно уменьшить немного

$formatted = preg_replace(
    '/(\d)(\d{3})(\d{5})(\d{2})/',
    '+$1 ($2) ***-**-$4',
    $tel
);

$formatted = preg_replace(
    '/^(\d)(\d{3})\d+(\d{2})$/',
    '+$1 ($2) ***-**-$3',
    $tel
);

В серьезных компаниях невозможно состояние гонки релизов, которую вы описали.
Во-первых, информационная система используется не в одном экземпляре. Всегда есть как минимум продакшен экземпляр, предпродакшен и девелоп экземпляры системы. В предпродакшен и девелоп версии могут загружаться не только разные релизы кода, но и гонятся разный набор данных для отладки и тестирования.
К этим экземплярам и набору данных имеют доступ разные работники, с разным уровнем допуска и ответственностью. Рядовой разработчик не будет иметь доступ в продакшен и предпродакшен, для него вышестоящий работник сформирует девелоп версию и подготовит нужный набор данных, который нужен именно для решения его рабочей задачи. Также рядовой разработчик не будет иметь полный доступ к действиям в репозитории, он может действовать только в рамках своей дев ветки, никто ему не даст прав сливать в мастер.
Для каждой новой разработанной функции пишутся автоматические тесты, как минимум с одним тестом, что она включается, эти тесты пишет отдельный контингент работников.
Прежде чем код попадет в продакшен, он будет просмотрен вышестоящим работником, его функционал будет протестирован сначала на тестовых данных, потом на боевых, с каждого теста будут сняты метрики не только по возникающим ошибкам, но и по производительности.
Уже на основе всех этих данных и будет принято решение компетентным работником вливать ваш функционал в прод или нет. Вместе с этим будет принято решение на слияние в мастер в репозитории.

=QUERY(A:A;"Select max(Col1) group by  month(Col1)")

Это венгерская нотация.
Как правило, сейчас её не применяют

Есть две категории случаев, где следует использовать хранимые процедуры:

1. Сложные запросы, которые нельзя выразить обычным SQL и при этом слишком дорого отправлять более крупный набор данных клиенту, чтобы он сам всё посчитал.

2. У тебя несколько клиентов и тебе нужно гарантировать целостность. Тогда ты всякие валидации из обычного кода переносишь на СУБД.

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

Метод querySelectorAll возвращает коллекцию элементов и у неё нет свойства onclick, метода addEventListener и т.п.
По коллекции нужно итерировать и назначать обработчик события для каждого элемента в отдельности.
Как это сделать, написано в каждом первом учебнике JavaScript.

console.log(typeof settings);
console.log(typeof flag);

Почти уверен что там будет строка в одном или обоих случаях. Поэтому проверка и не работает.

Нужно ли обычную форму обратной связи лендинга защищать от спам-ботов?

Нужно.

Если да, что можете посоветовать?

От самопала, вроде скрытых полей, которые человек не увидит, зато увидит глупый спам-бот, до нормальных решений вроде reCAPTCHA или Yandex SmartCaptcha.

Я использую именно reCAPTCHA (но не показываю ее, чтобы народ не злить), затем проверяю, если риски спама велики - шлю письма с высокими рисками на email с дополнительной пометкой (спам), письма автоматом сортируются в почтовом ящике по наличию спам метки, где приоритетные обрабатываются приоритетно (внезапно), а все остальные - если успеем.