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.
50 lines
2.1 KiB
Markdown
50 lines
2.1 KiB
Markdown
# 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.md` scope 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.md` naming 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.md` task 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.md`
|
|
disagreement 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.md` values).
|
|
|
|
## What this role explicitly does not do
|
|
|
|
See [LIMITATIONS.md](LIMITATIONS.md).
|