Тема: Прикладная часть 13. Практический зачёт: собрать production SDD-контур
Уровень сложности: Средний
Расчётное время изучения: 6-8 часов
Предварительные требования: Успешное освоение глав 1-12 второго тома курса
Понимание концепций SDD (Spec-Driven Development) и фреймворка AgentClinic-production
Навыки работы с терминалом и запуск runnable-скриптов (Python/Shell)
Базовое понимание принципов работы ИИ-агентов, CI/CD и пост-мортемов
Цели обучения: Самостоятельно собрать связный пакет артефактов (capstone/) для прохождения production-сценария SDD.
Научиться восстанавливать требования с провенансом (genealogy.md) и формировать контролируемо дефектные спецификации.
Освоить настройку правил конституции (constitution.md), бюджетного контроля и анти-Goodhart метрик.
Проводить валидацию кейса через runnable-скрипты и формировать записи файлового арбитража (judgment.md).
Оценить готовность пакета по 30-балльной шкале, гарантируя его воспроизводимость для независимого ревьюера.
Обзор: Данный модуль представляет собой финальный практический зачет второго тома. Его главная цель — доказать, что вы способны пройти реальный production-сценарий SDD (Spec-Driven Development) от наследуемого следа (legacy) до итогового решения, которое обосновано строгими фактами, а не слепой уверенностью ИИ-агента. Вместо изучения нового теоретического материала вам предстоит собрать единый проверяемый маршрут (пакет capstone/) на основе инцидента high_memory_usage или autoscale_200pct. Зачет считается успешно пройденным, если сторонний ревьюер сможет открыть ваш пакет и без дополнительных устных пояснений понять логику проверки, источник требований и причины блокировки или допуска в production.
Ключевые концепции: Sdd-контур (spec-driven development): Методология разработки и эксплуатации, в которой каждое автоматическое действие агента опирается на проверяемую спецификацию и неизменяемые правила, а не на эвристики.
Провенанс (genealogy): Принцип прослеживаемости происхождения любого требования. Артефакт genealogy.md связывает требование с источниками (пост-мортем, QWEN.md, устная практика) и оценивает уровень уверенности.
Шлюз готовности (readiness gate): Финальная проверка решения перед допуском к production. Включает readiness-балл, список блокирующих условий и доказательства (evidence_ref).
Контролируемо дефектная спецификация (poisoned spec): Спецификация, в которую намеренно внедрен ровно один дефект (например, конфликт приоритетов или скрытый выход за лимиты) для проверки механизмов валидации и исправления (fixed-spec).
Конституция (constitution): Набор правил системы, четко разделенный на immutable_principles (неизменяемые законы) и mutable_rules (изменяемые правила с заданным сроком жизни TTL, областью действия и условиями отката).
Анти-goodhart контроль: Механизм защиты от искажения метрик, когда чрезмерная оптимизация целевого KPI приводит к негативным последствиям. Контролируется через введение guard-метрик (например, token_health).
Практические упражнения: Название: Инициализация пакета и маршрутизация
Проблема: Создайте директорию capstone/ и файл README.md. Сформулируйте 5 ключевых строк-заготовок для инцидента high_memory_usage: Incident-case, Главный риск, Ключевая проверка, Главный блокер, Следующее исправление.
Решение: 1) Создайте папку mkdir -p capstone. 2) Создайте файл capstone/README.md. 3) Впишите заготовку: Incident-case: high_memory_usage; Главный риск: auto-remediation без полного audit_trace; Ключевая проверка: python3 scripts/check_readiness.py; Главный блокер: stateful workload без backup_verified; Следующее исправление: добавить evidence_ref для backup. Это сфокусирует дальнейшую работу.
Сложность: beginner
Название: Восстановление провенанса и дефекта
Проблема: На основе абстрактного пост-мортема создайте файл genealogy.md (одно требование, 2 источника) и пару poisoned-spec.md / fixed-spec.md с одним циклическим дефектом и его исправлением.
Решение: 1) В genealogy.md укажите требование 'Очистка кэша при достижении 90% памяти', источники: 'Grafana Alert' и 'Устная практика SRE', уровень уверенности: High. 2) В poisoned-spec.md создайте правило: 'Если память >90%, очистить кэш, если кэш пуст - запросить память у системы'. 3) В fixed-spec.md укажите: 'Исправление цикла: при пустом кэше запускать GC, а не запрашивать память'.
Сложность: intermediate
Название: Запуск валидации и фиксация результата
Проблема: Запустите скрипт проверки readiness_block_stateful.json из runnable-примеров. Перенесите результат в validation.md в формате: команда, ожидаемый факт, фактический результат, блокер.
Решение: 1) Запустите python3 scripts/check_readiness.py --readiness fixtures/readiness_block_stateful.json. 2) Команда вернет код 1 (ошибка/блокер). 3) В validation.md запишите: Команда: check_readiness...; Ожидание: Блокировка stateful; Результат: Exit code 1; Блокер: Отсутствует подтверждение backup. Это доказывает, что шлюз готовности работает корректно.
Сложность: advanced
Кейсы: Название: Инцидент high_memory_usage: от алерта до защищенного деплоя
Сценарий: Система AgentClinic-production получила критический алерт от Grafana о превышении потребления памяти. Legacy-следы частично утеряны: часть правил восстановления известна только из старой документации QWEN.md и устной передачи знаний. Автоматическая ремедиация (очистка и перезапуск) выглядит привлекательным решением.
Задача: Автоматическое вмешательство может нарушить лимит радиуса последствий (blast radius) или бюджет ярусов. Команде необходимо доказать, что предложенная спецификация безопасна, не содержит скрытых дефектов и готова к допуску в production без риска потери данных.
Решение: Инженеры собрали пакет capstone/. Восстановили происхождение требований в genealogy.md. Создали намеренно дефектную спецификацию и исправили её, зафиксировав правила в constitution.md. Провели тестовый прогон (dry-run) скриптом check_readiness.py, который заблокировал действие из-за отсутствия меток backup_verified у stateless-нагрузки. Результаты вынесли в judgment.md со статусом DEFERRED.
Результат: Пакет доказательств набрал 26/30 баллов. Опасный деплой был предотвращен благодаря правильной работе шлюза готовности. Решение было отложено до добавления evidence_ref для бэкапов, что позволило избежать даунтайма в production.
Извлечённые уроки: Readiness-балл без доказательств (evidence_ref) не имеет смысла и не может служить допуском.
Один обнаруженный блокер на этапе тестирования ценнее формального APPROVE без запуска проверок.
Не следует включать в итоговый ревьюируемый след логи out/, ревьюеру нужна только выжимка validation.md.
Связанные концепции: Readiness Gate
Genealogy
Poisoned Spec
Validation
Название: Разрешение спора при масштабировании autoscale_200pct
Сценарий: При пиковых нагрузках ИИ-агент (Имплементор) предложил масштабировать ресурсы на 200% на основе шаблона из QWEN.md. Агент безопасности (Safety) наложил вето, сославшись на риск превышения бюджета и возможный Goodhart-эффект, когда система будет масштабировать ресурсы ради метрики, а не реальной пользы.
Задача: Возник конфликт ролей. Требуется провести файловый арбитраж через дуэль (duel) и принять решение, опираясь на конституцию системы и метрики, а не на авторитет агентов.
Решение: Был запущен механизм трибунала: run_duel.py для фиксации аргументов и check_invariants.py для проверки бюджетов. В goodhart-note.md зафиксировали, что KPI 'скорость ответа' врет, и добавили guard-метрику 'стоимость/запрос'. В judgment.md вынесли вердикт DENY, что автоматически создало прецедент в precedents.md (с полями case_id и applies_to).
Результат: Конфликт разрешен формализованно. Создан прецедент, который в будущем позволяет автоматически отклонять подобные запросы без траты токенов на дуэль. Budget-note.md четко показал лимиты дешевого яруса.
Извлечённые уроки: Safety-veto невозможно обойти простым большинством голосов.
Любой повторяющийся спор должен превращаться в записанный прецедент (precedent).
Anti-Goodhart контроль (связка KPI и guard-метрики) жизненно необходим для автоматического масштабирования.
Связанные концепции: Арбитраж и роли
Judgment
Anti-Goodhart
Precedents
Советы по изучению: Начинайте с конца: сначала заполните 5 строк-заготовок в README.md, чтобы задать рамки, и только потом создавайте остальные артефакты.
Не смешивайте инциденты. Выберите строго один кейс (например, high_memory_usage) и не добавляйте в него элементы из других сценариев.
Используйте 'Золотой путь': откройте examples/templates/capstone-dossier.md как образец того, насколько лаконичным должен быть ваш пакет. Не раздувайте документацию.
Симулируйте чужую проверку: после сборки capstone/ отложите работу на час, а затем попробуйте ответить на 5 контрольных вопросов, глядя только на ваши файлы, без обращения к истории чата с ИИ.
Если застряли на артефакте, возвращайтесь к соответствующей главе (1-12), находя блок 'Как это попадает в capstone/'.
Дополнительные ресурсы: Examples/templates/capstone-dossier.md: Эталонный пример (золотой путь), демонстрирующий идеальный баланс детализации для зачета.
Часть 00: production-lab: Базовая лабораторная рамка AgentClinic-production. Обязательно к прочтению, если контекст кажется утерянным.
Часть 11: real-api-deployment: Инструкции по запуску runnable-скриптов для основного кейса high_memory_usage.
Часть 08: multiagent-tribunal: Теория и практика ведения файлового арбитража, дуэлей и работы с прецедентами для кейса autoscale_200pct.
Резюме: Практический зачет 'Собрать production SDD-контур' — это проверка вашей способности внедрить культуру доказательности в процессы ИИ-агентов. Вы научились формировать компактный, воспроизводимый пакет артефактов (capstone/), который связывает инциденты, дефекты, конституцию и валидацию в единый проверяемый маршрут. Ключевой вывод: готовность к production подтверждается не идеальными метриками или объемом документации, а наличием прозрачного провенанса, работающих блокировок и четких ответов на вопрос 'Почему это безопасно?'.