QA
Forginate verifies builds two ways: audits (does the code match the plan?) and the QA harness (does the built software actually do what the acceptance criteria say?). This page covers both, with a focus on the QA harness.
Acceptance criteria come from the plan
During planning, your documents include acceptance criteria — concrete, testable statements about what the finished software must do. These aren't decoration: the QA harness executes against exactly this list. If a behavior matters, make sure it's captured as an acceptance criterion before you approve the plan.
You control the bar
Because acceptance criteria are ordinary planning content, you can edit them like any other document — directly or through the vibe editor — before approving. Tighten vague criteria into checkable ones: "loads fast" is not testable; "the dashboard renders within 2 seconds on the seeded demo dataset" is.
How a QA run works
When a build reaches the QA stage:
- A dedicated, sandboxed QA runner starts — separate from the build agents, so the thing checking the work is not the thing that did the work.
- It receives a manifest describing the built artifact and the project's acceptance-criteria list.
- It exercises the built artifact against each criterion, sequentially.
- It reports per-criterion pass/fail results back to the platform.
- The run succeeds only if all criteria pass.
Results appear on the request, criterion by criterion, so a failure tells you which expectation broke — not just "QA failed".
QA vs. audit
| Audit | QA harness | |
|---|---|---|
| Question | Does the code match the plan and hold up to review? | Does the running software satisfy the acceptance criteria? |
| Performed by | Auditor agent reading the work | QA runner exercising the artifact |
| Output | Green / yellow / red verdict + findings | Per-criterion pass/fail |
| On failure | Findings → gap-closing tasks → re-audit | Failing criteria feed the fix loop |
Both must be satisfied before delivery. The audit loop is described in Build and review.
When QA fails
A failed criterion means the built software doesn't do something the plan promised. The failure flows back into the integration loop: the finding is addressed by a fix task and QA runs again. As with audits, this happens inside the budget envelope — repeated failures escalate to you rather than looping forever.
Things worth checking when a criterion keeps failing:
- Is the criterion actually testable as written? Ambiguous criteria produce ambiguous results. Sharpen the wording in the acceptance-criteria document.
- Did the plan change after the criterion was written? If you revised scope mid-flight, a criterion may describe behavior that was deliberately removed. Update the document.
- Is it a real bug? Then the fix loop is doing its job — let it run, or raise the budget if the envelope is exhausted.
QA on improvement requests
Improvement cards (features, changes, bug fixes on shipped products) pass through their own QA column on the Improve board — "auditing the change" — before reaching Awaiting merge. The same principle applies: the change is verified before it can land. See Improvement requests.
Costs
QA runs are runs like any other: their token usage and cost are metered, visible per run, and included in the request's per-stage cost breakdown.
Writing acceptance criteria that pass for the right reasons
- One behavior per criterion. "Users can register, log in, and reset passwords" is three criteria wearing one label; a single failure hides which of the three broke.
- State the observable outcome, not the implementation: what a user sees or receives, not which function runs.
- Include the edge you care about. If empty input, a duplicate submission, or a permission boundary matters, write a criterion for it — the harness only checks what's on the list.
- Keep the list current. When scope changes during planning, revisit the criteria document in the same pass.
Next
- Improvement requests — the post-delivery loop QA also protects.
- Deployments — shipping once QA is green.