Add project-aware QA as an optional verification capability

[BjRo]

Motivation

Code review already assesses implementation against acceptance criteria, but some changes also need the system to be exercised. Provide an independently installable QA capability that the verification plugin can select for the project and change.

Examples include starting a web UI and following the changed user journey, probing an API contract, or exercising a CLI or migration scenario. These illustrate project-appropriate methods rather than mandatory checks for every change.

Acceptance criteria

• QA is a separate, replaceable capability composed through public intent and a compatible verification contract. Its installation alone does not select it for every goal.
• A fresh-context QA agent derives relevant scenarios from the originating objective, acceptance criteria, changed behavior, and available project guidance, then exercises the system using appropriate project tools.
• The initial result identifies the assessed candidate and conditions, scenarios exercised, expected and observed behavior, reproducible findings, supporting evidence, and limitations or blockers.
• QA returns feedback to the active owner. The owner implements repairs and incorporates durable regression tests; QA can use temporary probes without taking ownership of product repairs.
• Follow-up QA receives the original findings and repair history and actually reruns relevant scenarios against the repaired candidate. It checks the closed original finding set and direct repair-caused regressions, preserving finding identity and progress evidence.
• QA participates in the same combined-results-before-repair boundary and shared repair budget as code review. It does not start a separate repair loop or reset the budget.
• A required environment or observation that is unavailable is reported honestly. QA cannot clear an unexercised required scenario or silently waive selected verification.
• Findings and reproduction evidence support convergence. Curated PR previews, recordings, and reviewer-facing packaging belong to the later evidence capability.

Concrete steps

1. Define QA's observable operation and fix-verification invariants against the verification contract.
2. Implement the independently installable QA skill, fresh-context assessment boundary, and project-guided execution workflow.
3. Bind QA as an optional selected provider in verification and return compatible initial and repair-verification results.
4. Add representative web click-through and API-contract fixtures, including failing behavior, owner repair, successful re-execution, direct regression, and unavailable-environment cases.

Verification

Demonstrate that QA discovers an observable failure through execution, provides enough information for owner repair, and independently verifies that repair on the current candidate. Exercise composition with code review and show that both contribute to the existing shared convergence policy.

Follow-up design

Project environment startup, test data, available tool capabilities, and cleanup mechanics need to be resolved for the initial supported execution paths. The capability must operate within the goal's existing authority and report missing prerequisites.