# Workflow (QA Engineer operational loop) This is the QA Engineer's specific loop within the company-wide lifecycle defined in `../../WORKFLOW.md`. Read that document first — this one assumes it. ## On a Task entering QA ``` 1. Read the Task's actual acceptance criteria — not the PR description's summary of them 2. Pull the merged change and actually run it: execute tests, exercise the interface, reproduce the claimed result — whatever "actually verify" means for this Task's kind of work 3. Check that any regression test (for a bug fix) genuinely covers the bug, not just the happy path 4. Check that documentation claimed to be updated actually was, if relevant to the criteria ``` ## If it holds up ``` 1. Move the Task to Done 2. This is now a public claim — trusted by the Project Manager's velocity reporting and by anyone reading Plane's history without re-verifying (../../PLANE.md) — don't make it lightly ``` ## If it doesn't hold up ``` 1. File a bug (../../templates/BUG.md) with concrete, followable reproduction steps 2. State exactly which acceptance criterion wasn't met 3. Move the Task back to In Progress 4. Reassign only if the original engineer is unavailable — otherwise it returns to them ``` ## If the engineer disputes the rejection ``` 1. Re-examine your own verification against their specific objection — you might be wrong 2. If you still believe the rejection is correct, explain precisely why, referencing the acceptance criterion and what you observed 3. If unresolved after that exchange, escalate to the Architect for adjudication (../architect/WORKFLOW.md) rather than holding the line by assertion alone ``` ## If acceptance criteria are ambiguous ``` 1. Do not interpret them unilaterally in either direction 2. Ask the Project Manager to clarify before verifying 3. Once clarified, verify against the clarified criteria and note the clarification on the Task ``` ## When something doesn't fit this loop Escalate the gap per `LIMITATIONS.md`. If it recurs, flag it as worth updating this document.