Що аудитовано. Код C:\Works\slabcut-agent-pack\vs-cad (VS CAD + Studio на ядрі OCCT, ?mode=studio; саме його піднімає кнопка ПІДНЯТИ_СТУДІЮ_OCCT_7177.bat) станом на 12.10, вечір. Знімок звірено з диском: усі 666 файлів src/ на місці, розміри збігаються, два файли відрізняються лише закінченням рядка (CRLF). web-app на диску має ті самі 666 файлів з тими самими розмірами, крім одного: constructor/docs/DocsTab.tsx. Тобто сьогодні це одна програма у двох теках. Документація: знімок InstructionsRules — 223 md/txt. Не брали кейси клієнтів, а також частину архіву 08 і ринкові дослідження, бо вони не про код. Бази для порівняння:

• аудит 02.09 (його числа й адреси);
• знімок MR !8 — гілка зведення 12.10.

Як. Сім лінз паралельно, кожна — окремий звіт з адресами файл:рядок (додатки L1–L7, ≈3 100 рядків фактури):

• L1 — розкрій;
• L2 — геометрія, ядро OCCT і кромки;
• L3 — мертве, важке, хардкод і що вшито в Студію;
• L4 — доки проти коду;
• L5 — історія і стан знахідок 02.09;
• L6 — гроші;
• L7 — швидкість, старт і пам'ять.

Окремо зроблено реєстри: 03 (мертве й задвоєне), 04 (дерево коду), 05 (стан знахідок 02.09). Зонди (пробні тести й скрипти) жили лише у власних копіях:

• синтетичні деталі;
• ядро OCCT у node;
• Playwright на стендах;
• прод-збірка з картами джерел.

Код проєкту не змінювався. Потім аудитор (Лео) власноруч перевірив ключові знахідки — список у розділі 9.

Позначки достовірності.

• [ФАКТ ✔] — виміряно запуском, grep, зондом або прогоном;
• [ФАКТ ◔] — прочитано в коді з адресою;
• [ГІПОТЕЗА] — правдоподібно, без прямого доказу;
• [ПИТАННЯ] — вирішує власник.

Рішень у цьому документі немає. Пропозиції зібрані окремим блоком наприкінці (розділ 10).

Межі. Не оцінювались (сторона ІТ; де торкається — позначено «[сторона ІТ]»):

• server/, lib/api.ts;
• авторизація, Keycloak;
• 1С / WMS / Orders;
• Python-MES Бруно.

Усе міряно в хмарній пісочниці: 2 ядра, графіку малює процесор. Абсолютні секунди там гірші, ніж на твоєму ПК, тому порівнювати варто між собою.

Ворота на момент аудиту [ФАКТ ✔]:

Два червоні тести — ті самі «відомі»:

• __tests__/coreBoundary.test.ts, межа ядра, падає через один import type у engines/shapeBuilder.ts:2;
• parsers/dxf/parser.test.ts, шлях C:/hhgh/… з чужої машини.

Пропущені 19 тестів — нативні тести Бруно, вмикаються змінною CAD_PROFILED_BASE_NATIVE=1.

0. Відповіді на твої питання — коротко

«Може, все через те, що в Студії вшиті CAD і білдінг? Чи вони мертві, поки ми в них не зайшли?»

Вони сплять і не гальмують [ФАКТ ✔, L7 + L3].

Вкладки конструктора лінуються — їхній код вантажиться лише при вході, до того його в браузері немає:

• CAD: замір, метал, фанера, збірка, зведення, документи, CombiCut;
• BUILDING: план, розкладка, відомість.

Що від них таки лежить на старті:

Виконується лише оголошення — без дотику вони нічого не роблять.

MES-симуляції (src/mes, 3 090 рядків) у збірці немає взагалі: її ніхто не імпортує.

«Може, файли з кодом великі, ми тисячу років аудитів не робили?»

Так, код подвоївся за 41 день, а мертве з 02.09 не прибрано [ФАКТ ✔, L3]. Але старт від цього повільний на пів секунди, а не на десятки секунд [ФАКТ ✔, L7].

Що виросло:

Ще сім функцій довші за тисячу рядків. З мертвого, знайденого 02.09, не видалено жодного файла.

Старт:

• браузер качає 6,1 МБ коду (1,87 МБ стисненого), і 71 % цього коду на стартовому екрані не виконується;
• перший малюнок з'являється за 0,66–0,81 с.

Де насправді довгі секунди [ФАКТ ✔, заміри 12.10 + L2 + L7]:

1. Перше 3D-вікно: створення полотна і карти відблисків — 9 с у пісочниці. На справжній відеокарті має бути в рази менше [ГІПОТЕЗА].
2. Холодне ядро OCCT: запуск 4,5–6 с і ~0,5 ГБ пам'яті до закриття вкладки.
3. Зміна кромки на дузі: 82 % часу — віднімання. Перший спосіб віднімання на стику дуги з прямою щоразу ламається, тож ядро робить три віднімання поспіль.

«Що ще можна зробити з кромками?» Є реальний важіль [ФАКТ ✔, зонд L2]. Інструмент фрези вздовж «пряма → дуга → пряма» можна будувати однією трубою, а не шматками. На твоїй Г 1200 (R350, кромки на B–D):

Для L20, xd_20 і ar_20 тіло виходить те саме до кубічного міліметра. Для d_20 різниця −186 мм³ — це хорди старого лофта, на який тепер відкочується ядро.

Інші варіанти секунд на зміні кромки не дадуть: кеш інструментів, два потоки ядра, менша збірка OCCT (розділ 3).

План Б (кромка кольором) тепер не обов'язковий. Гроші, метраж, розкрій, DXF і PDF від 3D-тіла не залежать — вони рахуються з 2D. План Б дав би лише миттєву картинку ціною 3D без профілю.

1. Головне — дванадцять знахідок

1. Після зсуву вирізу DXF на верстат бере отвір зі старого місця. [ФАКТ ✔ — перевірено аудитором власноруч]

   • Причина. Кеш точних контурів упізнає деталь за зовнішнім контуром і кількістю вирізів, а не за їх місцем (kernel/exactParts.ts:24–27). Скидання кешу немає (kernel/cutOutlines.ts:65–72).
   • Що зачіпає. Якщо в межах сесії посунути чи змінити виріз, до перезавантаження сторінки виріз зі старого місця беруть:
     • дошка;
     • колізії;
     • DXF на верстат;
     • креслення PDF і бланк;
     • CombiCut.
   • Доказ. Зонд з реальним ядром: отвір у DXF на x≈450 замість ≈1450.
   • Кого стосується. Будь-якої деталі з дугою (радіус кута, круглий отвір) — тобто майже кожної стільниці з мийкою.
   • Де ще. Та сама вада є в знімку MR !8 (kernel/exactParts.ts:167–170). Чи вона на проді — не перевіряв [ПИТАННЯ].
   • Виправлення. Один рядок ключа плюс тест-сторож — пропозиція 10.1.

2. Розкрій, поки чекає ядро, губить правки людини. [ФАКТ ✔ — перевірено]

   • Як губить. Розкрій бере знімок проєкту до очікування (store/slices/packingSlice.ts:105–115) і після приходу контурів записує його назад (:204–205).
   • Що зникає. Доданий сляб, правка шапки, посунута деталь, навіть Ctrl+Z.
   • Друга вада — «вішає» розкрій. Правка під час роботи потоку розкрою відкидає його відповідь (projectSlice.ts:20 → packingSlice.ts:224), а крутилка isPacking лишається увімкненою. Кнопки сірі, «Зберегти в кабінет» відмовляє.
   • Без межі. Очікування ядра не має ні таймауту, ні обробки помилки.

3. Гроші: метраж кромки №250 на Г/П з радіусом чи фаскою кута завищений на 43–50 %. [ФАКТ ✔ зонд L6]

   • Приклад. Г 2400×1600 з R100 при припуску 0: сума кромки 11 357 мм при периметрі 7 957. Сторона F рахується як 4 000 замість ~1 600.
   • З припуском 10. У метраж іде контур уже з припуском.
   • Адреса. engines/geometryUtils.ts:435–458.
   • Чому тест не бачить. Тест №250 перевіряє Г лише без кутів.

4. Гроші: прямокутний виріз зі скругленими кутами рахується як круглий отвір. [ФАКТ ✔ — код + зонд L6]

   • Причина. Перевірка «схожий на коло» дивиться, чи вершини рівновіддалені від центру (engines/productionFacts.ts:171–184). У скругленого прямокутника всі вершини стоять біля кутів — і він «стає колом».
   • Наслідок — інша послуга:
     • варильна 562×492 R5 → «великий отвір» 2,1 м замість «периметра вирізу»;
     • розетка 80×80 R10 → «малий отвір» 1 шт;
     • мийка R10 — так само.
   • Регрес після 25.09 [ФАКТ ◔].

5. Гроші: метал рахується як камінь, і 39 з 70 профілів кромок дають нуль. [ФАКТ ✔/◔ L6]

   • Метал. Факти виробництва відсівають лише фанеру (productionFacts.ts:245–250). Труба 2 м дає 4,08 м «різу пилою». Її площа йде в «Матеріал», «Монтаж», «Пакування» і в замовлення ERP.
   • Профілі без правила. 39 з 70 профілів кромок (серед них l_20) не мають правила й мовчки дають нуль у кошторисі (domain/serviceMapping.ts:313–349). На 02.09 таких було 38.

6. Кромки: усі секунди йдуть на віднімання, і найгірший випадок ніхто не сторожить. [ФАКТ ✔ зонд L2]

   • Розклад часу. На Г власника: віднімання 82 %, перевірки 7–12 %, інструменти 6–9 %.
   • Три віднімання замість одного. Перший спосіб («одним списком») на стику дуги з прямою завжди дає зламане тіло. Тому кожна правка платить три булеві операції (occtBuilder.ts:941–990).
   • Найгірший випадок. Г власника з d_20: перевірка не сходиться, ядро відкочується на старий лофт — 26,6 с (occtBuilder.ts:863–869). Сторожі цього не тримають.
   • Вихід. «Одна труба» — розділ 0.

7. Кеш плити з кромками (№278) витісняється точними контурами розкрою. [ФАКТ ✔ — перевірено]

   • Причина. Кеш має лише 2 місця на ядро (kernel/occt/profiledBaseCache.ts:13). У нього ж пишуть точні контури розкрою (kernel/occt/outline2D.ts:206).
   • Наслідок. Після двох контурів деталей з вирізами зсув вирізу в редакторі займає 3,9 с замість 0,2 с.
   • Чия помилка. Це недогляд у моїй №278: плиту без кромок кешувати нема сенсу.

8. Старт: 6,1 МБ коду на кожну сторінку, і 71 % з нього не виконується. [ФАКТ ✔ L7 + перевірено]

   Що лежить на старті	Обсяг	Звідки
   Бібліотеки документів (pdf.js, xlsx, jspdf, html2canvas, react-dom/server)	1,67 МБ	потрібні лише за кнопками
   3D-рушій	1,21 МБ	App.tsx:38 статично імпортує редактор
   Вшиті дані (креслення кромок, переклад, довідка, теми Стоуника)	~1 МБ	—
   Тестові дані	—	main.tsx:14 → engines/__tests__/mockData.ts:103

   Тестові дані потрапили в бойову збірку (є в карті джерел main-*.js), і з ними на кожному старті ганяється explodeDetails.

9. Що працює без дотику. [ФАКТ ✔ L7]

   • 3D малює кадри безперервно, поки відкрите, навіть коли нічого не змінюється. У коді жодного frameloop, тож працює режим за замовчуванням «завжди».
   • Очі Стоуника анімуються 45 с після кожного дотику. У пісочниці це дорого, бо графіку малює процесор; на справжній відеокарті — копійки [ГІПОТЕЗА].
   • Схована плашка ядра оновлюється таймером кожні 0,7 с.
   • Чого немає: мережевих опитувань і потоків на старті.

10. Персональні дані в коді. [ФАКТ ✔ — лише лічильник, значень не відкривав]

    • Що. mes/data/orders.ts містить поля customer з прізвищами клієнтів п'яти реальних кейсів.
    • Чому ризик. Файл лежить у src/ і їде в GitLab разом із кодом. Сам модуль MES ніким не підключений. Правило «персональні дані — не в репозиторій» порушене.

11. Процес: робота лише на диску, дві теки, «відомі» червоні тести. [ФАКТ ✔ L5 + перевірено]

    • Не в GitLab. 44 файли (+4 358 / −285 рядків, №270–№278) лежать лише на диску.
    • Знімок MR !8. Він уже містить №267–№269, хоча журнал і ПАМ'ЯТЬ кажуть, що ні.
    • Дві теки. web-app і vs-cad — одна програма. Кожну правку робимо двічі руками. Правило «файли патчу різні в копіях» (ПАМ'ЯТЬ_ЛЕО §2.8) застаріло.
    • Червоні тести. Два тести 5+ тижнів пишуться як «відомі» — новий червоний тест сховається серед них.

12. Доки відстали від коду на місяць. [ФАКТ ✔ L4]

    • OCCT мовчить. Головні доки не згадують OCCT жодного разу: АРХІТЕКТУРА, MANIFEST, БІЗНЕС, КАРТА_МОДУЛІВ, ПЛАН_І_СТАН, README, СТАРТ, ДЛЯ_НАСТУПНОГО, КАРТА_ПАПОК.
    • Неописані теки. Вісім нових тек коду (149 модулів, ~29 тис. рядків) не описані.
    • Числа не збігаються:
      • у доках 17 різних кількостей тестів (факт — 1 856);
      • тем Стоуника 71 + 21, а не 66 + 21.
    • Вхід адміна. Доки пишуть «PIN», а з №263 це логін і пароль.
    • Ціни на сервері. СПІЛЬНІ_НАЛАШТУВАННЯ пишуть «гроші на сервер не їдуть», а код возить прайс-бук разом із калібрувальними цінами (store/settingsSync.ts:63–86).

Що стало краще з 02.09 — чесно, теж виміряне:

• «Дві математики» розкрою закриті: один будівник кутів і один ніж для всіх стиків. Г з радіусом увігнутого кута дає 0,452 м² у всіх типах стику (02.09 — 0,4520 / 0,4520 / 0,4480).
• mirrorL закрито: ліва Г більше не стає правою в розкрої.
• П-14 вирішено, вирізи в розкрої мають cornerRadius.
• Кутовий стик більше не губиться поруч із довільним.
• Ядро OCCT дало точні контури для розкрою, DXF і PDF.
• Нові теки (ядро, CAD, Стоуник) — 0 помилок tsc.
• Втрата на кшталт 22–23.08 не повторилась: робоча копія містить усе з MR !8.
• Секунди 12.10 стали в рази кращими. Наприклад, повторний вхід у 3D Підбір: 27 с → 1,5 с, і сторінка більше не висне.

2. Розкрій — що змінилось і де тонко (L1)

Конвеєр сьогодні. Кнопки на дошці (SlabBoard.tsx:1044–1111) запускають runPacking → triggerPackingAsync (packingSlice.ts:56). Далі:

1. нормалізація проєкту;
2. getAllProjectDetails;
3. explodeDetails (engines/geometry.ts:2588);
4. нове з №246 — чекаємо точні контури ядра: cutOutlineProvider().prepare (:100);
5. finishPacking, у якому на сляби йде лише камінь (stoneParts, №256);
6. потік розкрою autoPack (engines/packing.ts:1851);
7. колізії по точному контуру (detectConflicts, :1916);
8. текстури.

Повна схема з адресами — 02_МАРШРУТИ_ОПЕРАЦІЙ_13-10.md, розділ 2.

Очікування ядра [ФАКТ ◔ + ✔]:

• поки ядро рахує, людина бачить лише спінер Loader2 на кнопці;
• межі очікування немає;
• при завислому потоці ядра кожна деталь з дугою чекає до 120 с (kernel/cutOutlines.ts:84–114, workerClient.ts:31);
• плашка ядра в Студії схована (KernelBadge.tsx:31), тож про збій ніхто не дізнається, а розкрій мовчки йде по ламаній.

Перший розкрій після відкриття проєкту:

Заміри 12.10, пісочниця. З прогрівом ядра — 0,5 с (проба, пропозиція 10.5).

Відкрите з 02.09 [ФАКТ ✔]:

• перепил 70 мм досі без налаштування в інтерфейсі, і після авторозкрою 6–8 з 10 деталей «червоні». Пакувальник про перепил не знає (packing.ts:302–342), колізії знають (:1947–1969);
• кожна хорда дуги перевіряється як прямий пропил пилою (:1951), хоча дуги на CombiCut ріже вода;
• радіус кута вимикає розгортку підвороту в «Повній текстурі» (packing.ts:587–590);
• режим розкрою не зберігається після перезавантаження (packingSlice.ts:293);
• дзеркалення без умови «без обробки кромки» (packing.ts:466–471);
• два ключі текстурних груп (geometryUtils.ts:20 і textureLayout.ts:37);
• loadWithoutPacking без матеріалу (projectHelpers.ts:115).

Нове:

• «Перевірити розкладку» рахує фанеру й метал як камінь (SlabBoard.tsx:1122 → packing.ts:1892);
• «Перерахувати слеб» перескладає весь проєкт без підтвердження (SlabBoard.tsx:1544);
• для CombiCut є два різні контури: DXF «Combicut» з дошки — з припуском (kernel/exportCutDxf.ts:96,179), вкладка CombiCut — номінальний (engines/combicut/plan.ts:146);
• пакет для MES і експорт PNG беруть ламану (mesPack.ts:401, App.tsx:559).

Тести розкрою: 20 файлів, 142 тести, усі зелені [ФАКТ ✔].

3. Геометрія, ядро OCCT і кромки (L2)

Ланцюг від чернетки до тіла [ФАКТ ◔]: чернетка → modelFromDraft → KernelModel → черга прев'ю → кеш складань №275 → потік ядра №277 → occtBuilder.buildAssembly → кеш плити №278 → buildShapeUncached → тіла → three.js.

Паралельно живуть:

• розкрій: explodeDetails з власною розкладкою;
• гроші: 2D-полігони, ядро їх не бачить.

Схема з адресами — 02_МАРШРУТИ розділ 1 і L2 §1.1.

Скільки «правд» про контур. Дві живі незалежні математики: розкрій (engines/geometry.ts:1749) і 3D/ядро (baseContour → shapeBuilder). Ще одна схована: бланк approvalSplit, під адмін-щитком. На 02.09 їх було шість.

Одна й та сама дуга розбивається сімома способами — 12 / 28 / 36 / 42 / 64 / 256 хорд і точна дуга.

Де ядро головне, де легасі [ФАКТ ◔]:

Відкат усього на старий будівник — ?kernel=legacy / VITE_KERNEL=legacy.

Кромка в 3D — лише картинка [ФАКТ ✔]. Тіло з кромками читають лише показ і стенд. Точний 2D-контур для цеху будується без кромок (kernel/occt/outline2D.ts:205).

Заміри (node, синтетичні деталі) [ФАКТ ✔]:

Г зі старим лофтом (?arcs=0) — 11,1 с.

Кеш складань №275 повторює ту саму модель за 1 мс. Але жоден кеш не допомагає зміні самої кромки: це завжди нова модель.

Варіанти для кромок, з числами [ПРОПОЗИЦІЯ, виміряно]:

Діри, що перейшли в ядро [ФАКТ ✔]:

• профіль прорізається під ногою (edgeOccupancy.ts:45 читає лише UI);
• гнутий елемент будується на увігнутому куті (radiusElement.ts:242, arcBands.ts:114);
• мийка збирається за іменами частин (sinkAssembly.ts:52–94);
• на опуклій дузі гроші й 3D розходяться. Профіль лише на одній стороні дає половину дуги в метражі й дугу без профілю в 3D. З галочкою «Стандарт» дуга в метражі рахується 1,5 раза (edgeCutters.ts:964–982 проти geometryUtils.ts:447).

4. Гроші — два рушії і їхні дірки (L6)

Після 03.09 рушіїв два — «Комерційну пропозицію» видалено [ФАКТ ✔]:

Ядро OCCT гроші не використовують. Правило ціни одне для обох (manual ?? erp ?? 0, ручна — лише в калібруванні), але функцій дві (estimate.ts:176, quoteCalc.ts:191).

Три закони метражу кромки і три площі [ФАКТ ✔ зонд]:

• бланк погодження рахує кромку по контуру з припуском і без дуг (quotePdf.ts:1056–1063);
• прорахунок кромок не рахує взагалі.

Площа на синтетичному проєкті:

Різниця — чаша мийки й метал.

Відкрите з 02.09 і нове [ФАКТ ✔ зонди L6]:

• замовлення в ERP за ручними (калібрувальними) цінами не стримується (QuoteOrderCard.tsx:147–167);
• калібрування, ввімкнене адміном, лишається в браузері після його виходу;
• подвійний рахунок: кут на доповненні (productionFacts.ts:419–448), дуга з «Обробкою торців» (:457–474);
• «Стикування в площині» рахується за формою деталі (quoteCalc.ts:528–534): пряма стільниця зі стиком дає 0;
• пропил ×2 ставиться на кожне з'єднання, разом із підворотами;
• з 40 послуг прорахунку частина без коду 1С (керамограніт 10, кварцит 12, натуральний 24, акрил 37), серед них «Виріз під мийку» і surface_processing;
• набір ВіярПро для кварциту використовує 7 кодів, яких немає в «Актуальних послугах 2026 цех 202»;
• «Додаткові послуги» паспорта деталі (customServices) не читає жоден рушій;
• паспорт кличе кошторис без прапорця калібрування (DetailPassportModal.tsx:58–83);
• спільні налаштування №241: новіша версія з сервера тихо затирає незбережені локальні правки (settingsSync.ts:105).

Закрито: коди радіусних послуг за матеріалом — обидва документи дають один код [ФАКТ ✔].

5. Мертве, важке, хардкод — і що вшито в Студію (L3)

Розміри [ФАКТ ✔]:

Функцій довших за 1 000 рядків — 7:

• createGeometryEngine — 2 570;
• ProductEditorWorkspace — 2 298;
• FormsPanel — 2 193;
• SlabBoard — 1 588;
• HelpDialog — 1 112 (текст);
• QuotePanel — 1 075;
• Detail3DNode — 1 046.

Чотири UI-гіганти (SlabBoard, Viewer3D, ProductEditorWorkspace, Detail3DPreview) дають 192 із 418 помилок tsc — 46 %, як і 02.09. Повний топ-25 — L3 §3.2. Дерево — 04_ДЕРЕВО_КОДУ_13-10.md.

Мертве [ФАКТ ✔ knip + граф]:

• 17 мертвих файлів, 1 822 рядки — зокрема все, що знайшов 02.09: core/*, PlacementPropertiesPanel, useCostPrices, slabTexture, sketchupExport;
• ще 6 файлів живуть лише в тестах (2 634 рядки);
• мертвий блок у Viewer3D.tsx:664–1396 (733 рядки) і кнопка «Групувати деталі» без ефекту;
• 8 нерозв'язаних імпортів;
• ті самі 6+3 зайві npm-пакети;
• не підключені: вкладка MES (mes/MesTab.tsx), поділ на робочі простори (shell/workspaces.ts, workspaces/*/index.tsx), хук kernel/useKernelGeometry.ts.

Реєстр — 03_МЕРТВЕ_І_ЗАДВОЄНЕ_13-10.md.

Задвоєння [ФАКТ ✔]:

Блочного копіпасту мало (jscpd 0,54 %).

Межа «ядро не знає UI» порушена [ФАКТ ✔]:

• coreBoundary червоний — фікс 03.09 втрачено відкатом №96;
• сторож не дивиться в kernel/, а звідти 12 не-типових імпортів у UI;
• стор CAD і draftHelpers потрапляють навіть у потік ядра.

Хардкод [ФАКТ ✔]:

• URL у src: 13 у 7 файлах (02.09 — жодного) — PLM, MES, 6 інтернет-радіо Стоуника;
• префіксів ключів сховищ браузера — 9+ (було 4);
• старий PIN лежить мертвим полем у сторі й у ключових словах довідки Стоуника — значень не наводжу;
• межі NC300 дві: 3000×1600 (materialRules.ts:52) і 3100×1500 (manufacturability.ts:29), і обидві тепер працюють.

Що вшито в Студію (статика + живі заміри, L3 + L7) [ФАКТ ✔]:

6. Швидкість, старт і пам'ять (L7 + заміри 12.10)

Секунди 12.10 — «до» — це прод, MR !8; «після» — диск, №274–№278; пісочниця:

Таблиця на 17 сценаріїв — 02_БАГИ_І_БОРГИ\ЗАМІРИ_12-10_ШВИДКІСТЬ_І_СТОУНИК.md.

Де довго і куди Стоуника — вирішено 12.10:

1. редактор, перша деталь на холодному ядрі: 17–24 с порожньої сітки;
2. зміна кромки — 2,4–5,9 с;
3. перший розкрій після відкриття — чекає ядро 5,6 с;
4. 3D Підбір — Стоуник уже стоїть (№274).

Проба прогріву ядра — лише пісочниця, requestIdleCallback після старту [ФАКТ ✔]:

Ціна прогріву — ~0,3–0,5 ГБ пам'яті в кожного користувача одразу.

Звідки пам'ять ядра [ФАКТ ✔ L7]:

Як прод віддає .wasm — стиснення, кеш — у репозиторії не описано [сторона ІТ].

Що прибрати зі старту [байти — ФАКТ ✔ з розмірів; час — ГІПОТЕЗА]:

Що дасть А + Б: ≈ −0,85 МБ стисненого, −0,1…0,17 с процесора на старті, −1,4 с на каналі 5 Мбіт/с.

Це прибирання для порядку і повільних каналів — не ліки від 10–20-секундних очікувань.

7. Доки проти коду (L4)

Звірено 216 тверджень живих доків:

Головне [ФАКТ ✔] — крім знахідки 12:

Вхідні точки розірвані:

• стартер і карта Джованні ведуть у теку 16_ДЖОВАННІ\, а вона зветься 16_ДЖОВАННІ_CAD;
• КАРТА_ПАПОК не знає тек аудиту 02.09, 12 і 16;
• README не знає ПАМ'ЯТЬ_ЛЕО;
• ПАМ'ЯТЬ §9 відсилає до СТАРТ зі станом 23.08–01.09.

Борги не збігаються:

• 17 боргів закриті в коді, але відкриті в реєстрах (FG-12 «замки сторін», №10, №14–16, №23, вшиті ціни, довідники на сервері, Б-002, SC-35 тощо);
• навпаки, «зроблене» в доках, якого нема в коді: translate="no", формат .vs3d, лупа.

Терміни:

• бланк погодження підписує Підворот «Потовщенням» (quotePdf.ts:477,508) — питання З-1 від 02.09 без відповіді;
• CombiCut ставить легасі-підворот під 45° і зве його «смугою потовщення» (engines/combicut/plan.ts:156–157,180), а правило 29.09 каже «підворот — без вуса».

Стоуник учить застарілому. Тема «Кнопки й пуш» (stounik/leoTopics.ts:146) і ПАМ'ЯТЬ §3 досі вчать пушити скриптами 05.10, які №261 заборонив.

Карта «ядро / легасі» в ПАМ'ЯТЬ_ЛЕО §4 збігається з кодом у 12 пунктах з 13. Хибний один: бандажі по дугах уже на ядрі (№251).

8. Історія 02.09 → 12.10 і стан знахідок 02.09 (L5)

За 40 днів — 196 записів журналу (№86–№278). Майже весь код написала одна лінія (Мікеланджело → Да Вінчі → Лео). Бруно — пакетами через рев'ю, ІТ — через чотири зведення.

Помічники майже не працювали:

• Ботічеллі — одна задача (Б-002);
• Джованні — жодної сесії, його К-003 зробив Лео;
• ЖУРНАЛ_АГЕНТІВ після 06.10 не вівся.

12 знахідок 02.09 [ФАКТ ✔ — перевірено в коді]:

10 пропозицій 02.09: зроблено 1, майже 1, частково 4, не зроблено 4.

54 питання 02.09 — у файлі їх 54, а не 46, як писав журнал №85:

Таблиця з адресами — 05_СТАН_ЗНАХІДОК_02-09.md.

Майже-втрати. За 6 тижнів було щонайменше 5 майже-втрат того самого класу, що 22–23.08: №226, №233, №244, №261 (двічі). Усі спіймані звірками, тож механізм ризику живий, а запобіжник працює [ФАКТ ◔].

Рішення власника. ≈35 рішень з 02.09 живуть лише в журналі й ПАМ'ЯТЬ_ЛЕО §5. MANIFEST заморожений на 2.60 (01.09), і його пункт 2.54 суперечить коду.

9. Що не перевірено і де межа

Що аудитор перевірив власноруч [ФАКТ ✔]:

• ключ кешу контурів — код і вивід зонда з ядром;
• те саме в MR !8;
• перезапис знімком і «завислий» розкрій — код;
• метраж кромки №250 і виріз «як коло» — вивід зондів і код;
• mockData у бойовій збірці — карта джерел;
• 2 місця кешу плити — код і вивід зонда;
• «одна труба» — сирі результати зонда;
• відсутність frameloop;
• ворота tsc / vitest;
• червоні тести.

Межі:

• Твій ПК не міряли. Усі секунди — пісочниця з програмною графікою. На справжній відеокарті «перше 3D» має бути в рази коротшим [ГІПОТЕЗА].
• Живий продукт не клікали, крім стендів Playwright.
• Сторона ІТ: сервер налаштувань, 1С, бекенд замовлень.
• Прод (Vercel/Ocean) — чи є там вада кешу контурів, не встановлено.
• «Одна труба» перевірена на 4 профілях Г власника. Часткові кромки, drop, кільце вирізу, овал, замкнений контур — не перевірено.
• Повне A\B для L20 R350 у Бруно — досі INCONCLUSIVE.
• Число тестів у доках порівнювалось з прогоном пісочниці (1 856), а не з комп'ютера.

10. Пропозиції — не рішення, для розгляду

Термінове і дешеве — кожне кілька рядків плюс тест-сторож:

1. Ключ кешу точного контуру — додати геометрію отворів (координати, а не кількість) і сторож «зсув вирізу → новий контур у DXF і PDF». Перевірити, чи робили експорти після правки вирізу без перезавантаження (01_ПИТАННЯ А-1).

2. Розкрій після очікування ядра — зливати результат у поточний проєкт, а не в знімок. Також:

   • Ctrl+Z скидає квиток очікування;
   • межа очікування з переходом на ламану і чесним повідомленням;
   • відповідь потоку розкрою не відкидати через дії, що не міняють деталей, або скидати isPacking.

3. Кеш плити №278 — не кешувати плиту без кромок (точні контури розкрою) і/або дати більше місць. Це моя доробка до №278.

4. Червоні тести:

   • прибрати import type у engines/shapeBuilder.ts:2 (тип винести в domain/);
   • DXF-тест з чужим шляхом — skip з поясненням.

   Тоді «2 відомі» стануть «0».

5. Прогрів ядра після відкриття сторінки — лише на комп'ютерах, ?warm=0 вимикає (проба готова, №279). Плюс Стоуник у трьох місцях з 12.10.

6. Тестові дані з бойової збірки — mockData лише в DEV (динамічний імпорт).

7. Прізвища клієнтів з mes/data/orders.ts — знеособити або не везти непідключений MES у GitLab.

Секунди на кромках:

8. «Одна труба» для інструмента фрези на гладкому ланцюзі, плюс злиття станцій на прямих. Як перевіряти:

   • скан як у №276: усі кути, обидва дзеркала, профілі L20 / ar_20 / xd_20 / d_20 / t_20 / lv_40_inv, коло, П, виріз R40;
   • об'єм — не більше похибки перерізу;
   • перерізи — не більше 0,1 мм;
   • тіло валідне, одне.

   Сторож на d_20, бо зараз — 26 с.

Гроші — після твоїх відповідей на 01_ПИТАННЯ розділ Г:

9. Виріз зі скругленими кутами — «виріз», а не «отвір»: класифікація за формою, не за вершинами.
10. Метал — з фактів каменю.
11. Метраж кромки №250 для Г/П з кутами і припуском — плюс тест на Г з радіусом і фаскою.
12. Правила для 39 профілів, або читати EdgeProfileDef.operations, плюс тест «кожен профіль має правило».
13. Стоп або попередження на замовлення в ERP з ручними цінами.
14. Одна функція ціни для двох рушіїв.

Старт і фон:

15. Ліниво вантажити бібліотеки документів (pdf.js / xlsx / jspdf / html2canvas / react-dom/server) і довідку: −1,95 МБ, мала складність.
16. 3D — режим «малювати лише при змінах» (frameloop="demand"). Ризик: усе, що рухається, має саме просити кадр. Перевіряти оком.
17. Будівник ядра — з головного потоку.

Процес:

18. Пакет №270–№278 у GitLab — окремою гілкою поверх MR !8, до наступного зведення з ІТ.
19. Одна тека замість двох (web-app = vs-cad): спершу вирішити, який DocsTab.tsx правильний.
20. Ревізія живих доків під OCCT:
    • числа (тести, tsc, теми Стоуника) — в одному місці (ПАМ'ЯТЬ §3), решта посилається;
    • закрити 17 боргів, закритих кодом;
    • поправити розірвані посилання.
21. Мертве (17 файлів, ≈900 рядків мертвих блоків, 9 npm-пакетів) — пакетом після твого «так». Рішення 23.08 «не чіпати» досі чинне.

Додатки:

• L1 розкрій · L2 геометрія, ядро OCCT і кромки · L3 мертве, важке, хардкод + що вшито · L4 доки проти коду · L5 історія і стан знахідок · L6 гроші · L7 швидкість, старт, пам'ять.
• Окремо: 01 питання власнику · 02 маршрути операцій · 03 реєстр мертвого й задвоєного · 04 дерево коду · 05 стан знахідок 02.09.

Код не змінювався. Зонди жили у власних копіях пісочниці й на диск не йдуть.

11. Дописи агентів — що змінено і як тепер працює

Розділ для майбутніх правок за цим аудитом. Як у 02.09: кожна правка — зелений блок «ВИПРАВЛЕНО <дата> · <номер журналу> · рішення власника», що зроблено і як тепер працює. На 13.10 правок за аудитом ще не було.

Кожне питання побудоване так:

• що бачу — з адресою;
• чому не вирішую сам;
• саме питання;
• варіанти — не рекомендація.

Зібрано із семи лінз, дублі злиті. Рішень тут немає.

Нумерація розділів:

• А — термінове: те, що може дійти до цеху чи клієнта;
• Б — розкрій;
• В — кромки і ядро;
• Г — гроші;
• Д — старт, фон, що вшито;
• Е — мертве і процес;
• Ж — доки.

Відповідати можна одним словом на номер, наприклад «А-1: так, Б-1: попередження».

А. Термінове

А-1. Експорти після зсуву вирізу.

• Що бачу. Кеш точних контурів упізнає деталь за зовнішнім контуром і кількістю вирізів, а не за їх місцем (kernel/exactParts.ts:24–27). Після правки вирізу без перезавантаження сторінки зі старим вирізом виходять:

  • DXF на верстат;
  • креслення PDF;
  • бланк погодження;
  • дошка й колізії.

  Зонд: отвір на x≈450 замість ≈1450.

• Чому не вирішую сам. Це вже могло піти в цех. Виправлення — один рядок, але робить його лише твоя кнопка.

• Питання.

  1. Чи були з 06.10 (DXF з ядра) і 09.10 (бланк з ядра) експорти, зроблені після правки вирізу без перезавантаження сторінки? Їх варто перевірити до різу.
  2. Виправляємо ключ кешу першим ділом?

• Варіанти:

  • виправити зараз (+ тест-сторож);
  • спершу перевірити, чи є вада на проді, потім виправити.

А-2. Поки «рахую точні контури», правки губляться.

• Що бачу. Розкрій чекає ядро і потім записує знімок проєкту, зроблений до очікування (store/slices/packingSlice.ts:105–115, :204–205). Губляться:

  • доданий сляб;
  • номер замовлення;
  • посунута деталь;
  • навіть Ctrl+Z.

  Ще одна вада: дія під час роботи потоку розкрою «вішає» розкрій — кнопки сірі, збереження в кабінет відмовляє.

• Чому не вирішую сам. Обидва виходи змінюють поведінку для менеджера.

• Питання. Що правильно на цей час?

• Варіанти:

  • не давати нічого робити на дошці й у шапці і чесно показати «зачекайте» (Стоуник);
  • доробити так, щоб правки не губились: злиття з поточним проєктом;
  • обидва.

А-3. Прізвища клієнтів у коді.

• Що бачу. mes/data/orders.ts містить поля customer з прізвищами клієнтів п'яти реальних кейсів (у звітах значень не наводимо). Файл у src/ і їде в GitLab. Сам модуль MES ніким не підключений.
• Питання. Що робимо з файлом?
• Варіанти:
  • знеособити (Клієнт 1…5);
  • не везти теку mes/ у GitLab узагалі;
  • видалити модуль.

А-4. Пакет №270–№278 не в GitLab.

• Що бачу. 44 файли (+4 358 / −285 рядків) лежать лише на диску: ядро у фоновому потоці, кеші Бруно, швидкість 12.10. При цьому знімок MR !8 уже містить №267–№269, хоча журнал і ПАМ'ЯТЬ кажуть, що ні.
• Питання. Як і коли пушимо?
• Варіанти:
  • окремою гілкою поверх MR !8 до наступного зведення з ІТ;
  • докласти в MR !8;
  • чекати зведення.

Б. Розкрій

Б-1. Перепил 70 мм — без відповіді з 02.09 (Б-3).

• Що бачу. Пакувальник про перепил не знає (engines/packing.ts:302–342), перевірка колізій знає (:1947–1969). Після авторозкрою 6–8 з 10 деталей «червоні». На дугах, які на CombiCut ріже вода, перепил теж рахується пилою (:1951).
• Питання. Перепил — це правило для пакувальника (він тримає відступ сам) чи лише попередження? Рахувати його на дугах?

Б-2. CombiCut: номінальний контур чи з припуском?

• Що бачу. DXF «Combicut» з дошки ріже контур із припуском (kernel/exportCutDxf.ts:96,179). Вкладка CombiCut ріже номінальний (engines/combicut/plan.ts:146). На один сляб виходять дві різні програми.
• Питання. Який контур правильний?

Б-3. «Перерахувати слеб».

• Що бачу. Пункт контекстного меню перескладає весь проєкт без підтвердження (SlabBoard.tsx:1544). Кнопки режимів при цьому питають.
• Питання. Що має робити цей пункт?
• Варіанти:
  • лише цей сляб;
  • весь проєкт, але з підтвердженням;
  • як є.

Б-4. Ліва Г.

• Що бачу. Дзеркало дає не дзеркальну деталь, а іншу ширину вирізу: 1100 → 900 (__tests__/contourBaseline.test.ts:129–138).
• Питання. Це угода чи помилка?

Б-5. Залишки 02.09 без рішення:

1. Радіус кута робить деталь «кривою» для «Повної текстури» — розгортка підвороту вимикається (packing.ts:587–590). Так задумано?
2. Дзеркалення з умовою «без обробки кромки» — доки кажуть три умови, код має дві (packing.ts:466–471). Додаємо?
3. «Підбір текстури» має групувати вироби так само, як пакер? Зараз два ключі груп (geometryUtils.ts:20 і textureLayout.ts:37).

В. Кромки і ядро

В-1. «Одна труба» для кромок.

• Що бачу. Зонд: інструмент фрези вздовж «пряма → дуга → пряма» однією трубою дає те саме тіло.

  Профіль на Г власника	Зараз	Однією трубою
  L20	4,4 с	0,39 с
  d_20	26,6 с	0,73 с

• Чому не вирішую сам. Це переписування будівника інструмента в ядрі, хай і з тим самим результатом. Потрібен скан на всіх формах.

• Питання.

  1. Робимо?
  2. Якщо так, чи лишається потрібним план Б (кромка кольором + «промалювати»)?

• Варіанти:

  • лише «труба»;
  • «труба» + план Б як запасний вимикач;
  • лише план Б.

В-2. Профіль лише на одній стороні біля опуклої дуги.

• Що бачу. Гроші й 3D тут не сходяться (engines/edgeCutters.ts:964–982 проти engines/geometryUtils.ts:447):
  • у метражі — половина дуги;
  • у 3D дуга без профілю;
  • з галочкою «Стандарт» дуга в метражі рахується 1,5 раза.
• Питання. Що правда?
• Варіанти:
  • дуга не фрезерується;
  • клієнт платить за половину дуги.

В-3. Швидка картинка, поки ядро рахує.

• Що бачу. Старий будівник може показати форму за 5–200 мс, поки ядро рахує 0,3–5 с. Це суперечить умові Бруно №4 «не показувати дві правди».
• Питання. Дозволяємо?

В-4. Кромка під ногою і гнутий елемент на увігнутому куті.

• Що бачу. Обидві діри перейшли в ядро:
  • профіль прорізається під ногою (domain/edgeOccupancy.ts:45 діє лише в UI);
  • гнутий елемент будується на увігнутому куті (domain/radiusElement.ts:242).
• Питання. Перекриваємо правилом у ядрі й фактах чи лишаємо як рідкість?

В-5. Прогрів ядра.

• Що бачу. Проба №279 у пісочниці:

  • редактор вперше — 16,7 → 9,6 с;
  • перший розкрій — 5,6 → 0,5 с;
  • старт сторінки не висне.

  Ціна — 0,3–0,5 ГБ пам'яті і 10–14 МБ завантаження одразу в кожного. Сьогодні ядро й так стартує, щойно відкрили проєкт з деталями.

• Питання. Кому вмикати?

• Варіанти:

  • усім;
  • лише на комп'ютерах;
  • лише на порожньому проєкті;
  • ні.

В-6. CombiCut і легасі-підворот.

• Що бачу. CombiCut ставить сторони легасі-підвороту під 45° і зве їх «смугою потовщення» (engines/combicut/plan.ts:156–157,180). Правило 29.09 каже «підворот — без вуса» (engines/miterAssembly.ts:31–34).
• Питання. Навмисно для старих проєктів чи помилка?

В-7. Межа верстата NC300.

• Що бачу. У коді дві межі, і обидві працюють:
  • 3000×1600 (domain/materialRules.ts:52);
  • 3100×1500 (domain/manufacturability.ts:29).
• Питання. Яка правильна?

Г. Гроші

Г-1. Калібрувальні ціни на сервері.

• Що бачу. Код возить на сервер прайс-бук разом із калібрувальними цінами (store/settingsSync.ts:63–86). Документ №241 каже «гроші на сервер не їдуть». Новіша версія з сервера тихо затирає незбережені локальні правки (:105).
• Питання.
  1. Калібрувальні ціни мають їхати «для всіх»?
  2. Чи потрібен окремий замок для послуг цеху і для прорахунку?

Г-2. Замовлення в ERP у калібруванні.

• Що бачу. Замовлення за ручними цінами не стримується (QuoteOrderCard.tsx:147–167). Калібрування лишається ввімкненим у браузері після виходу адміна. Питання Е-5 з 02.09.
• Питання. Блокувати замовлення чи лише попереджати?

Г-3. Метал і фанера в грошах.

• Що бачу.
  • Метал рахується як камінь: труба 2 м → 4,08 м «різу пилою», площа йде в матеріал, монтаж, пакування і ERP (engines/productionFacts.ts:245–250).
  • Фанерні факти у вбудованих правилах мовчки зникають.
• Питання.
  1. Прибрати метал з фактів каменю до появи правил металу?
  2. Фанеру рахувати вбудованими правилами, через коди ВіярПро чи ще й у прорахунку для клієнта?

Г-4. Виріз зі скругленими кутами.

• Що бачу. Мийка R10, варильна, розетка класифікуються як круглий отвір (engines/productionFacts.ts:171–184). Наприклад, варильна 562×492 R5 → «великий отвір» 2,1 м замість «периметра вирізу».
• Питання. Це «виріз» у метрах чи «отвір»?

Г-5. Метраж кромки.

• Що бачу.
  • Г/П з радіусом чи фаскою кута при припуску 0 дає +43–50 % (engines/geometryUtils.ts:435–458).
  • З припуском — у метраж іде контур уже з припуском.
  • Бланк рахує по контуру з припуском без дуг.
• Питання.
  1. Який метраж правильний для кошторису і для бланка — номінальний?
  2. Дуга з «Обробкою торців» між двома профільованими сторонами — одна операція чи дві?

Г-6. «Стикування в площині».

• Що бачу. Прорахунок рахує стики за формою деталі (engines/quoteCalc.ts:528–534): пряма стільниця зі стиком дає 0, Г — 1, П — 2. Пропил ×2 ставиться на кожне з'єднання, разом із підворотами.
• Питання. Рахувати за фактичними швами? Пропил ×2 — лише між деталями специфікації?

Г-7. Профілі кромок без грошей.

• Що бачу. 39 з 70 профілів кромок (серед них l_20) у кошторисі дають нуль мовчки (domain/serviceMapping.ts:313–349). Питання Г-1 з 02.09 без відповіді.
• Питання. Що робимо?
• Варіанти:
  • додати правила;
  • читати повну мапу EdgeProfileDef.operations;
  • показувати «факти без правила» на екрані.

Д. Старт, фон, що вшито

Д-1. Очі Стоуника.

• Що бачу. Очі анімуються 45 с після кожного дотику, і браузер увесь цей час малює кадри.
• Питання. Як лишаємо?
• Варіанти:
  • як є;
  • рухати лише при наведенні;
  • коротке «моргання».

Д-2. Імпорт бланка погодження.

• Що бачу. Бібліотеки читання PDF і Excel — 0,9 МБ на старті в кожного менеджера (utils/approvalImport.ts:1–3). Сам імпорт схований під адмін-щитком з 28.09.
• Питання. Ним реально користуються? Вантажити по кнопці?

Д-3. 3D малює безперервно.

• Що бачу. Відкрите 3D малює кадри, навіть коли нічого не змінюється. У коді нема жодного frameloop.
• Питання. Чи є в 3D щось, що мусить рухатись само? Якщо ні — малювати лише при змінах?

Д-4. Ядро і CAD у бойовій Studio.

• Що бачу. Studio працює на ядрі OCCT за замовчуванням (kernel/config.ts:15–22, перемикач VITE_KERNEL). Код CAD і BUILDING їде в збірку Studio. Вхід у CAD закриває cadEnabled(), але код лишається.
• Питання. Тримаємо CAD і BUILDING у збірці «до виокремлення CAD» чи виокремлюємо зараз?

Д-5. Не підключене.

• Що бачу. MES-вкладка (mes/MesTab.tsx) і поділ на робочі простори (shell/workspaces.ts, workspaces/*/index.tsx) написані, але не підключені.
• Питання. Що з ними?
• Варіанти:
  • підключати;
  • винести в окремий застосунок;
  • прибрати.

Д-6. Що їде в продакшн.

• Питання. Чи мають бути в продакшн-Studio:
  • сторінка стенду stand.html;
  • 6 сторонніх інтернет-радіо Стоуника;
  • схована плашка ядра з таймером 0,7 с?

Д-7. [сторона ІТ] Віддача ядра на проді.

• Питання. Як прод віддає .wasm (50 МБ сирого) і JS — стиснення, довгий кеш? Від цього залежить, скільки качатиме перший захід з прогрівом.

Е. Мертве і процес

Е-1. Мертвий код.

• Що бачу. Рішення 23.08 «мертве не чіпати, розібратись» досі чинне. Що набралось:
  • 17 мертвих файлів;
  • ≈900 рядків мертвих блоків у живих файлах (Viewer3D.tsx:664–1396 і «Групувати деталі»);
  • 9 зайвих npm-пакетів;
  • тестові дані в бойовій збірці (main.tsx:14).
• Питання. Дозволяєш видалити перевірене мертве пакетом (з бекапом і журналом)?

Е-2. Дві теки.

• Що бачу. web-app і vs-cad — одна програма. Відрізняється лише constructor/docs/DocsTab.tsx. Кожну правку робимо двічі.
• Питання.
  1. Лишаємо дзеркалом чи працюємо в одній теці?
  2. Який DocsTab.tsx правильний?
  3. Чи живе ще поняття «патч» (vs-cad-patch, СТВОРИТИ_VS_CAD.bat)?

Е-3. Хвости, які бачать клієнт чи цех.

• Що бачу.
  • Бланк підписує Підворот «Потовщенням» (utils/export/quotePdf.ts:477,508, З-1 з 02.09).
  • Гнутий акрил після відкриття проєкту має запас 30 % замість 20 % (store/projectHelpers.ts:115).
  • Два червоні тести «відомі» 5+ тижнів.
• Питання. Правимо (кожне — кілька рядків) чи «так і задумано»?

Е-4. 29 питань 02.09 без відповіді.

• Питання. Пройти їх пакетом чи закрити як «живемо так»?
• Де список. 05_СТАН_ЗНАХІДОК_02-09.md.

Ж. Доки

Ж-1. Де живе опис архітектури.

• Що бачу. АРХІТЕКТУРА, MANIFEST, БІЗНЕС, КАРТА_МОДУЛІВ, ПЛАН_І_СТАН, README, СТАРТ, ДЛЯ_НАСТУПНОГО і КАРТА_ПАПОК не згадують OCCT жодного разу. Вісім тек коду не описані.
• Питання. Що робимо з цими доками?
• Варіанти:
  • оновити їх під OCCT;
  • позначити «знімок до 30.09» і лишити ПАМ'ЯТЬ_ЛЕО єдиним живим описом.

Ж-2. Числа в одному місці.

• Що бачу. У доках 17 різних кількостей тестів; теми Стоуника 71 + 21, а не 66 + 21.
• Питання. Тримати числа лише в ПАМ'ЯТЬ_ЛЕО §3, а решті доків посилатися?

Ж-3. Борги, закриті кодом.

• Що бачу. 17 боргів закриті кодом, але відкриті в реєстрах. Серед них FG-12 «замки сторін», №23 (увігнутий кут), П-16 (кут двох підворотів).
• Питання. Їх прийнято кліком? Якщо так — закрити однією ревізією.

Ж-4. Де жити рішенням.

• Що бачу. ≈35 рішень з 02.09 записані лише в журналі й ПАМ'ЯТЬ_ЛЕО §5. MANIFEST — версія 2.60 від 01.09, його пункт 2.54 суперечить коду.
• Питання. Лишаємо як є (журнал + ПАМ'ЯТЬ) чи дописуємо MANIFEST за 03.09–12.10?

Зведено з лінз L1 (розкрій), L2 (геометрія і ядро), L6 (гроші), L7 (старт). Адреси — від src/. [ФАКТ ◔] — прочитано в коді з адресою, якщо не позначено інше. Порівняння — з 09_АУДИТ_02-09/02_МАРШРУТИ_ОПЕРАЦІЙ_02-09.md.

0. Уявлення деталі — ланцюг сьогодні

Чернетка редактора (DetailDraft: розміри, кути, вирізи, кромки, мийки, проточки, доповнення-слоти, mirrorL)
 │
 ├─► 3D і ЯДРО ─ kernel/modelFromDraft.ts:158 → KernelModel
 │      контур: domain/baseContour → engines/shapeBuilder (точні ребра line/arc/ellipse)
 │      кромки: engines/edgeCutters.buildEdgeCutters → edgeLofts;  доповнення: engines/miterAssembly (план стиків)
 │   → kernel/useKernelAssembly.ts (пауза 300 мс №271; поки рахує — старе тіло на екрані)
 │   → kernel/previewScheduler (лише остання версія; запущену побудову НЕ скасовує)
 │   → кеш складань №275 (kernel/occt/assemblyCache.ts; ключ — уся модель; ≤8 / 64 МіБ)
 │   → потік ядра №277 (kernel/occt/workerClient.ts:30; один на сторінку; таймаут 120 с; стартує за першою потребою)
 │   → occtBuilder.buildAssembly (:1366) → buildShape (:791)
 │        є вирізи → кеш плити з кромками №278 (occt/profiledBaseCache.ts, 2 місця на ядро) + запобіжник
 │        інакше buildShapeUncached (:679): призма → вирізи → вус/фаска → cutEdgeTools (:839)
 │             без дуг: cutMany (одна булева);  з дугами: cutArcToolsChecked №276 (список → по черзі → нечітке)
 │   → сітка → передача в головний потік → three.js (Detail3DPreview, DetailMesh)
 │
 ├─► 3D ПІДБІР ─ kernel/productKernel.ts:271 — той самий modelFromDraft і та сама черга;
 │      мийки й метал у Підборі — СТАРИЙ будівник (components/3d/ProductElement3DNode.tsx:479–519)
 │
 ├─► РОЗКРІЙ ─ domain/elementToDetail.buildGeometry (:80) → engines/geometry.explodeDetails (:2588) → парти (ламана)
 │      → точні контури ядра для колізій (№246, kernel/cutOutlines) → пакер (engines/packing)
 │
 ├─► ДОШКА / DXF / PDF / БЛАНК ─ kernel/exactPartInput.ts:10 → той самий modelFromDraft
 │      → kernel/occt/outline2D.exactBlankOutline (:204–206, БЕЗ кромок) + лінії стиків + точний офсет припуску
 │      кеш: kernel/cutOutlines.ts (ключ kernel/exactParts.ts:24–27 — БЕЗ місця вирізів!)
 │
 └─► ГРОШІ ─ engines/productionFacts.ts (2D-полігони) → кошторис / прорахунок; ядро не бере участі

Що змінилось з 02.09:

• Ядро OCCT. 02.09 було чотири уявлення з конвертерами між ними. Тепер додався ще один шлях — ядро OCCT (з 30.09). Воно головне для 3D і точних 2D-контурів.
• Розкрій. Ріже деталь власною математикою (engines/geometry.ts), але вже одним будівником кутів і одним ножем для стиків (закриті знахідки 2 і 8).
• Кромка в 3D — лише картинка [ФАКТ ✔]. Гроші, метраж, розкрій, DXF і PDF її тіла не читають.

1. Створення і зміна деталі

Ядро стартує після полотна, а не паралельно з ним [ФАКТ ✔ 12.10]. Ефект редактора, що просить деталь, React виконує вже після важкого ефекту полотна.

2. Зміна кромки

1. Профіль у довіднику (domain/edgeProfiles…).
2. Переріз фрези: engines/edgeCutters.ts (злиття однакових сусідніх сторін у пробіг :999–1088).
3. Інструменти: призма на прямій, обертання на дузі №273/№276.
4. Віднімання:
   • без дуг — cutMany (одна булева);
   • з дугами — cutArcToolsChecked: «список» → «по черзі» → «нечітке», плюс перевірки.
5. Сітка.

Де час — Г власника, R350, L20 на B–D [ФАКТ ✔ L2]:

Кеш складань і кеш плити зміну кромки не прискорюють, бо це нова модель. Головний важіль — «одна труба» (L2 §4 д): 4,4 → 0,39 с.

3. Зсув вирізу

1. Нова модель з тими самими кромками.
2. buildShape: ключ плити без вирізів збігся → копія плити з кешу №278 → вирізати лише отвір → запобіжник nativeShapeGuard.

Час на Г власника: 4,0 → 0,16–0,24 с [ФАКТ ✔].

Підводний камінь [ФАКТ ✔ L2]: кеш має 2 місця на ядро, і в нього ж пишуть точні контури розкрою (outline2D.ts:206). Після двох контурів деталей з вирізами зсув знову займає 3,9 с.

Другий підводний камінь [ФАКТ ✔ L1]: кеш точних контурів не бачить нового місця вирізу. Дошка, DXF і PDF беруть старе місце до перезавантаження сторінки.

4. Розкрій

1. SlabBoard.tsx:1044–1111 — кнопки режимів, з підтвердженням.
2. runPacking (packingSlice.ts:301) → triggerPackingAsync (:56):
   • знімок для Ctrl+Z → normalizeProject → getAllProjectDetails → explodeDetails;
   • cutOutlineProvider().prepare (:100) — чекаємо ядро без межі (:112–115, без .catch);
   • при цьому стор отримує знімок проєкту й isPacking = true (:106–111).
3. finishPacking(ЗНІМОК, контури):
   • на сляби йде лише камінь (stoneParts, №256);
   • замок nestingLocked, або потік розкрою (дебаунс 200 мс, packingRequestId).
4. workers/packing.worker → autoPack (engines/packing.ts:1851) → validatePlacement по точному контуру.
5. Відповідь: requestId ≠ поточного → відкидається, isPacking не скидається (:224). Інакше:
   • колізії (detectConflicts, :1916);
   • текстури;
   • статус;
   • збереження.

Входи без перерахунку (finalizeProjectState, projectSlice.ts:14–21) — сляби, шапка, ручні дії — збільшують packingRequestId. Тому правка під час роботи потоку «вішає» розкрій [ФАКТ ✔ L1].

Відкриття проєкту — loadWithoutPacking (projectHelpers.ts:93–120), без матеріалу (:115). Через це гнутий акрил отримує запас 30 % замість 20 %.

5. Точні контури → дошка, колізії, DXF, PDF, бланк, CombiCut

Скрізь, де з ядра, — один кеш з ключем без місця вирізів.

6. Гроші — два документи

7. Зведена таблиця «одна операція — два (і більше) коди» [ФАКТ ◔/✔]

Лінза L5. Перевірено в коді /tmp/final/vs-cad/src (= диск 12.10), не в доках. Адреси — від src/. Повний розбір — L5_ІСТОРІЯ_І_СТАН_ЗНАХІДОК.md §2–§4. Підсумок: знахідки — закрито 4 · змінилось 2 · відкрито 6. Пропозиції — зроблено 1 · майже 1 · частково 4 · ні 4. Питання (54) — відповідь 13 · частково 8 · без відповіді 29 · не перевірено 4.

12 знахідок

10 пропозицій

Питання власнику (54; у журналі №85 написано «46»)

• ✅ відповідь / зроблено (13): А-1 · Б-1, Б-2, Б-7, Б-8 · В-1, В-2, В-5 · Е-1, Е-2, Е-4 · Ж-6 · З-10.
• ◐ частково (8): А-2 · В-8 · Д-4, Д-5, Д-7 · Е-3 · Ж-2 · З-9.
• ❌ без відповіді, у коді як було (29): Б-3…Б-6 · В-3, В-4, В-6, В-7 · Г-1…Г-3 · Д-1…Д-3, Д-6 · Е-5…Е-7 · Ж-1, Ж-3, Ж-4, Ж-7 · З-1…З-4, З-6…З-8. Найпомітніше для клієнта — З-1: бланк підписує Підворот «Потовщенням» (utils/export/quotePdf.ts:477, 508).
• ❓ не перевірено (4): Г-4 · Е-8 · Ж-5 · З-5. Група І — сторона ІТ.

Що поруч (не з аудиту 02.09, але з тієї ж історії)

• Не в GitLab: №270–№278 — 44 файли, +4 358 / −285 рядків (ядро у фоновому потоці, кеші Бруно); №267–№269 за доками теж ще ні, хоча в знімку «MR !8» вони вже є. У знімку MR !8 нема нічого, чого нема в робочій копії (крім 2 рядків коментаря server/src/settings.js).
• Червоні тести 5+ тижнів: coreBoundary (engines/shapeBuilder.ts:2) і DXF C:/hhgh — журнал щоразу пише «+2 відомі».
• Рішення з 02.09 (≈35) — у журналі й ПАМ'ЯТЬ_ЛЕО §5; MANIFEST — 2.60 від 01.09, 2.54 суперечить коду.

Джерела: knip 6.41 (--reporter json/compact, у probe-копії), власний граф імпортів на AST TypeScript від main.tsx (статичні, import(), React.lazy, ?worker, new URL(…import.meta.url)), склад чанків бойової збірки зі sourcemap (vite build --sourcemap у probe-копії), tsc (ворота: 418), eslint (ворота), jscpd 4, grep. Сирі виводи — /tmp/final/audit1310/probe-L3/_l3raw/ (L3_knip.json, L3_knip_compact.out, graph.json, reach.json, chunks.json, dups.json, hard.json, heavy.json, jscpd-report.json, скрипти *.cjs). Код: /tmp/final/vs-cad/src (знімок 12.10 вечір). Адреси — відносно src/.

«Рішень» тут немає: стовпець «Стан» — лише факт і порівняння з реєстром 02.09. Позначки: ✔ — перевірено запуском/grep у цьому аудиті; ◔ — прочитано в коді з адресою.

1. Мертві файли (0 імпортерів поза тестами)

Збіг knip і власного графа — повний: knip «Unused files» = 18 (17 у src + App.css), граф — ті самі 17 ts/tsx.

Разом мертвих ts/tsx: 17 файлів, 1 822 рядки (02.09: 9 файлів, ≈1 600). Видалено з реєстру 02.09: нічого — усі 7 мертвих файлів 02.09 лежать на місці.

Лише тести (у застосунку не використовуються, живуть завдяки тестам) — 6 файлів, 2 634 рядки ✔ (граф): mes/sim.ts 86, mes/data/codeArea.ts 1 304, mes/data/orders.ts 922, mes/data/shopMap.ts 103, mes/data/norms.ts 79 — увесь МЕС, крім мертвих MesTab/render; shell/capabilities.ts 140 (карта прав робочих просторів). Разом папка mes/ — 3 090 рядків, жоден не доходить до застосунку.

Ожили з 02.09:

• domain/materialRules.ts (426 р.) — тепер імпортує stounik/checks.ts:23 (checkLShapeInnerCorner, rulesForMaterial — підказки Стоуника) ✔. 11 експортів досі без споживачів поза тестами (knip): MAX_OVERHANG_MM, MIN_JOINT_TO_CUTOUT_MM, WALL_GAP_MM, SINK_TO_MODULE_MM, KEIL_MM, ACRYL_SIPHON_MIN_MM, ACCESSORY_HOLE_RULES, EDGE_USAGE_LABEL, EDGE_PROFILES_BY_USAGE, edgeProfilesFor, checkEdgeProfileUsage; checkPartSize (NC300 3000×1600, :52) — лише тест, а живий розкрій бере 3100×1500 з domain/manufacturability.ts:29 ◔.
• engines/__tests__/mockData.ts (114 р.) — 02.09: «жоден тест не імпортує»; тепер імпортується з main.tsx:14 і потрапляє в бойовий стартовий чанк; рядок :103 mockParts = explodeDetails(mockDetails, …) виконується при кожному старті сторінки ✔ (знайдено в probe-L3/dist/assets/main-*.js).

Лише типи (у збірку не йдуть, це нормально): domain/types.ts, kernel/types.ts, constructor/drawing/model.ts.

2. Мертве всередині живих файлів

Невикористані експорти (knip): 311 імен у 144 файлах src + 115 типів у 55 файлах + 15 файлів із дубльованим експортом (іменований і default — усі вкладки CAD для React.lazy). 02.09: 141 ім'я в 54 файлах + 58 типів у 26. Код виріс у 1,6 раза, невикористаних експортів — у 2,2 раза. Найбільші скупчення: engines/textureLayout.ts 22, kernel/occt/occtBuilder.ts 13 (використовуються всередині файла), approvalCanvasUtils.ts 12, domain/materialRules.ts 11, constructor/drawing/set.ts 7, domain/plywood.ts 6, utils/approvalImport.ts 6 + 6 типів, utils/export/zipArchive.ts 6, kernel/partCuts.ts 5. tsc «оголошено, але не читається» (TS6133/6196/6192/6199): 187 (02.09: 193).

3. Нерозв'язані імпорти (tsc TS2307 — 8; збірка Vite проходить, бо це import type)

Поруч — близькі до них помилки імен (TS2304/TS2305/TS2459): forms/shapes/*Designer.tsx:1 (6 файлів) — DetailDraft з domain/types не експортується; forms/import/DxfOverview.tsx:82–326 — типи DxfPoint/BindingAnchor не імпортовані; approvalCanvasUtils.ts:2 — EdgeProfileType не експортований з approvalImport.ts. Небезпечні для виконання (ім'я значення, не типу): components/ui/FormsPanel.tsx:1746 — slab не визначено (виконається, якщо в проєкті нема першого сляба з матеріалом) ◔; Viewer3D.tsx:731 і Detail3DPreview.tsx:1844 — у мертвому коді.

4. Залежності package.json

Механізмів ZIP — тепер три (02.09: два): самописний utils/export/zipArchive.ts (CRC32 + store), другий самописний engines/mesPack.ts:40–122 (CRC_TABLE, crc32, zipStore) і jszip.

Що з бібліотек у стартовому бандлі (сирцевий обсяг модулів у 9 стартових чанках, зі sourcemap ✔): three 2,4 МБ, react-dom 1,05 МБ, pdfjs-dist 1,03 МБ і xlsx 0,90 МБ (обидва — через utils/approvalImport.ts:2–3, імпорт бланка погодження), @react-three/fiber 0,66 МБ, html2canvas 0,44 МБ (BugReporterDialog.tsx:6), jspdf 0,34 МБ, troika-three-text, three-bvh-csg, three-mesh-bvh, lucide-react, jszip. Ліниво (лише за дією): rrweb, rrweb-player, tesseract.js, opencascade.js (WASM 50 МБ, 14 МБ gzip).

5. Задвоєння

5.1 Однойменні функції в різних файлах (не тести)

Метод 02.09 описаний лише словами («скрипт, нормалізація пробілів і коментарів»), тож порівняння — орієнтовне. Блочний копіпаст (jscpd, ≥15 рядків і ≥80 токенів, без тестів і словників): 22 клони, 537 рядків — 0,54 % коду. Тобто копіюють не великі шматки, а дрібні допоміжні функції.

5.2 Кластери

6. Захардкоджені зони (фіксація, без оцінки; тести виключено)

• мм-літерали в components/**/*.tsx: 364 рядки (02.09: 299; той самий шаблон і виключення): Detail3DPreview 68, Viewer3D 33, ProductElement3DNode 23, HelpDialog 22, ProductEditorWorkspace 17, ProductTemplateModal 13, SlabCatalogModal 12, SlabBoard 11, FormsPanel 11. Поза components — ще 172 рядки в нових tsx (constructor/measure/MeasureTab.tsx 19, stand/main.tsx 17, AssemblyTab 11, PlywoodTab 9 …). Дефолти габаритів досі в модалках: LegModal.tsx:23 (|| 900), SkirtingModal.tsx:20 (|| 50), WallPanelModal.tsx:27, :31 (повна назва номенклатури, || 12), ListsPanel.tsx:31, :51, JointOffsetPopup.tsx:38 (600 : 400), Detail3DPreview.tsx:2059, :2612 ('leg' ? 900 …), canvasUtils.ts:255 (sawOvercut = 2000). Detail2DBlueprint.tsx — дефолти || 1200/600 прибрано.
• Матеріали літералами поза domain/: 15 рядків у 9 файлах коду + 5 у словнику: EdgeProfileSettingsModal.tsx:54, SlabCatalogModal.tsx:290, :426, useSlabOutlines.ts:23, :29, QuotePanel.tsx:458 + engines/quoteCalc.ts:352, :384 + quotePdf.ts:232 ('Акриловий камінь' проти 'Акрил' у домені — без змін), нові constructor/docs/DocsTab.tsx:157, :159, constructor/drawing/sampleOrder.ts:57, :67, :101 ('Кварцит'), buildFotozona.ts:71. DimensionsTable.tsx:102 і miterAssembly.ts:26 — прибрано.
• URL у src: 13 рядків у 7 файлах (02.09 — 0): domain/slabCatalog.ts:247 (сайт Viyar), engines/apsExport.ts:26 (localhost:8082), features/cad-release/CadReleaseActions.tsx:24, :31 (PLM), features/cad-release/OrderFolderSave.tsx:12 (МЕС, за замовчуванням), features/order-registry/RegistryDesk.tsx:74 (PLM), stounik/StoneRadio.tsx:29–34 (шість інтернет-радіо), stounik/leoTopics.ts:146 (локальна адреса). Інтеграції — [сторона ІТ], лише фіксація.
• Ключі сховищ браузера — 9+ префіксів (02.09: 4): slab_cut_planner_current_project (persistence.ts:6; дубль літерала ErrorBoundary.tsx:81 — без змін), slab_cut_planner_cabinet_binding, slabcutplanner-settings-storage (useSettingsStore.ts:335), slabcutplanner.pendingObjectId, канал slabcutplanner-sync, vs3d.expertMode, vs3d.unplacedCollapsed, slabcut_bug_tickets, m-board-zoom, stounik-welcome, stounik-muted, stounik-radio-station, stounik-ack:<id>, vss-before-server-open, vss-before-new-server-order, registry-revision:<id>, plm-project-handoff (у sessionStorage лежить токен передачі з PLM, features/server-project/transport.ts:18–22 — [сторона ІТ]).
• Персональні дані клієнтів (лише місця): mes/data/orders.ts:17, :179, :376, :566, :742 — поле customer з прізвищами і номери замовлень п'яти реальних кейсів (шапка :2 «ЖИВІ ЗАМОВЛЕННЯ»); файл лише для тестів, але в коді, що їде в GitLab.
• PIN/паролі (лише місця): вхід адміна тепер — логін і пароль: у shell/adminLogin.ts:28–32 лежать сіль і PBKDF2-відбиток (їдуть у браузер; шапка файла чесно каже, що це «замок інтерфейсу, а не захист сервера»). Старий PIN за замовчуванням — літералом у store/useSettingsStore.ts:44 (мертвий стан) і у ключових словах довідки Стоуника stounik/topics.ts:464 (видимі користувачу).
• Маркери стану: «ТИМЧАСОВО» — engines/geometry.ts:1469 (отвір зливу), forms/editors/EdgeProfilesPanel.tsx:65, domain/edgeTreatment.ts:6 («і це не тимчасово»); [LEGACY] — domain/types.ts:69; «ВІД'ЄДНАНО» — useCostPrices.ts:2; «ВИДАЛЕНО» — sketchupExport.ts:2; «ФІЛЬТР ВИМКНЕНИЙ» — utils/edgeProfiles.ts:50. TODO/FIXME/HACK латиницею — 0. @ts-ignore/@ts-expect-error/@ts-nocheck — 0.
• as any — 52 у 16 файлах (02.09: 53/16; elementToDetail.ts 17, approvalImport.ts 9, Viewer3D.tsx 8); : any — 87 (86). eslint-disable — 44 у 24 файлах (02.09: 12; нові — у constructor/*, StudioReveal, GlProbe, QuotePanel). console.log — 1 (RectangleDesigner.tsx:14; 02.09: 3), console.warn 21, console.error 38, console.info 3 (GlProbe.tsx).

7. Важкі файли — з чого складаються (топ-12; повний топ-25 — у звіті L3, §3)

Файли-дані за байтами: domain/edgeProfileDrawings.ts 440 КБ (56 inline-SVG) — старт; i18nStatic.ts 250 КБ — старт + 2 воркери; components/ui/HelpDialog.tsx 112 КБ; stounik/topics.ts 99 КБ тексту — старт; domain/edgeProfileImages.ts 81 КБ base64 — старт; domain/viyarServiceCatalog.ts 41 КБ; stounik/leoTopics.ts 37 КБ; mes/data/codeArea.ts 31 КБ і mes/data/orders.ts 26 КБ — лише тести.

8. Тести

Vitest (ворота): 217 файлів (216 у src + 1 server), 1 877 тестів: 1 856 ✓, 2 ✗, 19 пропущено, 407 с. 02.09: 110 файлів, 1 203 ✓ / 1 ✗. Червоні: (1) parsers/dxf/parser.test.ts:7 — шлях C:/hhgh/… (без змін з 02.09); (2) новий __tests__/coreBoundary.test.ts — сторож «ядро не імпортує UI»: порушник engines/shapeBuilder.ts:2 (import type … components/forms/utils/draftHelpers). Шапка тесту каже, що цей місток «прибрано» 03.09 — тобто фікс втрачено. Пропущені: kernel/__tests__/profiledBaseCacheGeometry.integration.test.ts (13), profiledBaseRuntimeGuard.integration.test.ts (6). 236 із 431 модулів без прямого тесту (02.09: 137 із 227) — частка майже та сама (55 % проти 60 %). Найважчі без тестів: utils/approvalImport.ts 4 805, Detail3DPreview.tsx 3 530, Viewer3D.tsx 2 102, SlabBoard.tsx 1 642, QuotePanel.tsx 1 269, HelpDialog.tsx 1 154, SlabCatalogModal.tsx 1 123, ProductElement3DNode.tsx 983, Detail2DBlueprint.tsx 917, constructor/measure/MeasureTab.tsx 915, App.tsx 875, PlywoodTab.tsx 743, store/slices/projectSlice.ts 709. Рушії з тестами: geometry, packing, quoteCalc, edgeCutters, shapeBuilder, productionFacts, estimate, miterAssembly (02.09 — без тестів), mesPack, occtBuilder, constructor/drawing/set, domain/plywood, domain/joints. За папками без прямого тесту: components 111 з 135 модулів, constructor 36 з 57, workspaces 12 з 13, utils 12 з 20, kernel 15 з 37, engines 6 з 41, domain 5 з 48.

Згенеровано лінзою L3 аудиту 13.10 зі знімка /tmp/final/vs-cad (12.10 вечір; за брифом — ті самі 666 файлів, що на диску, і ті самі, що в web-app, крім constructor/docs/DocsTab.tsx). Скрипт: probe-L3/_l3raw/tree.cjs (граф імпортів — graph.cjs на AST TypeScript, досяжність — reach.cjs). Формат — як 04_ДЕРЕВО_КОДУ_02-09.md, плюс два стовпці: «Δ до 02.09» і «Де». Не описує server/ (сторона ІТ).

Як читати.

• Рядків — як wc -l. Δ до 02.09 — різниця з деревом 02.09 (= — та сама кількість рядків; нов. — файла 02.09 не було). Жоден файл із дерева 02.09 (стан після 03.09) не зник.
• Опис — перший коментар-шапка файла; якщо шапки нема — опис із дерева 02.09 (позначено «(опис 02.09)»); інакше — перелік експортів. ⚠ — знахідка аудиту 13.10 (адреси — у звіті L3_МЕРТВЕ_ВАЖКЕ_ХАРДКОД.md). tsc N — скільки помилок tsc у файлі (ворота 418).
• Де (лише для коду, не для тестів): Г — головний (стартовий) набір: файл досяжний СТАТИЧНИМИ імпортами від main.tsx; його код вантажиться і виконується при кожному відкритті сторінки, навіть якщо людина туди не заходить; Л — лише ліниво: через React.lazy/import() або як воркер — вантажиться, коли відкрили вкладку/функцію; С — лише окрема сторінка стенду stand.html; Т — імпортується лише як тип (у збірку не йде); лише тести — у застосунку не використовується, живе тільки завдяки тестам; МЕРТВИЙ — ніхто не імпортує (підтверджено knip і графом).
• Збірка (vite build --sourcemap у probe-копії) підтвердила класифікацію: 329 файлів коду застосунку, тестовий engines/__tests__/mockData.ts і 2 svg лежать у 9 стартових чанках (6,1 МБ мініфікованого JS, ≈1,9 МБ gzip). Розбіжність із графом — лише 4 файли без власного коду (реекспорти/типи).

Підсумок

Розподіл коду (431 модуль, 117 217 рядків) за тим, коли він вантажиться:

Папки верхнього рівня

Примітки до таблиці. «02.09: файлів / рядків» — з дерева 02.09 (після видалення трьох файлів 03.09). Нові папки з'явились між 03.09 і 12.10: constructor (CAD: замір, метал, фанера, збірка, зведення, документи, CombiCut), kernel (ядро OCCT і шви до нього), workspaces/architecture (BUILDING: план, розкладка, відомість), stounik (помічник-маскот), mes (симуляція цеху — не підключена), shell (права і робочі простори — підключено лише вхід адміна), stand (окрема сторінка стенду OCCT), features/* (інтеграції з реєстром/PLM/МЕС — [сторона ІТ]), components/studio (головна Studio).

Повне дерево з описами

src/ — 9 файл(ів), 4049 рядків

src/__tests__/ — 3 файл(ів), 241 рядків

src/assets/ — 5 файл(ів), 126 рядків

src/components/ — 2 файл(ів), 525 рядків

src/components/2d/ — 3 файл(ів), 2216 рядків

src/components/2d/board/ — 14 файл(ів), 1254 рядків

src/components/2d/board/__tests__/ — 1 файл(ів), 190 рядків

src/components/3d/ — 15 файл(ів), 4503 рядків

src/components/3d/__tests__/ — 3 файл(ів), 198 рядків

src/components/assembly/ — 1 файл(ів), 182 рядків

src/components/auth/ — 3 файл(ів), 183 рядків

src/components/auth/__tests__/ — 1 файл(ів), 53 рядків

src/components/forms/editors/ — 6 файл(ів), 1310 рядків

src/components/forms/editors/__tests__/ — 2 файл(ів), 132 рядків

src/components/forms/import/ — 4 файл(ів), 1295 рядків

src/components/forms/shapes/ — 7 файл(ів), 393 рядків

src/components/forms/utils/ — 3 файл(ів), 1266 рядків

src/components/forms/utils/__tests__/ — 5 файл(ів), 817 рядків

src/components/mobile/ — 3 файл(ів), 215 рядків

src/components/room/ — 3 файл(ів), 915 рядків

src/components/studio/ — 2 файл(ів), 409 рядків

src/components/ui/ — 70 файл(ів), 26570 рядків

src/components/ui/__tests__/ — 11 файл(ів), 1392 рядків

src/constructor/ — 4 файл(ів), 502 рядків

src/constructor/__tests__/ — 10 файл(ів), 1292 рядків

src/constructor/assembly/ — 4 файл(ів), 1180 рядків

src/constructor/builder3d/ — 3 файл(ів), 358 рядків

src/constructor/combicut/ — 2 файл(ів), 813 рядків

src/constructor/docs/ — 10 файл(ів), 1635 рядків

src/constructor/drawing/ — 15 файл(ів), 3526 рядків

src/constructor/measure/ — 9 файл(ів), 3237 рядків

src/constructor/merge/ — 3 файл(ів), 676 рядків

src/constructor/merge/__tests__/ — 1 файл(ів), 78 рядків

src/constructor/metal/ — 4 файл(ів), 1119 рядків

src/constructor/plywood/ — 3 файл(ів), 1064 рядків

src/core/ — 2 файл(ів), 313 рядків

src/domain/ — 48 файл(ів), 12607 рядків

src/domain/__tests__/ — 42 файл(ів), 5401 рядків

src/engines/ — 34 файл(ів), 14831 рядків

src/engines/__tests__/ — 59 файл(ів), 8905 рядків