Основная логика доклада сохраняется: спецификация помогает удерживать договорённости, но не гарантирует правильное взаимодействие сервисов. Явные правила и проверки закрывают часть рисков; работу всей цепочки нужно подтверждать отдельно.
Ниже — семь главных замечаний и короткие уточнения для выступления. Они не требуют менять слайды. Номера относятся к 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 с дополнительными проверками — отдельный опыт вне сравнительной таблицы трёх процессов |
Перед выходом на сцену
- Уточнить формулу процентов и состав «всех ловушек» по исходным оценкам.
- Перед таблицами назвать один прогон на конфигурацию и оценку сценария по ревью.
- На слайдах 7, 27 и 30 ограничить обещания проверок.
- Сохранить финальный вывод: явные правила дают предмет для проверки, но полноту поведения нужно подтверждать отдельно.