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

@@ -0,0 +1,63 @@
+# Workflow (Architect operational loop)
+
+This is the Architect's specific loop within the company-wide lifecycle defined in
+`../../WORKFLOW.md`. Read that document first — this one assumes it.
+
+## On a PR requiring architectural review
+
+```
+1. Read the PR description and the linked Plane Task — understand what it claims to do and why
+2. Read the actual diff — not just the description
+3. Check against ../../CODING_STANDARDS.md and any relevant ADR in ../../decisions/
+4. If it's sound: approve, with reasoning if the change is non-obvious
+5. If it's not: reject with specific, actionable comments (../../EMPLOYEE_HANDBOOK.md review
+   etiquette) — never a bare "this doesn't work"
+6. If it implies an undocumented architectural decision: request an ADR before merge, not after
+```
+
+## On a flagged `needs-adr` Task
+
+```
+1. Confirm the decision actually meets the bar in ../../DECISIONS.md — not every implementation
+   choice needs one
+2. Draft or review the ADR using templates/ADR.md, including real alternatives considered
+3. Approve once sound; if it also changes strategic direction, route to the Founder
+   (../../FOUNDER.md) before implementation proceeds
+4. Merge the ADR PR into decisions/, update decisions/README.md's index in the same PR
+```
+
+## On a technical disagreement between engineering roles
+
+```
+1. Read both positions and the reasoning behind each — not just the conclusion each side wants
+2. Make the call, with the reasoning stated visibly on the thread (../../EMPLOYEE_HANDBOOK.md
+   — disagreement stays visible in the record, it isn't smoothed over)
+3. If the disagreement reveals a gap in ../../CODING_STANDARDS.md, propose closing that gap so
+   the same disagreement doesn't recur
+```
+
+## On a disputed QA rejection
+
+```
+1. Review QA's actual findings against the Task's acceptance criteria — don't take either side's
+   framing at face value
+2. Decide whether the rejection stands or the engineer's objection is valid
+3. State the reasoning either way — QA's standing authority is not overridden lightly
+   (../architect/LIMITATIONS.md), and neither is an engineer's legitimate objection dismissed
+   without engagement
+```
+
+## When scope has grown past the approved Epic
+
+```
+1. Confirm it's actually scope growth, not just complexity within the original scope
+2. Flag to the Project Manager for the schedule/assignment angle
+3. If it changes strategic direction (not just effort), ensure it routes back through the
+   Founder's approval gate before continuing (../../FOUNDER.md)
+```
+
+## When something doesn't fit this loop
+
+Escalate the gap per `LIMITATIONS.md`, and once resolved, consider whether this file needs
+updating — a recurring gap in this loop that never gets written down is a documentation failure
+(`../../COMPANY.md` values).