validate: нет ни одного правила для NFR (50 из 79 PRD без секции, никто не возразил)

[explosivebit]

Проблема

forgeplan validate не имеет ни одного правила для нефункциональных требований — ни MUST, ни SHOULD, ни COULD.

Для функциональных требований правил шесть, и они реально срабатывают. Для NFR — ноль.

	FR	NFR
MUST	prd-fr-exist	нет
Качество	prd-fr-format, prd-measurability-adjectives, prd-vague-quantifiers, prd-orphan-frs, prd-no-impl-leakage	нет

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

Извлечение всех идентификаторов правил из бинаря forgeplan 0.34.0:

strings $(which forgeplan) | grep -oE '\bprd-[a-z-]+' | sort -u | grep -i nfr
# пусто

Строка NFR встречается среди правил ровно один раз — в сообщении "Tech names in FR/NFR sections: ", которое принадлежит prd-no-impl-leakage. То есть единственное правило, которое вообще читает секцию NFR, проверяет её на названия фреймворков, а не на измеримость.

Рядом в таблице строк лежат Non-Functional Requirements, NFR, Quality Attributes — это алиасы имён секций, которые сканирует то же правило.

Следствие в живом проекте

Из 79 PRD в рабочем окружении:

• 77 имеют ## Functional Requirements (потому что prd-fr-exist — MUST);
• 29 имеют ## Non-Functional Requirements.

50 PRD без секции NFR, и валидатор ни разу не возразил.

Это признано и в документации потребителя: plugins/fpl-skills/skills/smith-bootstrap/SKILL.md:656 — «NFR and Acceptance Criteria sections are useful but not validator-required».

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

Три правила, по образцу уже существующих FR-правил:

Правило	Уровень	Что проверяет
prd-nfr-exist	Should	наличие секции ## Non-Functional Requirements (с теми же алиасами, что уже знает prd-no-impl-leakage)
prd-nfr-measurable	Should	у каждого NFR-NNN есть числовой порог или явное TBD — не «быстро», не «надёжно»
prd-nfr-measurement	Could	у каждого NFR указан способ измерения

Не MUST: 50 существующих PRD немедленно покраснеют. Should даёт сигнал, не ломая рабочее окружение.

prd-measurability-adjectives уже несёт готовый чёрный список (simple, intuitive, user-friendly, responsive, quick, efficient, robust, smooth) — prd-nfr-measurable может переиспользовать его, а не заводить свой.

Смежное

Форма, которую стоит поощрять, уже сложилась в 19 PRD и даёт ровно то, что нужно правилу prd-nfr-measurement:

| ID | Category | Requirement | Metric | Condition | Measurement |

Сторона маркетплейса (гейт guardian + MUST-список ревьюера + шаблон) заводится отдельной задачей в ForgePlan/marketplace — правила валидатора без неё работают, но вместе сильнее.

[explosivebit]

Сделано: prd-nfr-exist и prd-nfr-measurable, оба уровня Should. PR: #472.

Наблюдение из issue подтвердилось буквально. extract_nfr_section был написан и знает три алиаса секции — и вызывался ровно из одного места, проверки протечки технологий. То есть валидатор умел найти секцию NFR и не задавал ни одного вопроса о её содержимом. Это третий за неделю наполовину построенный механизм (до этого — compute_body_hash в PROB-093, определённая и не вызываемая ниоткуда).

Ловушка, из-за которой правило чуть не стало бесполезным. Список субъективных прилагательных (scalable, robust, efficient, responsive, fast) читается как перечень самих NFR — и применялся только к секции FR. По 69 PRD: 2 совпадения в FR (проверяются) и 15 в NFR (не проверялись).

Все 15 сидят внутри собственной подсказки шаблона — <!-- BAD: "System should be fast and responsive" -->. Правило, ругающееся на них, было бы незакрываемым: единственный способ его удовлетворить — удалить инструкцию, объясняющую, как писать не надо. Поэтому prd-nfr-measurable сначала вырезает не-прозу. Проверено: 0 находок по всем 69 PRD, при этом написанная руками расплывчатая формулировка по-прежнему даёт находку с номером строки.

Почему Should, а не Must. У 30 PRD из 69 секции NFR нет вовсе. Правило уровня Must немедленно заблокировало бы активацию почти половины корпуса за то, что не является дефектом в тактических PRD.

Не сделано, записано осознанно. check_measurability_adjectives — правило со стороны FR, зашипленное давно — не вырезает не-прозу и несёт тот же скрытый дефект. Оно никогда не срабатывало только потому, что BAD-примеры шаблона случайно живут под заголовком NFR. Оставлено как есть и зафиксировано в docs/handoff/spec-validator-and-nfr-rules.md, чтобы следующий не открывал это заново.

[explosivebit]

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

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