feat(validate): inject verification classes into milestone validation prompt (#2621)

Verification class fields (contract, integration, operational, UAT) are
captured during milestone planning and stored in the DB, but the
validate-milestone prompt never reads them back. This means milestones
can pass validation even when planned operational verification items
(migrations, deployments, runtime checks) were never addressed.

This change:
- Queries getMilestone() in buildValidateMilestonePrompt() to retrieve
  verification_* fields and injects them as structured context
- Adds a verification class compliance step to validate-milestone.md
  that requires the validator to check evidence for each non-empty class
- Adds a Verification Class Compliance table to the validation template

Backwards compatible: empty verification_* fields (existing milestones)
produce no additional prompt content.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

src/resources/extensions/gsd/auto-prompts.ts

@@ -1345,6 +1345,24 @@ export async function buildValidateMilestonePrompt(
   const inlined: string[] = [];
   inlined.push(await inlineFile(roadmapPath, roadmapRel, "Milestone Roadmap"));
 
+  // Inline verification classes from planning (if available in DB)
+  try {
+    const { isDbAvailable, getMilestone } = await import("./gsd-db.js");
+    if (isDbAvailable()) {
+      const milestone = getMilestone(mid);
+      if (milestone) {
+        const classes: string[] = [];
+        if (milestone.verification_contract) classes.push(`- **Contract:** ${milestone.verification_contract}`);
+        if (milestone.verification_integration) classes.push(`- **Integration:** ${milestone.verification_integration}`);
+        if (milestone.verification_operational) classes.push(`- **Operational:** ${milestone.verification_operational}`);
+        if (milestone.verification_uat) classes.push(`- **UAT:** ${milestone.verification_uat}`);
+        if (classes.length > 0) {
+          inlined.push(`### Verification Classes (from planning)\n\nThese verification tiers were defined during milestone planning. Each non-empty class must be checked for evidence during validation.\n\n${classes.join("\n")}`);
+        }
+      }
+    }
+  } catch { /* fall through */ }
+
   // Inline all slice summaries and UAT results
   let valSliceIds: string[] = [];
   try {

src/resources/extensions/gsd/prompts/validate-milestone.md

@@ -24,7 +24,12 @@ All relevant context has been preloaded below — the roadmap, all slice summari
 2. For each **slice** in the roadmap, verify its demo/deliverable claim against its summary. Flag any slice whose summary does not substantiate its claimed output.
 3. Check **cross-slice integration points** — do boundary map entries (produces/consumes) align with what was actually built?
 4. Check **requirement coverage** — are all active requirements addressed by at least one slice?
-5. Determine a verdict:
+5. If **Verification Classes** are provided in the inlined context above, check each non-empty class:
+   - For each verification class (Contract, Integration, Operational, UAT), determine whether slice summaries, UAT results, or observable behavior provide evidence that this verification tier was addressed.
+   - Document the compliance status of each class in your verdict rationale.
+   - If `Operational` verification is non-empty and no evidence of operational verification exists, flag this explicitly — it means planned operational checks (migrations, deployments, runtime verification) were not proven.
+   - A milestone with unaddressed verification classes may still pass if the gaps are minor, but the gaps MUST be documented in the Deferred Work Inventory.
+6. Determine a verdict:
    - `pass` — all criteria met, all slices delivered, no gaps
    - `needs-attention` — minor gaps that do not block completion (document them)
    - `needs-remediation` — material gaps found; remediation slices must be added to the roadmap

src/resources/extensions/gsd/templates/milestone-validation.md

@@ -35,6 +35,18 @@ validated_at: {{date}}
 
 - **{{requirementId}}**: {{status}} — {{disposition: covered by remediation slice / acceptable gap / needs attention}}
 
+## Verification Class Compliance
+
+<!-- If verification classes were defined during planning, document whether each
+     was addressed. Use N/A for classes that were empty or "none" in planning. -->
+
+| Class | Planned | Evidence | Status |
+|-------|---------|----------|--------|
+| Contract | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
+| Integration | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
+| Operational | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
+| UAT | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
+
 ## Remediation Slices
 
 <!-- New slices appended to the roadmap to address auto-remediable gaps.