Тема: Прикладная часть 3. Конституция проекта: первый референдум правил
Уровень сложности: Средний
Расчётное время изучения: 2-3 часа
Предварительные требования: Знакомство с материалов первого тома: файлами mission.md, tech-stack.md, roadmap.md (Часть 6).
Понимание основ безопасности SDD-процесса (Часть 18 первого тома).
Базовые навыки работы с форматами YAML и Markdown.
Цели обучения: Научиться четко разделять продуктовые контракты (mission/tech-stack/roadmap) и конституцию безопасности автоматизации (constitution.md).
Уметь формулировать неизменяемые принципы (immutable_principles) как строгие запреты, а не как рекомендации.
Освоить создание изменяемых правил (mutable_rules) с обязательным заполнением всех 6 критических полей (incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition).
Понять и уметь описывать базовый протокол управления (governance_protocol), включая роли агентов, правила голосования и условия вето.
Приобрести практический навык переноса правил с одного инцидента (node_not_ready) на другой (high_memory_usage) без слепого копирования.
Обзор: Данный раздел посвящен созданию «Конституции проекта» — версионированного набора правил и ограничений для безопасной автоматизации (авто-ремедиации) и работы ИИ-агентов. В то время как файлы первого тома (mission.md, tech-stack.md, roadmap.md) отвечают на вопрос «что мы строим», новый файл constitution.md отвечает на вопрос «что агенту нельзя сделать с этим, даже если очень хочется». Конституция состоит из двух основных слоев: immutable_principles (неизменяемых запретов, защищающих БД, бэкапы и аудит) и mutable_rules (изменяемых правил с жестко ограниченным радиусом действия, сроком жизни и условиями отката). В разделе также изучается процедура принятия поправок через референдум агентов, что делает изменения правил прозрачными и прослеживаемыми.
Ключевые концепции: Constitution.md: Версионированный набор инвариантов и изменяемых правил, описывающий контур безопасной автоматизации. Проверяется до выполнения любых опасных действий агентом.
Immutable principles: Неизменяемые принципы — правила-запреты, которые никогда не могут быть отключены автоматически (например, запрет на удаление бэкапов или перезапуск БД без резервной копии). Ограничивают агента в момент давления ради снижения MTTR.
Mutable rules: Изменяемые нормы с точным радиусом действия, которые можно отменить или переписать через формальную процедуру. Обязаны содержать 6 полей: incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition.
Governance protocol: Протокол управления, описывающий процедуру голосования (референдума) за внесение изменений в конституцию. Включает роли (Verifier, Implementor, Safety), веса голосов, кворум и правило-разрешитель ничьей (tie-breaker).
Ttl (time to live): Срок жизни изменяемого правила. По истечении этого срока правило должно быть пересмотрено или продлено, предотвращая появление бессрочных и забытых разрешений.
Max scope: Максимальный радиус последствий (blast radius) для изменяемого правила (например, single_node или single_pod). Защищает от массовых каскадных отказов.
Rollback condition: Условие автоматического отката изменяемого правила (например, повторение инцидента или вето от роли Safety).
Proposal.md: Форма поправки, выносимая на референдум. Должна содержать причину появления, контекст инцидентов, голоса и условия активации.
Практические упражнения: Название: Аудит изменяемого правила (mutable_rule)
Проблема: Ниже приведен фрагмент изменяемого правила, написанного разработчиком. Найдите в нем критические ошибки, из-за которых правило не может быть допущено в constitution.md, и объясните их влияние на безопасность системы.
- id: db_write_lag_restart
incident_type: "DBWriteLag"
permitted_actions: ["restart_database"]Решение: 1. Отсутствует pipeline_phase: Непонятно, на каком этапе (triage, recovery) разрешено действие.
- Отсутствует max_scope: Нет ограничения радиуса последствий. Действие может быть применено ко всему кластеру.
- Отсутствует ttl: Правило становится бессрочным. Через полгода никто не вспомнит причину его создания.
- Отсутствует rollback_condition: Нет механизма автоматического отката при усугублении ситуации.
Итог: Такое правило слишком широкое и создает риск потери данных.
Сложность: intermediate
Название: Разработка immutable_principles
Проблема: Сформулируйте два неизменяемых принципа (immutable_principles) для проекта автоматизации инцидентов. Они должны быть строгими запретами, а не пожеланиями.
Решение: Пример правильных формулировок:
- «Запрещено автоматически удалять резервные копии для освобождения дискового пространства».
- «Запрещено переводить инцидент в статус resolved без получения двух последовательных подтверждений стабилизации (OK) от системы мониторинга».
Неправильный пример (рекомендация): «Желательно не удалять бэкапы без необходимости».
Сложность: beginner
Название: Перенос правила на новый инцидент (high_memory_usage)
Проблема: Вам нужно перенести опыт работы с node_not_ready на инцидент high_memory_usage. Запишите изменяемое правило (mutable_rule) в формате YAML. Разрешите перезапуск пода (restart_pod) на фазе recovery, сроком на 14 дней, с откатом при росте 5xx ошибок или если память >= 90%.
Решение: ```yaml
- incident_type: high_memory_usage
pipeline_phase: recovery permitted_actions: ["restart_pod"] max_scope: "single_pod" ttl: "14d" rollback_condition: "memory_percent>=90% after 2 windows or 5xx increases"
Сложность: advanced
Кейсы:
Название: Авто-ремедиация инцидента NodeNotReady
Сценарий: В production-среде регулярно возникает инцидент NodeNotReady. ИИ-агент, стремясь минимизировать время простоя (MTTR), предлагает автоматически перезапускать узлы и агентов без участия человека.
Задача: Баланс между скоростью реакции и безопасностью. Если агент перезапустит не тот узел или вмешается в stateful workload без бэкапа, простой усилится, а данные могут быть потеряны. Необходим формальный шлюз.
Решение: Команда внедряет constitution.md. В immutable_principles записывается запрет на трогание stateful workload без бэкапа. В mutable_rules добавляется 'soft_restart_agent' строго с max_scope: 'single_node', ttl: '30d' и условием отката при повторных сбоях. Создается governance_protocol с кворумом (2 approve) и правом вето для роли Safety.
Результат: Агент получил возможность быстро реагировать на известную проблему (мягкий перезапуск), но система автоматически блокирует его, если он попытается выполнить опасное действие (жесткий перезапуск БД) или превысить зону поражения.
Извлечённые уроки:
Скорость восстановления (MTTR) не должна достигаться за счет обхода аудита и резервного копирования.
Каждое разрешение на авто-ремедиацию должно иметь срок годности (ttl) и ограниченный радиус (max_scope).
Изменяемые правила без условий отката превращаются в бессрочные и опасные лазейки.
Связанные концепции:
immutable_principles
mutable_rules
max_scope
Название: Шлюз конституции: проверка proposal.md
Сценарий: Система мониторинга зафиксировала 3 неизвестных инцидента с одним pattern_id за последние 48 часов. Инициирован процесс референдума агентов для создания нового правила.
Задача: Убедиться, что предлагаемая поправка (proposal.md) к конституции не нарушает базовые инварианты безопасности и содержит всю необходимую информацию для прослеживаемости (provenance).
Решение: Использование runnable-аналога (скрипта check.py). Агент Координатор формирует proposal.md с доказательствами. Затем скрипт читает конституцию и предложение, проверяя наличие всех 6 полей для новых правил. Роль Verifier проверяет формальную логику, а Safety оценивает риски расширения радиуса последствий.
Результат: Скрипт выдает verdict: PASS или BLOCK. Если правило принято, в change_log заносится запись с version, parent_version, итогами голосования (votes), decision_hash и activation_time. Создана прослеживаемая генеалогия решения.
Извлечённые уроки:
Поправка без происхождения (без фиксации причины и контекста) не является частью безопасного процесса.
Автоматизация проверки правил скриптами надежнее, чем ручное ревью человеком под давлением.
Генеалогия правок должна содержать криптографический хеш (decision_hash) для защиты от несанкционированного изменения истории.
Связанные концепции:
governance_protocol
change_log
decision_hash
Советы по изучению:
При первом чтении остановитесь на разделе «Ключевые идеи» и переходите к практике. Полный трек (референдум, хеши, арбитраж) лучше изучать после закрепления базы.
Формулируйте инварианты так, чтобы ответ на вопрос «какое действие агент не сможет выполнить, даже если это снизит MTTR?» лежал в тексте файла, а не в чате с разработчиком.
Используйте скрипт проверки (check.py) на ранних этапах. Если скрипт блокирует ваше предложение (verdict: BLOCK), он сразу укажет на недостающие поля (ttl, max_scope).
При переносе правил с одного домена на другой (например, с node_not_ready на high_memory_usage) адаптируйте условия отката (rollback_condition), а не копируйте их слепо.
Дополнительные ресурсы:
Шаблон предложения (proposal.md): book2/examples/templates/proposal.md — используйте этот шаблон для оформления ваших первых предложений к конституции.
Скрипт проверки конституции: book2/examples/constitution/scripts/check.py — runnable-аналог для проверки ваших YAML файлов на соответствие 6 обязательным полям.
Часть 6 первого тома: Опора по созданию продуктовых спецификаций (mission.md, tech-stack.md, roadmap.md), которые не заменяются constitution.md.
Часть 18 первого тома: Основы безопасности SDD-процесса, объясняющие почему опасные действия должны проходить формальный шлюз.
Резюме: Конституция проекта (constitution.md) — это критический контур безопасности, отделяющий то, что ИИ-агент может адаптировать, от того, что он не имеет права отключать. Она состоит из неизменяемых инвариантов (immutable_principles), защищающих данные и аудит, и изменяемых норм (mutable_rules), которые должны иметь жесткие границы (max_scope), срок жизни (ttl) и условия отката. Для зачета по теме достаточно создать минимальный файл с двумя запретами, одним изменяемым правилом на 6 полей и коротким протоколом управления, гарантируя, что любое расширение прав агента будет прослеживаемым и обоснованным.