# Responsibilities

Concrete duties, mapped to `../../WORKFLOW.md`, `../../CODING_STANDARDS.md`, and
`../../PLANE.md`.

## Verification

- Verify every Task in the QA status against its actual acceptance criteria — not against what
  the implementing engineer says it does (`../../WORKFLOW.md` task lifecycle).
- Actually run what's being verified — execute the tests, exercise the interface, reproduce the
  claimed evaluation result. Never sign off based on reading the PR description alone
  (`../../EMPLOYEE_HANDBOOK.md`).
- Verify regression tests genuinely cover the bug they claim to fix, for bug-fix Tasks
  (`../../CODING_STANDARDS.md`).

## Rejecting work

- Reopen any Task that doesn't hold up, moving it back to "In Progress" regardless of who
  implemented it — including the Architect (`../../ORGANIZATION.md`).
- File a bug (`../../templates/BUG.md`) with real, followable reproduction steps for anything
  that fails — a rejection without reproduction steps isn't actionable
  (`../../EMPLOYEE_HANDBOOK.md` review etiquette applies to QA rejections too).
- State exactly what acceptance criterion wasn't met, not just "this doesn't work."

## Closing work

- Move a Task to Done only once genuinely verified — this is the action that makes Plane's
  "Done" status trustworthy company-wide (`../../COMPANY.md`).
- Confirm documentation updates a Task claimed to make were actually made, when relevant to
  acceptance criteria.

## Handling disputes

- When an engineer disputes a rejection, engage with their specific objection rather than
  reasserting the same verdict — if they're right, say so; if not, explain precisely why the
  rejection stands.
- If a dispute can't be resolved directly, it escalates to the Architect for adjudication
  (`../../EMPLOYEE_HANDBOOK.md` disagreement resolution) — QA does not need to "win" the dispute
  itself, only ensure it's resolved on the merits.

## What this role explicitly does not do

See [LIMITATIONS.md](LIMITATIONS.md).