[PROB-105] The SPEC validator passed empty templates and blocked real specs

[explosivebit]

Closes #450. Closes #449. Refs prob-105.

The finding that reframed both issues

Issue #450 asks for a rule enforcing "every ### Requirement has a #### Scenario",
on the grounds that the invariant is declared in prose and checked nowhere.

Measured before implementing, the premise does not hold here — and the truth is
worse than the report.

Input	Before	After
untouched SPEC template	PASS — 0 error(s), 0 warning(s) → activates at R_eff 1.00	stub warning; activate refuses
behavioural spec, 2 requirements + 2 GIVEN/WHEN/THEN scenarios	x [MUST] spec-contracts → FAIL, cannot activate	PASS
SPEC-002 … SPEC-006	pass	unchanged
SPEC-001	fails spec-summary + spec-contracts	unchanged — it is a document about writing specs, filed as a spec

Core did not lack a rule about scenarios. It had a MUST pointing against them,
while waving through documents that said nothing. That is why the marketplace TDD
flow grew its own gate (tdd-planner HARD RULE 1): core actively rejected the
shape TDD needs.

Three fixes, none of which teaches the kernel a methodology

1. check_stub can see a SPEC. Its twelve phrase markers are all PRD prose,
   and the placeholder signal was capped at +1 against a threshold of 3 — fifteen
   unfilled slots weighed the same as one. The count scales now.

   Threshold from the corpus, not taste: SPEC template 15 placeholders, PRD
   template 5, the six real SPECs 0–3. A line-count test was measured and
   rejected — the untouched template has 25 non-empty lines under ## API Contracts,
   because placeholder JSON is still lines.

2. spec-contracts accepts a behavioural contract. It still demands a
   contract; it stopped demanding one particular form. ## Requirements,
   ## Contract, ## Behavioral Contract join the structural headings.

3. spec-requirement-has-scenario (Should) — validate: нет правила «каждый Requirement в SPEC имеет Scenario» — инвариант держит только TDD-потребитель #450, conditional. Silent on a
   structural spec, fires only on a half-authored behavioural one. The blanket form
   was measured: it fires on 6 of 6 SPECs here, none defective.

Plus: the stub gate's remediation told every kind to "Fill MUST sections (Problem,
Goals, FR)". It now names the sections of the kind in hand.

#449 — NFR rules, and the trap in them

prd-nfr-exist and prd-nfr-measurable, both Should. extract_nfr_section already
existed, called from exactly one place — the tech-leakage check — so the validator
could find the section and asked nothing about its contents.

The subjective-adjective blacklist reads like a list of NFRs (scalable, robust,
efficient, responsive, fast) and was only ever applied to the FR section.
Across the 69 PRDs: 2 hits in FR (checked), 15 in NFR (not).

All 15 sit inside the template's own guidance —
<!-- BAD: "System should be fast and responsive" -->. A rule flagging them would
be unclosable: the only fix is deleting the instructions. The rule strips non-prose
first. Verified 0 findings across all 69 PRDs, while hand-written vague prose
still produces findings with line numbers.

check_measurability_adjectives, the FR-side rule that shipped long ago, does
not strip and carries the same latent bug. It has never fired only because the
template's BAD examples happen to live under the NFR heading. Left alone — noted
in the handoff so the next person does not rediscover it.

Template + a test that reads it

The SPEC template is API-first and is the only signal an author has about what a
spec looks like. It now carries a short comment saying both contract shapes are
legitimate.

The existing stub test pins a hand-abridged copy of the template, so it cannot
notice the real file changing. A new test reads the file the binary actually ships
(include_str!, same path as template::engine) and asserts it still reads as a
stub, and that the new guidance comment does not register as a heading — it names
## Requirements inside backticks, and if section_exists ever started matching
those, an empty template would satisfy spec-contracts through its own comment.

Verification

Gate	Result
cargo fmt --all -- --check	exit 0
cargo clippy --workspace --all-targets -- -D warnings	exit 0, 0 warnings
cargo test -p forgeplan-core --features test-helpers --no-fail-fast	2239 passed, 4 failed (17 binaries)
cargo test -p forgeplan --no-fail-fast	807 passed, 0 failed (58 binaries)
cargo test -p forgeplan-mcp --no-fail-fast	274 passed, 0 failed (19 binaries)

3320 passed, 4 failed, 94 test binaries — the binary count matches what
--workspace produces, so the per-crate split skipped nothing. The core failures
are all in git::tests (#454); they pass serially (51/51,
--test-threads=1) and this diff does not touch that module. forgeplan-core
needs --features test-helpers because the *_for_test helpers are gated and
normally arrive through forgeplan-mcp's dev-dependency.

Mutation checks — each fix reverted, the matching test had to fail:

• remove the comment strip → nfr_adjectives_inside_html_comments_are_not_flagged FAILED
• remove the placeholder scaling → untouched template back to PASS — 0 error(s), 0 warning(s)
• MANY_PLACEHOLDERS = 100 → the new shipped-template test FAILED
• add a real ## Requirements heading to the template → the same test FAILED on its second assertion

Four pre-existing rule-count tests failed and were updated, not silenced. They
sum named groups with comments rather than asserting a bare number, so updating one
means explaining where the new term came from. rules_for_spec_returns_base_plus_3
was renamed to _plus_4 rather than edited in place — a test name carrying a
number goes stale silently.

Not done

• check_measurability_adjectives (FR side) still lacks the non-prose strip.
  Latent, not firing, deliberately out of scope.
• SPEC-001 still fails validation. It is a document about writing specs, filed as a
  spec; the fix is re-filing it, not loosening a rule.

Full reasoning, rejected alternatives, and environment notes:
docs/handoff/spec-validator-and-nfr-rules.md.

Evidence: EVID-171 (verdict: supports, CL3, evidence_type: test, with
git provenance), linked informs to PROB-105 — R_eff 0.00 → 1.00.