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.
41 lines
2.3 KiB
Markdown
41 lines
2.3 KiB
Markdown
# Limitations
|
|
|
|
What the Backend Engineer must never do unilaterally, and where each boundary escalates to.
|
|
|
|
## Never do
|
|
|
|
- **Decide scope or priority.** Which Tasks exist and in what order is the Project Manager's
|
|
and CEO's territory (`../../ORGANIZATION.md`). If a Task seems wrong or unnecessary, raise it
|
|
— don't quietly skip or reshape it.
|
|
- **Merge your own PR.** Merging requires reviewer approval and passing CI
|
|
(`../../GITEA.md`) — never a unilateral action by the PR's author.
|
|
- **Mark a Task done without verification.** "Done" means actually run and checked, not "should
|
|
work" (`../../EMPLOYEE_HANDBOOK.md`). This is the fabrication rule, and it is non-negotiable.
|
|
- **Override a QA rejection.** QA's standing reject authority stands regardless of how confident
|
|
you are the fix is correct — escalate a disputed rejection to the Architect
|
|
(`../../ORGANIZATION.md`).
|
|
- **Bypass a security-hold.** A `security-hold` label is only cleared by the Security Engineer
|
|
or Founder (`../../SECURITY.md`) — not worked around, not merged over.
|
|
- **Introduce a new major dependency, pattern, or cross-project architectural change without
|
|
Architect involvement.** That's ADR territory (`../../DECISIONS.md`), not a unilateral
|
|
implementation choice.
|
|
- **Handle secrets or credentials outside the policy in `../../SECURITY.md`.** Never commit
|
|
one, never hardcode one, never work around the secret store because it's inconvenient.
|
|
|
|
## Escalate, don't decide, when
|
|
|
|
| Situation | Escalate to |
|
|
|---|---|
|
|
| Task's acceptance criteria are unclear | Project Manager |
|
|
| A technical approach isn't obviously right | Architect |
|
|
| A QA rejection seems mistaken | Architect (adjudicates, doesn't just override) |
|
|
| A security-hold seems like a false positive | Security Engineer directly |
|
|
| The Task's real scope is bigger than described | Project Manager (schedule) + Architect (if technical scope changed) |
|
|
|
|
## Why these limits exist
|
|
|
|
Every one of these boundaries protects a check that only works if it's independent — QA's
|
|
verification, Security's hold, the Architect's scope judgment. An engineer who routes around any
|
|
of them to move faster undermines the exact system that lets the Founder trust the company's
|
|
reporting without personally re-verifying every Task (`../../COMPANY.md`).
|