---

Да, теперь промт уже можно отправлять. Он достаточно конкретный: Claude не должен снова уйти в плоские линии, случайные оффсеты или два верхних пояса. Геометрия, координаты, объём стержней, проверки и порядок работы определены однозначно.

Перед отправкой я бы добавил только один финальный блок — сейчас хорошо описано, как работать, но недостаточно жёстко указано, что именно Claude обязан показать в результате.

Вставь перед «Критические файлы»:

ФИНАЛЬНАЯ ПРИЁМКА И ФОРМАТ ОТЧЁТА

Работа не считается завершённой только потому, что код выполняется без ошибок.

Перед ответом владельцу обязательно предоставить:

1. Скриншот ОДНОЙ балки в изоляции крупным планом:
   - вся балка целиком попадает в кадр;
   - оба торца видны и не обрезаны;
   - отчётливо видны два нижних пояса;
   - отчётливо виден ровно один центральный верхний пояс;
   - видны обе симметричные плоскости раскосов;
   - между прутками настоящие сквозные просветы;
   - стержни воспринимаются объёмными, а не линиями или лентами.

2. Скриншот полной сцены на стадии только с балками:
   - все 4 балки читаются как отдельные одинаковые фермы;
   - отсутствуют диагонали между разными балками;
   - отсутствуют торчащие за пролёт элементы;
   - отсутствуют визуально хаотичные пересечения;
   - дальние и ближние поверхности отображаются в правильном порядке.

3. Скриншот стадии с блоками:
   - блоки имеют видимую опору на свободные полки лотка;
   - блоки не пересекают нижние пояса;
   - верхний пояс и верхняя часть раскосов выступают выше блоков;
   - выполняется trussTopZ > blockTopZ.

4. Таблицу фактических значений:
   length;
   baseWidth;
   trussWidth;
   ledgeWidth;
   clearLedgeWidth;
   baseHeight;
   trussHeight;
   targetPitch;
   panelCount;
   фактический pitch;
   rodRadius;
   trussTopZ;
   blockTopZ.

5. Результаты всех ассертов в явном виде:
   PASS/FAIL для каждого инварианта.

6. Diff изменённого кода.
   Отдельно подтвердить, что не изменены:
   - камера и proj();
   - количество и позиции балок;
   - стены и колонны;
   - геометрия блоков;
   - цветовая схема;
   - последовательность стадий;
   - поведение кнопок вперёд/назад.

Запрещено отвечать «готово», если нет всех трёх проверочных скриншотов или если хотя бы один ассерт не пройден.

Фразы «в целом похоже», «есть небольшой нюанс», «можно доработать позже» означают, что реализация не завершена и должна быть исправлена до ответа владельцу.

Ещё два точечных уточнения.

Сортировка во время анимации

Сейчас указана глобальная сортировка и проверка кадров .drop, но не сказано, что глубина меняется в процессе падения. Добавь к пункту 5:

При анимации .drop depthKey нельзя считать только по финальным неподвижным координатам, если вертикальный transform меняет порядок балки относительно стен или опор.

Во время активного падения использовать один из вариантов:
- пересчитывать transformed worldVertices/depthKey и порядок видимых граней через requestAnimationFrame;
- либо математически доказать и проверить контрольными кадрами, что на всём пути падения порядок относительно окружающей геометрии не меняется.

Сортировать только ВИДИМУЮ геометрию текущей стадии. Скрытые блоки, сетка и бетон не должны участвовать в depth-sort до появления своей стадии.
Формулировка «1:1»

Лучше заменить:

Цель — 1:1 с референсом.

на:

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

Иначе Claude может тратить время на буквальное копирование размеров и перспективы фотографии, что невозможно внутри текущей изометрической сцены.

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