feat(aidd-orchestrator): add independent acceptance QA before draft pull requests

Start with the SDLC flow in plugins/aidd-orchestrator/skills/01-sdlc/, then read the Acceptance QA hardening from #918, the developer journey in plugins/aidd-dev/skills/06-test/, and pull-request evidence in plugins/aidd-vcs/skills/02-pull-request/. Trace the existing Review, Challenge, and draft pull-request flow before defining the provider, routing, artifact ownership, and installation checks. Done means the listed passing, failing, blocked, skipped, artifact, and end-to-end fixture criteria are verified without treating developer-side evidence as acceptance evidence.

Problem

aidd-orchestrator:01-sdlc currently hands a committed candidate from Deliver to an independent Review, then Challenge, then a draft pull request. It never invokes aidd-qa:01-acceptance-qa, so a browser-facing change can reach the draft pull request without the independent qa.md and video evidence introduced in #917.

The existing aidd-dev:06-test browser journey is intentionally developer-side. It provides fast implementation feedback before the candidate is committed and must not become the owner of final acceptance evidence.

Two integration constraints also need an explicit contract:

• aidd-qa is still outside the recommended installation path;
• the independent checker cannot currently invoke aidd-qa or write its report artifacts.

Outcome

As a developer running the autonomous SDLC, I want browser-observable acceptance criteria independently exercised before a draft pull request is opened, so the pull request carries trustworthy acceptance evidence and failures return to the correct delivery stage.

Dependency

• Blocked by #918. Complete the Acceptance QA hardening before enabling it as an SDLC gate.

Ownership decision

• Keep aidd-dev:06-test test-journey in Deliver for developer-side feedback during implementation.
• Make aidd-qa:01-acceptance-qa the sole owner of durable acceptance evidence: qa.md and final qa/*.webm files.
• A developer-side journey report or screenshot never satisfies the Acceptance QA gate.

SDLC flow

Extend Check to run this sequence:

1. Review the committed candidate with the existing fresh checker.
2. When Review has no actionable finding, let that checker invoke aidd-qa:01-acceptance-qa against the same contract and candidate.
3. Permit the checker to write only the report and media paths owned by Acceptance QA. It must never edit the product, contract, plan, or validator.
4. Route the Acceptance QA result:
   • pass: continue to Challenge with qa.md and the final videos as evidence;
   • skipped: continue to Challenge with the skip report when no browser-observable criterion exists;
   • fail: return the product mismatch to Deliver for repair;
   • blocked by ambiguous or incomplete criteria: return to Frame;
   • blocked by environment, permissions, dependencies, or tooling: stop with the exact blocker and required user action instead of dispatching a code repair.
5. After Acceptance QA and Challenge both clear, verify that every new worktree change is an Acceptance QA artifact. Any product or validator change re-enters Review.
6. Commit the accepted QA artifacts, then open the draft pull request.

Failed or blocked evidence remains available during the repair cycle but is not committed as final pull-request evidence. A subsequent Acceptance QA run replaces it with the result for the repaired candidate.

Provider availability

• After #918 is complete, move aidd-qa into the recommended installation path and update the documented stable-plugin count and installation guidance.
• Keep the SDLC's provider check. If aidd-qa:01-acceptance-qa is unavailable, stop with the shortest installation instruction; never skip the gate silently.

Pull request evidence

• Pass qa.md and every final qa/*.webm path to aidd-vcs:02-pull-request.
• Extend the pull-request draft contract to link qa.md as well as its existing video links under the testing or verification section.
• The pull-request summary states pass or skipped; it never presents a failed or blocked run as cleared.

Acceptance criteria

• aidd-dev:06-test test-journey remains developer-side and produces no artifact that can satisfy the independent Acceptance QA gate.
• After #918, aidd-qa is included in the recommended installation path and the affected installation documentation is consistent.
• An SDLC run verifies that aidd-qa:01-acceptance-qa is available before depending on it and reports one actionable installation blocker when it is absent.
• A committed candidate with browser-observable acceptance criteria runs Acceptance QA after Review clears and before Challenge.
• The independent checker may invoke Acceptance QA and write only its owned qa.md and final video artifacts.
• pass and skipped supply their report to Challenge; fail, criteria-blocked, and operationally blocked results follow the routing defined above.
• No failed or blocked run reaches draft pull-request creation as a cleared gate.
• After Challenge clears, only Acceptance QA artifacts may be committed without repeating Review.
• The draft pull request links qa.md and every changed final qa/*.webm file.
• A non-browser change can produce skipped without running browser prerequisites or recording video.
• An end-to-end SDLC fixture proves both the passing browser-change route and one failure route back to Deliver.

Out of scope

• API or CLI QA interfaces.
• The Acceptance QA behavior gaps owned by #918.
• Removing developer-side browser journey testing.
• Automatically installing a missing plugin during an SDLC run.

References

• Acceptance QA plugin: #917
• Acceptance QA hardening: #918
• SDLC flow: plugins/aidd-orchestrator/skills/01-sdlc/
• Developer-side journey: plugins/aidd-dev/skills/06-test/
• Pull-request evidence: plugins/aidd-vcs/skills/02-pull-request/