# Что уточнить в докладе

Основная логика доклада сохраняется: спецификация помогает удерживать договорённости, но не гарантирует правильное взаимодействие сервисов. Явные правила и проверки закрывают часть рисков; работу всей цепочки нужно подтверждать отдельно.

Ниже — семь главных замечаний и короткие уточнения для выступления. Они не требуют менять слайды. Номера относятся к 35 слайдам презентации, а не к страницам PDF. Проверены слайды и заметки; исходные прогоны и реализации инструментов заново не проверялись.

## 1. Проверки плана существуют

**Слайды 7 и 12 · Уточнить предмет критики**

**Проблема.** «Плана не проверяет никто» расходится с собственными заметками: там указан `/speckit.analyze`, который сверяет spec, plan и tasks до реализации. Отсутствие эталонного плана тоже не мешает проверять требования и ограничения.

**Что сказать:**

> Проверки планов существуют. Мой вопрос — проверяют ли они правила взаимодействия конкретных сервисов: кто меняет состояние, как доставляется событие и что происходит при повторе. Согласованности документов для этого недостаточно.

Так сохраняется причина добавлять архитектурную проверку, без утверждения, что другие инструменты вообще не проверяют планы.

## 2. Рост средних не доказывает эффект инструмента

**Слайды 13, 19–20 и 28 · Обозначить границы замера**

**Проблема.** Фраза «меняются только процесс и модель» слишком сильная. По заметкам серии различались неделями запуска, версиями клиентов и изоляцией. У Gemini в контрольной серии план писала другая модель. На каждую конфигурацию приходится один прогон; усреднение по шести моделям не устраняет эти различия.

**Что сказать перед таблицей:**

> Это один стенд, одна задача и один прогон на конфигурацию. Условия серий немного различались, у Gemini в контрольной серии был другой планировщик. Средние описывают полученные решения; отдельно измеренного эффекта инструмента здесь нет.

Важные границы: опорные прогоны использованы для настройки оценщика; расхождение двух оценщиков с разными промптами не измеряет чистое согласие между ними. Из этих серий нельзя выводить общий рейтинг процессов или обещать такой же прирост в следующем запуске.

**Сохранить главный результат:** среднее покрытие чеклиста выросло, но полных сценариев по ревью осталось **по одному на серию**. Максимальный чеклист вырос с 79 до 95 %, поэтому «верхняя граница не сдвинулась» нужно относить именно к числу полных сценариев.

## 3. «Сценарий работает» — заключение ревьюера

**Слайды 10, 20–21 и 28 · Разделить способы проверки**

**Проблема.** «Да» в таблице можно принять за успешный запуск всей системы. Фактически сценарий оценивали по коду и тестам; подтверждённого сквозного запуска у таблицы нет. Это уже пояснено в заметках, но оговорка нужна до первого показа результатов.

**Что сказать:**

> «Да» означает, что ревьюер проследил выбранную цепочку: отказ, переназначение, новый оффер. Это не результат сквозного запуска и не отсутствие остальных ошибок.

Успешный `go test` подтверждает только имеющиеся проверки. В серии OpenSpec три модели не добавили тестов, остальные добавили юнит-тесты. Отсутствие сквозного запуска само по себе не доказывает сбой: его обосновывают конкретные дефекты.

На слайде 10 фраза «e2e не ловят дубли, гонки и редкие ветки» тоже требует ограничения:

> Такие случаи можно проверить, если заранее заложить их в тесты. Зелёный обычный проход не подтверждает это покрытие.

Вместо «каждый сервис написан правильно» точнее говорить «локальные проверки проходят»: ошибка может находиться в одном сервисе и проявляться на стыке.

## 4. Нужно уточнить формулу процентов

**Слайды 19–20 и 28 · Проверить исходную рубрику**

**Проблема.** Метрика объяснена как число выполненных требований из 21. При одинаковом весе и бинарном зачёте шаг равен примерно 4,76 процентного пункта. Например, 64, 79 и 93 % после обычного округления так не получаются.

Возможно, есть частичный зачёт, веса или другая агрегация. Это не доказывает ошибку оценок, но формула в материалах не раскрыта. **Средние по показанным процентам посчитаны верно:** 65,7 → 80,2 → 88,3 %.

**До выступления:** уточнить знаменатель, веса, частичный зачёт и округление; подготовить один пример расчёта строки.

**Пока формула не подтверждена:**

> Это процентная оценка покрытия чеклиста по ревью. Переводить её в целое число полностью выполненных требований по этой таблице нельзя.

Если частичный зачёт подтвердится, назвать его прямо. Одной речевой оговоркой вопрос к формуле окончательно не закрыть.

## 5. Неизменный файл не доказывает отсутствие ревью

**Слайд 23 · Разделить наблюдение и вывод**

**Проблема.** Одна сохранённая версия плана означает, что в истории нет его содержательных изменений. План могли проверить и оставить прежним. Для вывода «дефект родился на плане» нужно показать конкретный пропуск плана и его продолжение в коде.

Есть и стыковка источников: слева показана история контрольной серии и пример Sonnet в superpowers, справа — самоотчёт Sonnet уже из archspec. Отчёт и ревью справа относятся к одному прогону, но две половины слайда — к разным сериям.

**Что сказать:**

> В сохранённых планах не видно содержательных исправлений. Некоторые существенные правила были пропущены уже до кода. Справа пример из следующей серии, с archspec: добавленный процесс тоже пропустил ошибки.

Свежий контекст второго агента полезен, но сам по себе не гарантирует независимости предположений и полноты проверки.

## 6. Генерация удерживает диаграмму рядом с YAML

**Слайд 27 · Ограничить гарантию**

**Проблема.** Из «диаграмма — выход генератора» не следует «устареть не может». Генератор может точно воспроизвести устаревшую карту. Проверка `YAML → диаграмма` не доказывает соответствие `YAML → код`.

**Что сказать:**

> При активной проверке генерации диаграмма не может незаметно разойтись с YAML. Актуальность самого YAML относительно кода проверяется отдельно.

Простой контрпример: поведение сервиса изменили, карту оставили прежней, диаграмму пересобрали. Генерация корректна, описание системы уже устарело.

## 7. «Четыре требования закрыты» объединяет разные гарантии

**Слайды 12, 25–26, 29–30 и 33 · Назвать, что именно проверяется**

**Проблема.** Наличие механизма, инструкция агенту и исполняемая проверка дают разные гарантии. На слайде 29 это уже видно: поле ключа заполнено, но значение неверно; файл теста есть, но проверка риска не подтверждена.

| Что предусмотрено | Где проходит граница |
|---|---|
| Схема и обязательные поля | Не доказывают смысл значений. `key_source` остаётся свободной строкой |
| Уточнения и ревью плана | Выполняются агентом по инструкции; это не неизбежная проверка скриптом |
| Обход карт обеих сторон | Не гарантирует полноту карт и совместное поведение сервисов |
| Git-хуки | Автоматически запускают свой набор проверок. Остальные команды требуют вызова |
| Рост чеклиста у Gemini | Не означает рабочую фичу: ветка не собралась |

**Что сказать на слайде 30:**

> Для четырёх требований предусмотрены механизмы. Часть исполняют скрипты, часть выполняют агенты. Полноту поведения они пока не гарантируют.

Уточнить и время запуска: на этапе плана работает ревью агента; `validate` и `check-architecture` в описанном процессе идут после реализации. **«До первого коммита» не равно «до кода».** Существование файла теста или изменение ADR также не подтверждает их содержание.

**Для финала вместо «закрывает класс ошибок целиком»:**

> Часть структурных нарушений можно блокировать автоматически. Проверку каждого существенного риска нужно связать с требованием плана и конкретным тестом поведения.

## Короткие уточнения по ходу доклада

| Слайды | Что важно сохранить в объяснении |
|---|---|
| **1, 8–9** | Один учебный стенд показывает механизм сбоя, но не доказывает, что SDD в целом хуже работает в микросервисах. Сравнения с монолитом нет. Потеря контекста — мотивация; её влияние отдельно не измерено |
| **4** | 125–150 тысяч токенов нельзя подавать как универсальный порог. Короткая сессия помогает управлять контекстом, но не гарантирует правильный ответ |
| **5–7** | Требования описывают поведение, план — способ изменения, системная спека — действующие правила. Обновление спеки через archive и проверка её соответствия коду — разные операции |
| **8** | «Минуты → часы → дни → недели» — иллюстрация объёма переделки. Время, экономия и полная стоимость процесса в замере не измерены |
| **11, 32** | «Локальная» не означает «слабая». Практики переносимы между моделями, но качество их исполнения зависит от модели |
| **16, 22** | Расстояние разрешает равенство **рейтингов**. В заметках к 22 сказано «при равных навыках» — в речи придерживаться постановки слайда 16 |
| **18, 22** | `task_id + attempt` различает попытки в подборе, `match_id` — результаты подбора в уведомлениях. Новая попытка получает новый результат; повторная доставка сохраняет ID |
| **18** | Запрет обходить фасад проверяли ревью. Kubernetes с NetworkPolicy в этом замере не запускали |
| **22** | «Все ловушки у пяти моделей» требует сверки состава ловушек. Указанные частоты города и потери оффера не поддерживают буквальное «все семь у каждой из пяти». До сверки использовать частоты конкретных дефектов |
| **30** | OpenSpec с дополнительными проверками — отдельный опыт вне сравнительной таблицы трёх процессов |

## Перед выходом на сцену

1. Уточнить формулу процентов и состав «всех ловушек» по исходным оценкам.
2. Перед таблицами назвать один прогон на конфигурацию и оценку сценария по ревью.
3. На слайдах 7, 27 и 30 ограничить обещания проверок.
4. Сохранить финальный вывод: явные правила дают предмет для проверки, но полноту поведения нужно подтверждать отдельно.