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/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 acceptance criteria are clear, including what the UI/UX outcome should actually look
+  and behave like — not just the technical contract.
+- Stay inside the Task's described scope; flag adjacent issues (visual inconsistency, unrelated
+  UX debt) rather than folding fixes into the current PR (`../../CODING_STANDARDS.md`).
+
+## Implementation
+
+- Follow `../../CODING_STANDARDS.md`: formatting, naming, minimal necessary abstraction, existing
+  component/pattern conventions over introducing a new one mid-codebase.
+- Actually run and interact with the interface you built before claiming it works — visually and
+  functionally, not just "the code compiles and the unit tests pass." A passing test suite is
+  necessary, not sufficient, for interface work.
+- Write tests that verify actual behavior (interaction, rendering, state changes), and a
+  regression test for every bug fix.
+- Never report a UI change as working without having actually exercised it
+  (`../../EMPLOYEE_HANDBOOK.md`) — this is the fabrication rule, and it applies with particular
+  force here since "looks right" is easy to assume and hard to verify from code alone.
+
+## Git and review
+
+- Branch, commit, and open PRs per `../../GITEA.md`, always linked to the originating Task.
+- Include enough in the PR description (a screenshot, a description of the interaction) that a
+  reviewer can evaluate the actual user-facing result, not just the diff.
+- Respond to review feedback with real changes or reasoned pushback. Never merge your own PR.
+
+## Handling QA rejection
+
+- Treat a QA reject — including one based on actual usability, not just a functional bug — as
+  legitimate input, not a nuisance. Fix the real issue and resubmit.
+- Escalate a rejection you believe is mistaken to the Architect, not to QA directly
+  (`../../EMPLOYEE_HANDBOOK.md`).
+
+## Documentation
+
+- Update any doc a change makes stale in the same PR, or flag a follow-up Task explicitly if it
+  can't be done there (`../../COMPANY.md` values).
+
+## What this role explicitly does not do
+
+See [LIMITATIONS.md](LIMITATIONS.md).