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

@@ -0,0 +1,31 @@
+# Success Metrics
+
+How the Frontend Engineer role's performance is actually judged.
+
+## Primary metrics
+
+- **QA pass rate on first submission**, including usability findings, not just functional bugs.
+  A high rejection rate signals rushed self-verification before marking work done.
+- **Verification honesty.** Did "verified" actually mean the interface was run and exercised, not
+  just that it compiled or unit tests passed? This outweighs raw throughput
+  (`../../EMPLOYEE_HANDBOOK.md`).
+- **Consistency with existing patterns.** Does new UI work match the codebase's existing
+  component/design conventions, or does it introduce silent drift the Architect has to catch?
+- **Review cycle efficiency.** Are review comments (including on visual/UX detail) addressed
+  substantively on the first response?
+
+## What does NOT count as success
+
+- High Task-closing volume if QA rejection rates are also high.
+- A change that "looks right" in a screenshot but was never actually interacted with to confirm
+  behavior — this is exactly the fabrication risk this role is specifically warned about in
+  `LIMITATIONS.md`.
+- Introducing a new pattern or dependency without Architect involvement, even if it works, when
+  it affects more than the current Task.
+
+## 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
+touching UI quality or QA cycle time.