For Stakeholders

_The why-it-matters, risk, and impact view — for engineering leads, product owners, and anyone deciding whether this direction is sound._

What this changes, in a sentence

The AI QA pipeline that runs on every pull request moves out of GitHub and into Jira/Confluence, and its phases are restructured around required human approval gates (prepare → test → retest → fix), while the workflow code that glues it together shrinks by ~189 lines.

Why it matters

1. QA now lives where the QA team works

Test cases become Jira Stories on an epic — assignable, filterable, statused, commentable — instead of a pile of GitHub issues that no one triages. Reviews and living test reports become Confluence pages. The pull request goes quiet: one summary comment with two links.

2. Human governance is now structural, not optional

The old pipeline had a full-auto mode that ran review → plan → test → fix unattended. This PR removes it. Every phase is a deliberate manual dispatch, with a documented human gate between them (edit the epic; comment on tickets). For a system that can push code to a branch, making human approval a required step is the responsible design — and it's now enforced by structure, not convention.

3. Lower maintenance surface

189 lines of bespoke GitHub-issue orchestration are deleted. The workflow's remaining job is small and legible: dispatch a phase, post one comment, archive the run. Less code that can rot.

Impact

Dimension	Before	After
QA workspace	GitHub issues + PR comments	Jira epic + Confluence page
PR footprint	Review + plan + summary comments + N issues	One summary comment
Actions offered	review, plan, test, fix, full-auto (+scope)	prepare, test, retest, fix
Unattended run	`full-auto` existed	Removed — gated by design
Workflow LOC	—	−189 / +62

Risks — stated plainly

The real logic is off-repo and unversioned here. The agent (/opt/homelab/sandbox/bin/sandbox-qa) and the Jira/Confluence integration (qa-agent/atlassian-qa.py) live on the homelab, not in this repository. This diff only wires up to them via KEY=VALUE outputs. Changes to that integration won't show up in this repo's history or code review. This is the main governance gap — the most consequential behavior is the least visible.

Silent-no-op on missing PR. If QA is dispatched on a branch without an open PR, the work runs but nothing is posted (.github/workflows/sandbox-qa.yml:86). Low severity, but a first-time user may think it "did nothing."

New external dependencies. Jira and Confluence availability and API tokens now sit on the critical path for QA visibility. If Atlassian auth breaks, the phases may run but produce no visible epic/page (the workflow guards for this — links are optional, :95-96 — so it degrades to a link-less comment rather than failing).

Broad permissions retained. contents: write is needed only by fix, yet it's granted to every phase (:48-51). Not a new risk (it was there before), but worth a least-privilege note.

Trust in AI-authored fixes. fix commits to the PR branch. The mitigation is that fixes target only human-confirmed FAIL tickets and are retested — but a reviewer should still read fix commits, not rubber-stamp them.

Why the risks are acceptable

The human gates bound the blast radius: nothing gets "planned as truth" or "fixed" without a person acting.
It's unreleased and internal — it affects the team's own workflow, never a live clinic.
The workflow degrades gracefully — missing outputs produce a smaller comment, not a failure.
The off-repo concern is real but is a pre-existing architecture (the sandbox CLI already lived there); this PR follows the established pattern rather than inventing a new one.

The recommendation

A sound, restraint-forward direction: it puts QA in the right tools, makes human oversight mandatory, and deletes code. The one thing to watch is the off-repo integration — ensure atlassian-qa.py and sandbox-qa are themselves versioned, reviewed, and monitored somewhere, since this repo can't see them.