validate: нет правила «каждый Requirement в SPEC имеет Scenario» — инвариант держит только TDD-потребитель

[explosivebit]

Проблема

У kind spec три правила валидатора: spec-summary, spec-contracts, spec-related. Правила, проверяющего сценарии, нет.

Между тем центральный инвариант SPEC в методологии сформулирован жёстко: у каждого ### Requirement есть хотя бы один #### Scenario. Скилл /spec-author называет это «the single hard gate before freeze» (spec-author/SKILL.md:48), канон — NOTE-020, решение — ADR-008.

Инвариант заявлен прозой в трёх местах и не проверяется нигде.

Где он всё-таки держится — и почему это плохое место

Зубы появляются на стадию позже, у потребителя:

• agents-tdd/agents/tdd-planner.md:204 HARD RULE 1 — отказывается планировать против SPEC без блоков #### Scenario;
• agents-tdd/hooks/tdd-gate.sh:193 — ловит дрейф SPEC после заморозки по нормализованному хешу.

То есть автор SPEC узнаёт о дефекте, только когда кто-то попытается по нему работать. SPEC успевает пройти валидацию, попасть в active и стать источником истины — а потом оказывается, что оракула в нём нет.

Доказательство

strings $(which forgeplan) | grep -oE '\bspec-[a-z-]+' | sort -u
# spec-summary  spec-contracts  spec-related

Все 5 SPEC в рабочем окружении блоки #### Scenario несут — но это дисциплина автора, а не результат проверки.

Что предлагается

Правило	Уровень	Что проверяет
spec-requirement-has-scenario	Should	каждый ### Requirement имеет ≥1 вложенный #### Scenario
spec-scenario-format	Could	тело сценария содержит GIVEN и WHEN и THEN

Should, а не Must — по тем же соображениям, что и с NFR: не ломать существующие артефакты одномоментно.

Важно не перепутать с существующим правилом

В бинаре уже есть scenario-required-sections, но оно относится к отдельному brownfield-виду артефакта Scenario (см. plugins/forgeplan-brownfield-pack/templates/scenario.template.md и скилл /scenario-writer, который превращает use-case в Gherkin).

Это не то же самое, что блоки #### Scenario внутри SPEC. Новое правило должно смотреть на вложенные заголовки внутри тела SPEC, а не на вид артефакта.

[explosivebit]

Взял это, но перед реализацией измерил посылку — и она не подтвердилась. Правда оказалась хуже, чем в отчёте.

Утверждение issue: инвариант «у каждого ### Requirement есть #### Scenario» заявлен прозой и нигде не проверяется, поэтому нужно правило.

Что показал замер на 0.36.0 шипнутым бинарём:

Вход	Было	Стало
нетронутый шаблон forgeplan new spec	PASS — 0 error(s), 0 warning(s) → активируется с R_eff 1.00	предупреждение о заготовке; activate отказывает
поведенческая спека, 2 требования + 2 сценария GIVEN/WHEN/THEN	x [MUST] spec-contracts → FAIL, активировать нельзя	PASS
SPEC-002 … SPEC-006	проходят	без изменений

То есть ядру не не хватало правила про сценарии. У него был MUST, направленный против них, и одновременно оно пропускало документы, не говорящие ничего. Именно поэтому TDD-поток в маркетплейсе отрастил собственный гейт (tdd-planner HARD RULE 1) — ядро активно отвергало ту форму, которая нужна TDD.

Две причины. check_stub знает двенадцать фраз-маркеров, и все они — проза PRD; сигнал о плейсхолдерах был ограничен +1 против порога 3, так что пятнадцать незаполненных слотов весили столько же, сколько один. Теперь счёт масштабируется, а порог взят из корпуса, а не из вкуса: шаблон SPEC — 15 плейсхолдеров, шаблон PRD — 5, шесть реальных SPEC — 0–3. И spec-contracts требовал одну конкретную форму контракта; он по-прежнему требует контракт, но ## Requirements, ## Contract и ## Behavioral Contract теперь считаются наравне с ## API и ## Data Model.

Правило из issue сделано, но сознательно условным. Сплошную форму («каждое требование обязано иметь сценарий») я замерил перед тем, как отвергнуть: она срабатывает на 6 SPEC из 6 в этом репозитории, и ни одна из них не дефектна. Шипнутое правило spec-requirement-has-scenario молчит на структурной спеке и срабатывает только на наполовину написанной поведенческой. Уровень — Should, не Must: ядро не должно навязывать форму, которую его собственные шесть спек не используют.

Плюс шаблон SPEC теперь прямо говорит, что законны обе формы контракта — раньше он был единственным сигналом автору о том, как выглядит спека, и сигнал был односторонним.

PR: #472. Полный разбор с отвергнутыми альтернативами: docs/handoff/spec-validator-and-nfr-rules.md. Артефакт: PROB-105, доказательство EVID-171.

[explosivebit]

Смержено в dev — 551ddb9 (PR #472). Уедет в следующем релизе.

Автозакрытие по Closes #450 в теле PR не сработало: GitHub закрывает issue по ключевому слову только при мерже в ветку по умолчанию, а у нас это main, тогда как feature-ветки мержатся в dev. Закрыто вручную.