В `tricode2 dev` подчистили реальную frontend runtime-regression, из-за которой Studio могла падать ещё до нормального старта интерфейса с ошибками вида `Cannot access ... before initialization`. После фикса dev снова открывается, проходит browser smoke, а сам rollout-helper стал строже и больше не верит одному только `200 OK`.

🧯💥 Dev Studio подняли после TDZ-регрессии: bundle больше не падает до инициализации, а rollout теперь проходит через настоящий browser smoke

17 апреля в tricode2 dev выкатили полный rollout после разбора неприятного frontend-инцидента в Studio. Проблема была не в сети, не в “какой-то нестабильной прокладке” и не в формальном автодеплой-шуме. Ломался именно browser runtime: bundle мог упасть ещё до того, как интерфейс вообще успевал нормально собраться.

На живом dev.3code.dbz0.online это проявлялось как классическая TDZ-регрессия с ошибками вида ReferenceError: Cannot access 'dt' before initialization и ReferenceError: Cannot access 'Oe' before initialization. То есть Studio формально доезжала до браузера, но на реальном исполнении начинала спотыкаться ещё до рабочего состояния.

Что именно починили

Проблему разобрали как настоящий frontend runtime regression, а не как “автодеплой опять странно себя вёл”. В App.tsx переставили несколько вычислений выше их первого фактического использования.

В зону фикса попали:

activeProject-related binding logic;
runStatus, runtimeState, runtimeStateReason;
runnerWorkspaceView-dependent calculations;
связанные вычисления для runPrimaryControl и его labels.

Иными словами, это не “пересобрали тот же bundle ещё раз и стало лучше”, а реальный разбор порядка инициализации и зависимостей, которые уехали в зону temporal dead zone.

Что подтверждено после rollout

После выката зафиксировали уже нормальное живое состояние dev-контура:

live commit: 32c5b8b71a3ebe192d9ee395173faab273615d44;
live images: tricode2-dev-backend:20260417-32c5b8b7-full1 и tricode2-dev-web:20260417-32c5b8b7-full1;
GET /api/health отвечает {"ok":true};
GET /studio/ отвечает 200;
browser verify завершается строкой runtime smoke ok: https://dev.3code.dbz0.online/studio/;
в live сидит новый bundle assets/index-CKJgoXCu.js.

Почему это важно

Потому что раньше broken bundle мог формально выглядеть “живым” по health и HTTP-check’ам, хотя пользовательский runtime уже был сломан. Теперь dev-rollout helper стал строже: он проверяет не только то, что сервер отвечает, но и то, что Studio реально встаёт в браузере.

Это хороший тип ужесточения пайплайна: не косметический “добавили ещё одну галочку”, а дополнительный реальный фильтр против повторного выката bundle, который проходит 200 OK, но падает вживую до нормальной инициализации интерфейса.

Production этот rollout не трогал. История целиком про dev-контур, но именно в таком контуре и нужно ловить такие регрессии до того, как они начинают выглядеть как “почему опять Studio открывается через раз”.