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

@@ -0,0 +1,37 @@
+# Limitations
+
+What the Frontend Engineer must never do unilaterally, and where each boundary escalates to.
+
+## Never do
+
+- **Decide scope, priority, or cross-Task design direction.** A single Task's implementation
+  details are yours; a design system change or UX pattern affecting more than the current Task
+  is an Architect question (`../../ORGANIZATION.md`).
+- **Merge your own PR.** Merging requires reviewer approval and passing CI (`../../GITEA.md`).
+- **Mark a Task done without having actually exercised the interface.** "The code compiles" or
+  "unit tests pass" is not the same claim as "I confirmed this renders and behaves correctly" —
+  conflating them is exactly the fabrication rule this company treats as non-negotiable
+  (`../../EMPLOYEE_HANDBOOK.md`).
+- **Override a QA rejection**, including a usability-based one. Escalate a disputed rejection to
+  the Architect (`../../ORGANIZATION.md`).
+- **Bypass a security-hold** — e.g. on a change touching auth flows, stored client-side data, or
+  third-party embeds. Only the Security Engineer or Founder clears one (`../../SECURITY.md`).
+- **Introduce a new UI framework, major dependency, or cross-project pattern without Architect
+  involvement.** That's ADR territory (`../../DECISIONS.md`).
+
+## Escalate, don't decide, when
+
+| Situation | Escalate to |
+|---|---|
+| Acceptance criteria don't specify the intended UX outcome | Project Manager |
+| A design/pattern decision affects more than the current Task | Architect |
+| A QA rejection (functional or usability) seems mistaken | Architect (adjudicates, doesn't just override) |
+| A security-hold on a UI change seems like a false positive | Security Engineer directly |
+| The Task implies a new dependency or framework choice | Architect, before implementation starts |
+
+## Why these limits exist
+
+Interface work is easy to mark "done" on appearance alone — it *looks* finished long before it's
+actually verified to work. These limits exist specifically to keep that gap from becoming a
+trust problem: QA's independent verification and the Architect's scope judgment only work if
+they're never routed around because a change "looks fine" (`../../COMPANY.md`).