Interface Collection

Задача

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

Как изменение проходит путь до публикации

1. 01

   Ограничить область изменения

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

2. 02

   Собрать все представления из проверяемых данных

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

3. 03

   Отладить связку веб-приложения и API в контейнерах

   В Aster Ridge веб-приложение и API запускаются в отдельных контейнерах. Для обычной отладки используется горячая перезагрузка. После изменения зависимостей команда синхронизирует тома, после правок Docker или Compose — пересобирает образы. Журналы и проверки готовности показывают, где произошёл сбой: в API, прокси или веб-приложении. Перед публикацией та же производственная конфигурация запускается локально: веб-сервис ждёт готовности API, наружу публикуется только веб-сервис, а API остаётся во внутренней сети.

4. 04

   Передать Coolify выбор целей публикации

   У каждого развёртываемого приложения есть свой Dockerfile и набор отслеживаемых путей. После обновления ветки публикации Coolify сверяет изменённые файлы с этой матрицей: локальная правка пересобирает одно приложение, изменение общего пакета — только его потребителей, а документация не запускает сборку. Матрица проверяется по всем восьми приложениям и тестами выбора путей, поэтому пропущенное приложение или неверное правило обнаруживаются до выпуска.

5. 05

   Опубликовать проверенный коммит и сверить результат

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

Архитектура с видимым результатом

• Одна запись, несколько представлений

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

• Портфолио не подменяет продукты

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

• Карта возвращает к читаемой карточке

  При выборе проекта карта технологий передаёт каталогу только его идентификатор. Каталог прокручивает нужную карточку и выделяет её; на узком экране остаётся обычный список. Так карта показывает связи, но не подменяет читаемый каталог и не требует второго хранилища состояния.