Ventprom

The storefront, the customer workspace and the back office are three different products with different layouts, different navigation and different permissions. In the App Router they live as three route groups in one tree: (site), (workspace), (admin). Each brings its own layout.tsx, but all three share one data layer, one Prisma schema and one calculation core. Access to the admin zone is cut off in middleware.ts by the role in the token, before a single component renders.

Facets are routes rather than client state: /catalog/application/[type], /catalog/capacity/[range], /catalog/equipment/[category], with numeric ranges arriving in searchParams and collapsing into a single Prisma where on the server. The reason is not technical: a filtered selection has to be forwardable to a colleague as a link, and the page has to open with a list already in it rather than with a spinner.

An air handling unit is assembled from sections standing one after another inside a casing: damper, filter, heat recovery, heating coil, fan, silencer. It has two branches — supply and extract — and the order of sections has physical meaning: air leaving the heat recovery unit arrives at the coil in a different state. So the configurator is built as a pipeline where the outlet of one section becomes the inlet of the next.

1. Casing size selection selectSizeVariants() walks the casing sizes of a series from the database, computes face velocity and keeps the ones inside the limits. It returns a shortlist with “optimal” flags and warnings rather than a single answer.
2. Section-by-section calculation 12 calculators in SectionCalculators: filter, rotary and plate heat recovery, water and electric heating, water and DX cooling, fan, silencer, mixing section, damper, flexible connector. Each takes a SectionInput — air flow, cross-section, inlet temperature and humidity — and returns a SectionResult with the outlet air state. The psychrometrics are real: moisture content, enthalpy, dew point, and wet-bulb temperature via the Stull approximation.
3. Topology validation 18 rules in build-validation.ts check order rather than numbers: at most one fan per branch, a filter must precede heat recovery and any coil, humidifiers cannot sit just anywhere, glycol recovery coils only come in pairs, a gas-fired heater requires an empty section behind it. Findings split into blocking errors, which stop the calculation, and warnings, which simply sit next to the result.
4. Bill of materials assembly BOMService adds what the customer never thinks about: differential pressure switches, frost protection, valve actuators, variable frequency drives, the control panel. The set is derived from the section train — each sensor in the reference tables is bound to a section type and flagged either “one per unit” or “one per section”.
5. Controls by rule, not by memory ahu-configurator-logic.ts answers the questions that used to depend on an engineer's recall: control panel material follows motor power and phase count plus total electric heating load; valve actuator type follows the presence of a water coil (which forces spring return) and of recirculation; damper count follows cross-sectional area.
6. Price and document BOM lines are joined to component prices, and the result goes out as PDF — quote, invoice, calculation report — and as an order that then lives on in the workspace and in 1C.

The configurator lives on equipment reference tables, and those tables arrive as exports: a supplier's spreadsheet, a price list, an update from 1C. Hence three tools in the back office that look dull and save the most time: bulk operations across 21 equipment tables, a diff of two imports broken down into added / removed / modified with a per-field list of changes, and an integrity check — which records ended up with no price, no GUID, or no link into the component price table.

// Flag absent means count only. You get to make this mistake once,
// so it had better be the mistake where nothing happened.
const dryRun = params.dryRun ?? true;

async function autoLinkByGuid(tables?: string[], dryRun = true) {
  for (const table of tablesToProcess) {
    // rows that carry a 1C GUID but have no price linked to them
    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++;                // counted in both modes
    }
    details.push(`${table}: ${linkedCount} rows linked`);
  }
}

The portal itself does not start without a database, a search engine and 1C access — it cannot be shown as a link. But the calculation layer was written not to depend on infrastructure, and that had a direct consequence: two pieces detach from the portal and stand alone. These are live pages, not screen recordings.

• The calculation core is almost untested. Against 13,227 lines in lib/engineering there are four unit test files totalling 238 lines, and none of them touches section calculation. The real coverage is nine Playwright scenarios that drive the UI. The right move here is table-driven tests against reference results from the legacy configurator: the inputs and expected outputs already exist in its exports, they have simply never been turned into fixtures.
• The “formula calibration” page only displays coefficients so far. Values are read from a JSON config and are editable in the UI, but the Save button is not wired to the server — writing coefficients means editing the file. That is tolerable while calibrations are few; past a dozen it needs change history, not just a write path.
• There is no in-app sync scheduler. sync-scheduler.ts is a 26-line stub; the regular exchange is triggered from outside by an OS-scheduled script. It works, but it means the exchange state does not live in the application: the sync monitor in the back office shows results, not a queue.
• Some webhook handlers are minimal. Price, stock, deletion and order status events are handled fully; product_update returns a counter and does not rebuild the item card — a full resync is a separate script. Updating a price by item code (without a characteristic GUID) is not implemented: in the current schema price always belongs to a size, and handling a “price for the whole family” would be guesswork.
• Typing is dented at the Prisma boundary. Several catalogue pages and the bulk operations carry as any — where a model has to be reached dynamically by table name, or an include gets complicated. It is a deliberate trade for speed, but it removes exactly the protection TypeScript was brought in for, and in those places only a test will catch a mistake.
• There is no single design language across the zones. Storefront, workspace and back office grew in parallel under different requirements: the storefront is a marketing surface, the back office is dense tabular work. The components are shared, but visually these read as three products. Unifying them is separate work that has not been done.
• The project survived a platform migration mid-flight. It started on Next.js 14.2 and now builds on 15.5 with React 19. Async params and searchParams were walked through across the route tree, but pages remain that nobody has opened by hand since — their behaviour is attested only by the build and the type checker.
• The legacy reverse engineering is not fully verified. The migration register says everything was ported, and function by function that is true. But “ported” and “produces the same numbers for the same inputs” are different claims, and the second one is proven on a handful of calculations rather than across the whole archive. Driving that to an exhaustive comparison would be the first thing worth finishing.