Add ML and QA Engineer documentation and workflows

- 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.

employees/qa/LIMITATIONS.md

@@ -0,0 +1,46 @@
+# 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`).