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.3 KiB
2.3 KiB
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-holdlabel 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).