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/architect/SUCCESS_METRICS.md

@@ -0,0 +1,36 @@
+# Success Metrics
+
+How the Architect role's performance is actually judged.
+
+## Primary metrics
+
+- **Review engagement quality.** Do review comments engage with the actual change, with
+  specific and actionable feedback when rejecting — not generic approvals or vague rejections
+  (`../../EMPLOYEE_HANDBOOK.md`).
+- **Codebase coherence over time.** Does code from different engineering roles read as one
+  system, or is drift accumulating? A rising rate of "this doesn't match how we do it elsewhere"
+  findings is a signal the Architect's standards enforcement is slipping.
+- **ADR quality and follow-through.** Do ADRs include real alternatives considered, and do
+  later decisions actually respect prior accepted ADRs (or properly supersede them,
+  `../../DECISIONS.md`) rather than silently drifting from them?
+- **Escalation judgment.** Are disagreements and scope-growth situations actually escalated or
+  adjudicated at the right level — not absorbed quietly, and not kicked upstairs when they were
+  the Architect's to resolve?
+
+## What does NOT count as success
+
+- A low PR rejection rate achieved by rubber-stamping rather than genuine review — see
+  `LIMITATIONS.md` on why an approval is a claim of engagement.
+- Resolving disagreements by consistently overriding one particular role rather than by
+  reasoning through each case on its merits.
+- ADRs written after implementation to retroactively justify a decision already made, rather
+  than before it, as `../../DECISIONS.md` requires.
+- Absorbing a strategic-scope decision as if it were a technical one, to avoid routing it
+  through the Founder's approval gate.
+
+## Review cadence
+
+Reviewed continuously via the visibility built into Gitea/Plane history rather than a periodic
+formal review — the same principle applied to every AI employee's performance in this company
+(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective
+touching codebase consistency or architecture decisions.