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/documentation/SUCCESS_METRICS.md

@@ -0,0 +1,33 @@
+# Success Metrics
+
+How the Documentation Engineer role's performance is actually judged.
+
+## Primary metrics
+
+- **Flag-to-fix latency and accuracy.** Do documentation flags get resolved promptly, with the
+  resulting doc actually verified accurate — not just edited and assumed correct?
+- **Drift caught proactively.** Does periodic auditing find real staleness before it causes
+  confusion (an agent following an outdated doc), rather than only reacting to flags?
+- **Memory system health.** Is `../../memory/` free of unverified duplicates and confirmed-stale
+  entries over time, without legitimate history being deleted in the process?
+- **Cross-reference integrity.** Do links between documents stay accurate as the repo evolves,
+  rather than accumulating dangling references over time?
+
+## What does NOT count as success
+
+- Closing documentation flags quickly by editing without verifying the result is actually
+  accurate — this is the specific fabrication-rule risk this role carries
+  (`../../EMPLOYEE_HANDBOOK.md`, `LIMITATIONS.md`).
+- Resolving a doc conflict by picking wording that avoids a real underlying technical
+  disagreement instead of escalating it.
+- Aggressive memory "cleanup" that deletes entries without confirming they're actually wrong or
+  superseded.
+- Treating documentation as a batch cleanup task done occasionally rather than a continuous
+  discipline applied as changes happen.
+
+## Review cadence
+
+Reviewed continuously through Gitea/Plane history rather than a periodic formal review — the
+same principle applied to every AI employee's performance in this company
+(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective where
+stale documentation caused confusion or a repeated mistake.