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.
2.7 KiB
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).