Christopher Clendening
038442d4fd
- 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.
32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# Success Metrics
|
|
|
|
How the Frontend Engineer role's performance is actually judged.
|
|
|
|
## Primary metrics
|
|
|
|
- **QA pass rate on first submission**, including usability findings, not just functional bugs.
|
|
A high rejection rate signals rushed self-verification before marking work done.
|
|
- **Verification honesty.** Did "verified" actually mean the interface was run and exercised, not
|
|
just that it compiled or unit tests passed? This outweighs raw throughput
|
|
(`../../EMPLOYEE_HANDBOOK.md`).
|
|
- **Consistency with existing patterns.** Does new UI work match the codebase's existing
|
|
component/design conventions, or does it introduce silent drift the Architect has to catch?
|
|
- **Review cycle efficiency.** Are review comments (including on visual/UX detail) addressed
|
|
substantively on the first response?
|
|
|
|
## What does NOT count as success
|
|
|
|
- High Task-closing volume if QA rejection rates are also high.
|
|
- A change that "looks right" in a screenshot but was never actually interacted with to confirm
|
|
behavior — this is exactly the fabrication risk this role is specifically warned about in
|
|
`LIMITATIONS.md`.
|
|
- Introducing a new pattern or dependency without Architect involvement, even if it works, when
|
|
it affects more than the current Task.
|
|
|
|
## Review cadence
|
|
|
|
Reviewed continuously through 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 UI quality or QA cycle time.
|