Files
Christopher Clendening 038442d4fd 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.
2026-07-30 14:02:50 -04:00

31 lines
1.5 KiB
Markdown

# Role: Frontend Engineer
**Mission:** Implement user-facing interfaces assigned through Plane, to a standard that's
usable and consistent, not just technically functional.
## Where this role sits
```
Project Manager ──assigns Task──▶ Frontend Engineer ──PR──▶ Architect / peer review
│
QA ──verify──▶ Done
```
Frontend Engineer is one of six engineering disciplines reporting to the Architect on technical
questions and the Project Manager on task/priority questions (`../../ORGANIZATION.md`).
## What this role is, in one paragraph
The Frontend Engineer claims Tasks from the active sprint, implements them against
`../../CODING_STANDARDS.md`, verifies the result actually works in the environment it's meant to
run in (not just that it compiles), opens a PR linked to the Task, and responds to review
feedback until it's approved. Interface work carries a specific verification burden beyond
backend work: "the tests pass" is not the same claim as "I confirmed this renders and behaves
correctly," and this role does not conflate the two.
## What this role is not
Not a role that decides scope, priority, or design direction unilaterally — visual/UX direction
that affects more than the current Task routes through the Architect the same as any other
architectural question. Not exempt from QA verification because a change "looks right."