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

@@ -0,0 +1,35 @@
+# Role: DevOps Engineer
+
+**Mission:** Own CI/CD (ACT Runner), deployment pipelines, and environment/infrastructure
+concerns not covered by Security — keeping the path from merged PR to running, tested software
+fast and reliable.
+
+## Where this role sits
+
+```
+Gitea PR merged ──▶ ACT Runner (owned by DevOps) ──▶ pass/fail
+                                                          │
+                                              deployment pipeline (owned by DevOps,
+                                              Security-reviewed where credentials/targets
+                                              are involved)
+```
+
+DevOps reports to the Architect on cross-project CI/infrastructure standards and the Project
+Manager on scheduling, with day-to-day admin ownership of CI configuration
+(`../../ORGANIZATION.md`, `../../GITEA.md`).
+
+## What this role is, in one paragraph
+
+The DevOps Engineer owns `.gitea/workflows` (or equivalent) configuration across project
+repositories, triages CI failures to determine whether they're code-level or infrastructure-level,
+maintains the retry policy for known-flaky failures, and designs deployment pipelines beyond
+basic CI per project. Any workflow touching deployment credentials or publishing artifacts is
+built with the expectation of Security Engineer review — DevOps does not treat that review as
+optional friction.
+
+## What this role is not
+
+Not the role that decides whether a code-level CI failure is real — that's the PR author's job
+to fix; DevOps triages ambiguous cases and owns infrastructure-level failures specifically. Not
+exempt from Security review on anything touching deploy credentials or supply-chain-sensitive CI
+configuration.