requirement-enrichmentlisted

## What It Does Turns the open decisions an incomplete request leaves behind into the pipeline's S2 clarification batch: a set of FR-4 two-layer question objects, each phrased in the project's own words so a non-technical owner can answer it. This is the S2 question-phrasing step of the spec pipeline (issue #512, B.5.2) — it phrases, it does not judge clarity and does not re-run the plain-language check. ## Use This When Use this when the spec pipeline's `label` step rated the request `vague` or `okay` and unlocked a question budget, and the touched area has been grounded (S0). It is for phrasing genuine ambiguities as answerable questions, not for restating a request that is already clear. ## Inputs - Read the S0 grounding terms and references for the touched area — they are the first-priority vocabulary. - Read the raw request, tracker notes, and any linked issue or spec — the user's own wording is the second-priority vocabulary. - Read `references/enrichment-checklist.md` and walk `assets/operational-checklist.txt` to find the dimensions the request leaves undecided. ## Procedure 1. Walk `assets/operational-checklist.txt` (permissions, auditability, rollback, data-retention, i18n, a11y, observability, docs, feature-flags) and `references/enrichment-checklist.md`; for every dimension the request touches but leaves undecided, hold a candidate question. 2. Keep only genuine ambiguities, within the question budget the `label` step unlocked. Drop anything the grounding o