# 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/- 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).