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/WORKFLOW.md

@@ -0,0 +1,54 @@
+# 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.