Тема: Прикладная часть 3. Конституция проекта: первый референдум правил
Уровень сложности: Средний
Расчётное время изучения: 6-8 часов (минимальный трек: 2-3 часа; полный трек с референдумом: +4-5 часов)
Предварительные требования: Часть 6 первого тома: понимание структуры mission.md, tech-stack.md, roadmap.md
Часть 18 первого тома: основы безопасности SDD-процесса
Базовое понимание YAML-синтаксиса
Опыт работы с системами авто-ремедиации или инцидент-менеджмента
Понимание концепций CI/CD и production-безопасности
Цели обучения: Сформулировать минимум два immutable_principles как запреты (не рекомендации) и одно mutable_rule с обязательными шестью полями (incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition)
Создать рабочий файл constitution.md, проходящий проверку скриптом check.py с вердиктом PASS
Объяснить разницу между продуктовой конституцией (mission/tech-stack/roadmap) и конституцией безопасной автоматизации (constitution.md)
Описать governance_protocol с тремя ролями, кворумом, veto от Safety и детерминированным правилом-разрешителем ничьей
Перенести принципы с локального кейса node_not_ready на зачётный кейс high_memory_usage, сохранив переносимость инвариантов
Обзор: Этот раздел учит создавать версионированный контракт безопасности для авто-ремедиации — файл constitution.md, который отделяет то, что агент никогда не имеет права делать (immutable_principles), от того, что можно делегировать с ограничениями (mutable_rules). В отличие от продуктовых файлов первого тома (mission.md, tech-stack.md, roadmap.md), которые отвечают на вопрос «что мы строим», constitution.md отвечает на вопрос «что агенту нельзя сделать с этим, даже если очень хочется». Ключевое новшество — строгая структура изменяемых правил с шестью обязательными полями, обеспечивающими ограниченный срок жизни, чёткий радиус последствий и автоматический откат при деградации. Для учебного прохождения достаточно ручного заполнения минимального constitution.md; автоматический референдум агентов и внешний арбитр относятся к полному production-треку.
Ключевые концепции: Immutable principles: Неизменяемые принципы — запреты и обязательства уровня безопасности, которые никогда не могут быть отключены автоматически. Формулируются как инварианты, а не рекомендации. Примеры: запрет на перезапуск production-БД без проверенного бэкапа, запрет на автоматическое удаление резервных копий и аудита, требование двух последовательных OK перед переводом инцидента в resolved. Именно они ограничивают агента в момент давления, когда кратчайший путь к снижению MTTR может создать больший каскад отказов.
Mutable rules: Изменяемые нормы с точным радиусом действия, которые можно отменить или переписать через формальную процедуру. Каждое правило обязательно содержит шесть полей: incident_type (класс инцидента), pipeline_phase (фаза реагирования: triage, recovery и т.д.), permitted_actions (список разрешённых действий), max_scope (лимит радиуса последствий, например single_node), ttl (срок жизни правила, после которого требуется пересмотр), rollback_condition (условие автоматического отката). Без этих полей поправка становится слишком широкой и конкурирует с инвариантами.
Max scope: Максимальный радиус последствий (blast radius), в пределах которого разрешено действие. Критически важный параметр для ограничения каскадных отказов. Примеры: single_node, single_pod, single_namespace. Любое расширение max_scope требует отдельного proposal и референдума.
Ttl (time to live): Срок действия изменяемого правила. После истечения ttl правило автоматически деактивируется или требует явного продления через референдум. Предотвращает «забытые» правила, которые через полгода никто не пересматривает. Типичные значения: 12h для hotfix-правил, 14d, 30d для регулярных операций.
Rollback condition: Условие, при котором изменяемое правило откатывается автоматически, без ожидания истечения ttl. Примеры: repeat_incidents_same_node>=2, memory_percent>=90% after 2 windows, 5xx_increase, Safety veto. Обеспечивает быструю реакцию на непредвиденные побочные эффекты автоматизации.
Governance protocol: Процедура голосования для изменения конституции. Минимальный состав — три роли: Verifier (проверяет нарушения инвариантов), Implementor (оценивает применимость в плейбуке), Safety (проверяет радиус последствий, приватность, условия отката). Кворум: 2 approve + no Safety-veto. Правило-разрешитель ничьей (tie-breaker): safety-first. Референдум созывается после трёх unknown-инцидентов с одним pattern_id за 48 часов.
Proposal.md: Форма поправки к конституции, включающая входные события, текущую классификацию unknown, предполагаемый риск, ожидаемый эффект, условие отмены. Поправка без происхождения (reason) и записи голосования не считается частью production SDD.
Change log: Неизменяемый след изменений конституции, содержащий version, parent_version, reason, votes по ролям, decision_hash (криптографический хеш для верификации), incident_context, activation_time, ссылку на diff. Превращает историю правок в цепочку доказательств.
Decision hash: Криптографический хеш решения (например, sha256), по которому можно пересчитать и проверить голосование позже. Обеспечивает воспроизводимость и защиту от подделки истории изменений.
Safety-first tie-breaker: Правило-разрешитель ничьей, при котором критический риск от Safety всегда ведёт к отклонению поправки. Детерминированное правило предотвращает зависание системы при равном счёте голосов.
Constitution gateway: Шлюз проверки перед выполнением опасного действия: локальный скрипт проверяет immutable_principles и mutable_rules, затем LLM в режиме планирования объясняет риски, и только после этого исполнитель получает допуск. Порядок критичен: проверка до действия, а не после.
Практические упражнения: Название: Создание минимального constitution.md для node_not_ready
Проблема: Создайте файл constitution.md для сценария node_not_ready. Требуется: два immutable_principles, сформулированных как запреты (не рекомендации); одно mutable_rule с обязательными шестью полями; короткий governance_protocol. Проверьте файл вопросом: «какое действие агент не сможет выполнить, даже если это снизит MTTR?» Ответ должен находиться в immutable_principles, а не в чате.
Решение: Шаг 1: Сформулируйте immutable_principles как запреты. Пример: «Не выполнять auto-remediation без audit_trace» и «Не трогать stateful workload без подтверждённой резервной копии». Шаг 2: Создайте mutable_rule для incident_type: node_not_ready, pipeline_phase: triage, permitted_actions: ["soft_restart_agent"], max_scope: "single_node", ttl: "30d", rollback_condition: "repeat_incidents_same_node>=2 or Safety veto". Шаг 3: Опишите governance_protocol: роли Verifier/Implementor/Safety, кворум 2 approve + no Safety-veto, tie-breaker: safety-first. Шаг 4: Запустите проверку: cd book2/examples/constitution && python3 scripts/check.py --constitution specs/constitution.yaml --proposal proposals/valid_proposal.md. Ожидаемый результат: verdict: PASS. Шаг 5: Проверьте с proposals/missing_evidence.md — verdict: BLOCK с указанием причин.
Сложность: beginner
Название: Перенос принципов на high_memory_usage
Проблема: Перенесите структуру с node_not_ready на кейс high_memory_usage. Не копируйте правило — найдите переносимый принцип. Сформулируйте immutable_principle для подтверждённой стабилизации памяти и mutable_rule для restart_pod с соответствующими max_scope, ttl и rollback_condition. Если строку-принцип сформулировать нельзя, вернитесь к локальному кейсу.
Решение: Шаг 1: Immutable: «Не закрывать high_memory_usage без подтверждения, что RSS вернулся ниже 80% дважды подряд» (перенос принципа двух OK подряд). Шаг 2: Mutable: incident_type: high_memory_usage, pipeline_phase: recovery, permitted_actions: ["restart_pod"], max_scope: "single_pod", ttl: "14d", rollback_condition: "5xx_increase OR memory_percent>=90% after 2 windows». Шаг 3: Governance: Safety-veto при попытке расширить restart_pod на namespace (перенос принципа ограничения радиуса). Шаг 4: Проверьте, что все шесть полей заполнены. Шаг 5: Запишите в capstone/README.md одну строку с причиной появления правила.
Сложность: intermediate
Название: Проверка и исправление типичных ошибок
Проблема: Дан черновик constitution.md с типичными ошибками: immutable-правило сформулировано как «по возможности избегать»; у mutable_rule отсутствует rollback_condition; governance_protocol не описывает tie-breaker; change_log отсутствует. Найдите и исправьте все ошибки, сохранив воспроизводимость проверки.
Решение: Шаг 1: Преобразуйте «по возможности избегать» в строгий запрет: «Не выполнять X автоматически, даже при давлении на MTTR». Шаг 2: Добавьте rollback_condition: конкретное условие автоматического отката, привязанное к наблюдаемым метрикам. Шаг 3: Добавьте tie-breaker: safety-first_then_latest_matching_precedent. Шаг 4: Создайте change_log с минимум одной записью, содержащей version, parent_version, reason, votes, decision_hash, activation_time. Шаг 5: Проверьте через Qwen Code: запросите проверку черновика с возвратом списка несоответствий без автоматической записи файлов. Шаг 6: Повторите runnable-проверку до получения PASS.
Сложность: intermediate
Название: Симуляция референдума и заполнение change_log
Проблема: Три одинаковых unknown-инцидента NodeNotReady произошли за 36 часов. Сформируйте proposal.md, проведите референдум с тремя ролями, запишите результат в change_log. Рассмотрите сценарий: Safety подаёт veto при равном счёте Verifier и Implementor. Убедитесь, что tie-breaker работает детерминированно.
Решение: Шаг 1: Подтвердите достижение порога: 3 unknown-инцидента с pattern_id NodeNotReady за 48h (36h < 48h, порог достигнут). Шаг 2: Сформируйте proposal.md: входные события (3 инцидента с таймстемпами), текущая классификация unknown, предполагаемый риск (soft_restart_agent на неподготовленном узле), ожидаемый эффект (снижение MTTR на 40%), условие отмены (repeat_incidents_same_node>=2). Шаг 3: Созыв референдума в течение 15 минут. Шаг 4: Голосование: Verifier: approve, Implementor: approve, Safety: veto (critical_risk — узел содержит stateful workload без явного бэкапа). Шаг 5: Применение правила pass_rule: at_least_2_approve_and_no_safety_veto → Safety-veto блокирует. При tie-breaker safety-first результат: BLOCK. Шаг 6: Запись в change_log: version 1.2.0, parent_version 1.1.0, reason, votes (verifier: approve, implementor: approve, safety: veto), decision_hash, activation_time: null (поправка не принята). Шаг 7: Повторите сценарий с Safety: abstain — поправка принимается, activation_time заполняется.
Сложность: advanced
Кейсы: Название: Каскадный отказ при отсутствии max_scope: инцидент в облачном провайдере
Сценарий: Крупный облачный провайдер внедрил авто-ремедиацию для инцидента DiskPressure на Kubernetes-кластерах. Правило разрешало drain узла без ограничения радиуса последствий. При массовом сбое хранилища правило последовательно drain'ило узлы по всему региону, превратив локальный инцидент в региональную недоступность.
Задача: Отсутствие max_scope в mutable_rule позволило агенту расширять радиус действия каскадно. Не было ttl — правило действовало бессрочно. Не было rollback_condition — при увеличении охвата отказа система не остановилась автоматически. Команда обнаружила проблему через 47 минут, когда 60% узлов региона были уже drain'ированы.
Решение: После инцидента команда ввела строгую конституцию: immutable_principle «Не выполнять массовые операции над узлами без явного approval от Safety»; mutable_rule для DiskPressure с max_scope: single_node, ttl: 4h, rollback_condition: «drain_rate>1_node_per_5min OR affected_pods>10». Governance_protocol с Safety-veto на любое расширение max_scope. Автоматический шлюз проверяет конституцию перед каждым drain.
Результат: Время восстановления сократилось с 4 часов до 15 минут для изолированных инцидентов. Региональных каскадных отказов не происходило за 18 месяцев. Среднее время принятия нового правила через референдум: 12 минут. Все изменения прослеживаются в change_log с decision_hash.
Извлечённые уроки: max_scope — не декоративное поле, а критический барьер против каскадных отказов; его отсутствие дороже любой экономии на MTTR
ttl заставляет пересматривать правила и предотвращает «забытые» разрешения, которые становятся опасными при изменении архитектуры
rollback_condition должна быть привязана к наблюдаемым метрикам, а не к абстрактным оценкам; drain_rate и affected_pods измеряются автоматически
Safety-veto на расширение радиуса — необходимая компенсация скорости референдума; без него кворум 2 approve становится недостаточным для критических решений
Связанные концепции: max_scope
ttl
rollback_condition
safety-first tie-breaker
constitution gateway
Название: Успешный hotfix ticketing flood: ограниченное правило с чётким ttl
Сценарий: Платформа поддержки столкнулась с волной тикетов из-за сбоя интеграции с внешним API. Стандартная маршрутизация тикетов создавала очередь в 4 часа, критичную для SLA. Команда рассмотрела вариант автоматической переадресации всех тикетов в общую очередь без классификации.
Задача: Полная автоматизация маршрутизации нарушала immutable_principle «Не терять аудит-trace при обработке тикетов» и создавала риск утечки PII в неправильную очередь. Ручная обработка не справлялась с объёмом. Нужно было временное правило с гарантированным откатом.
Решение: Команда создала mutable_rule hotfix_ticketing_flood: incident_type: api_integration_failure, pipeline_phase: triage, permitted_actions: ["simplified_routing"], max_scope: "single_api_endpoint", ttl: "12h", rollback_condition: «checkpoint_missing OR pii_exposure_detected». Immutable_principle сохранял запрет на потерю аудита. Governance_protocol: Verifier проверял отсутствие PII в упрощённой маршрутизации, Implementor — наличие checkpoint, Safety — радиус последствий. Референдум созван за 8 минут, принят с Safety: abstain.
Результат: SLA восстановлен за 2 часа. Правило автоматически деактивировалось через 12 часов. Checkpoint позволил восстановить стандартную маршрутизацию без потери данных. Аудит-trace сохранён полностью. Запись в change_log с decision_hash используется как прецедент для будущих hotfix-правил.
Извлечённые уроки: Короткий ttl (12h) для hotfix-правил предпочтительнее «разумного» срока в неделю — принуждает к явному решению о продлении или архивировании
checkpoint как часть rollback_condition обеспечивает техническую возможность отката, а не только политическое разрешение
Safety: abstain вместо approve — допустимый исход, когда риски минимальны; важно, что veto всё ещё возможно и блокирует при критических рисках
Прецедент в change_log ускоряет будущие референдумы: latest_matching_precedent в tie-breaker ссылается на хеш принятого решения
Связанные концепции: ttl
rollback_condition
change_log
decision_hash
immutable_principles
Советы по изучению: Начинайте с ручного заполнения, не с автоматизации: создайте constitution.md в текстовом редакторе, проверьте глазами, затем используйте скрипт. Это формирует интуицию структуры, которую автоматизация скрывает
Проверяйте каждое immutable_principle тестом на давление: сформулируйте сценарий, где агенту «очень хочется» нарушить правило ради MTTR. Если формулировка позволяет обход — это рекомендация, не инвариант
Используйте парное сравнение «плохо/хорошо» для mutable_rules: возьмите правило без ttl/max_scope/rollback_condition, представьте его через год при смене архитектуры, затем добавьте недостающие поля и повторите мысленный эксперимент
Тренируйте перенос принципов, а не копирование правил: возьмите локальный кейс node_not_ready, выделите абстрактный принцип (например, «подтверждённая стабилизация перед resolved»), затем примените к совершенно другому контексту (high_memory_usage, cpu_throttling, disk_pressure)
Практикуйте интервью с Qwen Code по шаблону: задайте три сгруппированных вопроса, получите ответы, проверьте черновик, затем попросите найти типичные ошибки. Это моделирует production-процесс и готовит к работе с LLM-ассистентом
Создавайте собственные «плохие» примеры для runnable-проверки: возьмите proposals/missing_evidence.md и proposals/conflict_with_immutable.md, модифицируйте их, предскажите verdict, затем проверьте. Обратная связь скрипта укрепляет понимание границ
Ведите «конституционный дневник»: для каждого инцидента в вашей практике записывайте, какое immutable_principle и mutable_rule применились бы, какой max_scope и rollback_condition выбрали бы. Это превращает абстрактные концепции в профессиональную интуицию
Для полного трека: симулируйте референдум с коллегами или в ролевой игре. Назначьте роли Verifier/Implementor/Safety, раздайте одинаковый proposal, сравните голоса. Расхождения покажут неоднозначности в governance_protocol, которые нужно устранить
Дополнительные ресурсы: Book2/examples/constitution/: Runnable-примеры проверки конституции, включая скрипт check.py, шаблоны constitution.yaml и proposal.md, примеры PASS и BLOCK
Book2/examples/templates/proposal.md: Шаблон формы поправки с обязательными секциями для референдума
Book2/examples/spec-ci/readme.md: Runnable-аналог шлюза: идея та же — проверяемый шлюз до действия
Часть 6 первого тома (part-06-constitution.md): Источник mission.md, tech-stack.md, roadmap.md — продуктовая конституция первого тома
Часть 18 первого тома (part-18-sdd-security.md): Безопасность SDD-процесса — контекст для понимания цены ошибки в production
Часть 13 первого тома (part-13-legacy-support.md): Взаимодействие с работающим кодом — связь конституции с legacy-системами
Часть 16 первого тома (part-16-team-code-review.md): Сравнение ревью кода фичи и ревью опасных действий — почему одного человека недостаточно
Qwen code plan mode документация: Режим планирования для проверки конституции без автоматической записи файлов
Yaml 1.2 specification: Техническая спецификация формата constitution.md для глубокого понимания структуры данных
Резюме: Конституция проекта (constitution.md) — это версионированный контракт безопасности, отделяющий то, что агент никогда не имеет права делать (immutable_principles как строгие запреты), от того, что можно делегировать с ограничениями (mutable_rules с обязательными шестью полями: incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition). В отличие от продуктовых файлов первого тома, она отвечает на вопрос «что агенту нельзя сделать». Учебный минимум — ручное создание файла с двумя запретами и одним изменяемым правилом, проходящего проверку скриптом. Полный трек добавляет governance_protocol с тремя ролями, кворумом, Safety-veto и детерминированным tie-breaker, референдум агентов и неизменяемый change_log с decision_hash. Ключевой практический навык — перенос принципов между кейсами (node_not_ready → high_memory_usage), а не механическое копирование. Конституция проверяется до опасного действия, а не после, превращая скорость реакции из риска в управляемый процесс.