Евгений Педя

Определитесь с зонами ответственности.
Админка одно, а публичный доступ другое.
Определитесь с требованиями к паролю и ограничьте доступ к админке только с определённых IP.

Далее чётко дайте знать пользователю, что его пароль - это его ответственность.

Добавьте двух факторную авторизацию.

Если начинают ломать, то брутфорс - это только один из подходов.

Начинать нужно с функциональных требований. Всё остальное лишь инструменты для их реализации.

Не понятно как проверялось не прохождение запросов. Изучался лог сервера?
Если хостер не адекватный и дропает запросы через проксирование, то лучше его сменить.
Если речь о приёме вебхуков по POST ничего не возвращающих кроме статуса 200, то лучше принятые данные сохранить и передать id или имя файла скрипту запускающемуся в фоне.
Если речь об запросах к REST API на PHP, то узкое место при множественных одновременных запросах от одного клиента это сессии в PHP. Сессии при REST API как правило не нужны, а потому максимально быстро переключаем их в режим только чтения.

В файле докеркомпозе для разработки оставляю консоль для контейнеров

...
python_server:
        stdin_open: true
        tty: true
        ...

Потом конекчусь к запущенному контейнеру
docker exec -it <имя контейнера> bash
И делаю в нём что нужно. Например, запускаю и кладу свой скрипт. И прочее.
При этом правлю код снаружи.
В докер композе для публикации лишнее убирается и код размещается в контейнер.

Решайте задачи в новых областях с новыми инструментами.

Разбрасывать посты по модерам рандомно. Модераторы видят только свои посты.

Дать возможность отказа от модерации поста. Возврат поста в общий пул с переадресацией другому модератору с меньшим числом постов. Сдесь есть возможность, что посты будут гулять между модераторами по кругу.

Создать возврат авто переадресации поста, если модератор его не открывал, после определенного времени. Это как предыдущее но без воли модератора.

Дать возможность создания тикита поста по постам модерированым другим модератором.
И прочие усложнения.

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

В том и идея BBCode, что текст хранится и редактируется с ними, а отображается с html тегами.
По этому можно создать функцию хэлпер для преобразования.

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

0. Используем систему версий, делаем ветки. Перед началом работы переключаемся на нужную ветку, а не лезем в код. Таким образом мы сразу выделяем нужный кусок задачи для изменений.
1. Разбиваем задачи на максимально понятные куски действий. Если в требуемом есть хоть что-то не понятное, не пройденное и вызывающее неуверенность, то работать будет трудно. По этому планируем задачу по изучению.
2. С непонятным разбираемся через эксперименты и тестовый код минимального размера. Пусть эти шаги кажутся примитивными, но они легко воспринимаются мозгом. Иногда эксперименты с новым проще делать вне кодовой базы проекта на минимально необходимом коде.
3. Чужой гадкий код форматируем для лучшего чтения. Про свой и упоминания не должно быть в этом плане. Чем хуже читается код, тем быстрее устаёт мозг его воспринимать.
4. Стараемся код разбить на минимально понятные куски и из них автоматом собирать то что нужно.
5. Выполненные задачи в списке отмечаем. Хорошо видеть свой прогресс.
6. В коде оставляем тудушки (TODO), но если их список поддерживает IDE. Иначе выносим в отдельный список.
7. Стараемся формировать свой "поток действий". Например для страницы отображения: добавить роут; добавить, если нужно, контроллер; добавить метод; добавить пустой шаблон отображения; записать в нём, что должно отображаться; добавляем в него передачу одного из нужных данных; делаем отображение или проверку его наличия; повторяем со всеми нужными данными и т.д.
8. Перемежаем рутинное написание кода с изучением непонятного и разбором задач. При этом пишем вопросы и конспекты. Потом при новом обращении перечитываем. Не боимся быть капитаном очевидность. Находясь в контексте мы много считаем само собой разумеющимся, но при новом включении в задачу через некоторое время что-то выпадает.
9. В выходные отдыхаем.

Если что-то меняется редко, а нужно удобно, то вполне себе оно. Ещё копировать/переносить удобно в оперативном плане.

Какой-нибудь скрипт синхронизации с веб интерфейсом для настройки.
Какой-нибудь калькулятор с веб интерфейсом настройки.

Возможно прозвучит странно, но используйте кроме дебага форматирование кода, расстановку комментариев с вопросами и общее описание вашего понимания с вопросами. Разгружайте голову.

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

И ещё сразу совет в контексте. Если будет много копипаста и смесь грузина с чемоданом php html js и css, то требуйте до перехода к внесению нового функционала времени на рефакторинг кода. Иначе отказывайтесь.

Есть основные команды. Их указали выше.
Можно и через GUI работать, но всё же понимать, какая команда вызывается.

И есть поток разработки. Его то же не плохо понимать.
Вот старая, но не устаревшая статья https://habrahabr.ru/post/106912/

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

Первое, ТЗ вам не нужно, по крайней мере сразу. Нужны ФТ (функциональные требования). Это то что клиент хочет его языком с некоторой коррекцией, так как заказчик многое умалчивает, так как это для него по молчанию. Вас должны интересовать роли пользователей (гость, зарегистрированный, админ, зарегистрированный с такой или иной целью, гость с той или иной целью). Вас должна интересовать структура скринов приложения/страниц сайта (которые могут быть скорректированы в связи с потребностями юзабилити). Вас должны интересовать данные, с которыми вам придётся работать и в каких точках. И это ещё не всё. Порядок событий и их условий.

А вот ТЗ - это уже для вас. Как вы построите решение техническое и как его часто будите менять во время процесса решения задачи.