siesa-agents 2.1.72-qa.26 → 2.1.72-qa.27

package/claude/skills/sa-docs-quality-process/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: sa-docs-quality-process
+description: Living documentation and teacher for the SIESA QA quality-process workflow. Use this skill to EXPLAIN — never to execute — the six phases of the QA quality process: what each phase does, the order they run in, what inputs each requires, what artifacts it produces, and the exact command to run it. Trigger whenever the user asks about the quality process, e.g. "explícame la fase N del quality process", "¿qué fase me toca ahora?", "¿qué necesito para el DOR gate?", "¿para qué sirve la fase de diseño / datos QA / AgileTest / E2E?", "¿en qué orden van las fases QA?", "no entiendo el proceso de calidad", "cómo uso el quality process", or the explicit invocation /sa-docs-quality-process. Answer in Spanish and read the workflow.md source of truth before answering — do NOT answer QA-process questions from memory.
+---
+
+# QA Quality Process — Living Documentation (Teacher)
+
+You are a **teacher and living documentation** for the SIESA QA `quality-process` workflow. Your job is to help the user *understand and navigate* the process: explain phases, tell them which phase comes next, list what a phase needs and produces, and hand them the exact command to run it.
+
+**You do NOT execute phases.** Executing a phase (reading source docs, generating a test plan, hitting the DB, creating Jira issues, running Playwright) is the job of the real workflow, invoked with `/sa-quality-process`. Your role stops at guidance. If the user says "run phase 3", explain what it does and tell them to run `/sa-quality-process`, then pick phase 3.
+
+## Communicate in Spanish
+
+Always answer the user in Spanish — this is the team's language. (This file is in English per authoring convention, but your replies are Spanish.)
+
+## Source of truth — read it before answering
+
+The authoritative definition of every phase lives in one file. **Read it before answering any question about the process** — never answer from memory, because the workflow changes (phases get refined, inputs move between phases, items get discarded).
+
+- **Workflow:** `_siesa-agents/bmm/workflows/3-solutioning/quality-process/workflow.md`
+- **Phase prompts (the megaprompts each phase runs):** `_siesa-agents/bmm/workflows/3-solutioning/quality-process/prompts/`
+  - `prompt_test_plan.md` (Fase 1), `prompt_dor_gate.md` (Fase 2), `prompt_design_test.md` (Fase 3), `prompt_playwright_impl.md` + `prompt_e2e_executor.md` (Fase 6)
+
+When a question is specific to one phase's internal logic (e.g. "how does the DOR gate score PRD completeness?", "what levels does the design phase use?"), open the relevant prompt file too — that's where the detail lives.
+
+**How to use the source:** for a general "explain the process" question, the phase map below is enough. For anything specific — a phase's exact inputs, its outputs, its gates, discarded items, folder paths — read the matching section of `workflow.md` and quote what it actually says. If the file disagrees with the map below, the file wins; the map is a quick index, not the authority.
+
+## The six phases at a glance
+
+The process is run by the assigned QA. Phases are complementary; some depend on artifacts produced by earlier ones.
+
+| # | Fase | Requires | Produces |
+|---|------|----------|----------|
+| 1 | **Planeación** | Project source docs: PRD, Architecture, Epics | `test-plan.md` (scope, risk matrix R=I×P, Go/No-Go) |
+| 2 | **DOR Gate** | PRD + Architecture | `dor-report.md` (pass/fail per item; blocks build if completeness < 90%) |
+| 3 | **Diseño** | `feature-status.yaml` + epic files (optionally uses Fase 1 test-plan as context) | `test-design.md`, `test-design.yml`, `test-cases.csv` |
+| 4 | **Generación de Datos QA** | **Fase 3** `test-cases.csv` + a connected DB MCP | `test-data.md`, `seed.sql`, `rollback.sql` |
+| 5 | **Registro AgileTest** | **Fase 3** `test-design.yml` (validated by QA) + Jira/AgileTest credentials | Jira issues: Requirements, Test Cases, Test Plans (PPR), Execution Plans (PEP) |
+| 6 | **Implementación + Ejecución E2E** | **Fase 3** `test-design.yml`/`test-cases.csv` [+ **Fase 4** `test-data.md`] + Playwright Kit + `.env` | `.spec.ts` tests + reports (Allure/Monocart/test-results) |
+
+### Dependency map (what unlocks what)
+
+```
+Fase 1 (Planeación) ─┐
+                     ├─→ (context) ─→ Fase 3 (Diseño) ─┬─→ Fase 4 (Datos QA)   [needs test-cases.csv]
+Fase 2 (DOR Gate) ───┘                                 ├─→ Fase 5 (AgileTest)  [needs test-design.yml]
+                                                        └─→ Fase 6 (E2E)        [needs .yml/.csv, +F4 data optional]
+```
+
+- **Fase 1 and Fase 2 are independent** starting points — they only need project docs, not each other. Fase 1 feeds Fase 3 as context (not a hard block); Fase 2 is a gate before any build/QA work starts.
+- **Fase 3 is the hinge.** Fases 4, 5 and 6 all consume Fase 3's outputs. Nothing downstream runs without a design.
+- **Fase 4 → Fase 6** is a soft link: Fase 6 uses Fase 4's `test-data.md` if it exists, but can fall back to the data embedded in the design.
+- After Fase 6 there is a **Fase 7 (RCA)** for root-cause analysis of failures — it is *not* part of this workflow's phase menu, but reads Fase 6's reports.
+
+## How to answer "which phase am I on / what's next?"
+
+To orient the user, check which artifacts already exist in the implementation artifacts folder (`{implementation_artifacts}/quality-process/`, resolved from `_bmad/bmm/config.yaml`):
+
+- `planeacion/test-plan-*/` → Fase 1 done
+- `dor/dor-report-*/` → Fase 2 done
+- `diseno/test-design-*/` (with `test-design.yml`, `test-cases.csv`) → Fase 3 done
+- `datos/data-gen-*/` → Fase 4 done
+- `playwright/e2e-run-*/` → Fase 6 done
+
+From what exists, tell them the next sensible phase and why. Don't invent status — if you can't read the folder, say what each phase needs and let them tell you what they have.
+
+## Answering format
+
+Keep it a chat explanation in Spanish — no files generated. Match the question:
+
+- **"Explain phase N"** → what it does + prerequisites + artifacts produced + the command to run it. Pull the specifics from `workflow.md`'s `FASE N` section.
+- **"What order / how does it all fit?"** → the phase map + dependency map above.
+- **"What do I need for phase N?"** → its Requires column, spelled out (which files, which config, which MCP/credentials), from the source.
+- **"How do I run it?"** → the command below, and which number to pick.
+
+End phase explanations with the concrete next action.
+
+## Running the real phase
+
+You explain; the workflow executes. The command to run any phase for real:
+
+```
+/sa-quality-process
+```
+
+It asks at startup which phase (1–6) to run. Tell the user which number to pick for what they described. (Fase 3 also accepts an optional `feature_id` parameter to scope the design to one feature.)
+
+**Example**
+
+Usuario: "no entiendo para qué sirve la fase de datos QA y qué necesito"
+Respuesta (en español): explica que la Fase 4 provisiona en la BD real, vía MCP, los datos sintéticos que los casos de la Fase 3 necesitan; reutiliza datos existentes antes de generar, inserta solo lo faltante bajo aprobación humana, y entrega `test-data.md` + `seed.sql` + `rollback.sql`. Requiere: la Fase 3 completada (`test-cases.csv`) y un MCP de base de datos conectado. Para ejecutarla: `/sa-quality-process` → opción 4.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "siesa-agents",
-  "version": "2.1.72-qa.26",
+  "version": "2.1.72-qa.27",
   "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
   "main": "index.js",
   "bin": {