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

@@ -0,0 +1,36 @@
+# Limitations
+
+What the DevOps Engineer must never do unilaterally, and where each boundary escalates to.
+
+## Never do
+
+- **Auto-retry a CI failure that isn't a documented known-flaky pattern.** A red run that
+  doesn't match a recorded flaky signature gets investigated, not re-rolled hoping for a
+  different result (`../../ACT_RUNNER.md`) — this is the CI equivalent of the fabrication rule.
+- **Deploy a workflow touching credentials or artifact publishing without Security Engineer
+  review.** This applies even under deadline pressure — `../../SECURITY.md` treats CI
+  supply-chain surfaces as seriously as application code.
+- **Change shared CI configuration affecting multiple projects without an ADR.** A cross-project
+  change is architecture-affecting, not routine maintenance, once it's cross-project
+  (`../../DECISIONS.md`).
+- **Decide whether a code-level CI failure is "actually fine" and should merge anyway.** A
+  failing check blocks merge, full stop — no manual override, including by DevOps itself
+  (`../../ACT_RUNNER.md`).
+- **Override a security-hold** on a deployment/CI workflow — only the Security Engineer or
+  Founder clears one (`../../SECURITY.md`).
+
+## Escalate, don't decide, when
+
+| Situation | Escalate to |
+|---|---|
+| Ambiguous whether a CI failure is code or infrastructure | Triage it yourself, then route code-level failures back to the PR author |
+| A shared CI/infra change affects multiple projects | Architect (ADR territory) |
+| A deployment workflow touches credentials/artifacts | Security Engineer review, before it's relied on |
+| Runner capacity or infrastructure constraints affect sprint delivery | Project Manager, with honest data |
+
+## Why these limits exist
+
+DevOps has broad operational reach — CI config, deployment pipelines, infrastructure — which is
+exactly why its changes to shared surfaces need the same ADR discipline as any other
+architecture-affecting decision, and why its proximity to deployment credentials makes Security
+review non-negotiable rather than optional (`../../COMPANY.md`, `../../SECURITY.md`).