Вентпром

Витрина, кабинет клиента и админка — это три разных продукта с разными макетами, разной навигацией и разными правами. В App Router они живут как три группы маршрутов в одном дереве: (site), (workspace), (admin). Каждая приносит свой layout.tsx, но все три делят один слой данных, одну схему Prisma и одно расчётное ядро. Доступ к админке режется в middleware.ts по роли в токене, до того как отрисуется хоть один компонент.

Фасеты сделаны маршрутами, а не состоянием клиента: /catalog/application/[type], /catalog/capacity/[range], /catalog/equipment/[category], а числовые диапазоны приезжают в searchParams и собираются в один Prisma-where на сервере. Причина простая и не техническая: подборку нужно уметь переслать коллеге ссылкой, а страница должна открываться уже со списком, а не с крутилкой.

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

1. Подбор типоразмера selectSizeVariants() перебирает типоразмеры серии из базы, считает скорость в живом сечении и оставляет те, что уложились в ограничения. Возвращается список вариантов с пометками «оптимальный» и предупреждениями, а не единственный ответ.
2. Расчёт секций по цепочке 12 расчётчиков в SectionCalculators: фильтр, роторный и пластинчатый рекуператоры, водяной и электрический нагреватели, водяной и фреоновый охладители, вентилятор, шумоглушитель, секция смешения, заслонка, гибкая вставка. Каждый принимает SectionInput — расход, габарит, температура и влажность на входе — и отдаёт SectionResult с параметрами воздуха на выходе. Психрометрия честная: влагосодержание, энтальпия, точка росы, температура мокрого термометра по формуле Стулла.
3. Валидация топологии 18 правил в build-validation.ts проверяют не числа, а порядок: максимум один вентилятор на ветку, фильтр обязан стоять перед рекуператором и перед теплообменником, увлажнитель — не где попало, гликолевые рекуператоры — только парой, газовый нагреватель требует пустой секции после себя. Ошибки делятся на блокирующие и предупреждения: первые останавливают расчёт, вторые просто видны рядом с результатом.
4. Сборка спецификации BOMService добавляет к секциям то, о чём клиент не думает: датчики перепада давления, защиту от замерзания, приводы клапанов, частотники, щит управления. Набор выводится из состава установки — каждый датчик в справочнике привязан к типу секции и к признаку «один на установку» либо «на каждую секцию».
5. Автоматика по правилам, а не по опыту ahu-configurator-logic.ts отвечает на вопросы, которые раньше решались памятью инженера: материал щита определяется мощностью и фазностью двигателей и суммарной мощностью электронагрева; тип привода клапана — наличием водяного нагрева (тогда нужен возврат пружиной) и рециркуляции; количество заслонок — площадью сечения.
6. Цена и документ Позиции спецификации связываются с ценами компонентов, результат уходит в PDF — коммерческое предложение, счёт, отчёт о расчёте — и в заказ, который дальше живёт в кабинете и в 1С.

Конфигуратор живёт на справочниках оборудования, а справочники приезжают выгрузками: Excel от поставщика, прайс, обновление из 1С. Отсюда три инструмента в админке, которые выглядят скучно, но экономят больше всего времени: массовые операции по 21 таблице оборудования, сравнение двух импортов с разбивкой «добавлено / удалено / изменено» и построчным списком изменённых полей, и проверка целостности — какие записи остались без цены, без GUID или без связи с ценовым справочником.

// Флаг не передали — значит, только посчитать. Ошибиться можно один раз,
// и лучше пусть эта ошибка будет «ничего не произошло».
const dryRun = params.dryRun ?? true;

async function autoLinkByGuid(tables?: string[], dryRun = true) {
  for (const table of tablesToProcess) {
    // записи, у которых GUID из 1С есть, а цены к ним не привязано
    const unlinked = await (prisma as any)[table].findMany({
      where: { guid: { not: null }, componentPriceId: null },
      select: { id: true, guid: true },
    });

    const prices = await prisma.componentPrice.findMany({
      where: { guid: { in: unlinked.map((u) => u.guid) } },
      select: { id: true, guid: true },
    });
    const priceMap = new Map(prices.map((p) => [p.guid, p.id]));

    for (const item of unlinked) {
      const priceId = priceMap.get(item.guid);
      if (!priceId) continue;
      if (!dryRun) await (prisma as any)[table].update({
        where: { id: item.id }, data: { componentPriceId: priceId },
      });
      linkedCount++;                // считается в обоих режимах
    }
    details.push(`${table}: ${linkedCount} записей привязано`);
  }
}

Сам портал без базы, поискового движка и доступа к 1С не запускается — показать его ссылкой нельзя. Но расчётный слой писался так, чтобы не зависеть от инфраструктуры, и это дало прямое следствие: два куска отделяются от портала и живут самостоятельно. Ниже — живые страницы, не запись экрана.

• Расчётное ядро почти не покрыто тестами. На 13 227 строк lib/engineering приходится четыре файла юнит-тестов общим объёмом 238 строк, и ни один не проверяет расчёт секций. Основное покрытие — девять сценариев Playwright, которые ходят по интерфейсу. Правильный шаг здесь — табличные тесты по эталонным расчётам легаси-конфигуратора: исходные данные и ожидаемый результат уже есть в его выгрузках, они просто не превращены в фикстуры.
• Страница «Калибровка формул» пока только показывает коэффициенты. Значения читаются из JSON-конфига и редактируются в интерфейсе, но кнопка «Сохранить» не подключена к серверу — запись коэффициентов делается правкой файла. Пока калибровок мало, это терпимо; как только их станет больше десятка, понадобится история изменений, а не просто запись.
• Внутреннего планировщика синхронизации нет. sync-scheduler.ts — заготовка на 26 строк; регулярный обмен запускается снаружи, скриптом по расписанию операционной системы. Это работает, но означает, что состояние обмена живёт не в приложении: мониторинг синхронизации в админке показывает результат, а не очередь.
• Часть обработчиков вебхука сведена к минимуму. События цены, остатка, удаления и статуса заказа обрабатываются полностью; product_update возвращает счётчик и не пересобирает карточку — полный ресинк делается отдельным скриптом. Обновление цены по коду товара (без GUID характеристики) не реализовано: в текущей схеме цена всегда принадлежит типоразмеру, и обрабатывать «цену на семейство» было бы угадыванием.
• Типизация на границе с Prisma местами продавлена. В нескольких страницах каталога и в массовых операциях стоят as any — там, где нужен динамический доступ к модели по имени таблицы или сложный include. Это осознанный размен на скорость, но он снимает ровно ту защиту, ради которой брался TypeScript, и в этих местах ошибку поймает только тест.
• Единого дизайн-языка между зонами нет. Витрина, кабинет и админка росли параллельно и под разные требования: витрина — маркетинговая, админка — плотная табличная. Компоненты общие, но визуально это три разных продукта. Свести их в одну систему — отдельная работа, которая пока не сделана.
• Проект пережил миграцию платформы на ходу. Начинался на Next.js 14.2, сейчас собран на 15.5 с React 19. Асинхронные params и searchParams пройдены по всем маршрутам, но в дереве остаются страницы, которые с тех пор не открывали руками, — их поведение подтверждено только сборкой и типами.
• Реверс легаси проверен не полностью. Реестр переноса говорит, что перенесено всё, и по функциям это так. Но «перенесено» и «даёт те же числа на тех же входных данных» — разные утверждения, и второе доказано выборочно, на нескольких расчётах, а не прогоном по всему архиву. До сплошного сравнения расчётов доводить это стоило бы в первую очередь.