Know the route.
Then choose the right partner.

v2 — исправлен баг тернарной логики. В исходном файле факты, которые пишутся только как побочный эффект правил (reg.*.supersededBy, reg.*.applicable), не имели дефолтного значения и оставались undefined, если правило-источник ни разу не срабатывало. Правила маршрута, проверяющие такой факт через is:[unknown,false], читали это как «жду ответа» и зависали в pending навсегда — этапы LVD/EMC самодекларации молча пропадали из карты всякий раз, когда RED не применяется. Кейсы led-driver-eu и machine-annex4 из корпуса ниже проваливались на исходном файле. Фикс: любой факт, встречающийся в rulebase только как assert-цель, теперь дефолтится в false, а не остаётся отсутствующим — см. blankFacts(). Нажмите «Прогнать корпус кейсов» — теперь 7/7.

v3 — закрыты 2 дыры покрытия правил, найденные не corpus-кейсами, а отдельной exhaustive-проверкой (см. кнопку «Проверить покрытие правил», реализует tz-roadmap-engine.md §14.2 п.8): Annex IV машиностроения с полностью применёнными гармонизированными стандартами (новое правило mach.route.annexIV.harmonised, ст. 12(3) — требует проверки регуляторным специалистом), и RoHS/GPSR, которые были применимы, но не вели ни к одному этапу вообще ни в одном сценарии (obligation.techfile/obligation.marking теперь учитывают RoHS, для GPSR — отдельный obligation.gpsr, т.к. у него нет CE-маркировки). corpus-кейсы эти дыры не ловили: они сверяли только применимые регламенты и итог по НО/исполнителям, не то, что у каждого регламента есть хотя бы один этап.

v4 — снято закрытие мира и матрица покрытия выведена из базы правил. Дефолт false для производных фактов из v2 чинил один симптом и создавал худший: факт становился ложным даже когда правило-источник ещё ждало ответа, и целый регламент молча исчезал из выдачи. Разрешение перенесено в движок: false ставится только когда все правила-источники окончательно ложны, иначе факт остаётся unknown. Неопределённые регламенты теперь видны отдельным состоянием «не определено» с указанием, от какого факта они зависят; условные этапы называют своё допущение. Матрица COVERAGE_MATRIX удалена — сценарии выводятся из самой rulebase, поэтому новое правило больше не может остаться непроверенным. Добавлен восьмой сторож guard.derived-unknown: ни корпус, ни проверка покрытия этот класс ошибок не ловили, потому что покрытие перебирает только сценарии, где регламент уже применим.

v5 — добавлена ветка организации. ISO 9001/13485/14001/45001 — не «ещё один регламент»: объект оценки другой, и применимость следует не из закона, а из драйвера (заказчик, тендер, регуляторное требование, внутреннее решение). Правила получили scope, гейт по assessment.subject ставится автоматически на все правила, дорожная карта рендерится двумя дорожками. Закрыта дыра продуктовой ветки: MDR требует СМК для изделий всех классов (ст. 10(9)) — этап qms_mdr раньше отсутствовал. Добавлены предупреждения о двух массовых заблуждениях (ISO 13485 не даёт доступа на рынок, ISO 9001 не требуется для CE) и ограничение exclusiveWith по ISO/IEC 17021-1 п. 5.2.5: подготовка и аудит не могут уйти одному исполнителю. Все правила ветки организации требуют проверки специалистом по сертификации систем менеджмента.

Пост-фикс v5 (живое тестирование). Два регресса из v4 вернулись в v5 (собран не поверх исправленной версии) — восстановлены: nbUndetermined снова учитывается в блоке коррекции, overflow-wrap снова в паре с min-width:0 на .regstate. Плюс новая находка: вопрос про действующий ISO 9001 собирался, но ни одно правило его не читало — теперь сокращает описание этапа анализа разрывов (общие пункты Annex SL/HLS уже закрыты).

Пост-фикс v5.2 (ответ регуляторного специалиста, см. roadmap-engine-regulatory-questions.md). GPSR-vs-секторальное законодательство: правильная модель — не "выключение", а дополняющий слой (Reg. 2023/988 Art. 2(1), Commission Notice 2025). Единый gpsr_docs заменён на два этапа: gpsr_residual (Chapter II, только риски вне секторального акта — описание теперь называет, что именно уже покрыто) и gpsr_horizontal (ст. 19-21, Ch. IV/VI/VIII — действует независимо от секторального покрытия). Найдено движковой правкой два бага, не связанных с GPSR: краш в factDomains() на multi-select опциях без .sets, и неверные ожидания в собственном corpus-кейсе на fulfilment-роль (забыл про GPSR/WEEE). Ещё не решено (см. документ с вопросами): та же логика "дополняющий слой" вместо "выключение", вероятно, применима и к precedence.mdr/toys/ppe.over.gpsr — специалист явно отметил это как требующее отдельной проверки, не подтвердил.

Пост-фикс v5.3 — вопросы 2 и 3 регулятору отвечены. Вопрос 2: готовая машина в периметре 2006/42/EC не проходит отдельную процедуру по LVD — существенные требования электробезопасности включены в оценку по Machinery (Annex I §1.5.1). Новое integration.machinery.lvd_safety (не precedence.* — по терминологии специалиста это включение объекта регулирования, не поглощение конкурирующих актов), новый факт product.machineryArt1_2k для исключения по ст. 1(2)(k) (бытовая техника, аудио/видео, IT, офисная техника, НН-коммутационное оборудование, электродвигатели отдельно — для них наоборот, LVD напрямую). Вопрос 3: Annex IV Directive 2006/42/EC функционально заменён на Annex I Part A/B (Regulation 2023/1230, с 20.01.2027) — для Part A гармонизированные стандарты не снимают требование НО (в отличие от Part B и старой модели). Новая ветка mach2027.* (4 route-правила), факт product.machineryAnnexIPart. ML-триггер Part A (Annex I п. 5-6) — не отдельный assert-факт (создал бы двойное управление одним путём: и прямой ответ пользователя, и правило одновременно пишут в один факт — фаза переразрешения производных фактов безусловно перезаписала бы прямой ответ), а часть help-текста вопроса, как и остальные примеры категорий. Чекер покрытия правил чинён отдельно: без этого mach2027.* показывал бы "0 сценариев" и проходил бы молча, ничего не проверив — правила 2027 года неактивны на сегодняшнюю дату оценки по умолчанию. Теперь каждый сценарий покрытия прогоняется на двух датах (сегодня + после перехода). Оба ответа содержат непроверенные специалистом допущения (перенос исключения ст. 1(2)(k) и включения LVD на новый Регламент без подтверждения; приоритет при тройном пересечении RED+Machinery+LVD; EMC-vs-Machinery) — зафиксированы как вопрос 4-5 в документе.

Пост-фикс v5.4 — вопросы 4a/4b отвечены. Хорошая новость: маршрутизацию менять было не нужно. Специалист подтвердил ровно текущее поведение — RED не вытесняет Machinery целиком (обе применяются, LVD/EMC поглощены RED — это уже было верно), Machinery и EMC тоже сосуществуют (деление по аспекту: общие эмиссии — EMC, помехоустойчивость, влияющая на безопасность, — Machinery). Здесь никогда не было правила, вытесняющего Machinery через RED или EMC — специалист лишь подтвердил, что так и должно быть. Добавлены только информационные примечания к описанию machinery-этапов (правовое основание сосуществования) и новый corpus-кейс guard.red-machinery-coexist, закрепляющий это поведение — чтобы будущая правка не добавила по аналогии с LVD/EMC ошибочное precedence.red.over.mach.

Пост-фикс v5.5 — вопрос 5 отвечен. Перенос на Regulation 2023/1230 — НЕ буквальный в части исключения категорий. Ст. 1(2)(k) 2006/42/EC (триггер — только LVD) стала ст. 2(2)(p) 2023/1230 (триггер — LVD ИЛИ RED) с двумя новыми исключениями из исключения (электрически приводимая мебель, аддитивная 3D-печатная техника — обе остаются под Machinery). Новый отдельный факт product.machineryArt2_2p (не переиспользован старый — модель по существу другая). Практическое следствие из Recital 18 самого Регламента: бытовая Wi-Fi техника, которая раньше могла остаться под Machinery (если не покрыта LVD), с 20.01.2027 исключается уже из-за одного RED — закреплено кейсом mach2027-wifi-appliance-excluded, с контрольной парой mach2027-industrial-radio-not-excluded (та же RED+Machinery комбинация, но продукт вне шести категорий — исключение не срабатывает). Механизм включения LVD (вопрос 2) подтверждён перенесённым без изменений — Annex I §1.5.1 стал Annex III §1.5.1, тот же номер параграфа.

Пост-фикс v5.6 — независимое внешнее ревью нашло реальный баг, затрагивавший каждый кейс корпуса. Четыре правила (integration.machinery(2027).lvd_safety, precedence.ppe.over.mach(2027)) читали reg.mach(2027).applicable, но сами не имели границ дат — когда правило-источник этого пути отфильтровано по эпохе, путь вообще выпадает из активной sources-карты, и зависящее правило зависает в pending навечно, даже в полностью отвеченных кейсах. Полнота была 25-93% на всех 18 кейсах, включая полностью специфицированные — корпус этого не ловил, потому что completeness нигде не проверялся. Проверил сам перед тем, как чинить — подтвердилось. Два фикса, оба нужны (одних дат недостаточно: obligation.techfile/ marking читают тот же путь через any[] и заражались unknown через orT в сценариях без других применимых регламентов): (1) добавлены границы дат на все четыре правила; (2) производный факт без единого активного источника в эту эпоху теперь закрывается в false, а не остаётся unknown из дефолта blankFacts() — тот же принцип, что уже применялся к possibleRegulations (симптом чинился, корень — нет). Плюс три меньших фикса того же ревью: дефолт даты оценки в UI берётся из реального системного времени (не из фиксированной TODAY_ISO — движок остаётся чистым, меняется только вызывающая сторона); конфликт источников одного производного факта (RED vs Machinery за LVD) резолвится по rule.priority, а не по порядку объявления в массиве (поведение не изменилось, стало явным); добавлен 9-й сторож — полностью отвеченный кейс обязан давать completeness===1, кейсы с намеренно неотвеченными фактами помечены allowPartial. Проверено заново после фикса: корпус 20/20, покрытие 884/884, полнота 100% на всех 18 неallowPartial-кейсах (было 25-93%), приоритет/граница даты/детерминированность (50 прогонов)/чистота функции — без изменений.