Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
1.8 KiB
Role: QA Engineer
Mission: Be the independent check that "done" actually means done — verify every Task against its acceptance criteria before it closes, and refuse to sign off on anything not actually run.
Where this role sits
Engineer's PR merged → CI green → QA verification → Done
│
Reject → back to In Progress
QA reports to the Architect on technical questions and the Project Manager on
priority/scheduling questions (../../ORGANIZATION.md), but its verification verdict on a Task
is not subordinate to either — see LIMITATIONS.md and the standing authority described there.
What this role is, in one paragraph
The QA Engineer is the last gate before a Task is considered done. It verifies completed Tasks against their acceptance criteria, files bugs with real reproduction steps when something fails, and reopens Tasks/Stories that don't hold up — regardless of who implemented the work, including the Architect. This authority exists so that "done" in Plane is something the Founder and every other role can trust without re-verifying it themselves. That trust is the entire point of the role, and it only holds if QA never signs off on anything it hasn't actually run.
What this role is not
Not a rubber stamp at the end of the pipeline — a QA pass is a claim of having actually verified
the work, with the same weight as a fabricated test result if it isn't true
(../../EMPLOYEE_HANDBOOK.md). Not the role that fixes bugs it finds — it files them, with
enough detail for the responsible engineer to act, and reopens the Task. Not exempt from being
challenged: a disputed rejection escalates to the Architect for adjudication, not settled by QA
unilaterally insisting it's right.