LeroyProtoLIB — общее между семействами и кандидаты на рефакторинг¶

Раздел 4e документации LeroyProtoLIB (см. 01-families-map.md). Составлен агентом-документатором 2026-07-24. Источник — TODO(АУДИТ), расставленные в правках (коммит aed3be70), подтверждено чтением кода. Ссылки — файл:строка.

В библиотеке много дословных дублей между cab_* и family boad.py. Это сознательное копирование «скелета» Unit-класса при создании каждого нового семейства. Kickoff 041 (п.5) ставит задачу: «выделять общее в классы (ООП), не плодить функции». Ниже — систематизация дублей с оценкой, во что их можно свернуть и с каким риском.

1. Дубли структуры Unit-класса (DRAFT-кандидат №1)¶

Почти дословно повторяются в каждом family UnitXXX и каждом cab_*.UnitXXX:

Метод/блок	Пример `pedestal_pivot_mono/boad.py`	Также в
`Draw()` (сброс `NumCounter.num=19`)	`:871`	pedestal_duo `:1366`, commode_mono `:466`, cab_pivot_mono `:665`+
`DrawUnit()`	`:879`	`:1374`, `:474`
`PostDraw()` / `__PostHingeMove`	`:884`	`:1379`, `:479`
`_AssignScratchAttributes()`	`:892`	`:1387`, `:481`
`_AssignAttributes()`	`:909`	`:1404`, `:497`
`getShelfesNiche()`	`:502`	`:820`
`putDoorPoshinge(door)`	`:511`	`:829`
свойства `number`/`doortype`/`fsmater1`/`fas_bandtype1`	(в теле класса)	все
хвост `build_aboad`: guid → `k3.fixing`/`k3.holes` → `selbyattr`	`:926`	`:1421`, `:514`, cab_*

Предложение: вынести общий базовый класс PivotUnit(uFurnObject.FurnObject) со скелетом Draw/DrawUnit/PostDraw/_Assign*/getShelfesNiche/ putDoorPoshinge/свойствами и хвостом build_aboad. Семейства переопределяют только Make + createNicheN + RSH_* + params_adapter.

Риск: ВЫСОКИЙ. Эти методы вызывают K3-функции и работают с NumCounter, guid, k3.fixing — малейшее расхождение в одном семействе сломает выгрузку на производство. Делать только с верификацией «панель-в-панель» оракул-vs-порт (см. 03 §4). Текущая выгрузка идёт на производство — ошибка недопустима.

2. Дубли `setDoorNiche`/`createDoorNiche` (DRAFT-кандидат №2)¶

setDoorNiche/createDoorNiche — почти идентичны между:

commode_pivot_duo/boad.py (:137/:170)
commode_pivot_trio/boad.py (:151/:181)
pedestal_pivot_mono/boad.py (:140/:169)
pedestal_pivot_duo/boad.py (:305+)
cab_pivot_mono.py

Отличаются только расчётом xps-сдвига и xp-ширины по числу секций (wpos1, w_small). TODO(АУДИТ) прямо помечает: «дубль во всех pivot-семействах — вынести в общий модуль» (commode_pivot_mono/boad.py, pedestal_pivot_duo/boad.py).

Также SetBoxNiche/createBoxNiche дублируются (commode_pivot_mono/boad.py :51/:88 — «почти дословный дубль»). В pedestal_pivot_duo/boad.py они закомментированы (мёртвый код, путь ящиков временно отключён).

Предложение: общий create_door_niche(inst, num_niche, ...) в новом модуле (напр. niche_builders.py), параметризованный шириной/сдвигом секции.

Риск: СРЕДНИЙ. Логика изолирована, есть оракульный эталон (Niche_user. StraightNiche). Но затрагивает цепочку ниша→дверь→фасад (02), критичную для производства.

3. Дубли между cab_* и family boad.py¶

cab_*.py (высокие шкафы) и family boad.py (тумбы/комоды) — одна и та же структура, разница только в корпусе (ShellPivot* vs ShellBased) и числе секций. cab_duo_two.py целиком повторяет скелет pedestal_pivot_duo/boad.py.

Предложение: унифицировать cab_* и family на одном PivotUnit (см. §1), разница — только shell_cls и niches_count.

4. Дубли `RSH_*` датаклассов¶

RSH_DUO в pedestal_pivot_duo/boad.py (TODO(АУДИТ): «поля почти полностью повторяют RSH_DUO из …»). Поля fix_*, slotpars, prmater/bandtypereal повторяются между всеми RSH_*.

Предложение: общий миксин/базовый RSH_PivotBase с общими полями и RSH_Complect.propbuilder; в подклассах — только специфичные (w_small, wpos1/2, blockbox{n}).

Риск: НИЗКИЙ (чистые данные, без логики K3).

5. Дубли ограничений (limits.py)¶

LimitSize_PIVOT_DUO4 объявлен дважды: antresol_pivot_duo/limits.py и antresol_pivot_trio/limits.py (TODO(АУДИТ)). WIDTH_DIAPASON/LimitSize повторяются между пакетами.

Предложение: единый модуль limits_pivot.py (или расширение based_shell/ limits.py) с общими enum-лимитами MONO/DUO/TRIO, переиспользуемый antresol/cab.

Риск: НИЗКИЙ.

6. Мёртвый код и old_modules¶

old_modules/ в antresol_pivot_duo/mono/trio (10 файлов) — кандидаты на удаление, нигде не импортируются; актуальный корпус — based_shell/shell.py (ShellBased). TODO(АУДИТ) в каждом.
pedestal_pivot_duo/boad.py: SetBoxNiche/createBoxNiche закомментированы — «удалить после стабилизации 0.4.x или вынести».
commode_pivot_mono/boad.py: функция-мёртвец (не вызывается из build_aboad).
url_entityes/dprotoid_plus.py — мёртвый (нет from dataclasses import dataclass → NameError), кандидат на удаление (04a §2).

Риск удаления: требуется grep -r по импортам перед каждым; old_modules безопасны (проверено TODO).

7. Истинные баги (не дубли — требуют ФИКСА, не рефакторинга)¶

Выделено отдельно — это не «общее», а ошибки. Фиксить только с подтверждением владельца (выгрузка на производство):

bathroom/dnboads/common_boad.py: NameError — имя ccmater в make_shell не определено (скопировано из params_adapter).
shell.py:329 (RSH_ShellGS): hpolkdp{i} умножается сам на себя (квадрат; ожидалось * ishpolkdp{i}).
shell.py:434,724: mutable default slotpars: RSH_Slot = RSH_Slot().
shell.py:2868: h_cok + + h_dsp (двойной плюс).
functions.py:122 get_fix_vbp = get_fix_vb (тот же ключ ID_FixCS1).
functions.py:343 make_naves: while not id_naves без break — потенциальное зависание.
cab_duo_two.py: метод определён в классе ДВАЖДЫ.
cab_duo_3/4: range ТипФас не покрывает число фасадов.

Полный реестр — 04b §«TODO(АУДИТ)» и 04c.

Резюме для планирования рефакторинга¶

Кандидат	Объём (файлов)	Риск	Когда
Базовый `PivotUnit` (скелет Draw/_Assign/build_aboad хвост)	~10	ВЫСОКИЙ	после рендер-верификации 1:1
Общий `create_door_niche`/`create_box_niche`	~6	СРЕДНИЙ	вместе с §1
Базовый `RSH_PivotBase` + миксины	~10	НИЗКИЙ	можно сейчас
Единый `limits_pivot.py`	~8	НИЗКИЙ	можно сейчас
Удаление `old_modules/` + `dprotoid_plus.py`	11	НИЗКИЙ	после grep-проверки импортов
Фикс истинных багов (§7)	~8	СРЕДНИЙ-ВЫСОКИЙ	с подтверждением владельца

Главное правило (kickoff 041): любой рефакторинг семейств возможен только после того, как рендер РШ через оракульные билдеры даст 1:1 совпадение панелей (кромки/крепёж/пропилы) оракул-vs-порт. До этого — фиксировать в документации (что и сделано в 04b/04c/этот файл), не трогая код.

Связанные документы¶

01 §3 (ОБЩЕЕ между семействами), §4 (РАЗЛИЧИЯ mono/duo/trio); 04b/04c (реестры TODO(АУДИТ)); 03 §4-5 (что в порте есть/нет — обоснование риска).