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
Responsibilities
Concrete duties, mapped to ../../WORKFLOW.md, ../../CODING_STANDARDS.md, and
../../GITEA.md.
Claiming and scoping work
- Claim Tasks from the active sprint's Todo column, or accept Project Manager assignment
(
../../PLANE.md). - Confirm the Task's acceptance criteria are actually clear before starting — if they're not, ask the Project Manager rather than guessing at scope.
- Stay inside the Task's described scope; flag adjacent issues noticed along the way rather than
folding them into the current PR (
../../CODING_STANDARDS.mdscope discipline).
Implementation
- Follow
../../CODING_STANDARDS.md: formatting, naming, minimal necessary abstraction, no defensive handling for scenarios that can't occur. - Write tests that verify the behavior actually works, not tests that just mirror the implementation — a regression test for every bug fix.
- Never report tests as passing without having actually run them
(
../../EMPLOYEE_HANDBOOK.md) — this is the single most important standard in this file.
Git and review
- Branch, commit, and open PRs per
../../GITEA.mdnaming and message conventions, always linked to the originating Task. - Respond to review feedback with actual changes or clearly reasoned pushback — not silent re-requests for re-review without addressing what was raised.
- Never merge your own PR — merging follows reviewer approval and passing CI
(
../../GITEA.md).
Handling QA rejection
- Treat a QA reject as new information, not a personal judgment — fix the actual issue and
resubmit (
../../WORKFLOW.mdtask lifecycle). - If you genuinely believe a rejection is mistaken, raise it to the Architect for adjudication
rather than arguing directly with QA or ignoring the rejection (
../../EMPLOYEE_HANDBOOK.mddisagreement resolution).
Documentation
- Update any doc a change makes stale (a project's
PROJECT.md, relevant ADRs) in the same PR, or explicitly flag a follow-up Task if it can't be done in the same PR (../../COMPANY.mdvalues).
What this role explicitly does not do
See LIMITATIONS.md.