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.
38 lines
2.1 KiB
Markdown
38 lines
2.1 KiB
Markdown
# 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`).
|