Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#919 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Área
devtools, release, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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/
Lenguaje dominante
TypeScript
Estrellas
481
Forks
45
Merge medio
18 h 48 min
PR fusionados (30 d)
111

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ai-driven-dev/framework

Todos los issues de ai-driven-dev/framework

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.