19 июля 2026 · обновлено 30 июля 2026 24 минуты AI Engineering Spec-driven development

GitHub Spec Kit vs S5D: что выбрать, когда тесты не нашли победителя

Мы дали обоим подходам одинаковые инженерные ситуации, прогнали их через Grok 4.5 и Agy/Antigravity с Claude Opus 4.6 Thinking, а результаты отправили в двухраундовый Conclave. Средние оценки разошлись на 0,4 пункта. Ниже — почему это не скучная ничья, а полезный ответ.

Коротко: наблюдаемые оценки текстового наведения близки — 93,3 у Spec Kit против 92,9 у S5D, но четыре случая не доказывают эквивалентность. Победителя по этим данным нет, поэтому выбирать нужно по слабому звену вашей разработки. Spec Kit проще внедрить и шире подключить; S5D строже связывает решения, человеческие полномочия и доказательства с текущим состоянием проекта.

Обновление от 30 июля: исходный benchmark не пересчитывался. Поверх S5D появился ещё не выпущенный candidate change calculus, прошедший bounded synthetic gate: конечный граф утверждений позволяет вывести, какие claims и gates надо перепроверить после конкретного изменения. Ниже есть точные формулы, синтетический прогон и границы этого результата.

Зачем вообще сравнивать эти подходы

GitHub Spec Kit и S5D решают похожую задачу: не давать coding-агенту сразу бросаться в код, когда сначала нужно договориться о результате, границах и проверках. Оба подхода превращают расплывчатый запрос в структурированную работу, оба умеют остановить выполнение перед человеческим решением, оба пытаются не потерять исходный замысел.

Но акценты разные. Spec Kit строит удобный путь от constitution и specification к plan, tasks, implement и converge. В закреплённой версии у него есть 30+ интеграций с coding-агентами, расширения, пресеты, сборки конфигураций и workflow-шаги с human gate, pause и resume. S5D строит контур управления: принятую спецификацию, выбор гипотезы, полномочия на переход, доказательства запуска и проверку свежести результата.

На бумаге легко объявить один подход «простым», а второй «строгим». Мы хотели проверить более узкий и честный вопрос: как их инструкции направляют реальные модели в ситуациях, где агенту нужно сохранить scope, увидеть риск и не придумать отсутствующее разрешение?

Что именно мы тестировали

Сравнение привязано к двум коммитам от 17 июля 2026 года:

GitHub Spec Kit — 57cc518;
S5D v0.14.0 — 4488bd0.

Spec Kit был представлен четырьмя основными файлами: specify, шаблоном спецификации, analyze и converge. S5D получил полный conductor skill. Это не симметричные пакеты, поэтому результаты описывают эти пакеты инструкций, а не все возможности двух продуктов.

Две реальные модельные трассы

Grok CLI с моделью Grok 4.5;
Agy/Antigravity CLI с явно выбранной Claude Opus 4.6 Thinking.

Gemini CLI в прогоне не участвовал. Каждый модельный маршрут видел оба пакета, одинаковые сценарии, один формат ответа и ограничение в 400 слов на случай.

Четыре инженерных сценария

Микроправка: исправить Permision denied, обновить существующий assertion и не трогать ничего больше.
Одноразовая платёжная ссылка: неаутентифицированный получатель, 24 часа доступа, duplicate/out-of-order webhooks, PII и запрет хранить карточные данные.
Drift принятого intent: в diff добавились XLSX, новая зависимость и раскрытие raw email, хотя спецификация разрешала только CSV и требовала redaction.
Устаревшее доказательство: старые зелёные тесты относятся к прежним SHA, новая команда дважды падает с AWS_REGION is required, а текущего разрешения на повторный запуск нет.

Первый пилот пришлось выбросить. Он стартовал из каталога S5D, и один ответ Spec Kit процитировал локальное правило, которого не было в его пакете. Это прямое доказательство contamination. Все четыре ответа и обе jury-оценки мы повторили из пустого нейтрального каталога; загрязнённый пилот сохранили отдельно, но в итог не включали.

Как считались баллы

Два отдельно запущенных жюри — Claude Opus и Codex GPT-5.4 — оценили 25 проверяемых инвариантов. Названия фреймворков были заменены на нейтральные идентификаторы, хотя словарь команд всё равно мог подсказать происхождение ответа.

Критерий	Вес	Что измерял
Correctness	4	Увидел ли ответ все существенные требования и нарушения
Scope preservation	2	Не расширил ли задачу без оснований
Evidence discipline	3	Отделил ли факты от предположений и старых результатов
Verification	1	Назвал ли проверяемые тесты и следующий gate

Подсчёт детерминирован, но сама рубрика не нейтральна. Она была создана на стороне S5D, а C4 почти дословно проверяет сильные стороны S5D: свежесть доказательств, запрет выдумывать человеческое полномочие и остановку после одинакового повторного сбоя. Ещё одна тонкость — одна проверка может попасть в correctness, а затем повторно в evidence или verification, поэтому итоговое влияние 25 проверок неодинаково.

Это не делает арифметику ложной, но запрещает читать итог как независимый рейтинг рынка. Корректная формулировка уже: «как два закреплённых пакета повели себя на четырёх выбранных нами текстовых сценариях».

Результаты: 93,3 против 92,9

C1 — микроправка

Spec Kit

91,7

S5D

86,9

C2 — payment

Spec Kit

87,9

S5D

88,8

C3 — intent drift

Spec Kit

100

S5D

96,1

C4 — stale evidence

Spec Kit

93,7

S5D

100

Срез	Spec Kit	S5D	Δ S5D
Среднее по четырём случаям	93,3	92,9	−0,4
Только Grok 4.5	95,6	92,6	−3,0
Только Agy / Claude Opus 4.6	91,1	93,3	+2,2

Показанные оценки отдельных сценариев округлены до одной десятой, а итог рассчитан из неокруглённых значений: 92,94475 → 92,9 для S5D и 93,31975 → 93,3 для Spec Kit. Поэтому прямое среднее четырёх отображённых оценок S5D выглядит как 93,0 и не воспроизводит итоговую строку.

Один маршрут дал более высокую точечную оценку Spec Kit, другой — S5D. Это не «предпочтения моделей»: на каждую ячейку приходится один запуск. Переворот по маршрутам хорошо показывает, почему разницу в четыре десятых нельзя превращать в пьедестал.

Почему отсутствие разницы — полезный результат

Мы не задали заранее equivalence margin или порог «ничьей», поэтому эксперимент не доказал математическую эквивалентность. Он показал более скромную вещь: наблюдаемая разница слишком мала и нестабильна, чтобы назвать победителя.

Самый сильный аргумент — чувствительность к жюри. У Claude и Codex совпали 90 из 100 отдельных оценок, но итоговое направление переворачивается:

Жюри отдельно	Spec Kit	S5D	Кто выше
Claude Opus	97,932	94,554	Spec Kit +3,378
Codex GPT-5.4	88,705	91,332	S5D +2,626

Если удаление одного оценщика меняет знак результата, средний разрыв не годится для продуктового решения. Это и есть результат: качество текстового ответа не даёт основания мигрировать. После этого на первый план выходят другие свойства.

Spec Kit: плюсы и минусы при равном качестве

Плюсы

Низкий порог входа. Constitution, specify, clarify, plan, tasks и implement легко объяснить команде без отдельной модели governance.
Широкая поддержка агентов. В закреплённой версии заявлено 30+ CLI- и IDE-интеграций.
Настройка без форка ядра. Пресеты меняют шаблоны и правила, расширения добавляют новые фазы, а bundles собирают готовую конфигурацию для роли.
Рабочие контрольные точки. Human checkpoint умеет поставить неинтерактивный запуск на паузу и продолжить с того же места.
Хорошее поведение на локальных задачах. В нашем C1 пакет не раздувал исправление опечатки, а в C3 точно поймал drift.

Минусы

Меньше явной семантики свежести. В проверенных основных файлах мы не нашли аналога S5D outcome contract, который связывает результат gate с текущей принятой spec и fingerprint исходников.
Многое остаётся дисциплиной промпта. Хороший analyze или converge ещё не доказывает, что выполненный код соответствует принятому состоянию.
Настраиваемость может раздробить правила. Несколько presets, extensions и локальных overrides требуют собственной политики владения и совместимости.
Этот тест недодаёт Spec Kit контекста. Пакет не включал plan, tasks и implement, поэтому его слабые места нельзя объявлять свойствами всего продукта.

S5D: плюсы и минусы при равном качестве

Плюсы

Свежесть доказательств оформлена явно. Изменение spec инвалидирует approval; опциональный outcome связывает обязательные gates с текущей spec и governed-source fingerprint.
Human authority отделена от текста в репозитории. Агент не должен считать имя в файле, старый лог или сообщение другого агента разрешением на approve, execute, accept или waiver.
Сильное поведение при stale evidence. На C4 S5D получил 100: не переиспользовал старый зелёный результат, остановил слепые ретраи и не придумал разрешение.
Ограничения описаны честно. Документация прямо говорит, где hash неполон, где trust root остаётся в репозитории и что metadata rollback не откатывает git или исходники.
Есть выход для мелких задач. Bugfix меньше 30 строк, docs и config должны идти напрямую, без открытия control-plane state.

Минусы

Выше когнитивная цена. Package, record, hypothesis, evidence, preview, approve, import, run и outcome нужно понимать, иначе команда начнёт имитировать процесс.
Меньше готовых интеграций и способов распространения. По сравнению со Spec Kit путь от установки до привычного UX для разных агентов уже.
Не все гарантии машинные. Имена reviewer и approver — audit labels, а не аутентифицированные личности; execution-authority checkpoint проводит conductor, а не CLI.
Outcome enforcement опционален. Без него часть legacy-поведения не связывает успешный gate с текущими governed files.
Рубрика теста говорит на языке S5D. Сильный результат C4 отчасти ожидаем, потому что сам сценарий проверяет доктрину S5D.

Как выбирать, если средний балл одинаковый

Когда наблюдаемое качество не даёт победителя, выбор смещается с «кто умнее отвечает» на «какой сбой для нас дороже». Это обычная инженерная логика слабого звена: система ограничена компонентом, который первым ломает нужное свойство.

Выбирайте Spec Kit, если…

главная проблема — хаотичный переход от идеи к плану, а команде нужны быстрый старт, поддержка разных coding-агентов, понятные артефакты и настраиваемые workflow без тяжёлой модели управления состоянием.

Выбирайте S5D, если…

дороже всего стоит ложное «готово»: payment, auth, PII, compliance, архитектурные решения, долгие автономные запуски и ситуации, где вчерашний зелёный тест нельзя считать доказательством для сегодняшнего кода.

Условие	Предпочтение	Почему
Много IDE/CLI и быстрая адаптация команды	Spec Kit	Больше готовых интеграций и проще мысленная модель
Нужны собственные шаблоны и фазы	Spec Kit	Presets, extensions, bundles и overrides
Нужна свежесть evidence относительно текущего кода	S5D	SHA chain и опциональный governed-source outcome
Нельзя выдумывать человеческое разрешение	S5D	Переходы разделены и требуют текущего authority
Основной поток — мелкие независимые изменения	Spec Kit или direct	S5D тоже должен выйти из процесса до 30 LOC
Нужно одновременно и удобство, и строгий контроль	Один kernel + заимствованный UX	Два полных lifecycle создадут две версии истины

Наше решение: не ставить два фреймворка рядом

Мы не будем заменять S5D на Spec Kit из-за разницы 93,3 против 92,9 — этих данных для миграции нет. Но игнорировать сильные стороны Spec Kit тоже нелепо.

Целевое состояние выглядит так:

S5D остаётся единственным lifecycle kernel там, где нужны authority, freshness и воспроизводимое состояние.
Из Spec Kit заимствуются продуктовые поверхности: быстрый feature entry, integrations, presets/bundles и понятный pause/resume UX.
Микрозадачи не тащат control plane. Опечатки, docs, config и локальные bugfix идут прямым путём с фокусным тестом.
Не появляется второй набор accepted artifacts. Иначе spec, approval и completion начнут расходиться между двумя системами.

Это архитектурное решение, а не вывод из среднего балла. Его основание — цена stale evidence и конфликтующих источников истины в нашем типе проектов.

Что Conclave заставил исправить

Черновик отчёта прошёл два раунда независимого аудита Claude, Codex и Grok. Во втором раунде аудиторы получили выводы друг друга под нейтральными именами AUDITOR 1..3. Первую попытку пришлось отбросить: в пакете были видны имена провайдеров, что могло повлиять на оценку авторитетом модели.

Все три аудитора дважды вернули PASS WITH CHANGES. После проверки замечаний по фактическим артефактам мы изменили:

«практическую ничью» на «описательно близкий результат без доказанного победителя»;
«модель предпочла фреймворк» на «маршрут дал более высокий point estimate в одном запуске»;
продуктовую рекомендацию отделили от данных об оценках;
опубликовали фактическое влияние проверок и чувствительность к удалению одного жюри;
добавили асимметрию пакетов, смещение автора, оценивание Claude ответов Claude и отсутствие независимой временной отметки до запуска в ограничения.

После правок арбитр дал APPROVE. Отдельный historian на GPT-5.5 оценил качество самих аудиторов: Codex оказался сильнее в статистических границах утверждений и происхождении данных, Claude — в валидности измеряемого конструкта, Grok — в кратком поиске противоречий.

Чего этот тест не доказал

Он не измерял качество реального патча, время выполнения, число итераций или стоимость токенов.
Он не сравнивал удобство CLI и настройку нового репозитория.
Он не доказывает полное отсутствие контракта, привязанного к исходникам, во всех расширениях Spec Kit; поиск был ограничен проверенными основными файлами.
Он не подтверждает, что заявленные policy S5D всегда обеспечиваются машиной. Часть правил проводит conductor, а identity labels сами по себе не аутентифицируют человека.
Он не даёт стабильного рейтинга моделей или фреймворков: один запуск на ячейку для этого слишком мал.

Обновление: из изменения теперь выводится реверификация

У исходного S5D была важная дыра. Он умел связать outcome с fingerprint исходников и потребовать свежие gates, но внутри одного outcome выбор оставался грубым: изменился governed source — повтори весь набор. Из одного файлового diff действительно нельзя вывести корректность, но из diff + зарегистрированных claims + их support + графа зависимостей + контрактов gates можно вывести конечное множество обязательств.

В candidate-версии поверх commit 5e86b508 каждый outcome может объявить claims. Claim содержит проверяемый predicate, компоненты поддержки, зависимости от других claims и исполняемые gates. Для изменённых путей PΔ планировщик сначала находит прямое влияние, затем берёт наименьшее замыкание по обратным зависимостям:

TΔ = ordered affected bindings t = (package, spec SHA, subject SHA) D0,t(Δ) = { c ∈ Ct | ∃p ∈ PΔ : matches(supportt(c), p) } Ft,Δ(X) = D0,t(Δ) ∪ { c ∈ Ct | depends_ont(c) ∩ X ≠ ∅ } It(Δ) = μX.Ft,Δ(X) Gt(Δ) = stable_unique(⟨g ∈ Rt in declared order | ∃c ∈ It(Δ): g ∈ gatest(c)⟩)

Для каждого target binding t, It(Δ) — наименьшее множество claims, которое содержит непосредственно затронутые claims и замкнуто по их dependents. Gt(Δ) фильтрует их gates через доверенный верхнеуровневый порядок этого target. Это даёт четыре проверяемых закона: extensivity, closure, leastness и monotonicity. Добавление изменённых путей не может уменьшить область реверификации.

Выведенный набор и фактический floor — не одно и то же

Запускать только Gt(Δ) небезопасно. Trusted base может требовать больше; один файл может принадлежать нескольким спецификациям; изменение upstream-спецификации может затронуть downstream. Поэтому реально исполняемая последовательность шире:

Et(Δ) = stable_unique(Gt(Δ) ⧺ Bt(Δ) ⧺ Ot(Δ) ⧺ Lt(Δ)) Plan(Δ) = ⟨(t, Et(Δ)) | t ∈ TΔ in deterministic target order⟩

Знак ⧺ означает ordered concatenation, а stable_unique сохраняет первое вхождение. Для target t, Bt сохраняет trusted-base/candidate floor, Ot переоткрывает собственный floor target по co-owner trigger, Lt — его консервативный downstream floor. Для каждого изменённого пути co-owner triggers строятся по всем упорядоченным парам (selected source s, owner t), где s ≠ t, даже если все владельцы уже выбраны напрямую через path fallback или несколько валидных аннотаций. Строгий gate kind не переносится на чужой subject: каждый co-owner остаётся отдельной obligation, привязанной к собственным candidate spec SHA, governed-source SHA и полному outcome floor. Поэтому одинаковые gate kinds на разных package исполняются отдельно; глобальной дедупликации по kind нет. Это отдельно подтверждено трёхвладельческим runtime-контрпримером. Отчёт CI показывает target-local derived Gt, effective Et и причину каждого расширения. Иначе зелёный результат был бы неаудируемым.

Что показал финальный синтетический прогон

Прогон выполнен 30 июля на незакоммиченном candidate поверх 5e86b5087c26. Relevant-source bundle имеет SHA-256 a663005aaac57b7b68f4ff7714bf075f6af1df7a481604d6da91c6158e4a419e; в него входят и change-calculus spec a2d4c4c0…, и trusted-CI spec 5604c38b…. Результат:

Проверка	Результат	Что именно подтверждает
Finite fixed-point model	PASS	Все 64 четырёхузловых DAG под одним топологическим порядком × 16 direct-impact sets: 1024 конфигурации; проверены extensivity, closure, leastness, monotonicity и точная target-local gate sequence
`change_calculus`	24/24 PASS	Прямое влияние, reverse closure, co-owner composition, derived-vs-effective separation, invalid graph, duplicate ids, glob semantics и executable gate boundary
Изолированные `ci_verify_*` сценарии	74/74 PASS	Реальный CLI во временных репозиториях: позитивные и fail-closed сценарии, все пары co-owner bindings, одинаковые gate kinds без глобальной дедупликации, downstream architecture floor, scanner, gitlink и process boundary
Полный Rust suite	594/594 PASS	Свежий последовательный прогон текущего candidate; две контролируемые одновременные копии также прошли 594/594
Format, check, Clippy, build, обе spec validation и graph check	PASS	Статические и структурные predicates текущего candidate
`s5d ci verify` на всём dirty worktree	FAIL	Относительно clean base отчёт связал 50 изменённых файлов; trusted floor прошёл 59 specs, затем 33 нарушения annotation/ownership остановили все 20 выведенных target-bound obligations; исполнено 0 gates
Platform protection	UNKNOWN	`s5d ci check` подтверждает актуальность generated CI, но сам сообщает `platform_protection: unverified`

Есть и неприятное наблюдение, которое нельзя выкинуть из отчёта. На предыдущем snapshot один независимый полный suite, запущенный одновременно с другими проверками, однажды упал в тесте project lock. Причина осталась UNKNOWN; сам тест затем прошёл 540 из 540 последовательных повторов и 16-way parallel stress. На текущем bundle один последовательный и два контролируемых одновременных полных suite дали по 594/594. Это свежее evidence текущей версии, но оно не доказывает детерминизм тестового набора при произвольной конкуренции.

Негативные сценарии здесь принципиальны. Неполная карта claims, неизвестная ссылка, цикл, дубликат component id, неправильный glob, неисполняемый gate, unmapped behavior и испорченный claim-contract trusted base останавливают CI до запуска gates. Отдельно закрыты композиционные дыры: downstream-замыкание учитывает невыбранных co-owner спецификаций; каждый выбранный владелец триггерит полный floor остальных владельцев; strict co-owner проверяется как собственная source-bound obligation, а не чужой gate на weak package; architecture-only trigger расширяет effective floor, не подделывая локально выведенный Gt(Δ). Package-sensitive контрпримеры проверяют разные и одинаковые gate kinds, path fallback, несколько аннотаций и три одновременно выбранных owner. * не притворяется рекурсивным; для вложенных файлов нужен **; fingerprint и planner используют один matcher.

Adversarial scanner- и format-boundary-сценарии включают вложенные JavaScript templates, несколько literals и закрытие template с ложной аннотацией в суффиксе той же физической строки, escaped Python triple quote, шесть вариантов continued, quoted, composite и suffix shell heredoc, а также четыре семейства YAML block scalar: sequence/indent, quoted key, plain key с двоеточием и anchor/tag node properties перед |, |- или |2. Это не «тесты, которые сразу были зелёными»: шесть новых контрпримеров сначала воспроизвели false green на pre-fix implementation 08e3a7…. Затем независимый аудит нашёл валидный "a:b": &payload |; до фикса на 119b11… forged marker получал resolved и выбирал владельца, после фикса на 6cb74e… exact regression и bounded независимая матрица прошли. Это подтверждает закрытие названных классов, а не полноту YAML- или shell-парсера.

Unknown text, requirements.txt, MDX и snapshot-файлы обрабатываются fail-closed или через path ownership. Семь gitlink-сценариев отклоняют добавление, изменение и удаление pointer, unmerged/multistage index, mixed regular/gitlink stages и materialized content под неизменным pointer; вне текущего изменения остаётся только неизменный нематериализованный stage-0 gitlink. S5D не утверждает, что рекурсивно аттестовал содержимое submodule. На текущем macOS/Unix host отдельно проверены streaming-лимит общего вывода, timeout дерева через process group и обнаружение временной подмены package A→B→A. Это не доказывает изоляцию намеренно detached-потомков, защиту от same-user TOCTOU или эквивалентность non-Unix runtime.

Точный verdict: синтетический calculus gate — PASS; whole-worktree Trusted CI gate — FAIL. PASS относится к конечной модели и названным изолированным сценариям, а не к «корректности S5D вообще». Граф поддержки задаёт автор. Тесты умеют закрываться при обнаруженном пробеле, но не доказывают, что человек зарегистрировал все семантические зависимости. Candidate пока не committed и не released; его S5D record остаётся proposed и привязан к более раннему SHA спецификации, поэтому не даёт authority текущей версии. В текущем dirty worktree остаются недостающие аннотации governed Rust-файлов и unrelated unowned benchmark/local files.

Как добавить устойчивость и избыточность

Change calculus отвечает на вопрос «что стало потенциально неактуальным после изменения?». Он ещё не отвечает на другой вопрос: «что останется рабочим после отказа части системы и успеет ли восстановиться?». Для этого нужны не новые красивые слова в промпте, а ещё один тип зарегистрированных требований и внешние fault-injection checkers.

Избыточность: переживает ли топология допустимую потерю

Пусть T — конкретная топология, а Φ — конечная модель допустимых отказов: потеря процесса, узла, зоны, replica, link или dependency. Для каждого F ∈ Φ нужно проверить остаточную конфигурацию T \ F:

∀F ∈ Φ: Ready(T \ F) ∧ Capacity(T \ F) ≥ Demand ∧ Quorum(T \ F) ∧ Independence(T, F)

Последний предикат важен: три replica в одной availability zone не дают трёх независимых failure domains. Статический topology checker может проверить размещение, quorum и заявленную capacity, но не доказывает runtime recovery.

Устойчивость: что происходит во времени

Для каждого fault-сценария нужен ограниченный trace до горизонта H. Проверяются safety, доступность, восстановление и потеря данных:

∀φ ∈ Φ, τ ≤ H: Safety(traceφ,τ) ∧ Availability(traceφ,τ) ≥ SLO ∧ RecoveryTime(traceφ) ≤ RTO ∧ DataLoss(traceφ) ≤ RPO

Это не универсальное доказательство устойчивости. Это bounded claim для указанной топологии, нагрузки, fault model, горизонта и наблюдаемой среды. RTO, RPO, SLO и допустимая деградация должны быть числами, а не фразой «highly available».

Как связать fault-сценарии с selective re-verification

Каждый fault-сценарий получает support set: topology, component, config, dependency, data path, checker version и environment. После изменения повторяются только сценарии с пересечением поддержки — либо все, если impact неизвестен:

AffectedScenarios(Δ) = { φ ∈ Φ | Impact(Δ) ∩ Support(φ) ≠ ∅ } Impact = UNKNOWN ⇒ no carry-forward; scenario remains UNKNOWN

Для реализации S5D понадобятся типизированные fault_models, redundancy_sets, scenario IDs, support sets и checker contracts. Topology analysis даёт evidence класса CHECKED, fault injection — TESTED, production window — OBSERVED. Эти классы дополняют друг друга и не заменяют один другим.

Текущий статус этого слоя — UNKNOWN / not implemented. Формулы задают выводимые obligations, но runtime S5D пока не хранит и не исполняет их как first-class contract. Честный следующий шаг — маленькая конечная fault model для одного реального сервиса, а не обещание «проверять устойчивость вообще».

Следующий тест должен писать код

Добавлять ещё десять текстовых задач почти бесполезно: они уточнят поведение промпта, но не ответят, что происходит в рабочем репозитории. Следующий этап — два одинаково подготовленных проекта с намеренно посеянными дефектами и фиксированными hidden tests.

Для каждого model × framework нужны несколько повторов, а измерять стоит:

долю пройденных acceptance и hidden tests;
scope diff и число лишних файлов;
количество возвратов после review;
время, tool calls и token cost до принятого результата;
способность остановиться при stale evidence или отсутствии authority;
сохранность решения через следующий change cycle.

Только после этого можно обсуждать преимущество implementation system, а не качество четырёх ответов.

Итог

Spec Kit и S5D получили описательно близкие оценки в этом небольшом тесте; доказанного победителя нет. Это не повод пожать плечами. Такой результат говорит, что выбор нельзя оправдать качеством сгенерированного текста: решают организационная цена, требуемая строгость доказательств и тот класс ошибки, который нельзя себе позволить.

Если нужен быстрый, понятный и широко подключаемый spec-driven flow, Spec Kit выглядит сильнее. Если нужно доказать, что сегодняшнее «готово» относится к сегодняшней spec, сегодняшнему коду и текущему человеческому решению, S5D даёт более подходящую модель — с честно описанными остаточными рисками.

Для нас ответ такой: один S5D kernel, UX-уроки Spec Kit и никакой второй версии lifecycle truth.

Обновление от 30 июля добавляет к этому решению машинную причину: S5D candidate уже умеет отличать claims, затронутые изменением, от незатронутых, и консервативно расширять target-local gate sequence без смешивания derived Gt(Δ) и effective Et(Δ) или глобальной дедупликации разных bindings. Это новое свойство S5D, но не новый балл в старом сравнении: benchmark моделей не повторялся, а candidate ещё не выпущен.

• • •

Источники и границы воспроизводимости

GitHub Spec Kit, закреплённый commit.
S5D v0.14.0, закреплённый commit.
Дата финального прогона: 19 июля 2026 года. Модельные трассы: Grok 4.5 и Agy/Antigravity с Claude Opus 4.6 Thinking.
Cases, rubric и scorer были зафиксированы для финального нейтрального rerun, но manifest собран после прогона и не доказывает независимый ex-ante freeze.
Результаты относятся к выбранным instruction packets и четырём сценариям; они не переносятся автоматически на будущие версии или другие модели.
Change-calculus verification: benchmarks/change-calculus-synthetic-20260728/report.md. Candidate привязан к base 5e86b508, relevant-source bundle a663005a…, change-calculus spec a2d4c4c0… и trusted-CI spec 5604c38b….
Синтетический PASS не включает platform protection, полноту авторского semantic graph, production fault injection, устойчивость, избыточность или release readiness.