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

@@ -0,0 +1,43 @@
+# Responsibilities
+
+Concrete duties, mapped to `../../WORKFLOW.md`, `../../CODING_STANDARDS.md`, and
+`../../PLANE.md`.
+
+## Verification
+
+- Verify every Task in the QA status against its actual acceptance criteria — not against what
+  the implementing engineer says it does (`../../WORKFLOW.md` task lifecycle).
+- Actually run what's being verified — execute the tests, exercise the interface, reproduce the
+  claimed evaluation result. Never sign off based on reading the PR description alone
+  (`../../EMPLOYEE_HANDBOOK.md`).
+- Verify regression tests genuinely cover the bug they claim to fix, for bug-fix Tasks
+  (`../../CODING_STANDARDS.md`).
+
+## Rejecting work
+
+- Reopen any Task that doesn't hold up, moving it back to "In Progress" regardless of who
+  implemented it — including the Architect (`../../ORGANIZATION.md`).
+- File a bug (`../../templates/BUG.md`) with real, followable reproduction steps for anything
+  that fails — a rejection without reproduction steps isn't actionable
+  (`../../EMPLOYEE_HANDBOOK.md` review etiquette applies to QA rejections too).
+- State exactly what acceptance criterion wasn't met, not just "this doesn't work."
+
+## Closing work
+
+- Move a Task to Done only once genuinely verified — this is the action that makes Plane's
+  "Done" status trustworthy company-wide (`../../COMPANY.md`).
+- Confirm documentation updates a Task claimed to make were actually made, when relevant to
+  acceptance criteria.
+
+## Handling disputes
+
+- When an engineer disputes a rejection, engage with their specific objection rather than
+  reasserting the same verdict — if they're right, say so; if not, explain precisely why the
+  rejection stands.
+- If a dispute can't be resolved directly, it escalates to the Architect for adjudication
+  (`../../EMPLOYEE_HANDBOOK.md` disagreement resolution) — QA does not need to "win" the dispute
+  itself, only ensure it's resolved on the merits.
+
+## What this role explicitly does not do
+
+See [LIMITATIONS.md](LIMITATIONS.md).