ADR 0034: Недееспособность оператора (Incapacitation), Emergency Mode и опциональное сенсорное присутствие¶

Статус: Proposed (намерение и границы зафиксированы; реализация — по отдельной дорожной карте).
Дата: 2026-04-12 · Обновлено: 2026-04-15

Связанные ADR¶

ADR	Роль
0021	модель внимания, EICAS как слой сигналов; метафора КВС — [§1, глоссарий](0021-pfd-mfd-cockpit-attention-model.md#glossary-kvs
0025	зоны и capabilities
0032	HUD / «умное» снижение шума при ограничении внимания
0008	внешние MCP, stdio

Контекст¶

В авиации Pilot Incapacitation — ситуация, когда пилот не может продолжать безопасное управление (здоровье, усталость, стресс, потеря сознания). В кокпите есть процедуры передачи управления и ограничения риска.

Для Cascade IDE как «кокпита разработки» периодически поднимается идея аналогичного срабатывания на уровне продукта: если система фиксирует, что оператор перестал адекватно реагировать на критические сигналы (в т.ч. EICAS-подобные алерты) или долго не подтверждает опасные действия агента при включённой автономности, IDE переходит в Emergency Mode: жёстко фиксирует безопасное состояние рабочей копии (например запрет записи в защищённую ветку, блок автономных мутаций), требует явного выхода (перезапуск сессии, повторная авторизация, ручное снятие режима).

Отдельно обсуждается использование уже существующего в meta-repo open MCP webcam-capture-mcp не как «развлечение», а как опциональный канал сигналов — в перспективе не только «стрим пикселей», а контракт на уровне безопасности: присутствие оператора, грубая оценка внимания к экрану (при наличии отдельного контура анализа, например webcam-analysis-mcp), liveness для политик «оператор в контуре» — в дополнение к чисто программным триггерам.

Роль в «авионике» и EICAS¶

Когда этот контракт будет реализован, EICAS (смысл 0021: слой критичных/предупреждающих сигналов для оператора) получает ещё один класс входов — состояние КВС (оператор в кадре / не в кадре / нет подтверждения внимания к монитору), с приоритетом и объединением с существующими сигналами здоровья workspace. Аналог в авиации — не прямое копирование боевой авионики, а по смыслу: датчики «руки на управлении» / присутствия пилота и системы, которые пересчитывают риск автоматики при потере контакта (в IDE — риск автономной задачи агента).

Этот ADR не утверждает готовую реализацию и не смешивает:

здоровье репозитория / сборки / тестов (существующие и плановые сигналы IDE Health, EICAS в смысле 0021);
со состоянием человека-оператора (новый класс входов и политик).

Решение (намерение)¶

Два класса сигналов (канон на будущее):
A — программные: таймауты на критические подтверждения, отсутствие реакции на высокоприоритетные алерты при включённой автономности агента, явные пороги «сколько раз подряд отклонён опасный шаг» — без камеры. Дополнительно внутри приложения (без видео) возможны прокси-сигналы присутствия: активность указателя (движение мыши, события в зоне клиента IDE), клавиатуры (ввод в редакторе и т.д.) — как дешёвый и приватный индикатор «кто-то взаимодействует с кокпитом». Ограничения: чтение без движения курсора, уход в другое приложение, длинный простой при мониторинге — дают ложные «нет в контуре» или наоборот; политика должна комбинировать сигналы и пороги, а не опираться на мышь одну.
B — опциональные внешние: данные с webcam-capture-mcp (или аналога) как датчик присутствия / отсутствия в кадре с пользовательски настраиваемыми порогами и явным opt-in; без opt-in слой B не активен.

C — аппаратный eye tracking (отложено, не baseline): отдельные устройства/API (Tobii и др.), калибровка, стоимость, ОС. Сильно отложенная дорожная карта, не требующаяся для первых версий политик присутствия. Риски: у части пользователей движения глаз / саккады не укладываются в «типовую» модель калибровки при нормальном поле зрения и работе с широким экраном — система не должна трактовать это как «не смотрит» или отказывать в interlock. Доступность: любой сценарий, где теоретически задействован взгляд, обязан иметь эквивалент без eye tracking (фокус, мышь, явное подтверждение).

Emergency Mode (целевое поведение на высоком уровне): при выполнении политики «оператор недоступен для безопасного продолжения» — стабилизация: остановка или приостановка автономных действий с побочными эффектами, блок опасных git-операций (как минимум push/merge в защищённые ветки — точная матрица — в проектировании), сохранение состояния UI/сессии там, где это не противоречит безопасности, явный выход только после осознанного действия оператора (или администратора в корпоративном сценарии — вне scope v1).

Smart Attention / HUD: при сигналах «оператор не у экрана» (слой B или эвристика по отсутствию ввода — отдельно) — снижение навязчивости подсказок агента (например ghost text, интенсивность HUD) по согласованию с 0032 и Dark Cockpit из 0021 §9; не выжигать контекстное окно, пока оператора нет.

Приватность и безопасность: видеопоток не является обязательным для Cascade IDE; хранение и обработка — по политике пользователя; никакой обязательной отправки изображений наружу из IDE; интеграция с MCP — локальный процесс и явные настройки. Ложные срабатывания камеры компенсировать консервативными порогами и ручным override.

Границы ADR (уточнение «биометрия»): не заменять integrity-протоколы агента в KB. Слово биометрия здесь — в смысле сигналы присутствия и живости (liveness) для безопасности, не идентификация личности и не медицинская диагностика; отдельное согласие и политика (в т.ч. корпоративная) — если канал когда-либо станет обязательным для класса команд. Не обещать в ранних версиях распознавание эмоций; не позиционировать камеру как единственный источник истины — слой A (программный) остаётся базой.

Liveness / присутствие без «кнопки я тут» (целевое): при включённом opt-in оператор не обязан периодически нажимать отдельную кнопку подтверждения; система использует непрерывные или частые сигналы присутствия/внимания (в рамках политики и приватности), чтобы отличать «в контуре» от «выпал / ушёл» для пересчёта риска автономной задачи. Комбинация слоя A (мышь/клавиатура/фокус окна) и при необходимости слоя B (камера) задаётся политикой; только мышь без контекста — недостаточно для строгих interlock.

Контекстный HUD и внимание (целевое): если доступна оценка куда направлено внимание (хотя бы грубо: зона PFD/телеметрии vs зона редактора кода), агент/UI могут усиливать релевантную телеметрию и приглушать второстепенное по принципу Dark Cockpit (0021 §9) и настраиваемого HUD (0032). Базовый порядок — эвристики фокуса окна/панели и слоя A; аппаратный eye tracking (п. 1, слой C) — только как опциональное улучшение, когда появится и будет иметь смысл по продукту; не v1.

Safety interlock (целевое): для заранее определённого класса опасных действий (примеры класса: деплой, разрушающие операции с БД, необратимые git-операции — точный список политикой) при активной политике «требуется подтверждённое присутствие» — запрет или двухшаговое подтверждение, если сенсоры не подтверждают, что оператор в контуре / внимание к рабочей зоне (прокси: фокус, слой A; при наличии — B; не обязательный буквальный «взгляд» до появления надёжного и доступного канала). Это дополняет PFD-подтверждения (0017), а не заменяет integrity в KB.

Последствия¶

Появится место в архитектурной памяти для дорожной карты: политики, настройки, UI режима Emergency, интеграция с git/автономностью агента.
Реализация потребует отдельных задач: модель состояний, тесты политик, UX снятия режима, документация для пользователя.

Отклонённые / отложенные альтернативы¶

Только камера без программных порогов — высокий риск ложных срабатываний и приватности; слой A остаётся базой.
Обязательная камера для автономности — противоречит принципу opt-in и разным средам (сервер без камеры, политика организации).
Обязательный eye tracking для любого критичного сценария — отклонён: дорого, не у всех есть устройство, доступность и разнообразие паттернов движения глаз относительно поля зрения; допустим только как опция (п. 1, слой C).

Открытые вопросы¶

Точная матрица git-операций в Emergency Mode и взаимодействие с 0019.
Единый реестр сигналов (EICAS репозитория vs «оператор недоступен») в UI — один слой или два визуально связанных; приоритет при одновременном критическом алерте repo и сигнале «оператор не в контуре».
Нужен ли отдельный IdeCommands / MCP-тул для принудительного Emergency с подтверждением (как PFD-подтверждения — см. 0017, 0031).
Пайплайн взгляда/фокуса: достаточно ли эвристик «активная панель / зона внимания» без камеры, или для interlock нужен отдельный контур (например анализ кадра в webcam-analysis-mcp); калибровка и ложные срабатывания.
Eye tracking (если когда-либо): калибровка под разные профили; не смешивать «широкое поле зрения» с качеством сигнала трекера; режим «без eye tracking» в настройках всегда доступен.
Мышь/клавиатура как сигнал: пороги простоя (ms), учёт фокуса окна, смешение с алертами; сценарии «читает без движения мыши», «ушёл в браузер» — явно в политике или в UX-подсказках.
Юридические и организационные ограничения на биометрические сигналы в корпоративной среде (даже как liveness, не идентификация).