Проверка проекта на прочность
Где решения проекта конфликтуют друг с другом?
Конструкция объединяет требования, которые ограничивают друг друга. Ниже разобраны шесть компромиссов и способы проверить выбранные решения на стенде.
Качество нельзя получить независимым максимумом характеристик. Более плотный фильтр лучше задерживает часть пыли, но меняет воздушный тракт. Более тяжёлая модель может повысить качество отдельной задачи, но занять память и задержать ответ. Удобное восстановление может ослабить границу доверия.
Ниже собраны такие конфликты и условия, при которых принятое решение следует пересмотреть. Это не история переписки и не протокол внешней комиссии, а карта аргументов для собственной инженерной проверки.
Здесь система рассматривается с позиций аппаратуры, системного ПО, безопасности, акустики, интерфейса и эксплуатации. Выводы описывают инженерную позицию проекта и открытые проверки. Агентное ревью помогает сопоставлять аргументы; лабораторные и аппаратные испытания требуют самостоятельных результатов.
Конфликт 1. Вычислитель и механика#
Выбор состоит в следующем: сразу купить мощную платформу с запасом или сначала ограничиться малой платой. Первый подход ускоряет эксперименты с голосом, второй уменьшает корпус и питание, но может рано упереться в speech-нагрузку.
Решение: H0 на имеющемся ПК, затем измерительный выбор автономной основы. Mini-ITX сохраняется как прозрачная конструкция куба, мини-ПК — как быстрый альтернативный экземпляр. Конкретная модель CPU не считается окончательной до RU/ EN-бенчмарка.
Инженерное следствие: размеры корпуса выделены в параметрическую компоновку; реальные сокет, I/O и кабели вынесены в обязательные проверки. Ведомость профиля привязана к явной схеме стыковки.
Незакрытый риск: собственный металлический корпус ещё не проверен физически. Условие перехода — полноразмерный макет, проверка доступа и тепловой стенд.
Конфликт 2. Воздух, пыль и голос#
Выбор состоит в следующем: три вентилятора дают простой запас охлаждения, но усложняют акустику. Reverse-blade соответствует визуальной идее, но не является технической необходимостью.
Решение: двухприточная/одновытяжная схема остаётся исходной, а количество и обороты подтверждаются измерением. CPU сохраняет отдельный кулер. Микрофон сначала выносной; reverse-blade — опция конкретной модели.
Инженерное следствие: нужны рабочая точка вентилятора, оценка сопротивления фильтра, отдельный тракт БП и проверка голоса при длительной нагрузке. Предположение «два на вход автоматически дают положительное давление» не принимается.
Условие перехода: температуры всех узлов, загрязнённый фильтр, отсутствие рециркуляции и сравнение качества команд.
Конфликт 3. Электроника и физические данные#
Выбор состоит в следующем: объединить все датчики в красивый куб или разделить измерительные точки. Объединение упрощает корпус, но делает температуру и присутствие плохо связанными с комнатой.
Решение: Sense и Presence отдельные. У температуры и lux допускаются разные точки даже внутри одной логической комнаты. Первый исполнитель низковольтный и имеет физическую кнопку.
Инженерное следствие: необходимы карта GPIO, расчёт I²C, различие микросхемы и готового модуля, проверка самовозбуждения света и несколько уровней подтверждения действия.
Условие перехода: повторяемые измерения, отсутствие стартового импульса реле и проверка присутствия при неподвижном человеке.
Конфликт 4. ПО, протокол и доверие#
Выбор состоит в следующем: полностью Rust-стек против зрелых компонентов с C/FFI; универсальный собственный транспорт против малого проверяемого профиля.
Решение: собственная предметная логика и протокол на Rust, но Linux, TLS, SQL и ML-runtime не переписываются ради языковой чистоты. Первый KQIP — TCP/TLS 1.3 и ограниченный CBOR. Сопряжение устройств опирается на готовый защищённый механизм, Linux-bootstrap выделен отдельно.
Инженерное следствие: ACCEPTED отделяется от APPLIED; используются outbox, controller_fence, ограничения парсера и проверка реальной TLS-конфигурации ESP-IDF. Восстановление времени не использует trustAll.
Условие перехода: interop Core/MCU/KMP, повторы, fuzz, отзыв и незавершённое сопряжение.
Конфликт 5. Интеграция в обычную жизнь#
Выбор состоит в следующем: максимально автономная собственная Wi-Fi-сеть против удобства пользователя и одного радиомодуля. Полностью бесшовный удалённый доступ против прозрачной первой реализации.
Решение: домашний Wi-Fi — основной путь, Ethernet дополнительный. Отдельная сеть устройств возможна позже без переключения телефона. E0 remote использует WireGuard; встроенный relay/VPN проходит отдельный мобильный gate.
Инженерное следствие: проверяются изоляция клиентов роутером, смена сети, разрешения iOS/Android и раздельные полномочия пользователя и SSH. Удалённая доступность не объявляется гарантированной при любых блокировках.
Условие перехода: второй человек подключает узел, восстанавливает сеть и понимает неопределённый результат команды.
Конфликт 6. Восстановление и повторная сборка#
Выбор состоит в следующем: быстрое обновление вручную против воспроизводимого состояния; простое копирование диска против риска двух контроллеров.
Решение: подпись и штатная процедура установки, A/B для appliance-профиля, совместимые миграции, восстановление с изоляцией старой станции и ротацией полномочий.
Инженерное следствие: backup включает состояние доверия; модель речи рассматривается как версия поведения; изготовление E2 проверяет полноту инструкции, а не только успех автора.
Условие перехода: прерванное обновление, старый архив, заполнение диска и второй экземпляр без скрытых ручных правок.
Принятые решения и условия проверки#
Зафиксированы архитектурные границы, основной сетевой путь, низковольтный первый исполнитель, схема собственного протокола, форма наблюдения и маршрут сборки. Открыты точная compute-конфигурация, окончательная CAD-компоновка, Linux BLE-onboarding E1, встроенный аудиомодуль и численные эксплуатационные показатели. Это конкретные инженерные задачи с проверками, а не скрытые обещания готовности.
Проверим ту же систему со стороны измерений, статистики и управления. Эти вопросы дополняют конструктивные компромиссы: даже исправное железо может принять неверное решение из хороших на вид данных.
1. Измерительная инженерия#
Возражение. Один аккуратный числовой поток скрывает размещение, задержку, насыщение и собственный нагрев. Дорогой датчик ошибочно воспринимается как точная картина комнаты.
Контракт содержит объект, интервал измерения, ревизию размещения, качество, калибровку и явные пробелы. Комнатные сенсоры отделены от корпуса станции. Влияние лампы определяется на конкретной плоскости. Проверка — эпизоды с переносом и внешними помехами.
2. Модели и статистика#
Возражение. Успешный прогноз ошибочно принимается за причинное понимание; соседние отсчёты создают утечку теста; confidence путается с безопасностью.
Разделены наблюдение, оценка, прогноз и действие. Введены эпизодные разбиения, журнал воздействия и проверка области применимости. Jev и JEPA разведены по роли. Перестановка вариантов, новые условия и цена ошибок вошли в тесты.
3. Управление и физическое исполнение#
Возражение. Мягкий штраф может позволить нежелательное действие; старый план перезапишет ручную кнопку; подтверждение прошивки выдаётся за достижение цели.
Раздельные ограничения, ручной режим с собственной ревизией, повторная проверка предусловий и несколько видов результата ограничивают исполнение. Бинарному реле нельзя приписывать возможности непрерывного регулятора. Состояние «исход неизвестен» остаётся частью API.
4. Rust, безопасность и ресурсы#
Возражение. Один асинхронный процесс может зависнуть на native-инференсе; файл модели меняет поведение без смены кода; Rust ошибочно воспринимается как полная защита всех зависимостей.
AI-worker вынесен из быстрого пути. У артефакта есть полный манифест и отдельный допуск. Ограничены IPC, память и предложения. Критические права и секреты не попадают в модель. Cgroups рассматривается как средство управления ресурсами, не доказательство hard real-time.
5. Сквозной сценарий и критика «революционности»#
Возражение. Архитектура может остаться набором громких названий без преимущества перед автоматом. Добавление Jev создаст внешнюю зависимость, а новая камера — лишнюю приватную телеметрию.
Базовый профиль не требует камеры и облачной модели. Есть воспроизводимый числовой пример, сильный эталон для будущего сравнения и пять фальсифицируемых гипотез. Новизна сформулирована как направление, а не доказанный мировой приоритет.
6. Совместимость и редакционное ревью#
Проблема. Удобное объяснение может скрыть критические детали: модель времени, стартовый импульс реле, единицы измерения, ограничение памяти. И наоборот, подробная схема бесполезна, если непонятно, что именно она должна обеспечить.
Связываем объяснение с проверкой: что измерить, какой результат ожидать, когда остановиться. Схемы различают физические соединения и логические связи; числа симуляции не выдаются за измерения оборудования. Размерные, электрические и программные примеры читаются вместе с их исходными условиями.
Оставшиеся вопросы для стенда Реальные задержки и тепловой режим; качество присутствия в кабинете; допустимые пороги и паузы; эффективность локальной RU/EN-модели; совместимость выбранного ML-backend; точность часов; устойчивость восстановленного управления. Эти пункты не закрываются редактурой документа или аналитическим ревью.
Реестр рисков первого экземпляра#
Это не статистика отказов, а начальная инженерная оценка. Вероятность и влияние: 1 — низкие, 2 — средние, 3 — высокие; произведение служит только порядком работы. Владелец всех действий сейчас — автор проекта в указанной роли. «Проектно решён» не равно «проверен на стенде». Полный реестр, связи с замечаниями и картами находятся в review_r2/risk_register.csv.
| Риск / P×I | Триггер и действие | Статус / карта |
|---|---|---|
| Повтор после кнопки / 3×3 | ACK потерян; дедуп до предусловий, high-water | Проектно решён; Q-01 |
| Старый срок после сна / 3×3 | Resume/reboot; BOOTTIME, консервативный дедлайн | Проектно решён; T-01 |
| Клон старого Hub / 2×3 | Restore; новый ключ, owner transfer, passive start | Нужен стенд; S-01 |
| MCU TLS/BLE/OTA не сходятся / 3×3 | Heap, handshake или rollback не проходят | Открыт; MCU-01 |
| Реле/питание не совпали с картой / 2×3 | Неизвестный IN, пуск или brownout | Открыт до BOM; E-01 |
| PIR приняли за отсутствие / 3×2 | Неподвижный человек; запрет авто-OFF E0 | Проектно решён; F-01 |
| Слишком широкий scope / 3×2 | Новый стек блокирует первый свет | Контроль этапов; PLAN-01 |
| Диск или retention ломают обещание / 2×3 | ENOSPC, потеря оснований; запрет ACCEPTED | Нужен стенд; D-01 |
| Риск / P×I | Триггер и действие | Статус / карта |
|---|---|---|
| Привязка KMP/FFI / 3×2 | Отмена/callback ломаются на iOS | Открыт; APP-01 |
| Голос выполняет чужую фразу / 2×3 | ТВ, отрицание; ограниченный субъект | Открыт E1; V-01 |
| Корпус мешает радио/охлаждению / 2×2 | Закрытые панели ухудшают измерения | Открыт H2; M/H/N-01 |
| Зависимость от облачного AI / 2×2 | Нет сервиса или лицензии; локальный baseline | Исключена из E0; AI-01 |
| Неверная ML-валидация / 3×2 | Утечка времени/контрфактическая метрика | Проектно решён; ML-01 |
| Компрометация зависимостей / 2×3 | Advisory, новый источник/веса | Постоянный; SUP-01 |
| Обновление возвращает старое доверие / 2×3 | Rollback схемы/ключей | Нужен стенд; R/S-01 |
| Материалы, контрафакт, EOL / 2×2 | Другая ревизия/неизвестный пластик | Проверка экземпляра; BOM-01 |
Профиль DEV допускает физическую отладку и не защищает секреты от владельца лабораторной платы. APPLIANCE требует отдельной квалификации защиты. Личные эксперименты, передача сборки для совместного теста и выпуск на рынок — разные основания ответственности; книга не является сертификатом электрической, радио- или коммерческой пригодности.
Ограничитель расширения: до закрытия команд, времени, ручного режима и физического выхода не добавляем обучение управляющей политики как обязательную зависимость. Это не отказ от физического интеллекта, а способ получить эксперимент, которому можно доверять. Энергия станции, время настройки и ручные исправления измеряются вместе с пользой алгоритма.