feat(quality): add per-requirement quality checklist with 9 ISO criteria

Create requirement quality checklist covering all 9 ISO 29148 quality
criteria that each individual requirement must satisfy:
1. Necessary - traces to real stakeholder need
2. Implementation-Free - states WHAT not HOW
3. Unambiguous - single interpretation
4. Consistent - no contradictions
5. Complete - sufficient detail
6. Singular - one requirement per statement
7. Feasible - achievable within constraints
8. Traceable - has ID and source reference
9. Verifiable - can be tested or inspected

Includes quick reference card, red flags, and scoring guidance.
Used across StRS, SyRS, and PRD/SRS validation workflows.

Part of ISO 29148 compliance initiative (Wave 1).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/bmm/workflows/shared/templates/requirement-quality-checklist.md

@@ -0,0 +1,122 @@
+# Per-Requirement Quality Checklist (ISO 29148)
+
+Apply this checklist to EVERY individual requirement in StRS, SyRS, and PRD/SRS documents. Each requirement must satisfy all 9 quality criteria.
+
+## The 9 Quality Criteria
+
+### 1. Necessary
+
+- [ ] The requirement traces to a real stakeholder need or business objective
+- [ ] Removing this requirement would leave a stakeholder need unmet
+- [ ] The requirement is not gold-plating (adding unnecessary complexity)
+
+**Test:** "If we remove this requirement, would a stakeholder's need go unmet?"
+
+### 2. Implementation-Free
+
+- [ ] The requirement states WHAT is needed, not HOW to build it
+- [ ] No technology choices are embedded (unless it IS a design constraint)
+- [ ] No UI/UX specifics are included (unless it IS an interface requirement)
+- [ ] The requirement could be implemented in multiple different ways
+
+**Test:** "Could an architect choose from 3+ different implementation approaches?"
+
+### 3. Unambiguous
+
+- [ ] The requirement has only ONE possible interpretation
+- [ ] No vague adjectives (good, fast, easy, user-friendly, intuitive, robust)
+- [ ] Measurable criteria are used where applicable
+- [ ] Terms are defined in the glossary or are industry-standard
+
+**Test:** "Would 5 different engineers interpret this the same way?"
+
+### 4. Consistent
+
+- [ ] The requirement does NOT contradict any other requirement
+- [ ] Terminology is consistent with the rest of the document
+- [ ] Scope aligns with the product vision and boundaries
+- [ ] No conflicting quality attribute targets (e.g., maximum security AND minimal latency)
+
+**Test:** "Does this requirement peacefully coexist with all other requirements?"
+
+### 5. Complete
+
+- [ ] The requirement contains enough detail to design and test against
+- [ ] All conditions and constraints are specified
+- [ ] Edge cases and boundary conditions are addressed (or explicitly deferred)
+- [ ] No TBD, TBC, or placeholder values remain
+
+**Test:** "Could a developer implement this without asking clarifying questions?"
+
+### 6. Singular
+
+- [ ] The requirement expresses exactly ONE capability or constraint
+- [ ] No compound requirements joined by "and" or "or" (split if needed)
+- [ ] The requirement can be independently verified
+- [ ] The requirement can be independently prioritized
+
+**Test:** "Can I assign a single pass/fail verdict to this requirement?"
+
+### 7. Feasible
+
+- [ ] The requirement is technically achievable with known technology
+- [ ] The requirement is achievable within the project's constraints (budget, timeline, team)
+- [ ] No physical impossibilities or contradictions with laws of physics/math
+- [ ] Required third-party capabilities or services are available
+
+**Test:** "Can the team actually build this within the project constraints?"
+
+### 8. Traceable
+
+- [ ] The requirement has a unique identifier (ID)
+- [ ] The requirement's source is documented (stakeholder, regulation, business objective)
+- [ ] The requirement can be linked to downstream artifacts (design, code, tests)
+- [ ] The requirement can be linked to upstream sources (StRS, business needs)
+
+**Test:** "Can I follow this requirement from origin to implementation to test?"
+
+### 9. Verifiable
+
+- [ ] There exists a method to prove the requirement is satisfied
+- [ ] The verification method is identified (Test, Analysis, Demonstration, Inspection)
+- [ ] Acceptance criteria are clear and objective
+- [ ] The verification can be performed within project constraints
+
+**Test:** "Can I write a test or create a verification procedure for this?"
+
+---
+
+## Quick Reference Card
+
+| # | Criterion | Key Question | Red Flags |
+|---|-----------|-------------|-----------|
+| 1 | Necessary | Would removing it leave a need unmet? | Gold-plating, nice-to-have disguised as must-have |
+| 2 | Implementation-Free | Can it be built 3+ ways? | Technology names, UI specifics, algorithm choices |
+| 3 | Unambiguous | Would 5 engineers agree? | "Good", "fast", "easy", "user-friendly", "robust" |
+| 4 | Consistent | Does it conflict with others? | Contradicting metrics, overlapping scope |
+| 5 | Complete | Can dev build without questions? | TBD, TBC, "details to follow", missing conditions |
+| 6 | Singular | Can I give one pass/fail? | "and", "or" joining two capabilities |
+| 7 | Feasible | Can the team actually build it? | Unrealistic targets, unavailable technology |
+| 8 | Traceable | Can I follow origin → test? | Missing ID, no source reference |
+| 9 | Verifiable | Can I test/prove it? | Subjective criteria, unmeasurable quality |
+
+## Usage
+
+**When to Apply:**
+- During PRD/SRS creation (Step 9: FR synthesis, Step 10: NFR synthesis)
+- During PRD validation (validation workflow)
+- During StRS and SyRS review steps
+- During change management (new or modified requirements)
+
+**How to Apply:**
+1. Select a requirement
+2. Walk through all 9 criteria
+3. Mark any failures
+4. Fix failures before proceeding or flag for review
+5. A requirement that fails ANY criterion needs attention
+
+**Scoring:**
+- 9/9: Requirement is high quality
+- 7-8/9: Minor issues, address if time permits
+- 5-6/9: Significant issues, must address before approval
+- <5/9: Requirement needs rewrite