/test-automation

el mapa — índice mental del deck

Plan → Code → Review, con sus gates

Cada fase del mapa = una sección de este deck, en el mismo orden.

mode routing: se resuelve antes del preflight

Dos modos: automate escribe, explain solo lee

> /test-automation <KEY>               # automate
> /test-automation explain <scope>     # explain

antes de nada — qué entra y a qué tamaño

Elige el scope primero, una sola vez

Ante la duda, PREGUNTA al usuario. Nunca asumas "module" solo porque aparecen varios IDs de TC en el briefing.

gate 0 · readiness preflight — MANDATORY, corre antes que todo

Está todo listo para escribir y correr código?

phase 0 · resume check, inline y sin subagente

Hay una sesión previa? Retómala, no la repitas

phase 1 · plan — lo que se lee, en este orden

El manifest primero; la Story completa, después

• kata-manifest.json (root). Cruza cada TC ID contra los @atc existentes y cada nombre de componente contra el registro. Coincide? Reusa o extiende — NUNCA dupliques. Husky lo refuerza en pre-commit.
• Doctrina KATA. references/kata-architecture.md + typescript-patterns.md — capas, identidad del ATC, fixtures, aliases.
• tests/components/. Las formas Api / Page / Steps que ya existen en disco — naming y patrones a seguir.
• La Story sincronizada. bun run jira:sync-issues get <KEY> --include-comments → lee la carpeta ENTERA: ACs, scope, business rules Y comments.md. NUNCA acli view para customfield_* (devuelve null).
• El ATP, según la modalidad TMS (testing.tms_cli en .agents/project.yaml). jira-native: el campo acceptance_test_plan del Story, sincronizado como acceptance-test-plan.md. jira-xray: la description del Test Plan «ATP: …» (lo crea /sprint-testing en Planning), vía bun run jira:sync-issues get <ATP_KEY> → test-plans/ATP-<KEY>-<slug>.md; los resultados por TC salen del TMS, no del sync.
• api/schemas/ + .env. Types de OpenAPI (refresca con bun run api:sync); credenciales vía config.testUser — jamás hardcodear.

phase 1 · plan — lo que se escribe, y el gate humano

Un plan que responde 5 preguntas — y espera tu sí

• 1 · Escenarios: cuáles se vuelven tests, cuáles ATCs, cuáles preconditions compartidas (Steps)?
• 2 · Componentes: qué *Api.ts / *Page.ts ya existen y cuáles se crean?
• 3 · Datos: clasificados Discover / Modify / Generate — nunca asumas que existen en staging.
• 4 · Fixture: {api}, {ui} o {test} — los Steps no tienen fixture: se instancian directo.
• 5 · Trazabilidad: qué ATC ID del TMS mapea a qué método del componente.

craft del plan · test-design doctrine — binding

Cubrir los ACs es el piso, no la meta

Canon: agentic-qa-core/references/test-design-doctrine.md — carga MANDATORY antes de derivar ATCs desde ACs. Nunca reportes "% de ACs verificados" como completitud.

craft del plan · estrategia de datos — se clasifica al PLANEAR

Discover → Modify → Generate (prioridad estricta)

phase 2 · code — orden de construcción innegociable

Types → componente → fixture → test → verificar

$ bun run test tests/e2e/checkout/processCheckout.test.ts   # pasa? (0 retries)
$ bun run types:check                                       # tsc --noEmit, sin errores
$ bun run lint:check                                        # ESLint, sin errores
$ bun allure:agent                                          # opcional: reporte markdown por bloque @atc

Dispatch Sequential: un subagente de Code por unidad de scope (module: 1 por TC · ticket: 1 total). Cada uno carga /playwright-best-practices junto a esta skill y retorna archivos cambiados + resumen (el orquestador nunca lee diffs). Si además necesita manejar un browser real (snapshot, trace, record), suma /playwright-cli, el único camino de browser, con sesión con nombre según agentic-qa-core/references/browser-sessions.md.

craft del code · la arquitectura — nunca colapses capas (T3)

Las capas KATA, de abajo hacia arriba

craft del code · selección de fixture — carga estructural

El fixture decide si se abre un browser

craft del code · las reglas que deciden el review

Reglas ATC — los rechazos más comunes

phase 2 · code — la forma de un componente API (L3)

Helper sin decorator, ATC con @atc

export class OrdersApi extends ApiBase {
  private readonly baseEndpoint = '/api/v1/orders';

  @step                                  // helper — read-only, sin @atc
  async getOrderById(id: string): Promise<[APIResponse, Order]> {
    return this.apiGET<Order>(`${this.baseEndpoint}/${id}`);
  }

  @atc('UPEX-411')                        // ATC — muta estado, trazado al TMS
  async createOrderSuccessfully(payload: CreateOrderRequest) {
    const [response, body, sent] = await this.apiPOST(this.baseEndpoint, payload);
    expect(response.status()).toBe(201);   // assertion FIJA — vive en el ATC
    expect(body.id).toBeDefined();
    return [response, body, sent];        // 3-tupla: permite encadenar
  }
}

GET / DELETE retornan 2-tuplas; POST / PUT / PATCH retornan 3-tuplas (comparar lo enviado vs lo recibido). Test files: {verb}{Feature}.test.ts e importan de @TestFixture, nunca de @playwright/test.

phase 3 · review — el gate de merge

Tres Verifiers en paralelo; cero blockers para aceptar

después del accept: quién hace el git, y contra qué base

La skill se detiene en un review local limpio

Local gate green. Ready for /git-flow-master: cut test/UPEX-411-checkout
from the integration trunk, push, Sanity-CI, PR into the trunk, merge --no-ff.

Después, en el pipeline: /regression-testing (Regression) corre las suites en CI y emite GO / CAUTION / NO-GO.

tres transiciones que esta skill es dueña

El TC avanza con el código, y llega a Automated solo en la rama de producción

a escala · batch fleet, segundo ejecutor opcional

Un lote corre en serie; en paralelo solo si los módulos no se tocan

Por defecto un batch corre en esta sesión, un Work Package a la vez, Plan → Code → Review cada uno. La flota se ofrece solo si la pides o si el lote tiene 3+ Work Packages sobre módulos disjuntos; nunca se entra en silencio.

light stage verifier · cierra el stage Automation

Antes de decir "listo", ocho líneas en YES o N/A

[ ] TCs del scope en in_automation o más allá
    (start_automation disparado)
[ ] Cada ATC lleva la clave de su TC; ningún Test automatizado aparte
[ ] Labels cambiados en su estado: +automated
    -automation-candidate en merged, nunca
    en el merge al trunk
[ ] Ningún TC en candidate con código ya escrito
[ ] Slug sin mapear pasó por el fallback §4
    (se preguntó), nunca un salto silencioso

Canon: agentic-qa-core/references/artifact-lifecycle.md §5. Va después del ACCEPT de Phase 3 y del verificador separado; con REJECT no se llega aquí.

session footer · gate de calidad del cierre, solo en el chat

La sesión no termina hasta imprimir dos bloques

Testing levels touched:
- API: cobertura automatizada nueva en OrdersApi (L3 component) + spec
- E2E/UI: none (fuera del scope de este ticket)
- Unit: none
Refinements proposed: 0

quién decide qué — el contrato de Automation

El agente ejecuta. La evidencia prueba. La persona decide.

• El agente hace: escribe spec.md + automation-plan.md, después el código KATA con @atc, corre los tres verificadores y deja el handoff a /git-flow-master, que abre el PR contra la base de git_strategy:. /test-automation nunca corre git por su cuenta.
• La persona firma: el plan antes de una línea de código, el merge, y la llamada en el tercer loop de revisión.
• La evidencia que sobrevive: tests verdes, types limpios, lint limpio, ids @atc que resuelven a tickets reales, manifest fresco.
• Autonomía CSA 2 → 3, y solo dentro del plan aprobado. Solo Regression puede llegar a 4, en un GO limpio.
• Verificador separado: REQUERIDO. /pr-review-lead o /judgment-day, en contexto limpio. Automation es el único stage con esta obligación, a cambio de más autonomía a la entrada.

cierre — cómo invocarlo y qué deja

/test-automation — planéalo, codéalo por capas, pásalo en verde

← → navegar · O resumen · S presentador · N notas · F pantalla completa