On this page
What this is, in one pageThe four phasesWhat's actually in this pull requestWhy it was worth doingWhere to go nextJira/Confluence QA Pipeline
_PR #355 · ci(sandbox): QA pipeline moves to Jira/Confluence (prepare / test / retest / fix) · branch ci/qa-jira-confluence_
Status: unreleased. This is an internal engineering-workflow change. It ships nothing to dental clinics or their patients — it changes how the Dentolize team reviews its own pull requests before they merge. Nothing below is a customer-facing product feature.
What this is, in one page
Every Dentolize pull request already gets a temporary live copy of the app — a "sandbox" at https://<branch>.sandbox.anastawfik.com — so reviewers can click through the change before it merges. On top of that sandbox sits an AI QA agent: it reads the code, invents test cases, drives the sandbox with a real browser (Playwright), and reports what passed and what broke.
This PR relocates where that QA work lives and how a human steers it. Before, the whole conversation happened on the GitHub pull request — a review comment, a plan comment, and one GitHub issue per test case. After this PR, the QA agent writes into the team's Atlassian tools instead:
- a Confluence page — the readable review and a living test report, and
- a Jira epic — one Story ticket per test case, which is now the QA team's actual workspace.
The GitHub pull request keeps just one short summary comment that links out to those two places.
The four phases
QA is no longer one big button. It's a sequence of phases you dispatch by hand from the GitHub Actions tab, with the QA team steering between them:
| Phase | What it does | Human gate after |
|---|---|---|
| prepare | Deep code + business review and an exhaustive list of user stories → writes the Confluence page and the Jira epic (one Story per test case). | Edit the epic in Jira — delete nit-picks, refine or add Stories. What the epic says at dispatch time is the test plan. |
| test | Playwright-tests the epic's current Stories on the sandbox. Per ticket: result comment, screenshots, status change (PASS → Done, FAIL → In Progress + failed label). Files Bug tickets for real problems that weren't in a Story. | Review the board, comment on tickets. |
| retest | Re-tests every ticket that isn't Done, plus any ticket with new human comments (read as instructions). Never commits. | Read results, comment again. |
| fix | Fixes confirmed FAIL tickets on the PR branch ([skip ci], then self-redeploys and retests). Moves them to Done with the commit reference. | — |
The heart of the design is those QA gates: the pipeline pauses between phases and treats a human's edits and comments as the source of truth for what runs next. See The Human QA Gates.
What's actually in this pull request
Be precise about scope — this matters for reviewing it honestly:
- The diff is one file:
.github/workflows/sandbox-qa.yml, +62 / −189 lines. It is a net deletion — the workflow got dramatically simpler. - The GitHub Actions workflow now does three things: (1) dispatch the agent for one phase, (2) read a handful of outputs it emits, (3) upsert one PR summary comment linking to Jira and Confluence, then (4) upload the run's state as an artifact.
- The intelligence is not in this repo. The agent runner (
/opt/homelab/sandbox/bin/sandbox-qa) and the deterministic Jira/Confluence integration (qa-agent/atlassian-qa.py, referenced in the header comment) live on the homelab infrastructure, not in this diff or this repository. Everything this PR asserts about Jira Stories, Confluence tables, screenshots-per-ticket, and Bug tickets is implemented over there and only wired up here.
Where the PR description and the committed code disagree, this walkthrough documents the code and flags the gap. The most important one: the PR body describes a rich Jira/Confluence experience, but the only Atlassian-related thing the workflow file itself contains is reading two output URLs (JIRA_EPIC_URL, CONFLUENCE_URL) and printing them into a comment. See Workflow Internals and For Quality.
Why it was worth doing
- QA belongs in the QA tool. A Jira epic is a board the QA team already lives in — assignable, filterable, commentable — instead of a wall of GitHub issues nobody triages.
- Humans stay in the loop by design. The old flow let you edit a comment; the new flow makes editing the Jira epic a required, first-class step. The machine proposes; a person disposes.
- The PR gets quieter. One summary comment with two links, instead of a review comment, a plan comment, a summary comment, and N issues.
- Less code to maintain. 189 lines of issue-wrangling GitHub-script deleted.
Where to go next
- New to the whole idea? Read The Four Phases.
- Want to see the sandbox the agent drives? Feature Tour.
- Reviewing this PR? For Quality and What Changed.
- Explaining it to someone? Pick your hat under By team in the sidebar.