Тема: Прикладной том. Production SDD для Qwen Code CLI
Уровень сложности: Средний
Расчётное время изучения: 40-60 часов (первый проход), 80-120 часов (с полным треком и практическим зачётом)
Предварительные требования: Прохождение первого тома учебника (book/) — базовый цикл SDD на AgentClinic
Понимание структуры requirements.md, plan.md, validation.md, QWEN.md
Работа с границами фичи, отрицательными требованиями и проверкой фактами
Базовые навыки работы с командной строкой и bash-скриптами
Опыт работы с LLM-инструментами (желательно Qwen Code CLI)
Понимание основ CI/CD и production-инфраструктуры
Цели обучения: По завершении обучения студент сможет восстановить спецификацию из legacy-кода и оформить провенанс в genealogy.md для одного production-кейса
Студент сможет провести диагностику дефектов спецификации, создать poisoned/fixed-пару и оформить constitution.md с immutable- и mutable-правилами
Студент сможет запустить и интерпретировать результаты LLM-дуэли, мутационного тестирования и Spec CI, зафиксировав контрольные факты в validation.md
Студент сможет принять или отклонить теневую спецификацию, оценить бюджетный риск яруса моделей и оформить judgment.md с evidence_ref
Студент сможет собрать итоговый пакет capstone/README.md, проверить его на антипаттерны и подготовить три риска в форме blocker/owner/next_check
Обзор: Прикладной том учебника переносит базовый цикл SDD (Specification-Driven Development) из первого тома в production-сценарии. Если первый том учил конституцию, спецификацию фичи, план, проверяемые факты, реализацию, ревью и перепланирование на платформе AgentClinic, то второй том работает с legacy-следами, валидаторами, многоагентными проверками, Spec CI, метриками, бюджетами моделей и ограниченной авто-ремедиацией. Главное правило: первый проход должен оставить один маленький проверяемый след в capstone/, а не познакомить со всей терминологией. Основной зачётный кейс — high_memory_usage; остальные кейсы (autoscale_200pct, node_not_ready, appointment_latency, cdn_error_budget_burn) используются для демонстрации специфических механизмов с последующим переносом принципа в основной кейс одной строкой.
Ключевые концепции: Agentclinic-production: Расширение базового AgentClinic для production-сценариев: работа с существующим кодом, а не greenfield-разработка. Требует восстановления требований из legacy, а не написания с нуля.
Genealogy.md: Артефакт провенанса: откуда взялось требование. Фиксирует источник (пост-мортем, тикет, интервью), уровень неопределённости и цепочку преобразований от сырого сигнала до спецификации.
Poisoned-spec.md / fixed-spec.md: Пара артефактов диагностики дефектов спецификации. Poisoned — спецификация с скрытым дефектом (противоречие, неявное предположение, конфликт приоритетов); fixed — исправленная версия с явным обоснованием.
Constitution.md: Проектная конституция: правила, ограничивающие действия агента. Immutable-правила — неизменные без референдума (например, 'не трогать production-конфигурацию в рабочие часы'). Mutable-правила — с ttl и rollback_condition, могут адаптироваться по мере накопления прецедентов.
Llm-дуэль (verifier vs implementor): Многоагентная проверка формальных утверждений. Верификатор ищет контрпримеры к Then-утверждению спецификации; Имплементор защищает. Результат — контрпример или next_guard (условие, при котором спецификация нарушается).
Stress-mutator / мутационное тестирование спецификаций: Автоматическая генерация мутантов спецификации для проверки robustness валидаторов. Smoke-результат показывает, какие мутанты прошли незамеченными — это вектор иммунитета валидатора.
Теневые спецификации (shadow specs): Кандидатные спецификации, генерируемые агентом параллельно основной. Проходят отбор по критериям: не противоречат конституции, покрывают новые факты, не дублируют существующее. Принятые — в capstone/README.md, отклонённые — с причиной.
Spec ci: Specification CI: спецификация как исполняемый артефакт. Проверяет покрытие требований, схему контрактов, наличие validation.md. Выдаёт PASS/BLOCK на каждом коммите.
Файловый арбитраж (multiagent tribunal): Ролевая модель ревью спорных изменений: Safety (безопасность), Liveness (функциональность), Economy (ресурсы). Результат — judgment.md с verdict, evidence_ref и dissenting opinion если есть.
Ярусные бюджеты (tier budgeting): Маршрутизация задач по моделям разного уровня и стоимости. Дешёвый ярус — быстрые проверки, дорогой — арбитраж. token_health отслеживает расход; при отказе дешёвого яруса — fallback или ручной эскалация.
Защита от гудхарта: Парная метрика: KPI (целевая) + guard-метрика (сторожевая, предотвращающая игру системы). Например: KPI 'время ремедиации' + guard 'количество ложных срабатываний ремедиации'.
Readiness / dry-run: Production API интеграция: readiness-метрика показывает готовность контура к деплою (например, 23/25 проверок пройдено). Dry-run — прогон без побочных эффектов для валидации перед реальным применением.
Antipattern-audit.md: Три диагностических риска в форме blocker / owner / next_check после прохода антипаттернов. Не превращение каждого антипаттерна в CI-политику — это полный трек.
Capstone/readme.md: Итоговая сборка всех артефактов по одному кейсу. Должен читаться без истории чата как самостоятельный пакет доказательств от legacy-следа до production-ready решения.
Важные даты: 2026-05-20: Версия v1.0 прикладного тома — проверена и зафиксирована. Дата отсечки для материалов учебника.
Глава 0: Начало работы — выбор кейса high_memory_usage, создание пустого capstone/
Главы 1-3: Формирование базовых артефактов: genealogy.md, poisoned/fixed-пара, constitution.md
Главы 4-5: Получение контрпримера и smoke-результата stress-mutator
Главы 6-7: Отбор теневых кандидатов, запуск Spec CI
Главы 8-9: Сборка judgment.md, проигрыш отказа дешёвого яруса
Главы 10-11: Проверка guard-метрик, readiness и dry-run для high_memory_usage
Глава 12: Запись трёх рисков blocker/owner/next_check
Глава 13: Сборка итогового capstone/README.md и практический зачёт
Практические упражнения: Название: Восстановление требования из пост-мортема
Проблема: Дан фрагмент пост-мортема инцидента node_not_ready: 'В 03:15 нода node-7 ушла в NotReady, поды не эвакуировались за 5 минут, клиенты получили таймауты. Вручную drain + reboot помогли за 12 минут. Автоэвакуация не сработала из-за taint custom-scheduler=protected'. Восстановите одно проверяемое требование и оформите genealogy.md. Укажите уровень неопределённости (high/medium/low) и обоснуйте.
Решение: 1. Выделите сырой сигнал: автоэвакуация не сработала на ноде с taint custom-scheduler=protected. 2. Преобразуйте в проверяемое требование: 'Если нода имеет taint custom-scheduler=protected, то автоматическая эвакуация подов должна быть отключена или заменена на ручной workflow с уведомлением on-call'. 3. В genealogy.md запишите: source='post-mortem-2024-03-15-node7', raw_signal='auto-evacuation skipped due to protected taint', uncertainty='medium' (не ясно, intentional ли это или bug), requirement='protected-taint-evacuation-policy', derivation_steps=['incident report', 'taint analysis', 'policy decision']. 4. Обоснование medium: один инцидент, нет подтверждения что поведение intentional, нужен replay или дополнительный кейс для low.
Сложность: intermediate
Название: Создание poisoned/fixed-пары для конфликта приоритетов
Проблема: Дана спецификация: 'Given система бронирования приёмов; When количество одновременных запросов превышает 100; Then все запросы обрабатываются в порядке FIFO с максимальной задержкой 2 секунды'. Найдите дефект, создайте poisoned-spec.md и fixed-spec.md. Покажите обратный прогон (backwards walk) от дефекта к корню.
Решение: 1. Дефект: неявное предположение что 'все запросы' равнозначны. VIP-пациенты и emergency-запросы не должны ждать FIFO. 2. Poisoned-spec.md: сохраните оригинал, добавьте метку DEFECT='priority-blindness', trigger='emergency request during peak load', expected_failure='VIP patient waits 2+ seconds while routine appointment processed'. 3. Fixed-spec.md: 'Given система бронирования приёмов с приоритизированными очередями (routine, urgent, emergency); When количество одновременных запросов превышает 100; Then emergency-запросы обрабатываются с задержкой ≤ 500ms, urgent ≤ 1s, routine — FIFO с задержкой ≤ 2s при наличии capacity'. 4. Backwards walk: expected failure (VIP timeout) → причина (нет приоритетов в Then) → причина (нет классификации в Given) → корень (доменное предположение 'все пациенты равны', неверное для healthcare).
Сложность: intermediate
Название: Запуск stress-mutator и интерпретация иммунитета
Проблема: В директории book2/examples/ запустите bash smoke_all.sh. Найдите вывод stress-mutator для кейса payment_latency_spike. Сколько мутантов прошло незамеченными? Какой вектор иммунитета валидатора это указывает? Запишите результат в validation.md.
Решение: 1. Перейдите в book2/examples/ и выполните bash smoke_all.sh. 2. Найдите блок [stress-mutator] payment_latency_spike. Пример ожидаемого вывода: 'MUTANTS_GENERATED=12, CAUGHT=9, ESCAPED=3, ESCAPE_VECTOR=timing-assertion-weakness'. 3. ESCAPED=3 указывает что валидатор не проверяет граничные условия времени достаточно строго. Вектор иммунитета: 'добавить строгую проверку P99 < 200ms при spike > 500% baseline, а не только среднего'. 4. В validation.md добавьте: 'Мутационный иммунитет: stress-mutator payment_latency_spike, 3/12 escaped, вектор timing-assertion-weakness. Усиление: строгий P99-guard при spike-условии'.
Сложность: intermediate
Название: Отбор теневой спецификации: принять или отклонить
Проблема: Даны два теневых кандидата для кейса voice_handoff: A) 'При передаче голосового вызова между операторами сохраняется полная аудиозапись разговора' и B) 'При передаче голосового вызова между операторами сохраняется аудиозапись только с момента подтверждения принимающим оператором'. Конституция проекта содержит immutable-правило: 'Полная аудиозапись всех клиентских взаимодействий хранится 7 лет для compliance'. Принять или отклонить каждый кандидат? Обоснуйте и запишите в capstone/README.md блок Shadow notes.
Решение: 1. Кандидат A: проверяем на конституции — не противоречит immutable-правилу (полная запись). Покрывает новый факт (handoff как часть взаимодействия). Не дублирует существующее (ранее handoff не был явно специфицирован). РЕШЕНИЕ: принять. 2. Кандидат B: противоречит immutable-правилу ('только с момента подтверждения' ≠ 'полная аудиозапись всех взаимодействий'). РЕШЕНИЕ: отклонить, причина 'нарушает constitution.md §3.1 immutable-правило full-recording-compliance'. 3. В capstone/README.md блок Shadow notes: 'Accepted: shadow.p0.voice_handoff.full-recording — соответствует конституции, покрывает handoff-gap. Rejected: shadow.p0.voice_handoff.partial-recording — нарушает immutable full-recording-compliance. Прецедент: приоритет compliance над оптимизацией хранения'.
Сложность: intermediate
Название: Оценка бюджетного риска и оформление budget-note.md
Проблема: Сценарий: дешёвый ярус (Qwen2.5-7B-instruct, $0.10/1K tokens) отказал при проверке сложного контракта autoscale_200pct — выдал ложное PASS на нарушенном Then-условии. Дорогой ярус (Qwen2.5-72B-instruct, $1.20/1K tokens) поймал ошибку. Текущий token_health: 3400 tokens осталось в дневном бюджете дешёвого яруса, при этом нужно проверить 15 спецификаций. Оформите budget-note.md с бюджетным риском и сценарием отказа.
Решение: 1. Рассчитайте риск: 15 спецификаций × средний расход 400 tokens = 6000 tokens needed, доступно 3400. Дефицит: 2600 tokens (43% недостаёт). 2. Вероятность отказа дешёвого яруса: высокая — уже один ложный PASS показал что 7B-модель не справляется с масштабными контрактами. 3. Сценарий отказа: при исчерпании дешёвого бюджета fallback на дорогой ярус увеличит стоимость проверки с $0.60 до $7.20 (12×). При недостатке и дорогого — ручная эскалация с задержкой 4-24 часа. 4. budget-note.md: 'tier: cheap, model: Qwen2.5-7B-instruct, token_health: 3400/6000 needed, risk_level: critical, failure_mode: false_PASS_on_scale_contracts, fallback: expensive_tier_with_cost_spike, mitigation: pre-filter_scale_contracts_to_expensive_tier, owner: on-call-SRE, next_check: 2026-05-21T09:00Z'.
Сложность: advanced
Название: Парная anti-Goodhart-метрика для KPI ремедиации
Проблема: KPI команды SRE: 'Среднее время ремедиации инцидента (MTTR) ≤ 15 минут'. Какая guard-метрика предотвратит игру этой метрикой? Оформите goodhart-note.md для кейса cdn_error_budget_burn.
Решение: 1. Игровая стратегия: автоматически 'ремедировать' инциденты маркером resolved без фиксации, чтобы MTTR выглядел хорошо. 2. Guard-метрика: 'Процент ремедиаций с подтверждённым фиксом в течение 24 часов' (confirmed_fix_rate) + 'Процент повторных инцидентов по той же причине в течение 7 дней' (recurrence_rate). 3. Условие тревоги: если MTTR < 15min но confirmed_fix_rate < 80% или recurrence_rate > 15% — аварийный режим, запрет автоматической ремедиации без человеческого подтверждения. 4. goodhart-note.md: 'KPI: MTTR ≤ 15min, guard: confirmed_fix_rate ≥ 80% AND recurrence_rate ≤ 15%, emergency_mode_trigger: MTTR_green_but_guard_red, action: disable_auto_remediation_require_human_approval, case: cdn_error_budget_burn_2024-11'.
Сложность: intermediate
Кейсы: Название: Внедрение Spec CI в платёжном контуре fintech-стартапа
Сценарий: Fintech-стартап с 50 микросервисами обрабатывающих 10M транзакций/день. Команда из 8 разработчиков, 2 SRE. Ранее использовали ad-hoc спецификации в Confluence, которые устаревали за 2-3 недели. После инцидента с двойным списанием (потеря $340K компенсаций) руководство потребовало 'проверяемые требования на каждое изменение'.
Задача: Legacy-код платёжного шлюза на 8 лет — нет актуальных спецификаций, только комментарии в коде и устные договорённости. Разработчики сопротивлялись 'лишней бюрократии'. CI-пайплайн занимал 23 минуты, добавление Spec CI рисковало увеличить до 40+. Нужно было показать ценность без блокировки delivery.
Решение: Применён подход прикладного тома: главы 1-7 в сжатом виде. 1) Выбран один критичный кейс — payment_latency_spike (глава 5). 2) Восстановлена genealogy.md из пост-мортема двойного списания (глава 1). 3) Найдена poisoned-spec: 'при latency > 2s retry автоматически' без idempotency-key — создаёт двойное списание (глава 2). 4) Создана constitution.md с immutable-правилом 'все retry платежей требуют idempotency-key' (глава 3). 5) LLM-дуэль нашла контрпример: retry при network_timeout vs retry при insufficient_funds — разное поведение (глава 4). 6) Stress-mutator проверил валидатор: 2/8 мутантов прошли — усилена проверка idempotency (глава 5). 7) Spec CI внедрён только на payment-сервисы, не на все 50 — строка в CI: 'spec-ci --scope=payment-* --block-on-uncovered' (глава 7). Время: +4 минуты к пайплайну.
Результат: Через 3 месяца: 0 инцидентов двойного списания (было 4 за полгода до). Spec CI поймал 12 непокрытых требований до production. Команда разработчиков оценила — 'видим зачем это, не просто бумажки'. Расширение на остальные сервисы инициировано разработчиками, не руководством. Среднее время добавления спецификации сократилось с 45 минут до 12 (шаблоны из capstone/).
Извлечённые уроки: Начинать с одного критичного кейса, а не 'внедрить везде' — принцип 'один маленький проверяемый след' работает и для организационных изменений
Poisoned-spec с реальным финансовым ущербом убедительнее любого тренинга — 'вот где мы уже ошиблись'
Spec CI на подмножестве сервисов даёт ценность быстрее, чем ожидание полного покрытия
Разработчики принимают процесс, когда видят что он ловит реальные баги до production, а не когда им 'продиктовано сверху'
Связанные концепции: genealogy.md
poisoned-spec.md / fixed-spec.md
constitution.md
LLM-дуэль
stress-mutator
Spec CI
capstone/README.md
Название: Арбитраж спорного autoscale-изменения в облачной платформе
Сценарий: Облачная платформа с 2000+ Kubernetes-кластеров. Команда platform-SRE предложила изменение: 'При CPU > 80% на 5 минут — автомасштабирование +200% нод'. Изменение спорное: Liveness-команда считает что это спасёт от cascade failures; Safety-команда — что 200% резкий скачок создаёт риск overprovisioning и cost-spike при кратковременных burst'ах.
Задача: Классический конфликт приоритетов: доступность vs экономика. Ранее подобные решения принимал старший SRE единолично — создавалось ощущение 'диктатуры', решения не воспроизводились. Нужен был формальный процесс с доказательствами, пригодный для аудита и обучения новых инженеров.
Решение: Применён файловый арбитраж (глава 8) с ролевой моделью. 1) Safety подготовила контрпример: burst на 4 минуты 50 секунд — не должен триггерить +200%, но при текущей спецификации триггерит. 2) Liveness подготовила evidence: история инцидентов, где 80% на 6+ минут приводила к cascade failure в 73% случаев. 3) Economy рассчитала: стоимость false-positive (лишние ноды на 10 минут) vs стоимость cascade failure (минуты downtime × SLA-штрафы). 4) judgment.md: verdict='CONDITIONAL_APPROVE', условие 'добавить guard-метрику burst_duration < 5min AND rate_of_change > 50%/min для исключения кратковременных spike'ов', evidence_ref=['safety-counterexample-burst-290s', 'liveness-historical-73pct', 'economy-cost-model-v2']. Dissenting opinion Safety: 'предпочёл бы 70% порог, но принимаю 80% с guard-условием'.
Результат: Изменение внедрено с guard-условием. Через 2 месяца: 3 случая срабатывания guard-условия (не было масштабирования), все подтверждены как кратковременные burst'ы. 1 случай где 80% держалось 7 минут — масштабирование сработало, предотвратило потенциальный cascade failure. Стоимость ложных срабатываний снизилась на 67% по сравнению с первоначальным предложением. Процесс арбитража принят как стандарт для всех спорных изменений > $10K потенциального impact'а.
Извлечённые уроки: Ролевой арбитраж с dissenting opinion создаёт воспроизводимые прецеденты — новые инженеры учатся на истории, не на авторитете
Контрпример + исторические данные + экономическая модель = три вида evidence, которые вместе убедительнее любого одного
CONDITIONAL_APPROVE лучше бинарного approve/reject — сохраняет скорость decision-making при добавлении guard-условий
Dissenting opinion в judgment.md не ослабляет решение, а укрепляет его легитимность — показывает что альтернативы рассмотрены
Связанные концепции: файловый арбитраж
judgment.md
evidence_ref
роли Safety/Liveness/Economy
guard-метрика
dissenting opinion
Название: Защита от Гудхарта при автоматизации ремедиации CDN-инцидентов
Сценарий: Крупный медиа-стриминговый сервис с глобальным CDN. KPI: 'Время ремедиации CDN-инцидента ≤ 5 минут'. Достигнуто автоматической ремедиацией: при error_rate > 5% — автоматический purge cache + переключение на origin. MTTR снизился с 12 минут до 4.
Задача: Через 3 месяца после внедрения: MTTR = 3.2 минуты, но клиенты жалуются на buffering. Расследование: автоматическая ремедиация при error_rate > 5% срабатывала на ложных spike'ах (measurement error, не реальные 5xx). Purge cache при ложном срабатывании создавал thundering herd на origin, ухудшая реальный UX. Команда 'играла' KPI: MTTR отличный, реальный сервис ухудшился.
Решение: Применён подход главы 10. 1) Диагностика: KPI (MTTR) 'лжёт' — оптимизация его привела к ухудшению реального результата. 2) Guard-метрика: 'Процент ремедиаций с подтверждённым реальным 5xx (не measurement error)' + 'Origin load spike после ремедиации < 150% baseline'. 3) Аварийный режим: при guard_red + KPI_green — disable auto-remediation, require human confirmation, alert on-call. 4) goodhart-note.md: 'KPI: MTTR ≤ 5min, guard: confirmed_5xx_rate ≥ 90% AND origin_post_remediation_load ≤ 150%, emergency_mode: 3 consecutive guard_red in 24h'. 5) Дополнительно: добавлен dry-run режим (глава 11) — при новых типах инцидентов ремедиация отрабатывает без побочных эффектов, результат проверяется человеком.
Результат: После внедрения guard-метрик: MTTR вырос до 6.5 минут (хуже KPI), но подтверждённых реальных ремедиаций — 94% (vs 61% ранее). Жалобы на buffering снизились на 78%. Команда перестала 'играть' метрику — стало невыгодно. Руководство пересмотрело bonus structure: теперь 50% веса на guard-метрики, 50% на KPI. Dry-run для новых типов инцидентов предотвратил 2 потенциальных ложных ремедиации за первый месяц.
Извлечённые уроки: KPI без guard-метрики активно вредит — инженеры рационально оптимизируют измеряемое, даже если оно не совпадает с реальным результатом
Аварийный режим должен быть автоматическим — 'require human confirmation' при guard_red должно срабатывать без дополнительных решений
Dry-run для новых типов инцидентов — незаменим при расширении автоматизации, иначе каждый новый кейс — потенциальная ловушка Гудхарта
Bonus structure должен включать guard-метрики иначе KPI победит — организационная инженерия важнее технической
Связанные концепции: защита от Гудхарта
KPI и guard-метрика
goodhart-note.md
аварийный режим
dry-run
readiness.md
Советы по изучению: Никогда не читайте главу линейно от начала до конца. Сначала найдите блок 'Перед чтением', затем выполните минимальный учебный сценарий, потом вернитесь к 'Ключевым идеям'. Только после этого — калибровки, [project script] и [conceptual interface].
Держите пять вопросов при чтении каждой главы: Опора из первого тома? Минимальный учебный сценарий? Контрольный факт? Как попадает в capstone/? Что относится к полному треку?
Правило одного нового термина: если глава вводит пять названий, но только одно нужно для текущего файла capstone/ — запомните одно, остальное отложите до второго прохода.
Создайте физическую или цифровую 'сквозную карту' на стене/экране: какая глава → какой файл capstone/ → что именно туда пишется. Проверяйте по ней после каждой главы.
Для глав с чужими кейсами (не high_memory_usage) сразу пишите строку переноса: 'Принцип X из кейса Y защищает high_memory_usage, потому что...'. Если не пишете — глава не закрыта.
Запускайте bash book2/examples/smoke_all.sh после каждой главы с runnable-примерами. Ожидаемые блокировки — часть обучения, не ошибка. Если пример не блокируется где должен — проверьте версию.
Используйте шаблон capstone-dossier.md как эталон минимальности. Если ваш пакет длиннее в 3 раза — скорее всего, вы захватили полный трек в первый проход.
Для визуальных учеников: рисуйте конвейер артефактов genealogy → poisoned/fixed → constitution → validation → judgment → budget → goodhart → readiness → antipattern. Отмечайте, где вы сейчас.
Для аудиальных учеников: озвучивайте контрольные факты вслух перед записью в файл. Если звучит расплывчато — факт недостаточно проверяем.
Для кинестетических учеников: физически перемещайте 'карточки' артефактов по доске от 'сырой идеи' к 'проверено в capstone/'. Тактильный прогресс мотивирует.
Формируйте учебную группу из 2-3 человек: один читает главу, объясняет другим минимальный сценарий, третий проверяет capstone/. Обучение через обучение ускоряет усвоение в 2-3 раза.
Не пытайтесь достичь 'production-ready внедрение' на первом проходе. Цель первого прохода — воспроизводимый контур для одного кейса. Полный трек — отдельный проект после зачёта.
Дополнительные ресурсы: Book2/examples/readme.md: Локальные smoke-прогоны и шаблоны для всех глав. Обязательный ресурс для практики.
Book2/examples/templates/capstone-dossier.md: Заполненный эталон минимального пакета по high_memory_usage. Показывает, насколько коротким может быть хороший первый проход.
Book2/glossary.md: Определения всех терминов второго тома. Используйте как справочник, не как текст для заучивания.
Book2/appendix-a-bridges-to-book.md: Мосты к первому тому — предпосылки и полная доменная карта AgentClinic. Полезно при возникновении вопросов 'а где это объяснялось раньше'.
Book2/appendix-b-qwen-code-compatibility.md: Встроенные команды, пользовательские команды и проектные скрипты Qwen Code. Необходимо для адаптации runnable-примеров под вашу версию CLI.
Book2/appendix-c-checklists.md: Чек-листы для Spec CI, арбитража, метрик и production-готовности. Используйте для самопроверки перед зачётом.
Book2/appendix-d-threshold-calibration.md: Таблицы 'Низкий / По умолчанию / Высокий', упражнения по сдвигу порогов. Отложите до второго прохода или реального внедрения.
Book2/instructor.md: Форматы воркшопов и типичные ошибки. Полезно если вы обучаете команду или проходите в группе.
Book2/changelog.md: История редакций текста. Проверяйте актуальность при использовании материалов.
Исходный документ курса (readme прикладного тома): Базовый документ, на основе которого построен этот гайд. Возвращайтесь к нему для проверки соответствия вашего прогресса плану.
Резюме: Прикладной том Production SDD для Qwen Code CLI учит переносить базовый цикл спецификационно-управляемой разработки в реальные production-условия. Ключевой принцип — один маленький проверяемый след за проход: каждая глава добавляет ровно одну строку, файл или блокер в capstone/. Основной кейс high_memory_usage проходит через все этапы: восстановление требований из legacy (genealogy.md), диагностика дефектов (poisoned/fixed-пара), проектная конституция, LLM-дуэль и мутационное тестирование (validation.md), отбор теневых спецификаций, Spec CI, файловый арбитраж (judgment.md), ярусные бюджеты (budget-note.md), защиту метрик от Гудхарта (goodhart-note.md), readiness и dry-run (readiness.md), антипаттерны (antipattern-audit.md). Итог — воспроизводимый контур от следа до production-ready решения, понятный без истории чата. Первый проход требует дисциплины отсечения: полный трек — после зачёта, не вместо него.