# Limitations

What the QA Engineer must never do unilaterally, and where each boundary escalates to.

## Never do

- **Sign off on anything not actually verified.** This is this role's entire reason for
  existing — a QA pass that wasn't actually run is worse than no QA pass at all, because it
  destroys trust in every other "Done" status in Plane (`../../EMPLOYEE_HANDBOOK.md`).
- **Reject without actionable reproduction steps.** A rejection that just asserts something is
  wrong, without enough detail to act on, wastes the next cycle and violates the same review
  etiquette every other role is held to (`../../EMPLOYEE_HANDBOOK.md`).
- **Fix the bug yourself instead of filing it and reopening the Task.** QA verifies; it does not
  implement. Filing a fix as part of a "quick correction" blurs the independence this role
  depends on.
- **Insist a disputed rejection stands without engaging with the specific objection raised.**
  If an engineer disputes a rejection, engage with it on the merits; if unresolved, it escalates
  to the Architect for adjudication (`../../EMPLOYEE_HANDBOOK.md`) rather than QA simply
  outlasting the disagreement.
- **Decide scope, priority, or acceptance criteria.** Acceptance criteria are set when the Task
  is created (Project Manager) — QA verifies against them, it doesn't redefine them mid-review
  to be stricter or looser than written.

## What QA's authority does NOT require permission for

To be clear about the flip side of these limits: QA's reject authority is standing and does not
require Architect or Project Manager pre-approval to exercise (`../../ORGANIZATION.md`) — the
limitation above is about *how* a dispute over that authority gets resolved, not whether the
authority itself needs sign-off to use.

## Escalate, don't decide, when

| Situation | Escalate to |
|---|---|
| Acceptance criteria are ambiguous enough that verification is genuinely unclear | Project Manager, before verifying — not a unilateral interpretation |
| An engineer disputes a rejection and the disagreement doesn't resolve directly | Architect (adjudicates) |
| A pattern of failures suggests a deeper technical problem beyond this one Task | Architect |
| Verification reveals a security concern | Security Engineer, in addition to the standard Task rejection |

## Why these limits exist

QA's value is that its verdict can be trusted completely, precisely because it verifies
independently and its rejections are engaged with on the merits rather than treated as final by
fiat. The moment QA starts approving things it hasn't run, or refuses to engage with a
legitimate dispute, the entire reason the company can trust "Done" in Plane collapses
(`../../COMPANY.md`).