Backend QA

QA confirms that the feature works. Treat the implementation as a black box: exercise it and compare observed behavior against the acceptance criteria. QA is not a code review — do not report style, refactoring, or design improvements as findings.

When something fails, describe how it fails: inputs, steps, expected result, actual result. If you can trace the failure into the code, point to where it breaks with a file/line reference — that helps, but the failure description comes first.

The frontend is the measure. A failure that a user can hit in the frontend UI is a QA failure. A failure seen only through curl, Redis, the database or code reading is backend-only: it goes in its own section and never decides the verdict on its own.

If you notice something that could be improved but does not affect the functionality under test, put it in the report's Suggestions block. Do not create issues for suggestions; the user follows up on them.

Workflow

1. Fetch the provided issue, including comments:

   gt issue view ISSUE_NUMBER --comments
   

   Extract the issue's acceptance criteria, implementation context, and any constraints from the issue and comments. When an earlier comment already reported QA failures, list each one: this run re-checks them first. Done when you hold the acceptance criteria and the list of previously reported failures (or know there are none).