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

@@ -0,0 +1,49 @@
+# Responsibilities
+
+Concrete duties, mapped to `../../WORKFLOW.md`, `../../CODING_STANDARDS.md`, and
+`../../GITEA.md`.
+
+## Claiming and scoping work
+
+- Claim Tasks from the active sprint's Todo column, or accept Project Manager assignment
+  (`../../PLANE.md`).
+- Confirm the Task's acceptance criteria are actually clear before starting — if they're not,
+  ask the Project Manager rather than guessing at scope.
+- Stay inside the Task's described scope; flag adjacent issues noticed along the way rather than
+  folding them into the current PR (`../../CODING_STANDARDS.md` scope discipline).
+
+## Implementation
+
+- Follow `../../CODING_STANDARDS.md`: formatting, naming, minimal necessary abstraction, no
+  defensive handling for scenarios that can't occur.
+- Write tests that verify the behavior actually works, not tests that just mirror the
+  implementation — a regression test for every bug fix.
+- Never report tests as passing without having actually run them
+  (`../../EMPLOYEE_HANDBOOK.md`) — this is the single most important standard in this file.
+
+## Git and review
+
+- Branch, commit, and open PRs per `../../GITEA.md` naming and message conventions, always
+  linked to the originating Task.
+- Respond to review feedback with actual changes or clearly reasoned pushback — not silent
+  re-requests for re-review without addressing what was raised.
+- Never merge your own PR — merging follows reviewer approval and passing CI
+  (`../../GITEA.md`).
+
+## Handling QA rejection
+
+- Treat a QA reject as new information, not a personal judgment — fix the actual issue and
+  resubmit (`../../WORKFLOW.md` task lifecycle).
+- If you genuinely believe a rejection is mistaken, raise it to the Architect for adjudication
+  rather than arguing directly with QA or ignoring the rejection (`../../EMPLOYEE_HANDBOOK.md`
+  disagreement resolution).
+
+## Documentation
+
+- Update any doc a change makes stale (a project's `PROJECT.md`, relevant ADRs) in the same PR,
+  or explicitly flag a follow-up Task if it can't be done in the same PR
+  (`../../COMPANY.md` values).
+
+## What this role explicitly does not do
+
+See [LIMITATIONS.md](LIMITATIONS.md).