delivery-quality-gates

Delivery Quality Gates

Development work is not complete when code compiles. Every implementation must move through developer verification, QA review, automation planning, and evidence capture.

Developer Gate

• Developer delivers code with unit tests for new or changed business logic.
• Unit tests must cover success paths, failure paths, and relevant boundary cases.
• Developer must run the focused unit test suite and report the exact command and result.
• If unit tests are not feasible, Developer must document the technical reason and propose the smallest testable refactor.
• Developer must address API, data, frontend, performance, concurrency, config, and AI-assisted development rules when the change touches those areas.

QA Gate

• QA receives the Developer handoff before release approval.
• Workflow gate approval is not a status shortcut. po→architect can be approved only when the issue/task has user-validated scope, non-goals, assumptions, priority, acceptance criteria, and sizing context. qa→release can be approved only after real implementation evidence, QA findings, BA/PO acceptance, and Architect review when technical contracts changed.
• Generated handoffs with Acceptance Criteria: none are incomplete for release purposes. Pull the criteria from the linked GitHub issue or Orchestra task, record a review finding, and block release until the criteria/evidence gap is fixed or explicitly risk-accepted by the Product Owner.
• QA must produce a test plan covering acceptance criteria, regression areas, edge cases, data setup, and environment assumptions.
• QA must block test planning when acceptance criteria are fragmented, non-verifiable, or only role/phase headings. Return those findings to PO/BA before release evidence is generated.
• QA plans must include an AC-to-evidence matrix with expected observable result, actual result, artifact/command, and pass/fail/deferred status for each acceptance criterion.
• QA must validate that the planned tests exercise the actual risk, not a weaker surrogate. For scope/split, handoff, workflow, runtime, queueing, failback, or release-gate bugs, the test data must create the condition that should trigger the guardrail.
• QA must block when the plan substitutes a weaker surface for the requested behavior, such as browser smoke for workflow/CLI behavior, command execution without stdout/files/events checks, or API response checks without receiver-side effects for integrations.
• QA must execute or explicitly defer each test case with a reason.
• QA findings must include severity, reproduction steps, expected result, actual result, and evidence.
• QA execution must be reviewable through a sprint-review-style evidence demo before release approval. Analyst/BA compares the executed evidence against the GitHub issue, user story, acceptance criteria, and Orchestra task; Architect reviews whether the tests cover architecture contracts, boundaries, integrations, data flow, and risk areas.
• Analyst/BA must record comments on the GitHub issue/user story and the Orchestra task when evidence does not prove the requested behavior, acceptance criteria, or business workflow. Those findings block release until fixed or explicitly accepted as risk by the Product Owner.
• QA approval is incomplete when only QA signs off on execution. Record Analyst/BA and Architect review outcomes, or document why a role is not applicable with Product Owner acceptance.