d'Ivan

Вариант 1
Сервер SIEM (хост A) -> REST API (хост Б) -> логи Elasticsearch
микросервис REST API - на любом ЯП (языке программирования)

Вариант 2 с использованием proxy(по-моему, так интереснее и возможно даже проще):
Сервер SIEM (хост A) -> proxy (хост Б) -> логи Elasticsearch
Nginx Unit, Lighttpd, HAproxy и т.д.

Затем, дополнительно построить (микро)сервис (хост Б или В) периодически отправляющий запросы в Elasticsearch, подготавливающий нужные отчеты и отправляющий данные по ТГ или куда надо.

https://jekyllrb.com или подобные ему генераторы

Можно, к примеру, при помощи разметки RDFa:

Собирался использовать в качестве БД PostgreSQL или MySQL, а вот с выбором фреймворков и других компонентов возникают проблемы.

Вот и замечательно. Обычно берут одну из этих СУБД, чаще первую.

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

Надо продолжать собирать требования и на их основе искать решения.

Нужно взяться за протоколы передачи данных.
Начиная с геолокации:
1. что за устройства устанавливаются на грузовой транспорт?
2. куда должны передаваться данные?
3. с какой частотой?
4. какие ограничения у этих устройств?
5. кто получатель геолокации? какие посредники при сборе геолокационных данных?
6. что происходит при получении геолокационных данных?

В зависимости от решаемых задач с данными подбирается стек технологий.

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

Так как подробностей не предоставлено, то, в целом, схема коммуникаций может быть такой:
Интернет - маршрутизатор (с пробросом порта 80) - ПК с Windows.
Почитай о пробросе порта в Интернете.
Твоё веб-приложение будет доступно по адресу твоего IP, скажем, http:// 10.20.30.40 , то есть по незащищённому HTTP и будет обслуживаться чем-то типа uWSGI.
Затем, при помощи сервисов Dynamic DNS можно получить доменное имя, чтобы было легче запомнить вместо IP.
Далее, веб-сервер реализуешь любыми технологиями, веб-фреймворками или как желаешь.

Автоматизация с Chef, Ansible, Puppet, Terraform
Масштабирование - это обычно когда нужно больше машин (горизонтальное) или больше (одинаковых) сервисов на одной машине.

Регулярные выражения слабо подходят для модификации HTML.

Данные вещи могу реализовать с помощью подключения VSCODE-ом по SSH, но проблема в том, что нужен доступ для конечного пользователя, а подключение по SSH

Клиент будет массово редактировать HTML при помощи регулярных выражений? О, господи! А что за категория клиентов?
Возьми какой-то парсер HTML.

выделение части текста в фотографии

Гугли: Project Naptha . Под капотом Tesseract.js

Приходящие данные разбирать, десериализуя JSON, и сохранять в обычную реляционную СУБД с колонками на каждое поле в JSON. Затем составить запрос с группировкой по категории и последующим выводом результата в формате JSON.

а договора небыло. просто был прислан текстовый файл с заданием и я ответил что сделаю это.

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

Так что проще всего максимально оградить от проблем изначально, чтобы избежать недопонимания, как описал Владимир Коротенко . Ну и финансовая сторона. И действовать поэтапно, не выполняя работы без оговоренной предоплаты
Сроки и всё такое - должно быть описано, чтобы всегда был пункт

б) а если "так", то будет "вот так".

Это можно писать простым языком, не юридическим. Никому не хочется заниматься с судами и многие вопросы лучше заранее решать за их пределами.
Так что условия доставки ПО нужно хорошо обговорить. Кому-то достаточно доступа к GitHub,а кому-то нужно развернуть прямо в продакшен сервере. И даже на Маке ))

429 Too Many Requests

Уменьшить частоту запросов (не логично ли?). Не нужно "бомбить" сайт.

Стоит посмотреть на возвращаемые заголовки и посмотреть на заголовок Retry-After. Попытаться перезапланировать задачу скрэпинга на время согласно рекомендации заголовка.

После внедрения вышесказанного, если позволенная частота запросов не удовлетворяет, только тогда рассматривать всякие прокси сервера и прочие.

Если схематично, то как-то так:
User flow / UX -> wireframe -> tech. design -> API contracts (OpenAPI) -> front-end + back-end (параллельно, начиная с API mocking).

Весь цикл разработки должен происходить итеративно, с поправками. Невозможно продумать всё до мелочей.
Разработаете прототип по этой схеме и продолжаете наращивать функции, по не будет достигнут MVP.

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

Есть много вопросов к тому что из себя будет представлять конечный программно-аппаратный комплекс и для каких условий работы он предназначен. Одно дело, когда он расположен где-то в "тепличных" условиях в офисе/дома. И совсем другое дело, когда находится в шумном и пыльном цехе, где по кнопкам и экрану будут тыкать грязными руками. Ко второму должны предъявляться совсем другого уровня требования по надежности и не только.

физически подключать свой ноут к серверу

В смысле? Пойдут в серверную и будут подключать ноут к серверу кабелем? Что за бред? Если не бред, то по какому протоколу? И этот ноутбук нужен для постоянной работы с оборудованием? Или "сервером" будет достаточно мощный ПК? ПК и ноутбук в цехе? Серьёзно?

с видеокамер на которых отображается деталь

Это видеокамеры со встроенными экранами? Или же без, а изображение должно передаваться по кабелю на сервер?

будет потоковое видео и его обработка

К потоковой обработке видео, я полагаю, есть достаточно высокие требования и к железу и к коммуникациям (ширина канала, задержки, кабели, маршрутизаторы и т.д.). Должен быть чип DSP (если встраиваемое оборудование) или достаточно мощный процессор на ПК/сервере, который потянет обработку.

web или desktop

Десктоп - настольное оборудование, web - передача данных преимущественно по HTTP. Одно другому не мешает. Наверное, речь больше про выбор клиент-серверной технологии, таких как терминал-сервера с терминал-клиентами (Citrix и др.) или же комбинированного оборудования с периферией (допустим, ПК с подключеннами экраном, веб-камерой и другими устройствами). Из-за необходимости обработки видео терминал-сервер, похоже, не подходит.

Если, скажем, брать (промышленный) вариант ПК, тогда обработка видео будет происходить на нём и по сети гонять ничего не надо. Тогда настольное приложение может состоять из модулей обработки видео, бизнес-логики и пользовательского интерфейса - всё в одном. Для настольных приложений обычно берут C# (WPF), C++ (Qt), Delphi, Java (Swing, JavaFX). Модуль обработки видео можно использовать, подключив как библиотеку (SO, DLL), реализованную на любом высокопроизводительном ЯП.

Веб-технологии пока достаточно специфичны и ограничены. У меня нет пока представления как происходит пакетная обработка видео в вебе. WASM едва только пробует войти в веб и мало распространён. Одно дело на веб-приложении крутить фильмы, а нечто другое - обрабатывать на лету и встроить в пользовательский интерфейс. Так что к настольным веб-приложениям я пока несколько скептически отношусь. Они пока не предназначены для промышленного использования.