# R3: фактический результат по десяти находкам R2

Статус ниже относится к новой веб-редакции и приложенному проектному контракту. Исходные R2-файлы сохранены; аппаратная реализация не создавалась и не квалифицировалась. «Исправлено в тексте» не означает «прошло стенд».

| Находка | Фактическое изменение | Статус и оставшаяся проверка |
|---|---|---|
| R2-01: несовместимые реестры ошибок | Один `site/contracts/registry.json`, generated SPEC/schema/enum, A39-018 содержит тот же словарь; BUSY и STALE_COMMAND исключены из активных норм | Исправлено в проектном контракте и модели. Независимые реальные реализации ещё должны пройти совместимость |
| R2-02: отзыв owner authority | A21-022, R24-006/007/011 разделяют session credential и owner/recovery authority; отзыв каждого MCU завершается отдельно, недоступный узел PENDING | Архитектурное уточнение внесено. OwnerSet, формат подписей, bootstrap, rollback и криптографическая реализация остаются открытыми |
| R2-03: слабая семантическая валидация | Registry-driven validator проверяет обязательные поля, типы и границы; 32 тестовых метода с subtests; STATE_CONFLICT и body-limit мутации обнаруживаются | Исправлено в приложенном Python reference. Это не проверка firmware/runtime или скомпилированных Rust/Kotlin declarations |
| R2-04: Event health/provenance | R3-14-HEALTH-P описывает привязку события к placement/descriptor/mode, cutover и качество канала с возрастом | Открыто. Wire 0.2 не расширен молча; нужен согласованный профиль или формальный барьер и отрицательные тесты. Документ теперь явно сообщает ограничение |
| R2-05: совокупная частота переключений | A24-018 добавляет общий guard выбранного реле/нагрузки, границу Core/GPIO, сохранение deadline и немедленный ручной OFF | Открыто для постоянной эксплуатации. Числовой envelope и реализация не выбраны; модельные переходы не выдаются за ресурс механического контакта |
| R2-06: отсутствующий 5 В источник в BOM | A33-005 дополнен источником Actuator, питанием Sensor/Presence и жгутом; R16-003 задаёт подключение и сервисный USB/backfeed, проверку с выключенным Hub | Пробел закупочного списка исправлен. Выбор точных артикулов, ревизий, токов, F1, жгута и сборка только по ведомости остаются аппаратной приёмкой |
| R2-07: неполный Markdown | `content/chapters.json` — единый источник; все 51 intro, содержащие исходные вводные абзацы, 51 question, 7 terms и units выводятся в страницы глав и /read/ | Исправлено для двух полных веб-представлений и проверено по фактическому HTML. Исторический R2 Markdown не переписан; новый полный Markdown-экспорт не заявляется |
| R2-08: Observation без delivery_kind | A39-004 заменён точным numeric-key примером frozen frame; A39-003/005 поясняют ключи, hex-ID, величину и обязательные поля | Исправлено в каноническом примере и книге; схемы/decoder проверяют комплектность. Это не миграция всех внешних потребителей старого примера |
| R2-09: lease против indefinite HOLD | A02-017 разделяет бессрочный E0 ManualOverride и возможный deadline E1; E0 HOLD/explicit release/BOOT_INHIBIT сохранены | Исправлено в активном тексте. Модельные тесты подтверждают выбранную политику; это не стендовая гарантия |
| R2-10: два порядка replay | R36-002 разделяет audit replay по доступности/commit и сохранённому decision_snapshot от event-time ретроспективного пересчёта | Неоднозначность текста исправлена. Новый полноценный runtime replay не реализован; гипотетический контрпример не объявлен доказанной прежней поломкой |

Результаты reference-тестов и границы описаны в `site/contracts/README.md`, `test-results.log`, `mutation-results.json`, `schema-validation.json`. Полная независимая матрица программных замечаний SWR3 ведётся в `software-audit-plan.md`; её подробные статусы не заменяются этой таблицей.

## Семь ослабленных формулировок внешнего ревью

| Предмет | Восстановленный адрес | Что уточнено |
|---|---|---|
| SFX: объём штекеров | A05-011, глава 5 | Монтажная оболочка включает штекеры, выход и изгиб родных кабелей; размеры корпуса БП недостаточны |
| Доверенное время | R24-004, глава 24 | Долговечная нижняя граница с происхождением/качеством; откат часов/backup не уменьшает её молча. Граница не доказывает текущее UTC |
| SET/toggle, exactly-once | A20-016, глава 21 | Повтор toggle инвертирует выход; SET не отменяет неопределённость после физического эффекта. Exactly-once физического мира не обещается |
| Фрагменты образа | A20-022, глава 21 | Ограниченные offset/length chunks одного подписанного образа, лимит до allocation, отдельная приёмка E1 |
| Температурные точки | A07-024, глава 7 | Вход, зона платы, после CPU-кулера; положение и крепление фиксируются для повторного сравнения |
| Теплоёмкость зоны | A24-011, глава 33 | Эффективное C охватывает выбранную зону; открытое окно меняет условия и требует проверки применимости |
| Независимость защиты | I15-018, глава 38 | Малый отдельно тестируемый модуль не ждёт GPU/AI-worker. Сохранена оговорка: независимость Core логическая, общие panic/OOM остаются |

Предел F1, метод и числовой порог PE не назначались без выбранных деталей и соответствующего нормативного основания. Геометрическая модель и иллюстрации не принимаются как свидетельство электрической безопасности или выпуска CAD.

## Редактура и веб-приёмка

Проведён адресный проход по вводным, риторическим цитатам и заголовкам, затем дополнительные 29 явных правок прямого изложения. Технические отрицания — запрет повторного действия, unknown, границы измерений и безопасности — сохраняются. Таблицы не превращались в прозу там, где они нужны для параметров, соответствий и проверок. Все изменения имеют before/after в `site/content/editorial-changes.json`.

Нельзя утверждать, что каждый абзац всей книги прошёл полную независимую литературную или инженерную экспертизу. Проверка `content_web_audit.py` доказывает соответствие фактического HTML каноническим текстам, каждой ячейке таблиц, подписи и TeX каждого математического вхождения; она не оценивает визуальную композицию и чтение экранным диктором.


# Фактическое состояние 32 решений SWR3

Это не список 32 закрытых продуктовых дефектов: статусы различают изменение текста/модели, отклонённую гипотезу и открытый gate. Точные пути свидетельств находятся в software-resolution.json.

| ID | Статус | Сделано / принято | Осталось |
|---|---|---|---|
| SWR3-01 | implemented_document_or_model | Единый enum, registry и генератор; числовой mapping проверен. | Rust/Kotlin/MCU interoperability не проверен. |
| SWR3-02 | implemented_document_or_model | Устранены два набора лимитов и старые названия в активной норме. | Полная машина сеанса вне stateless codec. |
| SWR3-03 | implemented_document_or_model | Новый bounded codec: типы, поля, пределы; четыре Hello и mode_id отклонены. | TLS identity, authorization, concurrency, physical I/O не реализованы. |
| SWR3-04 | implemented_document_or_model | Две ранее выжившие мутации обнаружены новыми regression tests. | Это покрытие двух guards, не доказательство полноты. |
| SWR3-05 | partially_documented_open_gate | Текст и модель задают current auth/boot/fence перед cache, cache перед mutable conditions. | Actual TLS binding и serialized firmware требуют реализации. |
| SWR3-06 | open_qualification | Ограничение ID после eviction признано; это не обход replay исходных байт. | Durable Core intent map, retention и запрет нового seq для старого intent ещё нужны. |
| SWR3-07 | rejected_as_stated | Категоричная невозможность N/N−1 отклонена; версия продукта не равна wire. | Матрица версий и реальные rolling upgrade tests остаются gate. |
| SWR3-08 | partially_documented_open_gate | Owner/session authority разделены, PENDING для неотозванного MCU явно описан. | OwnerSetUpdate, durable revoke и convergence не реализованы. |
| SWR3-09 | partially_documented_open_gate | Независимый recovery и последний ключ отмечены как отдельный договор. | Нужен реальный recovery без исходного телефона. |
| SWR3-10 | partially_documented_open_gate | Recipient-bound user invite отделён от node claim. | API и durable redemption, cancel/retry negative tests не реализованы. |
| SWR3-11 | partially_documented_open_gate | Текст явно требует identity/role/installation binding перед ACTIVE. | Actual TLS peer registry и тест подмены Sensor→Actuator отсутствуют. |
| SWR3-12 | open_qualification | Универсальный crypto profile не объявлен квалифицированным. | Алгоритмы TLS/owner COSE/firmware и verifier tests остаются gate. |
| SWR3-13 | partially_documented_open_gate | Открытый transport TrustTransfer назван прямо. | Signed target binding, атомарный commit и TLS/COSE traces не реализованы. |
| SWR3-14 | rejected_as_stated | SET EXPLICIT_USER создаёт HOLD; освобождает только RELEASE, модель это проверяет. | Principal→cause runtime mapping и late-speech pipeline не проверены. |
| SWR3-15 | rejected_as_stated | Универсальный resumption bypass отклонён; auth generation или отключение явно требуются. | Тест после revoke с ticket и без него ещё нужен. |
| SWR3-16 | partially_documented_open_gate | Создан OpenAPI3.1 draft: snapshot/cursor/SSE/410, scoped idempotency, revisions, intent/effect status; refs и negative JSON examples PASS. | Backend, auth lifecycle, durable idempotency, stream replay и KMP runtime не реализованы; voice-upload отдельный gate. |
| SWR3-17 | partially_documented_open_gate | UNKNOWN заменён Error без фиктивной истории; unsolicited Snapshot reply_to=0. | Credits/gap/reconnect/health и binding нового boot остаются gate. |
| SWR3-18 | partially_documented_open_gate | Diagnostic JSON содержит numeric keys и delivery_kind. | Event provenance и humidity descriptor не добавлены в wire0.2; они открыты. |
| SWR3-19 | implemented_document_or_model | AUTO/HOLD/BOOT_INHIBIT, явный release и delayed command проходят browser/Python model tests. | PIR не даёт leave/reentry; E1 и MCU/HIL не квалифицированы. |
| SWR3-20 | open_qualification | Sleepy/wearable scope отделён от собственного E0 без сна. | Power/transport/admission и gateway trust требуют отдельного профиля. |
| SWR3-21 | open_qualification | Недоказанный handshake/Nagle дефект не превращён в новый протокол. | Fairness/backoff/RAM/latency измерения на выбранном SDK нужны. |
| SWR3-22 | partially_documented_open_gate | Перед socket write текст требует durable DeliveryAttempt и UNKNOWN на неопределённом исходе. | БД и power-cut/crash injection не выполнены. |
| SWR3-23 | open_qualification | Backup/migration/trust atomicity признаны необходимыми договорами. | Реализация, restore тесты и rollback protection отсутствуют. |
| SWR3-24 | rejected_as_stated | PRNG-before-radio дефект не доказан: исходник уже требует hardware entropy conditions. | Init order и RNG выбранной firmware ещё проверяются. |
| SWR3-25 | implemented_document_or_model | BOOTTIME slew включён в бюджет; RAW не предложен как слепая замена. | Реальная chrony/OS конфигурация, suspend и clock traces не проверены. |
| SWR3-26 | open_qualification | OS appliance предложения остаются ADR/gates. | Boot chain, recovery, watchdog, /data и diagnostics не реализованы. |
| SWR3-27 | rejected_as_stated | Обязательное удаление bulk TLS отклонено. | Lazy bulk/RAM/latency выбор должен опираться на измерения. |
| SWR3-28 | rejected_as_stated | Зависимость OTA valid только от Core не принята; reset ведёт в BOOT_INHIBIT. | Локальный self-test и bounded network trial ещё квалифицируются. |
| SWR3-29 | rejected_as_stated | Две ревизии сохранены: уровень и ручное намерение имеют разный смысл. | Без нового выигрыша state_rev рефакторинг не требуется. |
| SWR3-30 | implemented_document_or_model | Frozen vectors, negatives и killed mutations; README ограничивает модельное evidence. | Нет Rust/Kotlin compile, TLS, MCU, GPIO, durable-store evidence. |
| SWR3-31 | partially_documented_open_gate | Stable lineage связывает старое содержание с активной новой редакцией. | Не утверждается независимый полный нормативный аудит всех архивных legacy cards. |
| SWR3-32 | partially_documented_open_gate | Есть stable source IDs, lineage, decision matrix и модельные test artefacts. | Полный requirements→tests→risk→evidence ledger ещё не завершён. |


# Koobique: редакционная модель и приёмка полного веб-издания

Статус: модель приёмки и журнал начатой реализации. По уточнению пользователя отдельного R3 нет: новая редакция создаётся из полного R2. Исходный R2 неизменен; канонический веб-контент формируется в `site/content/`. Предоставленное внешнее ревью используется для проверки гипотез. Его спорные аппаратные/протокольные рекомендации не принимаются автоматически.

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

## 1. Эталон содержания

R2 уже содержит структурированные данные, пригодные для импорта. Основной файл — `work/r2/Koobique_R2/Koobique_Book_Source/source/unified.json`; экспорт Markdown не является единственным полным источником. Дополнительные реестры: `math.json`, `figure_index.json`, `sources_unified.json`; сборщик содержит обложку, служебные страницы, колофон и способы раскрытия математических токенов.

Независимым чтением R2 получены следующие контрольные числа. Это baseline R2, а не ожидаемые неизменные числа R3:

| Сущность | Проверено в R2 | Правило переноса |
|---|---:|---|
| Главы | 51 | Сохранить идентичность, номер, название и принадлежность группе; изменение названия отразить в alias |
| Смысловые units | 1758 | Каждый имеет запись о судьбе в migration map |
| Абзацы | 1055 | Переписывание допускается с сохранением утверждений, условий, чисел, исключений и источников |
| Подзаголовки h2 / h3 | 449 / 34 | Можно объединять при сохранении адресуемости подразделов |
| Lead / quote / code | 67 / 17 / 5 | Lead и quote не считать автоматически рекламной водой; код переносить без смысловой редакторской замены |
| Вводные intro / вопрос question | 51 / 51 | Это отдельные поля глав, не входят в units; обязательны в импорте |
| Термины terms | 7 значений | Отдельное поле; сохранить связи с главой и определениями |
| Таблицы / ячейки | 63 / 1244 | Точно сохранить заголовки, все значения, единицы, сноски и связь строки с колонкой |
| Инженерные фигуры | 68 | Сохранить содержание/подпись/происхождение; замена визуального исполнения требует карты соответствия |
| Реестр figure_index | 77 записей | Не путать число записей с количеством инженерных схем; включает математические изображения |
| Реестр math | 54 записи | В сериализованном chapter-контенте найдено 53 вхождения токенов; отдельно установить используемые и неиспользуемые записи, не удалять «лишнее» по одному счетчику |
| Источники | 178 | Сохранить ID, URL, название, аннотацию, прежние ID и все места использования |

Внешнее ревью сообщает о сохранности R1→R2 и нескольких ослабленных местах. Эти выводы полезны как список контрольных мест, но не заменяют новую сверку R2→R3→web. Отдельно проверить место для кабельных штекеров SFX, доверенное время, exactly-once/toggle, фрагментацию образов, точки замера температуры, область тепловой модели и независимость защитного механизма. Не восстанавливать ошибочную формулировку, которую R3 обоснованно исправил.

### Полный inventory

Импорт формирует `content-inventory.json`. Для каждой записи нужны `id`, `kind`, `chapter_id`, `source_file`, `source_pointer`, `source_hash`, `text_or_payload`, `reference_ids`, `related_asset_ids`, `source_status`, `target_anchor`, `editorial_disposition`. Для таблицы инвентаризируется каждый ряд/ячейка; для схемы — подпись, значимые надписи, направления связей, легенда и ограничения. Номер страницы хранится как вспомогательная ссылка на PDF, а не как устойчивый идентификатор.

В inventory входят и элементы вне основного потока: заголовок/подзаголовок издания, «как читать», маршруты, intro/question/terms, словари, библиография, подписи, формулы inline/display, исходные примеры, легенды, предупреждения, ограничения применения, карточки испытаний и ссылки на комплект файлов. Build-only CSS и декоративные артефакты не становятся содержимым книги, но различие фиксируется явно.

Каждый целевой блок хранит `source_ids[]`; каждый исходный смысловой блок получает одну из разрешённых судеб: `preserved`, `rewritten_equivalent`, `merged`, `moved`, `superseded_by_correction`, `archived_historical`. У merged/moved есть целевой адрес; у superseded — замещающее требование и основание; у исторического материала — доступный архив и видимая маркировка. Статус `dropped` запрещён без отдельного обоснования. Сохранение неправильной инструкции в активной главе ради процента дословного совпадения не считается сохранностью содержания.

Для переписанных абзацев нужен смысловой ledger: что утверждается, при каких условиях, какие границы/исключения, величины и единицы, отрицания, степень уверенности, версия профиля и ссылка на источник. Новое написание может менять порядок и соединять предложения, но не превращать «требует испытания» в «работает». Правки технического решения и литературные правки учитываются отдельно.

## 2. Редактура без потери инженерного смысла

Основной текст строится как последовательное объяснение: наблюдаемая ситуация, механизм, следствие, практическое действие и способ проверки. Заголовок отвечает содержанию, а абзац развивает одну мысль. Список коротких тезисов не превращается автоматически в пять карточек с теми же тезисами. Если связь причинная, её следует изложить связным текстом; если требуется сравнить характеристики, сохранить таблицу; для процедуры оставить честную последовательность действий.

Нельзя глобально удалять «не», «нельзя», противопоставления или оговорки. В книге они часто выражают запрет включать нагрузку, ограниченность измерения и отсутствие полномочий. Убирается шаблонная форма, а не логика защиты. Например, «Это не магия, а инженерия» можно убрать; «UNKNOWN не разрешает автоматический OFF» должно сохраниться как точный контракт.

| Проблема исходника | Редакторское решение | Проверка сохранности |
|---|---|---|
| «Важно отметить», «стоит помнить», повторный итог без новых сведений | Начать с конкретного факта или действия; удалить пустой переход | Ни одна предпосылка и рекомендация не исчезли вместе с оборотом |
| Цепочка буллетов вместо объяснения | Соединить причинно связанные пункты в абзац; выбрать подходящую таблицу/процедуру для независимых данных | Все исходные тезисы сопоставлены новым предложениям |
| Повторная формула «не X, а Y» | Сформулировать положительный механизм; оставить запрет, если он нормативный | Сохранилась область допустимого поведения |
| Новые R2-хвосты противоречат ранним абзацам | Переписать главу как одно объяснение с одним действующим договором | На активный контракт одна формулировка; старый вариант помечен историческим |
| «Готово», «безопасно», «проверено» без уровня доказательства | Указать, что именно проверено и на какой реализации/модели | Документ, Python-модель, runtime и физическое испытание не смешаны |
| Несколько названий одного понятия | Один русский термин и точный идентификатор; синонимы в словаре/поиске | API/протокольные имена не переведены и не переименованы самовольно |
| Повторная общая аннотация у десятков источников | Общая методологическая заметка один раз; у источника конкретное назначение | Статус проверки/версия конкретного документа остались доступны |
| Англоязычная россыпь в прозе | Понятное русское объяснение при первом упоминании, технический ID рядом | Код и состояния остаются точными и копируемыми |

Единицы и числовые данные проходят отдельную проверку. Типографская замена `lux` на `лк` допустима в русской прозе при сохранении протокольного `unit_code` и исходного кода. Десятичная запятая в пояснении не переносится в JSON. Диапазоны, знаки минуса, степени, индексы, знаки сравнения и неопределённость сохраняются. Математический TeX — канонический источник; пользователю доступны читаемая формула, её текстовое объяснение и копирование TeX. Изображение формулы не должно быть единственным представлением.

Главы редактируются целиком, а не дописываются блоком «исправления» внизу. Журнал изменений и спорные решения выводятся в отдельную редакционную страницу. В основном чтении остаётся связный актуальный текст. Формальные определения и коды берутся из одного реестра; обнаруженное противоречие не разрешается стилевой догадкой.

### Схемы и 3D

У схемы есть объясняющая задача: показать размещение, связь, последовательность, зависимость, границу доверия или изменение состояния. Несвязанные текстовые карточки с буллетами не считаются диаграммой. В узлах остаются короткие имена; связи имеют направление/тип; развернутое объяснение находится в подписи и соседнем тексте. Если для понимания требуется предостережение, оно не прячется за hover.

Для каждой заменяемой схемы составляется `diagram-equivalence`: исходные сущности, связи, условия, подписи и их места в новой статической/интерактивной версии. Пространственная сцена может раскрывать куб по слоям, показывать поток воздуха или путь сигнала, но не должна изображать непроверенные размеры как готовый CAD. Иллюстративная модель и производственная геометрия маркируются по-разному.

Видео-референсы оцениваются только после фактического просмотра: выписать конкретные композиционные и временные признаки с таймкодами. В этом подзадании видео не предоставлены и не просмотрены; утверждать совпадение с их уровнем нельзя. Для приёмки нужны выбранные reference moments и сопоставимые записи реализации, а не слова «кинематографично» или «премиально».

## 3. Навигация и чтение 51 главы

Каждая глава имеет постоянный URL и server-rendered либо статический HTML. Прямое открытие главы, перезагрузка, браузерные Back/Forward и ссылка на конкретную формулу/схему работают без предварительного захода на обложку. Положение в книге и текущая глава понятны как на широком экране, так и на телефоне. Главная сцена даёт вход в чтение; она не является обязательной заставкой перед содержимым.

Оглавление показывает все 51 главу по группам; локальная навигация отражает разделы текущей главы. Читатель может перейти к следующей/предыдущей главе, открыть полный список, вернуться к месту после источника. Якоря строятся из стабильных ID, а не только русского заголовка. После редакторского переименования прежние ссылки сохраняются через alias/redirect.

Маршруты «собрать E0», «разработать Core/MCU», «исследовать измерения и модели» помогают выбирать порядок, но не заменяют полный текст выборкой популярных блоков. Каждый маршрут указывает предпосылки и выводит читателя к соответствующим полным главам. Не объявлять маршрут «60 страниц» без реально подсчитанного объёма.

Поиск охватывает основной текст, intro/question, термины, подписи, табличные данные, рабочие карты и источники. Русский поиск учитывает `е/ё`, регистр и распространённые названия, сохраняя точный поиск `MANUAL_HOLD`, `execution_seq`, `KQIP 0.2`. Результат показывает главу, заголовок и контекст, ведёт к конкретному блоку. Нет скрытой зависимости от внешнего AI или передачи текста запроса третьей стороне. При отказе JS остаются оглавление и читаемые страницы; продвинутый поиск может перейти в простой режим или сообщить об ограничении.

Ссылка [n] ведёт на единственную запись библиографии, а источник содержит обратные ссылки на места цитирования. Ссылка на схему открывает её в контексте главы, а увеличение сохраняет доступ к подписи и закрывается с возвратом фокуса. Определения терминов доступны и по нажатию/клавиатуре, а не только наведением.

## 4. QA и критерии выпуска

### Полнота и корректность

Перед визуальной приёмкой сборка должна доказать покрытие inventory: 51/51 главы; все intro/question/terms; все смысловые блоки с разрешённой судьбой; все таблицы с ячейками; все использованные формулы; все схемы/подписи; все цитаты и источники. Проверка текста DOM/HTML дополняет JSON: наличие записи в данных не означает её отображение. Текст, скрытый за отсутствующим компонентом, не считается доставленным.

Тест ссылок проверяет все внутренние маршруты, якоря, источники, фигуры, карточки и assets; отсутствующие цели блокируют выпуск. Дубликаты DOM-ID запрещены. Внешние URL проверяются с учётом redirect и возможной защиты от роботов; недоступность автоматическому запросу не приравнивается к доказанному отсутствию документа.

Линтер редакторских оборотов создаёт очередь для ручного просмотра, но не исправляет текст автоматически. Отдельный factual diff извлекает числа, единицы, состояния, условия, требования и отрицания. Редактор подтверждает каждый значимый diff. Внешнее ревью — список гипотез: не переносить в текст уверенные обещания аппаратной производительности, конкретные правовые требования или смену инженерной политики без проверки. Предыдущий ложноположительный finding о позднем голосе не возвращать: R2 md1468–1470 уже содержит исходный snapshot/deadline и нужную историю.

### Матрица устройств и доступности

| Условие | Обязательная проверка | PASS |
|---|---|---|
| Узкая ширина 320 CSS px; основные 360/390/430 | Проза, заголовки, меню, поиск, подписи | Нет горизонтального скролла всей страницы; сложная таблица/диаграмма имеет локальный просмотр |
| 768/1024/1440/1920 px | Чтение, навигация, композиция сцен | Текст не превращается в чрезмерно длинную строку, подписи не отрываются от объекта |
| Масштаб текста 200%; reflow при 400% | Заголовки, панели, диалоги и ссылки | Контент и управление доступны, sticky-элементы не закрывают чтение |
| Клавиатура без мыши | Меню, поиск, диалог, источники, 3D-управление | Видимый фокус, логичный порядок, Esc закрывает диалог, нет ловушки |
| VoiceOver/Safari и TalkBack/Chrome на реальных устройствах | Глава, таблица, формула, схема, результат поиска | Семантические landmarks/heading/table; осмысленные имена; нет многократного чтения декоративного текста |
| Контраст и цвет | Текст, подписи, состояние фокуса | WCAG 2.2 AA: обычный текст ≥4.5:1, крупный ≥3:1; существенные нетекстовые элементы ≥3:1; смысл не только цветом |
| Touch | Меню, закрытие, шаги сцены | Проектная цель минимум44×44 CSS px для основных controls; подписи и плотный текст не искажаются ради цели |
| Печать / export | Глава, таблицы, ссылки, рисунки | Нет обрезанного текста; сцены заменены статическими кадрами; источники читаемы |

Автотест a11y дополняется ручными проверками. Его зелёный результат не означает сертифицированное соответствие WCAG. Базовое требование reflow сверяется с [W3C 1.4.10](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html); таблицам и двумерным схемам допускается соответствующее отдельное представление, но это не оправдывает переполнение обычной прозы.

### Motion и WebGL

Анимация объясняет состояние или переход. Читатель управляет воспроизведением; глобальная настройка уменьшения движения видна и сохраняется локально. `prefers-reduced-motion: reduce` действует с первого кадра и при изменении настройки ОС. Камерные пролёты, параллакс и непрерывное вращение в этом режиме заменяются статическим кадром либо пошаговым переключением без пространственного движения. Существенные сведения не зависят от того, успел ли пользователь заметить короткую фазу анимации.

Для движения, которое начинается само, длится более пяти секунд и сопровождает другое содержимое, необходим доступный pause/stop/hide; настройка ОС не единственный способ управления. Это следует из [W3C 2.2.2](https://www.w3.org/WAI/WCAG20/Understanding/pause-stop-hide.html). Уменьшение несущественного движения от взаимодействий принимается как дополнительная цель проекта; соответствующий [критерий2.3.3](https://github.com/waic/w3c-wcag/blob/master/wcag22/understanding/animation-from-interactions.html) относится к AAA, а не автоматически к AA.

| Сбой/режим | Что испытывать | Ожидаемый результат |
|---|---|---|
| WebGL недоступен | Запрет создания context | Статический poster + полная текстовая/векторная схема; обычное чтение работает |
| Потеря context после загрузки | `WEBGL_lose_context` в тестовой среде | Нет пустого ключевого блока, бесконечного спиннера и ошибки навигации; fallback либо контролируемое восстановление |
| Ошибка GLTF/текстуры/шейдера | 404, повреждённый ресурс, decode failure | Видимое стабильное изображение и смысл; повтор загрузки не циклический |
| Медленный CPU/GPU | Ограниченный pixel ratio и adaptive quality | Интерфейс/чтение приоритетны; декоративная сложность уменьшается |
| Сцена вне viewport / вкладка скрыта | Scroll away, background, return | RAF и лишние ресурсы приостановлены; возврат без скачка текста |
| Reduced motion | ОС reduce и локальный toggle | Нет обязательного autoplay/камерного scroll scrub; доступны ручные шаги |
| Canvas с клавиатурой/скринридером | Доступные кнопки шагов/ракурса и обычный текст | Canvas не единственный носитель информации; жест вращения не обязателен |
| Network offline после загрузки главы | Нагрузка и переключение режима | Уже прочитанный текст не исчезает; отсутствие будущих ресурсов объяснимо |

Испытание потери context опирается на [MDN WEBGL_lose_context](https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_lose_context/loseContext); жизненный цикл ресурсов — на [MDN WebGL best practices](https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices). Одновременно активна только необходимая сцена; материал книги не грузится как 51 постоянно работающий canvas.

Проектные performance budgets задаются после выбора реальных референсов/стека и замера baseline. Стартовая цель: читаемый текст не ждёт 3D; большие модели загружаются по необходимости; на средней мобильной платформе управление отвечает без видимого зависания. Для релиза измерить LCP/INP/CLS, JS/asset transfer и максимальный long task при загрузке/переходах; отчёт содержит устройство, браузер, сеть и холодный/тёплый cache. Нельзя выдавать один desktop Lighthouse за проверку мобильной сцены.

## 5. Порядок выполнения и доказательства

Сначала R2 фиксируется как неизменный вход. Затем создаётся новая редакция R3 и строятся inventory и lineage R2→R3, включая исправления и архив. После этого импортируется полный текст веб-издания, и тест полноты должен пройти ещё до сложных сцен. Полная доставка текста не откладывается до окончания дизайна обложки.

Редактура идёт главами с параллельной проверкой factual diff. Схемы меняются по карте эквивалентности. Три репрезентативных главы — аппаратная с геометрией, протокольная с кодом/таблицами и исследовательская с формулами — проходят визуальную и мобильную проверку раньше масштабирования шаблона на все 51 главу. Затем оформляются все главы, поиск, ссылки, словари и источники. Последний проход объединяет content QA, техническую проверку, device QA и запись сцен для сопоставления с видеорефами.

В deliverable входят сайт, машинный inventory, semantic migration map, изменённые блоки с основаниями, отчёт ссылок/формул/чисел, результаты браузерных и device проверок, кадры/записи контрольных состояний, список известных ограничений. Готовность формулируется точно: локальная сборка, открытие браузером, реальный телефон, опубликованный URL и принятие визуального результата — разные подтверждения.

Выпуск блокируют потеря содержимого, конфликт актуальных инженерных правил, неработающие внутренние ссылки, нечитаемая мобильная глава, недоступное управление либо потеря смысла при отключённом WebGL/motion. Оставшийся косметический полировочный пункт записывается отдельно и не маскируется под технический дефект. Обратное также верно: красивый motion не закрывает содержательную потерю.

## 6. Реализованный слой контента

Канонические файлы находятся в `work/r3/site/content/`: chapters.json, math.json, figures.json, sources.json, editorial.json и pages.json. Карта происхождения — lineage.json и inventory.json; before/after правок — editorial-changes.json. Сборка воспроизводится scripts/content_build.py, структурная проверка — scripts/content_validate.py. Ручные редакторские решения хранятся в editorial-overrides.json; входной R2 не изменяется.

Проверка подтверждает наличие всех 1758 исходных units, 51 intro (102 вводных абзаца) и 51 question, семи значений terms, 63 таблиц/1259 ячеек, 68 фигур, 53 вхождений математических токенов при54 записях реестра и178 источников. Исходно было1244 ячейки; три добавлены при исправлении реестра ошибок и двенадцать — в ведомость питания и жгута. Она также подтверждает сохранность исходных библиографических ссылок в изменённых блоках и неизменность TeX. Текущий точный счётчик добавлений и правок публикуется в content/validation.json. Это проверка структуры и ссылок, а не доказательство семантической эквивалентности каждого предложения.

16 технических патчей программной архитектуры применены через отдельный журнал: числовые wire-примеры, лимиты, коды ошибок, область и порядок проверки команды, права владельца и пользователя, DeliveryAttempt, OTA/BOOT_INHIBIT и границы совместимости. Изменение формы таблицы допускается проверкой лишь при наличии точного before/after технической миграции. Все прочие исходные таблицы сохраняют количество и расположение ячеек. Исправленный текст представляет проектный профиль и открытые приёмочные требования, а не заявление о готовой прошивке.

Добавлены сквозные страницы маршрутов, физического цикла, этапов, словаря и уровней доказательства. Предметные дополнения уточняют причинность и физическое свидетельство, влияние неопределённости на решение, различие точки сенсора и рабочей плоскости, контрфактическое оценивание и независимый допуск модели. Семантика E0 с PIR-only, бессрочным HOLD, явным освобождением и BOOT_INHIBIT сохранена.

## 7. Фактическая веб-приёмка и незавершённые проверки

Независимый scripts/content_web_audit.py разбирает собранные HTML через lxml. Он проверяет каждую исходную и добавленную единицу в странице главы и повторно в /read/, сравнивает нормализованный текст, все ячейки таблиц, подписи и TeX в MathML annotation. Финальная сборка от 2026-10-16T04:06:07.534Z получила PASS: 1781 единица, 51 intro / 102 вводных абзаца, 51 question, 7 terms и 53 математических вхождения в каждом из двух режимов; 178 записей источников и 4353 href без потерянных локальных страниц или fragments. Проверены также абзацы всех пяти сквозных страниц и содержимое библиографических записей. Актуальный результат с хешем канонического контента хранится в content/web-validation.json. Счётчики release.json совпадают с исходником; скачиваемый chapters.json побайтно совпадает с каноническим.

Подпись A41 явно относит EMPTY/auto-OFF к отдельно квалифицированному E1 и сохраняет запрет auto-OFF от молчания PIR в E0. Подпись A32 требует долговечной отметки DeliveryAttempt до записи в сокет и не выдаёт неизвестный исход после сбоя за отсутствие физического действия. Это приёмка смыслов подписей; визуальная доступность текста внутри SVG проверяется отдельно.

Выполнена адресная содержательная редактура, включая дополнительный проход по 29 вводным и заголовкам. Убраны повторяющиеся риторические противопоставления и рекламные обобщения; необходимые технические отрицания сохранены. Полная ручная литературная проверка каждого абзаца всех 51 глав не заявляется. Количество правок и сохранённых unit ID не является такой проверкой.

В пределах этого редакционного прохода ещё не подтверждены на реальных устройствах VoiceOver/TalkBack, визуальное качество 320 CSS px/400% zoom, читаемость всех SVG, потеря WebGL context, производительность и соответствие видеореференсам. Таблицы критериев выше остаются программой приёмки, пока отдельный браузерный отчёт не приложит наблюдаемые результаты. Статический HTML PASS не закрывает эти пункты. Фактические статусы десяти замечаний R2 и семи восстановленных оговорок записаны в content-review-resolution.md.


# Koobique web edition: направление 3D и инженерная точность

Статус: новая веб-редакция R3 создаётся из R2 по уточнению пользователя; это не новый конструкторский выпуск. Просмотрены контактные листы feathers, atelier и cloudflare. Старые исходники не изменялись. Desktop-приложения не устанавливались; Three.js 0.186.1 установлен в проект главным агентом. Для независимых скриншотов сцена собирается в локальный IIFE и запускается в Chromium без публикации и без сервера.

## Что фактически доступно

На машине найдены `node` и `ffmpeg` в `/opt/homebrew/bin`, а в bundled runtime — `Playwright` и `sharp`. `blender` и `freecad` не найдены в PATH и проверенных `/Applications`/`~/Applications` locations. Это проверка обычных путей, а не утверждение об отсутствии бинарника на всём диске.

До локальной установки `three`, `@react-three/fiber`, `@react-three/drei`, `gsap`, `@gltf-transform/core` не разрешались из workspace и bundled node_modules. Для реализации установлен Three.js 0.186.1; дополнительные 3D-фреймворки не требуются. Среди доступных skills и callable tools специализированного CAD/Blender-инструмента не найдено. Наличие Figma/генерации изображений не заменяет редактируемую геометрическую модель.

Для реализации достаточно зафиксированной локальной зависимости Three.js и обычного JavaScript; для этой задачи React Three Fiber и GSAP не обязательны. Процедурная геометрия позволяет изменять сборочную последовательность и интерактивно объяснять инженерные связи. Если позднее появятся CAD/Blender assets, импорт glTF можно добавить вместо процедурного builder по тому же интерфейсу. [Официальная документация Three.js](https://threejs.org/docs/) содержит геометрию, материалы, анимацию и загрузчики; версии API надо зафиксировать вместе с приложением, а не полагаться на latest CDN.

## Художественный принцип

3D должно объяснять, **как соотносятся физическая вещь, наблюдение и действие**, и одновременно выглядеть как предметная съёмка хорошего промышленного изделия. Качество приходит от правдоподобного масштаба, фасок, стыков, света, мягких теней и осмысленного движения. Декоративный неон, произвольные светящиеся дорожки и бесконечные орбиты не объясняют проект.

После просмотра референсов: светлая mineral-плоскость #f0f2ef; серебристая рама; глубокий navy корпуса; кобальт как локальный акцент. Из feather берём крупный объект, музейную композицию и контактную тень; из cloudflare — металлическую деталировку и связь с крупной типографикой; из atelier — ощущение материальности, но не физически ложную деформацию металлического куба. Металл отличается от пластика отражением и шероховатостью, а не только цветом. Тонкие фаски ловят свет. На PCB видны разделение компонентов, разъёмы и пустая RF-зона, но не выдуманные точные номера деталей.

Материалы рендера — художественная интерпретация. Отображение анодированного алюминия, ASA или прозрачного стекла не присваивает реальной детали PE-связность, огнестойкость, RF/оптическую прозрачность или допустимость контакта с кожей. Реальный материал хранится в метаданных только там, где он выбран источником.

## Два слоя модели

1. **Предметный вид.** Чистая законченная композиция, закрытый/раскрытый объект, крупные детали, управляемая камера. Подпись «Концептуальная компоновка H2»/«Функциональная модель узла» размещается компактно рядом с названием, не перекрывает изображение.
2. **Инженерный разбор.** Кнопки «Слои», «Размеры», «Питание», «Что проверено». Появляются подписи, габаритные объёмы кабелей, цепи, нерешённые коллизии и ссылка на исходный раздел. Необходимо видеть, что модель иллюстрирует, что взято точно из документа и что является допущением.

Один и тот же объект может быть эстетичным и честным. Нельзя молча изменить размер/координату компонента для красивой посадки, а затем подписать полученный вид исходным чертежом.

## Четыре обязательные сцены

### Station — самостоятельный хаб, H2 как вариант

**Композиция:** вид в три четверти, один чёткий силуэт; сначала корпус собран, затем панели отъезжают вдоль собственных нормалей и открывают раму, поддон, плату, охлаждение и источник питания. В exploded-view связи остаются читаемыми: детали не разлетаются случайно и не вращаются независимо ради эффекта. Полностью раскрытая модель обязана иметь кнопку «Собрать».

**Смысловые шаги:** оболочка → несущая рама → вычислительный модуль → воздушный тракт → питание → обслуживание. Наведение/фокус на детали подсвечивает и её описание. Переход по главе может выбирать деталь; вращение в canvas не управляет прокруткой страницы.

**Точные исходные параметры R2:** наружная рама 320 мм, профиль 20×20 мм, внутренний номинальный размер 280 мм; четыре элемента 320 мм и восемь 280 мм для описанной схемы стыковки. Фасадный DRAFT 324×324 мм, принятая толщина 2 мм; локальные центры вентиляторов (162;92) и (162;232), отверстия Ø116, квадрат крепления 105 мм, проходные отверстия Ø4,5 мм. В геометрии книги центры на раме (160;90)/(160;230). Эти две системы координат не смешивать.

**Габаритные, а не утверждённые монтажные данные:** Mini-ITX 170×170 мм; SFX ориентировочно 125×100×63,5 мм; кулер около 125 мм. Реальные footprint, штекеры, крепёж и отступы не заданы. Кулер не помещается «от поверхности пола»: высота отсчитывается от соответствующей базы CPU. Ось сокета не равна автоматически центру платы. Перед модульными кабелями SFX нужен объём штекеров/радиусов кабеля, не только коробка БП.

**Открытые зоны:** нижний вентилятор пересекается с плоскостью поддона около Z=105; поддон, вход БП и I/O ещё не образуют проверенную сборку. В инженерном режиме это показывается выделенным полупрозрачным конфликтным объёмом и выбором «канал/перенос — требует решения». В hero допускается разнесённая, явно концептуальная компоновка, но не новый незаметно «исправленный» рабочий чертёж.

**Панели:** R2 выдаёт точный DRAFT только фасада. Нельзя дублировать 324×324×2 шесть раз и получить правдоподобный короб без проверки углов. Для preview допустимы схематические боковые панели с явно выделенным статусом provisional; схема нахлёста является новым проектным решением, если её нет в R3. В exploded-view отсутствие углового пересечения ничего не доказывает о собранном состоянии.

**Воздух:** струи отображают предположенное направление, а не CFD. Не присваивать им скорости, доли потока, CFM или температуру по цвету, если их нет в данных. Вентилятор вращается только при демонстрации режима; скорость анимации не является измеренным RPM. Для страницы охлаждения рядом может быть честный расчёт Q=P/(ρcpΔT) с заданными параметрами и отдельным пояснением ограничений.

### Sense / Presence — датчики и место измерения

Не сливать два разных узла в одно выдуманное изделие. У Sense световой канал и температура/влажность; у Presence PIR и исследуемый радар. Можно показать их в общей сцене как два автономных модуля с одинаковой визуальной грамматикой.

**Sense:** матовый концептуальный корпус, съёмная крышка, функциональные объёмы MCU и сенсоров. Термоканал расположен в отдельной доступной воздуху области, световой канал — за открытым/оптически квалифицированным окном. Оттягивание крышки показывает путь воздуха и направление измерения света. Положение датчика в комнате соединяется тонкой линией с соответствующей наблюдаемой величиной.

**Presence:** линза PIR визуально отличается от радарной области; металл не перекрывает радар. Не изображать гладкую универсальную прозрачную крышку как пригодную сразу для PIR, 24 ГГц и lux. Цветная прозрачность в рендере не доказывает прозрачность в нужном спектре.

**Граница точности:** у корпуса Sense/Presence нет проверенного размерного CAD. Не ставить точные размерные стрелки, не обещать совместимость клипс/винтов. В этих сценах геометрия функциональная. Если используется точная DevKit-модель, габарит и ревизия берутся из первичного чертежа либо R3, а не угадываются по SVG.

**Интерактивный смысл:** «открытый корпус / закрытый корпус», «рядом с электроникой / выносной канал», «PIR видит движение / неподвижность не доказывает пустоту». Последнее показывается сменой доступных свидетельств, не исчезновением силуэта человека при отсутствии PIR.

### Actuator — команда и физический контакт

**Композиция:** компактная плата, реальный смысл разъёмов, отдельные логическая и нагрузочная цепи, локальная кнопка, релейный модуль, источник 12 В и лампа. Геометрия корпусов концептуальная, электрические связи обязаны быть точными.

**Питание:** независимый 5 В источник MCU/модуля; GPIO10 — сигнал, не питание катушки. Логическая GND связывает MCU и драйвер. Цепь нагрузки: +12 В → F1 → COM → NO → лампа → минус 12 В. NC остаётся неиспользованным. Сухой контакт не требует объединять минус 12 В с GND MCU. Измеритель тока — опция с отдельно показанным изменением электрической топологии, если он добавлен.

**Анимация:** принятие команды → переключение управляющего сигнала → механическое движение контакта → появление тока/света. Стадии должны оставаться различимыми, даже если демонстрация ускорена. `APPLIED` не означает проверенный свет на рабочем столе; `VERIFIED` допускается только в отдельной ветке свидетельства. Движение частиц по проводам — условное обозначение замкнутого пути, не электроны в реальном времени.

**Демонстрации отказов:** пропадает Wi-Fi, кнопка действует локально; reset приводит к OFF и BOOT_INHIBIT по R2; сварившийся контакт не размыкается от кнопки. Сценарий нельзя «улучшить» визуальным магическим размыканием. Если R3 поменяет manual/reboot, сценарий переключается на R3-данные; нельзя оставить старую анимацию со свежим текстом.

### Room — от наблюдения до последствия

**Композиция:** небольшая открытая сверху комната с двумя стенами, окно, рабочий стол, лампа и абстрактный человеческий силуэт. Не нужны коллекции декоративной мебели; каждый объект участвует в объяснении. Station, Sense, Presence и Actuator должны быть физически отдельны и связаны беспроводной/электрической топологией без ложного питания по радиолинии.

**Смысловые шаги:** дневной свет → вход человека → измерение/оценка → допущенная команда → лампа → ручное OFF → потеря наблюдений. Отдельное место измерения lux и отдельная рабочая плоскость показывают проблему переноса показания. Влияние окна и лампы можно включать по одному.

**Два режима:** «Учебный сценарий» — детерминированная последовательность с фиксированными объяснениями; «Исследовать» — ползунки параметров и видимые ограничения модели. Реальные данные позднее подаются тем же API, но режим обязан иметь понятную метку. Нельзя выдать синтетическую красивую телеметрию за данные комнаты пользователя.

**UNKNOWN:** человек не исчезает из сцены при потере канала. Меняется статус знания системы; физический мир остаётся. Это центральное визуальное различие Koobique. PIR-only не должен анимировать автоматический OFF по уходу как штатную возможность E0.

## Реестр утверждений для каждого 3D объекта

Минимальные поля: `id`, `role`, `sourceIds`, `revision`, `geometryStatus`, `dimensions`, `materialStatus`, `coordinateFrame`, `assumptions`, `openIssues`, `explanationId`.

Допустимые статусы геометрии: `documented_nominal` (размер из документа), `component_envelope` (габаритный объём), `conceptual` (функциональное представление), `verified_assembly` (только при появлении доказательства). Сейчас последнего статуса для куба нет.

Размерные подписи генерируются из тех же параметров, что и геометрия. Все оси хранятся в миллиметрах исходника, Three.js получает единый перевод в метры/условную шкалу. Не делать свободный scale по отдельным осям ради композиции. В exploded-view трансформации отделяются от исходного assembly transform.

## Motion и взаимодействие

- Одна доминирующая сцена в viewport, остальные спят. Переходы между главами не запускают четыре бесконечных renderer loop.
- Главные состояния задаются данными: assembled, exploded, section, selectedPart, failureScenario, stepProgress. Пользователь может остановить движение и вернуться к исходному виду.
- Камера меняется плавно при переходе шага, но текст не прыгает. Перемещение детали следует реальному направлению извлечения, если оно известно. Если направление концептуально, нельзя подписывать его «проверено обслуживание».
- Перетаскивание вращает объект только после взаимодействия внутри canvas. На мобильном вертикальный swipe остаётся прокруткой страницы; pinch/zoom не блокирует доступ к тексту.
- Мелкая фоновая анимация применяется только там, где несёт смысл: вращение вентилятора в режиме охлаждения, свет лампы при ON. При `prefers-reduced-motion` — мгновенные состояния/короткое затухание без облётов и разлёта деталей.
- Кнопки и hotspots имеют обычные DOM-эквиваленты. Все объяснения, численные данные и исходные схемы доступны без WebGL, курсора и анимации.

## Программа качества визуального слоя

1. **Геометрия:** фасад совпадает с `dimensions.json` и DXF; mm-перевод один; 324/320 не смешаны. Отдельный тест проверяет возврат всех exploded-деталей в исходные трансформации.
2. **Состояния:** каждый сценарий воспроизводится детерминированно, manual/reboot/UNKNOWN согласованы с выбранной редакцией. Смена лампы в сцене не подменяет достоверность физического свидетельства.
3. **Изображение:** проверить полный, раскрытый и детальный виды на desktop и узком экране; отсутствие клиппинга, z-fighting, плавающих винтов, прозрачных чёрных артефактов и перекрытия подписей.
4. **Производительность:** стартовый рабочий бюджет — одна активная сцена, до 200 тыс. треугольников station, порядка 50 draw calls, ограниченный DPR; это целевые ограничения разработки, не измеренные результаты. Увеличивать качество только после профилирования целевых устройств. На слабом устройстве отключать тяжёлые тени/эффекты, сохраняя объяснение.
5. **Ресурсы:** геометрии/материалы/текстуры освобождаются при уничтожении сцены; управление останавливается вне viewport и во скрытой вкладке. WebGL context loss заменяет изображение fallback, а не пустым прямоугольником.
6. **Содержание:** исходные 2D-иллюстрации не исчезают вследствие добавления 3D. Сцена получает ссылки на заменяемые/дополняемые фигуры и текст. Семантическая сохранность измеряется отдельно от визуального качества.

## Что из второго ревью нельзя превратить в «факты рендера»

Второй предоставленный отчёт прочитан как источник замечаний, а не распоряжение поменять аппаратную архитектуру. Его реальные сильные вопросы — монтажная база I/O, пересечение поддона и притока, кабельный объём SFX, источник 5 В, отсутствие полного CAD, оптические/радиочастотные окна, разделение точки датчика и рабочего стола.

Цифры «31% решётки», «−42% обратный поток», «1600 об/мин», «+10 дБ», «125 Гц первая мода», «40 А бросок», «230–350 кВт·ч/год» зависят от модели и допущений; независимых исходных расчётов/измерений здесь пока нет. Не использовать их как доказанные значения в интерфейсе, теплокарте, струях или motion. Предложение заменить SFX на DC-ATX либо H2 на мини-ПК — альтернативное проектное решение, не исправление, которое следует автоматически внедрить в 3D.

Не принимать без отдельной квалификации категорические предписания о единственном материале, классе горючести, толщине RF-окна, номинале F1/NTC и безопасности поверхности. Прекрасная механическая сцена не является доказательством электрической, пожарной, температурной или радиочастотной безопасности.

## Порядок реализации

Сначала закрепить R2 и оба ревью как входы новой R3, с картой явно принятых изменений hardware-утверждений. Затем собрать один общий visual language и станционную сцену, проверить её статичный главный кадр; только после этого добавлять движение. Параллельно подготовить actuator topology и room state model как данные. Sense/Presence моделируются функционально до появления точной сборки. Последним этапом — связь сцен с навигацией, полнота исходного материала, reduced-motion и мобильная проверка. Самовольное обновление проекта Koobique при создании издания не входит в задачу.


## Реализованный модуль и проверка 16 октября 2026

`site/src/scene.js` содержит четыре параметрических builder и `mountScene(container, options)`. Это визуальные функциональные модели, не CAD и не PCB layout. Номинальные размеры Station направляют пропорции; декоративная фаска, крепёж, расположение разъёмов и компоненты не являются полным воспроизведением DXF. Стек: Three.js 0.186.1, RoundedBoxGeometry, RoomEnvironment, OrbitControls, объединение статической геометрии по материалам. Внешних текстур и CDN нет.

Station: 12 элементов каркаса, съёмные панели, проёмы/защита/лопасти вентиляторов, плата Mini-ITX, RAM, радиатор/теплотрубки, PSU, кабельные объёмы. Sense: полая оболочка, снимаемая крышка, функциональные платы радио/света/термоканала, опора. Actuator: логический модуль, релейный блок, COM–NO–NC, независимые источники 5 V и 12 V, F1, лампа и ручная кнопка. Room: открытая комната, окно, стол/рабочая плоскость, человек и отдельное место датчика. Состояние unknown не удаляет человека.

Публичный API:

```js
const scene = mountScene(element, {
  kind: 'station', // station | sense | actuator | room
  onSelect: ({id,title,body,status,source}) => {}, // null при снятии
  onReady: api => {},
  onError: ({reason,error}) => {},
  reducedMotion: undefined, // по умолчанию системная настройка
  quality: 'high', // low отключает shadow map и снижает cap DPR
});
scene.getParts(); // [{id,title}]
scene.selectPart('compute');
scene.rotate(0.15,0); // радианы azimuth / polar
scene.zoom(1.15); // приблизить; <1 отдаляет, расстояние ограничено
scene.setView('front'); // front | back | top | isometric
scene.setExplode(0.08); // 0..1, bool также допустим
scene.setMode('airflow');
scene.reset();
scene.dispose();
```

Поддерживаемый смысл режимов: Station `default / airflow / inspect / section`; Sense `default / inspect / section`; Actuator `default / on / off / section`; Room `default / on / off / unknown / inspect`. Алиасы `assembly → default`, `placement → inspect`, `effect → on` предусмотрены. Переключение режима не генерирует реальные данные. Flow — условные направления, не CFD; on/off — учебное состояние лампы, не подтверждение действия железа.

Рендер имеет прозрачный canvas, PBR-материалы, окружение, мягкую контактную тень, камерный отъезд при разборке. DPR ограничен 1.75, low 1.25. RAF прекращается после стабилизации и вне видимой области. `prefers-reduced-motion` отключает циклическое вращение/частицы и ставит explode без анимации. При потере WebGL сцена приостанавливается и выдаёт callback; при восстановлении снова отрисовывается. `touch-action: pan-y` сохраняет вертикальную прокрутку браузером. Физический touch-тест на устройстве не выполнялся.

Проверка: локальный headless Chromium через bundled Playwright, software ANGLE SwiftShader, без сервера/деплоя. Скрипт `scene-test/check.cjs`, полный результат `scene-test/results.json`. Все четыре сцены создавались, разбирались, выбирали часть, сбрасывались и освобождались; JS/console errors отсутствуют. В тесте скрытия счётчик кадров остался 21 → 21. Искусственный `WEBGL_lose_context` дал lost, затем ready и новые кадры. После dispose canvas отсутствует. Отдельный снимок viewport 390×844 показал целый Station без обрезки. Настоящая GPU-производительность и Safari/iOS этим тестом не подтверждаются.

Базовые draw calls (включая shadow pass): Station 114, Sense 48, Actuator 83, Room 54; low Station 63. Объединение геометрии сделано внутри смысловых частей, поэтому интерактивность и независимая разборка сохранены.

Пять постеров `site/public/assets/3d/*-poster.webp` и `station-exploded.webp` сняты с canvas этой реализации, 1100×790, без генеративной подмены. Они дают честный fallback и исходное изображение до загрузки WebGL. Оригиналы кадров лежат в `scene-test/*.png`. Внешний UI и интеграционные состояния тестируются отдельно главным агентом.

Финальный material pass: детерминированные CanvasTexture 256×256 для roughness/bump алюминия и powdercoat, три студийные карты в PMREM. Фактура художественная, без утверждения измеренной шероховатости. До/после и критерий выбора сохранены в `qa/material-comparison.png` и `qa/atlas-review.md`; финальные постеры обновлены.