Оба дефекта вскрылись сборкой образа после слияния веток.
1. public.ts: SQL выбирает content_json_en, а описание типа запроса пришло из
ветки визиток и этой колонки не знало — tsc отказывался собирать. След
слияния: запрос из одной ветки, тип из другой.
2. Английские колонки (sections.content_json_en, products.title_en/subtitle_en/
description_en) существуют на боевой базе, но их не создаёт ни одна
миграция — когда-то добавили руками. На бою работало, на любой ЧИСТОЙ базе
приложение упало бы на первом запросе /api/content. Заведена 005 с
IF NOT EXISTS: на бою пусто, на чистой базе создаст.
Проверено на живом сайте: образ собран, контейнер healthy, миграции 004 и 005
применились сами, /api/content отдаёт 4 раздела на двух языках, 2 продукта,
полные реквизиты; страница визитки отвечает 200.
Две линии разработки разъехались и месяц жили порознь: в Gitea уехали
электронные визитки с QR-кодом, а в рабочей копии на fortress остались шесть
коммитов, которые до репозитория не дошли и, значит, не попали на сайт —
английская версия с переключателем языков, карточка Бонитировки, логотипы
продуктов, реквизиты компании в подвале, убранная кнопка Telegram, имя
директора латиницей. Плюс незакоммиченное бургер-меню.
Что разрешено вручную:
1. Landing.tsx, блок контактов. Столкнулись наша расстановка (почта главной
кнопкой с подписью из cta_primary, телефон второй) и правка из Gitea,
переводящая оба контакта с href на onClick, чтобы адрес и номер не лежали
в разметке и их не собирали боты. Взято и то, и другое: защита от ботов
сохранена, порядок и оформление наши, адрес почты в подписи не светится.
2. Коллизия номеров миграций: обе стороны завели номер 003. На живой базе
применены 001, 002 и 003_business_cards, а 003_product_url_and_requisites
не выполнялась никогда — она и переименована в 004, чтобы раннер (он
отслеживает миграции по имени файла) отработал её штатно.
3. package-lock пересобран под слитый манифест, а не выбран со стороны.
Проверено: tsc чист, vite build проходит, 118 модулей, 241 КБ.
Две одинаковые серые плитки не давали понять, что это разные приложения,
а у Бонитировки стояла служебная заглушка вместо логотипа.
- logo_url и brand_color у продукта; логотипы взяты из самих приложений;
- фон и рамка карточки — мягкий градиент фирменного цвета, ссылка тоже;
- в шапке было «1 — ФЛАГМАНСКИЙ ПРОДУКТ», стало «2 — ПРОДУКТА В PRODUCTION».
Нужна для проверки компании иностранными партнёрами и магазинами приложений:
проверяющий должен понять, кто мы и чем заняты, не зная русского.
- переводы лежат в тех же строках БД (products.*_en, approach_items.*_en,
sections.content_json_en, settings.company_name_en/company_address_en),
админка остаётся одна;
- фронт откатывается на русский ПО КАЖДОМУ ПОЛЮ отдельно — недопереведённая
секция не оставляет пустого места на странице;
- выбор языка запоминается в localStorage, проставляется <html lang>.
Нужно для подтверждения принадлежности сайта компании: по реквизитам
организацию проверяют контрагенты и магазины приложений, а ссылка связывает
ООО «Умный Байт» с его продуктом АгроТО.
- products.site_url (миграция 003), отдаётся в /api/content;
- в карточке продукта — ссылка на сайт;
- в подвале — ИНН, КПП, ОГРН, юр. адрес, генеральный директор, почта и телефон.
Значения лежат в settings, правятся через админку без пересборки.
zeroday
admin