Перейти к содержанию

LeroyProtoLIB — документация (оглавление)

K3-библиотека корпусной мебели РШ (распашные шкафы, тумбы, комоды, антресоли, обувницы, санузел, гардеробные). Составлено 2026-07-24. Проверка по ссылкам файл:строка; номера строк — после коммита aed3be70 (докстринг-правки) и последующих инвентарей 04c–04e.

Документация построена послойно: 01–02 — архитектура и поток построения, 03 — корпус/цоколь/параметры и статус порта в новую архитектуру, 04a–04e — инвентарь модулей и точки для рефакторинга.

Путеводитель по разделам

Раздел Что внутри Читать, когда нужно …
01-families-map Двухслойная архитектура корпуса (старое shell.py / новое based_shell/shell.py); точки входа cab_*; 8 семейств-подпакетов; ОБЩЕЕ/РАЗЛИЧИЯ mono/duo/trio; механизм посекционных параметров понять структуру библиотеки, добавить новое семейство, найти класс корпуса/ниши
02-niche-door-facade-chain Цепочка построения ниша → дверь → фасад → петли → ручка → крепёж; кто ставит кромку/пазы/крепёж; обязательные входные атрибуты прототипа разобраться, как рождается фасад, почему дверь не строится без _fstype, где крепёж панелей
03-shell-socle-params-port Корпуса Shell*, цоколь ShellSocle, ниши-наполнения; резолв номенклатуры из «цвета»; таблица «оракул→порт→статус» §4; готовые классы для прямого переиспользования §5 узнать, что уже портировано в arline-geometry, что ещё нет; найти готовый оракульный *.factory(...) для моста 1:1
04a-inventory-url_entityes-tests 96 модулей url_entityes/ (датаклассы параметров прототипов), таблица ProtoID→изделие, «сироты»; tests/ (не pytest, запуск из K3) сверить дефолты прототипа, найти мёртвый dprotoid_plus.py, понять тестовый конвейер
04b-inventory-shell Инвентарь shell.py (~10000 строк): данные RSH_*, корпуса, цоколь, терминалы, ниши; 10 TODO(АУДИТ) найти класс корпуса/ниши по роли, посмотреть потенциальные баги ядра
04c-inventory-core-utils 5 модулей ядра (piv_param_nichenumber_utilites, functions, details, based_shell/shell, url_data_reader) + сводка TODO(АУДИТ) всех cab_*/family/antresol/bathroom найти функцию резолва материала/крепежа, понять посекционные параметры, список всех найденных багов
04d-inventory-entry-points 77 точек входа P_*.py/Commode*.py (45 старых + 32 новых); контракт main()/build_aboad(); разбивка по 10 семействам добавить/найти точку входа прототипа, понять контракт обёртки
04e-refactoring-candidates Систематизация дублей (Draw/Assign/build_aboad, setDoorNiche, RSH*, limits); мёртвый код; 7 истинных багов с риск-оценкой спланировать рефакторинг, оценить риск правок, найти мёртвый код к удалению

Краткая карта (если читать некогда)

  • Главное деление — два поколения корпусов: корневой shell.py (старое, высокие шкафы + склад примитивов) и based_shell/shell.py (ShellBased — новое, все семейства-подпакеты). См. 01 §0.
  • Единая точка вызова любого семейства — LeroyProtoLIB.<family>.boad.main(...) из тонкой обёртки P_*.py (04d).
  • Вся вариативность (число секций, ящики/двери, симметрия) — параметры прототипа с числовыми суффиксами, разбираются get_param_from_nichenumber + setNicheFasFromIndex (01 §5, 04c §1).
  • Фасад строится только при _fstype != 0 (02 §1) — частая причина «дверь не построилась».
  • Порт в новую архитектуру (arline-geometry) не имеет: крепежа, пазов под ЗС, наложения кромки, навесов, терминалов, ряда наполнений (03 §4). Мост к 1:1 — отдавать оракульным *.factory(...) shell-подобный объект (03 §5).

Найденные проблемы (TODO(АУДИТ) — код НЕ правился)

Зафиксированы в правках (коммит aed3be70) как аналитические пометки. Полный реестр — 04b §«TODO(АУДИТ)» и 04c/04e §7. Критичные:

  • NameError ccmater в bathroom/dnboads/common_boad.py make_shell
  • shell.py:329 — hpolkdp{i} в квадрате (ожидалось * ishpolkdp{i})
  • shell.py:434,724 — mutable default slotpars
  • functions.py:122 — get_fix_vbp дублирует get_fix_vb
  • functions.py:343 — make_naves потенциальное зависание (while без break)
  • cab_duo_two.py — метод определён в классе дважды
  • cab_duo_3/4 — range ТипФас не покрывает число фасадов

Правило: фиксить только после подтверждения владельца (выгрузка идёт на производство). Рефакторинг семейств — только после рендер-верификации 1:1 оракул-vs-порт (04e §резюме).

Внешний контекст

  • Каноничные правила работы с K3 — k3-mcp-server/K3-RULES.md.
  • Интеграционная ветка K3 (потребляет калькулятор): feature/CA-46516, тег arline-geometry-v0.1.1 (там собраны MONO-1, DUO-2N корпус).
  • План рендера РШ через оракульные билдеры — plans/041-kickoff-oracle-render.md.