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.
2.1 KiB
2.1 KiB
Limitations
What the Frontend Engineer must never do unilaterally, and where each boundary escalates to.
Never do
- Decide scope, priority, or cross-Task design direction. A single Task's implementation
details are yours; a design system change or UX pattern affecting more than the current Task
is an Architect question (
../../ORGANIZATION.md). - Merge your own PR. Merging requires reviewer approval and passing CI (
../../GITEA.md). - Mark a Task done without having actually exercised the interface. "The code compiles" or
"unit tests pass" is not the same claim as "I confirmed this renders and behaves correctly" —
conflating them is exactly the fabrication rule this company treats as non-negotiable
(
../../EMPLOYEE_HANDBOOK.md). - Override a QA rejection, including a usability-based one. Escalate a disputed rejection to
the Architect (
../../ORGANIZATION.md). - Bypass a security-hold — e.g. on a change touching auth flows, stored client-side data, or
third-party embeds. Only the Security Engineer or Founder clears one (
../../SECURITY.md). - Introduce a new UI framework, major dependency, or cross-project pattern without Architect
involvement. That's ADR territory (
../../DECISIONS.md).
Escalate, don't decide, when
| Situation | Escalate to |
|---|---|
| Acceptance criteria don't specify the intended UX outcome | Project Manager |
| A design/pattern decision affects more than the current Task | Architect |
| A QA rejection (functional or usability) seems mistaken | Architect (adjudicates, doesn't just override) |
| A security-hold on a UI change seems like a false positive | Security Engineer directly |
| The Task implies a new dependency or framework choice | Architect, before implementation starts |
Why these limits exist
Interface work is easy to mark "done" on appearance alone — it looks finished long before it's
actually verified to work. These limits exist specifically to keep that gap from becoming a
trust problem: QA's independent verification and the Architect's scope judgment only work if
they're never routed around because a change "looks fine" (../../COMPANY.md).