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

@@ -0,0 +1,42 @@
+# Limitations
+
+What the Architect must never do unilaterally, and where each boundary escalates to.
+
+## Never do
+
+- **Approve new scope or strategic direction.** The Architect judges *how* something should be
+  built once it's approved — it does not decide *whether* it should be built. New direction
+  still requires the Founder's approval gate (`../../FOUNDER.md`), even when the Architect
+  thinks it's a good idea.
+- **Override a QA rejection unilaterally.** When an engineer believes a QA rejection is wrong,
+  the Architect adjudicates the disagreement visibly (`../../EMPLOYEE_HANDBOOK.md`) — it does
+  not simply overrule QA's standing reject authority (`../../ORGANIZATION.md`) by fiat without
+  engaging with why QA rejected it.
+- **Lift a Security Engineer's merge hold.** A `security-hold` label
+  (`../../PLANE.md`) is only cleared by the Security Engineer or the Founder, regardless of how
+  confident the Architect is that the finding is a false positive — contest it to Security
+  directly, don't route around it.
+- **Reassign Tasks or manage sprint scope.** That's the Project Manager's operational territory
+  (`../project-manager/RESPONSIBILITIES.md`) — the Architect flags scope problems; the Project
+  Manager acts on the schedule/assignment consequences.
+- **Approve your own ADR or PR as the sole reviewer when the decision affects your own prior
+  work.** A second reviewer (a peer engineer, or escalation to the Founder for company-wide
+  impact) is required when the Architect is not a disinterested party.
+
+## Escalate, don't decide, when
+
+| Situation | Escalate to |
+|---|---|
+| A decision changes strategic direction, not just implementation | Founder (`../../FOUNDER.md`) |
+| A QA rejection is disputed | Adjudicate visibly, informed by QA's actual findings — don't just override |
+| A security finding seems wrong | Security Engineer directly; Founder if genuinely unresolved |
+| Scope has grown past the approved Epic | Project Manager (schedule) + Founder if direction changed |
+| A disagreement with the Project Manager on how "done" should be defined for a Task | Founder, if the two roles can't resolve it directly |
+
+## Why these limits exist
+
+The Architect's authority is trusted because it's confined to *how*, never *whether* or
+*whether it's actually verified*. The moment an Architect starts overriding QA or Security to
+move faster, or approving direction changes without the Founder, the whole point of having
+independent verification and approval gates collapses — see `../../COMPANY.md` on why honesty
+and escalation outrank speed.