Виктор Кожухарь

Нет. Всё, что попало в интернет - остаётся там навсегда. Особенно все изменения в git репозитории - копии его есть не только на сервере, который вам не принадлежит и в организации, в которой вы вряд ли админ/владелец, так еще и у всех остальных разработчиков тоже есть копия.

Настроить можно...

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

Как скоро выловят вашу серую "схему" при таком подходе? Может даже сразу. Что сделают? Скорее всего будут показательно пороть, при массовом стечении народа, и не будут разбираться - а зачем оно вами было сделано (ну как слуба безопасности, которая будет вас наказывать, может прийти к выводу, что корень проблемы в самой службе безопасности?).
Возможно даже выстявят на мороз...

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

- Первый (крайне эффективный, но часто малореальный) - "итальянская забастовка" - это когда все начнут работать строго по правилам безопасности и КПД труда станет близок к нулю. Это приведет к краху работы и руководству "прилетит по башке", да так, что придется разбираться с неприкосновенными безопасниками.
Или вашему руководству придется, или другим людям вместо них, если они не справятся (вместе со сменой руководства).
Но возможно, что большинство работников морально не готовы к такому шагу. Их держит в страхе великая вера в бесконечную силу управленцев, да к тому же "за забором стоит очередь из желающих"... Они не видели ни разу, что происходит, когда весь коллектив разворачивается и уходит из офиса. И как мгновенно решаются все вопросы, когда под директором начинает качаться стул.
Хотя чаще бывает так, что большинство сотрудников действительно можно заменить - ведь когда бюрократия и кумовство - многие некомпетентные товарищи могут сидеть на "теплых" должностях, ничерта не умея работать. А из рабочих навыков - у них хорошо развито только чувство собственной важности.
Тварь вы дрожащая, или право имете? Можете сказать свое мнение открыто там, где оно будет услышано?

- И второй путь, вполне реальный, зависит только от вас. Вы о нём знаете, думаете... Ведь это слово "бежать".
И со временем он у вас обязательно превратиться в нечто гораздо более конкретное - "быстро бежать".
Так не лучше ли, вместо страданий и героического преодоления искуственно создаваемых трудностей, в ожидании момента, когда вам скажут "Мери Поппинс - до свидания!" - принять решение и самому освободиться от оков?
И сменить работу, улучив удачный момент.

возможно сделать то что Вы хотите, но Вы можете за это огрести вплоть до увольнения
пишите служебки, пусть админы делают то, что нужно Вам для работы
Это самый логичный вариант

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

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

Если работаешь с vue - тебе не нужно трогать dom руками и наоборот.
v-html только для статических каких-то данных.

Вот это вот <b class="aaakjhij" data="hk">jjj!!!!</b> должно быть уже в шаблоне. Если надо по условию - то использовать v-if или v-for если несколько.
Примерно так:

<script>
export default {
  data() {
    return {
      data: 'hk',
      text: 'jjj!!!!',
      show: false
    }
  },
  methods: {
    _jjj(){
      this.show = true
      this.data = 'hk';
      this.text = 'jjj!!!!';
    },
   _kkk(){
      this.data = 'ooooooooooo';
      this.text = 'ha-ha-haaaa!!!'
    }
  }
}
</script>

<template>
  <div>
    <b v-if="show" :data="data">{{text}}</b>
  </div>
  <button @click="_jjj">11</button>
  <button @click="_kkk">12</button>
</template>

Тебе надо перестать мыслить в jquery и начать мыслить в vue.

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

Нет никакого ограничения в 65К портов. При трекинге TCP-потоков используется связка "src ip:port - dst ip:port".

А теперь возьмите не синтетический тест, а реальную задачу сложнее перекладки json'ов, например, с шифрованием, дайте серьëзную длительную нагрузку и посмотрите латентность по процентилям.

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

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

На Го очень просто писать многопоточность и асинхронность, не нужно думать об await-ах, каждая горутина имеет свой стек, что снимает с программиста много головной боли. Вся стандартная библиотека и большой набор библиотек с гитхаба из коробки поддерживают асинхронность и потоковую обработку данных, работать с этим сильно проще, чем в других языках. Соответственно, сложнее накосячить.

Но абстракций на Го очень мало, по сравнению с той же Джавой, он довольно бедно выглядит (что и дает простоту чтения кода). Это является минусом в определенных ситуациях, поэтому на Го стараются писать небольшие сервисы.

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

сменить работу - пока не вариант

Когда будет вариант, ищите сразу позицию senior.

Пока нет варианта, остается только узнать у текущего руководства что нужно для перехода на позицию senior.

Если бы я был преподавателем, то хотел бы, чтобы проект лежал в репозитории github, причём готовый к развёртыванию одной командой.

Похоже на попытки повесить ваш сайт.

Но недавно, почитав статьи и узнал, что яндекс плохо обрабатывает SPA приложения в поиске (В сравнении Google)

Google не лучше.

как можно решить проблему SEO на вот таком вот стеке?

Фронт должен создаваться как SSR (если нужно SEO), не совсем понял, для чего Вы указали Go, но схема примерно такая: Go -> SSR -> JS. Не знаю, что там сильно актуально для Vue, но например для React это NextJS.