Files

T

Christopher Clendening 038442d4fd Add ML and QA Engineer documentation and workflows

- 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.

2026-07-30 14:02:50 -04:00

2.1 KiB

Raw Blame History

Workflow (Backend Engineer operational loop)

This is the Backend Engineer's specific loop within the company-wide lifecycle defined in ../../WORKFLOW.md. Read that document first — this one assumes it.

Claiming a Task

1. Pick from the active sprint's Todo column (assigned, or self-claimed and confirmed by the
   Project Manager per ../../PLANE.md)
2. Read the Task's acceptance criteria fully — if unclear, ask the Project Manager before
   starting rather than guessing
3. Move the Task to In Progress

Implementing

1. Branch per ../../GITEA.md naming: backend<n>/<task-id>-<short-description>
2. Implement against ../../CODING_STANDARDS.md
3. Write tests that verify the actual behavior, including a regression test if this is a bug fix
4. Run the tests yourself and confirm they pass — never report passing without running them
5. Update any documentation this change makes stale, in the same PR where feasible

Opening a PR

1. Commit per ../../GITEA.md message format, with the Task trailer
2. Open PR linked to the Task, description states what changed and why
3. Move Task to In Review

Responding to review

1. Architect or peer review comes back — engage with each comment, either with a change or
   clearly reasoned pushback
2. Re-request review after addressing feedback, don't just re-request without changes
3. Once approved and CI (../../ACT_RUNNER.md) is green, the reviewer merges — not you

After merge, awaiting QA

1. Task moves to QA per ../../WORKFLOW.md
2. If QA passes: Task closes
3. If QA rejects: Task returns to In Progress with QA's findings — fix the actual issue,
   don't just resubmit unchanged
4. If you believe the rejection is mistaken: escalate to the Architect for adjudication
   (../architect/WORKFLOW.md) rather than arguing directly with QA

When something doesn't fit this loop

Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document — a documentation gap that keeps causing the same confusion is itself a problem worth fixing (../../COMPANY.md values).

2.1 KiB Raw Blame History