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/backend/WORKFLOW.md

@@ -0,0 +1,58 @@
+# Workflow (Backend Engineer operational loop)
+
+This is the Backend Engineer's specific loop within the company-wide lifecycle defined in
+`../../WORKFLOW.md`. Read that document first — this one assumes it.
+
+## Claiming a Task
+
+```
+1. Pick from the active sprint's Todo column (assigned, or self-claimed and confirmed by the
+   Project Manager per ../../PLANE.md)
+2. Read the Task's acceptance criteria fully — if unclear, ask the Project Manager before
+   starting rather than guessing
+3. Move the Task to In Progress
+```
+
+## Implementing
+
+```
+1. Branch per ../../GITEA.md naming: backend<n>/<task-id>-<short-description>
+2. Implement against ../../CODING_STANDARDS.md
+3. Write tests that verify the actual behavior, including a regression test if this is a bug fix
+4. Run the tests yourself and confirm they pass — never report passing without running them
+5. Update any documentation this change makes stale, in the same PR where feasible
+```
+
+## Opening a PR
+
+```
+1. Commit per ../../GITEA.md message format, with the Task trailer
+2. Open PR linked to the Task, description states what changed and why
+3. Move Task to In Review
+```
+
+## Responding to review
+
+```
+1. Architect or peer review comes back — engage with each comment, either with a change or
+   clearly reasoned pushback
+2. Re-request review after addressing feedback, don't just re-request without changes
+3. Once approved and CI (../../ACT_RUNNER.md) is green, the reviewer merges — not you
+```
+
+## After merge, awaiting QA
+
+```
+1. Task moves to QA per ../../WORKFLOW.md
+2. If QA passes: Task closes
+3. If QA rejects: Task returns to In Progress with QA's findings — fix the actual issue,
+   don't just resubmit unchanged
+4. If you believe the rejection is mistaken: escalate to the Architect for adjudication
+   (../architect/WORKFLOW.md) rather than arguing directly with QA
+```
+
+## When something doesn't fit this loop
+
+Escalate the gap per `LIMITATIONS.md`. If it recurs, flag it as worth updating this document —
+a documentation gap that keeps causing the same confusion is itself a problem worth fixing
+(`../../COMPANY.md` values).