QA
Key Ideas
- Quality Evidence: QA gathers proof that the work behaves as intended.
- Project Specific: QA should use project Quality tests, guidance, and governance.
- Failure Is Useful: failed QA should create actionable evidence, not just block progress.
Purpose
QA exists to turn confidence into evidence. Refine should make agent-produced work accountable through tests, checks, diagnostics, review aids, and other target-app verification.
Expected Role
QA should connect workflow to the Agents capability's quality, governance, logs, and evidence behavior. It should record what ran, what passed, what failed, and what should happen next.
QA should be flexible. Some apps need automated tests, some need build checks, some need visual inspection, and future agents may generate targeted verification for the Goal.
What Happens
When a Goal is in QA:
- Refine gathers quality evidence for the change.
- The configured agent evaluates every project Quality test against the isolated Goal candidate for
pre_merge, or against the exact integrated target checkout forpost_build, deciding how to run each plain-text test. - Each test requires a command. Refine correlates the claimed command with a supervised execution and records its process ID, exit code, output evidence, and final pass or fail.
- Checks should run through shared Process and Agents capabilities where commands or agents are involved.
- Workflow and manual Goal checks use the same exclusive Goal/candidate operation and write the same exact Goal-round Quality fields and log shape.
- Quality verifies the recorded evaluation commit, HEAD, index, and checkout before and after evaluation without cleaning or resetting detected work.
- Results should attach to the Goal as evidence: what ran, what passed, what failed, and what risk remains.
- Exact Goal-round fields and the Goal log must be durable before the operation reports success or failure; persistence failures leave the operation nonterminal for restart recovery. Cancellation also remains nonterminal until every owned process is confirmed exited.
- Passing QA should move the Goal toward review or completion according to workflow rules.
- Failing QA should preserve output and create a recovery path rather than losing the failed attempt.
The authoritative Quality timing controls ordering: pre_merge runs QA against the isolated candidate before Ready Merge, while post_build runs QA against the integrated target after Ready Merge and the optional rebuild. The candidate round pins that choice when validation begins, and every later stage or retry reads the pinned choice rather than mutable project settings. Provider, parsing, cancellation, and restart-interruption outcomes remain visible instead of being converted to generic success or hidden retries; provider and test launches recheck operation state and share the process-registration/cancellation barrier. Restart recovery uses the target-app and Refine-state identity stored on the operation, independent of whichever app is currently selected.
Future Direction
Future QA should become more agentic: generated tests, screenshot comparison, semantic checks, dependency analysis, risk scoring, and evidence summaries. The state should remain the workflow point where proof is gathered.