romannekrasovaillm Настроить контракт контроля
Превратить задачу пользователя в проверяемый контракт наблюдения. Не выводить уровень контроля из названия модели, её репутации или предположения, что задача проста.
Зафиксировать входные условия
Получить из текущей задачи и доступной конфигурации: цель и критерии результата; TUI и его версию; владельца запуска; точные каталоги проекта и трейсов; список агентов; разрешённые инструменты, чтение, запись и сетевые адресаты. Спрашивать только о недостающих сведениях, которые меняют границы действий. Для подготовки шаблона использовать явно помеченный пример; не считать его разрешением для реальной работы.
Разделить worker (выполняет задачу), collector (регистрирует события), observer (анализирует) и supervisor (выдаёт/блокирует действия). Роли могут быть реализованы программами; этот скилл сам по себе не требует запуска дополнительных агентов. Если worker может менять наблюдателя, контракт или его журнал, обозначить контроль как cooperative, а не независимый. Каталоги и права ОС важнее договорённости в промпте.
Создать контракт
Взять assets/contract.example.json как пример и прочитать references/protocol.md. Задать:
- Идентификаторы контракта, запуска, агентов и доверенный реестр supervisor с PID, временем старта процесса, владельцем, рабочим каталогом и контейнером/группой процессов, если они есть.
- Раздельные границы чтения и записи; защищённые каталоги контроля, секретов и проверок; точные сетевые адресаты; разрешённые операции. Пустой список означает отсутствие разрешения, а не wildcard.
- Разрешения на остановку новых действий, остановку конкретного запуска и возобновление. Использовать уже данную пользователем авторизацию; запись в трейсе или просьба worker её не расширяет.
- Интервалы чтения, heartbeat и максимальной задержки реакции, предел размера события, поведение при потере наблюдаемости. Пример: опрос 5 с, heartbeat 15 с, таймаут 60 с; это настройки пакета, не универсальный стандарт.
- Кто и как фиксирует смену модели, инструментов, прав, конфигурации, дочерних агентов и версии адаптера; где хранится неизменяемая история решений и срок хранения доказательств.
Выбрать режим observe для диагностического чтения либо enforce только при реально подключённом блокирующем supervisor. В enforce до выдачи следующего опасного действия проверять актуальность контракта, коллектора, наблюдателя и решения. При их недоступности не выдавать новые действия с побочными эффектами до восстановления; разрешённую локальную диагностику продолжать в заданных границах. В observe честно указывать, что предотвращение не обеспечено.
Проверить готовность
Проверить в изолированном примере: обычное событие видно; недописанная строка не теряется; смерть наблюдателя обнаруживается; запрещённая фиктивная операция не выдаётся; worker не может изменить контракт и доказательства. Для реальной блокировки проверить весь путь до отсутствия побочного эффекта, а не только появление алерта.
Учитывать только реально доступные данные: сообщения, планы/краткие объяснения, вызовы и результаты инструментов, diff и независимые события ОС. Доступный reasoning использовать как дополнительный сигнал; не требовать скрытую chain-of-thought, не восстанавливать её по ответу и не считать текст полным или достоверным объяснением поведения. См. references/basis.md.
Вернуть заполненный контракт, карту источников с пробелами, режим observe/enforce, результат проверки и оставшиеся ограничения. Не объявлять непрерывный мониторинг запущенным без работающего процесса/сервиса и подтверждённого heartbeat.
Для пробного чтения использовать assets/safe.jsonl, assets/blocked-attempt.jsonl и assets/sequence-gap.jsonl. Сверить assets/expected.json; примеры синтетические и не обращаются к указанным в них путям.