enhance(#3717): make the edge probe's shape cues language-aware via an optional text_en field (#4156)

* test(#3717): add failing-first coverage for text_en language-aware classification

Adds unit tests for the not-yet-implemented text_en field on Requirement
(fallback selection, empty/whitespace/non-string rejection, shapes-override
precedence), a SHAPE_CUES/VALID_SHAPES parity guard (RULESET.GENERATIVE-FIX),
and workflow-prose contract tests asserting spec-phase.md Step 5.5 documents
populating text_en for response_language projects. All new tests are RED
until src/edge-probe.cts and the workflow docs are updated.

* feat(#3717): make edge-probe shape classification read an optional text_en field

Requirement gains an optional text_en; classifyShape's own signature stays
untouched (a locked, directly-tested export), and the text_en ?? text
selection is pushed to proposeEdges' single call site instead. text_en is
validated fail-closed: an empty or whitespace-only value throws rather than
silently winning the ?? fallback and degrading classification to zero shapes.

This makes the #2773 doc-only translation convention an explicit,
validatable field instead of an invisible instruction, per the approved
Form-1 scope on #3717.

* docs(#3717): document the text_en field across spec-phase, reference and how-to docs

Updates Step 5.5's response_language instructions, the edge-probe reference
Inputs contract, the FEATURES.md fragment, and the non-English how-to guide
to describe the new text_en field: text keeps the requirement's own wording
in all cases, text_en (when populated) is the engine-only English rendering
the classifier prefers.

* docs(#3717): record the text_en locked-surface change in CONTEXT.md and ADR-550

Updates the Edge Probe Module glossary entry to describe the text_en field
and its fail-closed validation, and appends an ADR-550 amendment recording
why this is additive and does not re-open the #652 LLM-classifier rejection
(text_en is a plain field read by the existing deterministic regex
classifier, not a new model-dependent surface).

* docs(#3717): add changeset fragment and regenerate FEATURES.md

pr:0 placeholder — backfilled with the real PR number after the PR opens.

* docs(#3717): attribute the text_en machine check to engine-level validation, not prose tests

Code-review (Spec axis) finding: the workflow-prose contract tests and the
ADR-550 amendment overclaimed themselves as "the machine check the #2773
doc-only stopgap lacked." That check is actually engine-level
(validateRequirement/classifyShape, covered in tests/edge-probe.test.cjs) —
the prose tests are the same style of assertion #2773 already used. Reworded
both to attribute the claim correctly.

* fix(#3717): rewrap spec-phase.md so the id-unchanged sentence stays on one line

The #3717 rewrite of Step 5.5's response_language paragraph moved a line
break so "requirement `id`s" ended one physical line and "are never
translated" started the next. The pre-existing #2773 regression test
(tests/edge-probe-spec-phase-contract.test.cjs) asserts id + "never
translated" on the SAME line (no \n in between, matching git's own
line-oriented prose), so the reflow silently broke it. Rewrapped so the
sentence lands on one line again, verified against every #2773/#3717
regex assertion in that test file.

Emitted-Drift-Ack-Growth: spec-phase.md — #3717 adds text_en documentation to Step 5.5 (response_language paragraph + REQS_JSON heredoc comment); this growth is this PR's own diff, not incidental drift.

* chore(#3717): backfill changeset PR number

pr:0 -> pr:4156 now that the PR exists.

---------

Co-authored-by: sim <sim@local>

gsd-core/references/edge-probe.md

@@ -41,19 +41,23 @@ core finding that the spec layer is the measured weak point:
 
 ## Inputs
 
-A list of requirements, each a `{ id, text, shapes? }` record where `text` is a testable
-statement and `shapes` is an optional author-supplied override of the data/behavior shape.
-The five shapes are: `numeric-range`, `collection`, `text`, `stateful`, `io`. When
-`shapes` is absent, a heuristic classifier proposes them from the requirement prose
-(propose-then-confirm) — the author may correct the shape.
+A list of requirements, each a `{ id, text, text_en?, shapes? }` record where `text` is a
+testable statement, `text_en` is an optional English translation of `text`, and `shapes` is an
+optional author-supplied override of the data/behavior shape. The five shapes are:
+`numeric-range`, `collection`, `text`, `stateful`, `io`. When `shapes` is absent, a heuristic
+classifier proposes them from the requirement prose — reading `text_en` in preference to
+`text` when present (`text_en ?? text`) — (propose-then-confirm); the author may correct the
+shape.
 
-**`text` is English, whatever language the SPEC is in.** The heuristic cues are English
-word-boundary patterns, so a project running with `response_language` set must pass `text` as a
-faithful English translation of the requirement; the SPEC itself keeps the original language and
-the `id` is never translated. Prose in another language matches no cue, classifies to zero
-shapes, and surfaces as `unclassified` (#1110) — the probe contributes nothing. Where a
-requirement carries no cue even in English, author `shapes` explicitly rather than leaning on
-the classifier.
+**The classifier reads English; `text` does not have to be.** The heuristic cues (`SHAPE_CUES`)
+are English word-boundary patterns, so a requirement whose `text` is not English classifies to
+zero shapes unless `text_en` supplies a faithful English translation. A project running with
+`response_language` set should populate `text_en` for every requirement; `text` keeps its own
+meaning — the requirement's own text, in whatever language the SPEC uses — and is never
+translated or overwritten. `text_en` is engine input, not part of the SPEC. `id` is never
+translated. Prose that matches no cue in either field surfaces as `unclassified` (#1110) — the
+probe contributes nothing for that requirement. Where a requirement carries no cue even in
+English, author `shapes` explicitly rather than leaning on the classifier.
 
 ## Taxonomy (8 categories)