qa-review

name	qa-review
description	Validate that implemented code fully satisfies Story acceptance criteria, respects rules, and introduces no regressions. This is the hard quality gate — no pass means no delivery. Activate after implementation is complete.
license	ELv2
compatibility	Works with any filesystem-based AI coding agent
metadata	{"author":"gaai-framework","version":"1.0","category":"delivery","track":"delivery","id":"SKILL-QA-REVIEW-001","updated_at":"2026-04-15T00:00:00.000Z","status":"stable"}
inputs	["contexts/artefacts/stories/**","contexts/artefacts/plans/**","codebase (working tree)","contexts/rules/**","contexts/memory/** (optional — past bugs, regressions, risks)"]
outputs	["qa_report (PASS | FAIL)"]

QA Review

Purpose / When to Activate

Activate after implementation is complete. This is a hard quality gate.

No pass → no delivery.

---

Process

1. Story Compliance Check

• Parse Story YAML frontmatter
• Extract acceptance criteria
• Validate each criterion is demonstrably satisfied in code
• Required Skills AC verification: if the story frontmatter contains required_skills, for each entry X, identify its co-declared bound output AC. Verify that the bound output AC is satisfied by inspecting the actual output or changed artefacts (file contents, generated output, behaviour). Do NOT verify by checking invocation traces or logs — the test is output-based only. If the bound output AC cannot be evaluated from output alone (ambiguous) → FAIL with escalation note. If the bound output AC is unmet → FAIL immediately with: FAIL: bound output AC for required_skills entry "${X}" is not satisfied — [AC text] not met in output. Inspect [relevant file/output].
• Any criterion unclear or unmet → FAIL immediately

2. Scope Integrity Check

• Only files within Story scope were modified
• No feature creep introduced
• No unrelated refactors included
• Unexpected changes → FAIL

3. Rule Enforcement

• Confirm compliance with each applicable rule
• Surface violations explicitly
• Any broken rule → FAIL

4. Regression Scan

• Broken tests → FAIL — but only a new breakage is a regression. A regression is a test that fails on this change yet passed on the pre-change baseline. Before failing on a red test, establish whether it is pre-existing: re-run it on the base branch / the story's fork-point, or consult known-failing context. A test already red on the baseline and unrelated to this story's changed surface is not a regression — record it as pre-existing and do not FAIL/ESCALATE on it. A failure this story caused, or in a test that exercises the surface this story changed, is a regression → FAIL. Do not weaken this by labelling a genuinely new failure "pre-existing" — verify, don't assume.
• Behavior drift → FAIL
• Known risk patterns from memory → FAIL
• Large command output: redirect test-runner output to a file (e.g. /tmp/test-output.txt) and inspect via grep/tail/rg. NEVER use the Read tool on a file expected to exceed ~256KB — it has a hard 256KB ceiling that burns a turn and returns no content. On an accidental oversized Read, switch immediately to grep -E "FAIL|✕|Error" <file> to extract failures rather than retrying the Read.

5. Build / Type / Lint Integrity

Test runners that transpile (vitest, jest, ts-jest, swc, esbuild, babel) execute code WITHOUT type checking — a green test suite does not prove the code compiles. Static-type or linter errors in test files, fixtures, and adjacent modules will pass tests locally and only surface at deploy time.

Identify and run the project's full static-analysis gate for every workspace package whose files were modified (directly or via type/dep propagation):

• TypeScript: tsc --noEmit (or pnpm typecheck / equivalent script)
• For Cloudflare Workers projects: regenerate runtime types first (wrangler types) — drift between worker-configuration.d.ts and wrangler.jsonc masks real errors
• Lint (if the project enforces it as a gate): eslint, ruff, clippy, etc.
• Other ecosystems: cargo check, mypy, go vet, etc.

If the project documents the exact command in contexts/memory/patterns/conventions.md or a delivery rules file, use that command verbatim — do not improvise.

Any error → FAIL. "Test files only" is not a mitigation: test files are part of the typecheck graph and break the deploy gate.

Large output: redirect tsc --noEmit / lint output to a file and inspect via grep/tail. Do NOT Read files expected to exceed ~256KB — the Read-tool hard ceiling is 256KB; a failed Read burns a turn with no content returned. To summarize a large output file: grep -E "error TS|Error|warning" /tmp/tsc-output.txt | tail -100.

6. Quality Checks

• Error-prone operations lack error handling → FAIL
• External input enters functions without validation → FAIL
• Identifiers are ambiguous or non-descriptive → FAIL
• A function or module handles more than one responsibility without decomposition → FAIL
• Dead code or unreachable branches present → FAIL
• Tests were disabled or skipped to make the suite pass → FAIL

7. Memory Alignment (PASS only)

On PASS verdict, the skill MUST invoke memory-alignment-check (SKILL-MEMORY-ALIGNMENT-CHECK-001) before returning. QA MUST NOT improvise the delta — memory-alignment-check owns it.

The delta MUST match this exact skeleton (authoritative source: memory-alignment-check/SKILL.md Outputs). Do NOT invent alternative section headers (e.g. ## Summary, ## New facts delivered by this story, ## Implementation Footprint, ## No memory updates required) and do NOT change the frontmatter field names — any deviation FAILs the validate-memory-deltas CI gate:

---
artefact_type: memory-delta
skill: memory-alignment-check
story_id: {id}
generated_at: YYYY-MM-DD
verdict: ALIGNED | DRIFT_DETECTED | NEW_KNOWLEDGE_FOUND | DRIFT_AND_NEW_KNOWLEDGE
---

## Confirmed Entries
# (list, or leave the section present with no items)

## Contradicted Entries
# (list, or leave the section present with no items)

## New Knowledge Candidates
# (list, or leave the section present with no items)

A "nothing changed" delta is still expressed in this schema (verdict: ALIGNED, the three sections present with no items) — NOT as free prose. The full field-level schema lives in memory-alignment-check/SKILL.md Outputs. The delta is written exclusively to contexts/artefacts/memory-deltas/{id}.memory-delta.md (canonical path — never under contexts/memory/).

---

Outputs

If PASS:

status: PASS
validated_stories:
  - E01S01
notes:
  - All acceptance criteria satisfied
  - No rule violations
  - No regressions detected

If FAIL:

status: FAIL
blocking_issues:
  - Story E01S01: acceptance criterion #2 not satisfied
  - Rule code-style violated in services/api/user.ts
  - Unexpected file modified: services/payments/
recommended_actions:
  - Fix acceptance behavior
  - Revert out-of-scope change
  - Apply code rule formatting

---

Hard Rules

This skill must NEVER:

• Modify code
• Reinterpret Stories
• Negotiate acceptance criteria
• Approve partial conformance
• MUST NOT write or modify contexts/artefacts/memory-deltas/{id}.memory-delta.md directly. The delta is written exclusively by memory-alignment-check (invoked at Step 6). Free-form delta variants are a governance violation.

If it's not explicitly validated → it's broken. If it's broken → it doesn't ship.