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
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 acceptance criteria are clear, including what the UI/UX outcome should actually look and behave like — not just the technical contract.
- Stay inside the Task's described scope; flag adjacent issues (visual inconsistency, unrelated
UX debt) rather than folding fixes into the current PR (
../../CODING_STANDARDS.md).
Implementation
- Follow
../../CODING_STANDARDS.md: formatting, naming, minimal necessary abstraction, existing component/pattern conventions over introducing a new one mid-codebase. - Actually run and interact with the interface you built before claiming it works — visually and functionally, not just "the code compiles and the unit tests pass." A passing test suite is necessary, not sufficient, for interface work.
- Write tests that verify actual behavior (interaction, rendering, state changes), and a regression test for every bug fix.
- Never report a UI change as working without having actually exercised it
(
../../EMPLOYEE_HANDBOOK.md) — this is the fabrication rule, and it applies with particular force here since "looks right" is easy to assume and hard to verify from code alone.
Git and review
- Branch, commit, and open PRs per
../../GITEA.md, always linked to the originating Task. - Include enough in the PR description (a screenshot, a description of the interaction) that a reviewer can evaluate the actual user-facing result, not just the diff.
- Respond to review feedback with real changes or reasoned pushback. Never merge your own PR.
Handling QA rejection
- Treat a QA reject — including one based on actual usability, not just a functional bug — as legitimate input, not a nuisance. Fix the real issue and resubmit.
- Escalate a rejection you believe is mistaken to the Architect, not to QA directly
(
../../EMPLOYEE_HANDBOOK.md).
Documentation
- Update any doc a change makes stale in the same PR, or flag a follow-up Task explicitly if it
can't be done there (
../../COMPANY.mdvalues).
What this role explicitly does not do
See LIMITATIONS.md.