siesa-agents 2.1.72-qa.2 → 2.1.72-qa.21

package/claude/skills/sa-onboard-db/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: sa-onboard-db
+description: 'Generates the exact SQL block of GRANTs that must run in psql to enable the dev user on a new Cloud SQL schema, plus the connection command. Use whenever the user is provisioning a new database schema and needs the GRANT statements ready to copy-paste.'
+---
+
+> **Contexto de ejecución:** este skill asume que el cwd está dentro de la carpeta del workspace de despliegue (`_siesa-agents/devops/` en Siesa-Agents tras correr `/sa-init-devops`, o la raíz de un clon directo de `architecture-sa-devops`). Las rutas relativas (`environments/`, `terraform/`, `k8s/`, `scripts/`, etc.) se resuelven contra ese cwd.
+
+Genera el bloque SQL exacto de GRANTs que se debe ejecutar en psql para habilitar el usuario `dev` en un schema nuevo de Cloud SQL. También muestra el comando para conectarse.
+
+**Uso:** `/sa-onboard-db {schema} {owner-role}`
+
+**Ejemplo:** `/sa-onboard-db treasury treasury`
+
+**Schemas existentes y sus owner-roles:**
+| Schema | Owner role |
+|---|---|
+| `access_manager` | `accmgr` |
+| `segment` | `segments` |
+| `base_config` | `base_config` |
+| `tprt` | `third_party` |
+| `acct` | `accounting` |
+| `liquid_tax` | `liquid_tax` |
+
+---
+
+## Instrucciones
+
+Los argumentos son: `$ARGUMENTS`
+
+- `SCHEMA` = primer argumento
+- `OWNER_ROLE` = segundo argumento
+
+Lee `environments/dev.yaml` para obtener:
+- `PROJECT_ID` = `.gcp.project_id`
+- `INSTANCE` = `.database.instance_name`
+- `DB_NAME` = `.database.database_name`
+- `REGION` = `.gcp.region`
+
+---
+
+### Paso 1 — Mostrar el comando de conexión
+
+```bash
+# Conectarse a Cloud SQL via Auth Proxy
+./scripts/dev-connect.sh
+
+# O directamente con cloud-sql-proxy:
+cloud-sql-proxy {PROJECT_ID}:{REGION}:{INSTANCE} --port=5433 &
+
+# Conectar con psql (usar PGPASSWORD del entorno):
+psql "host=127.0.0.1 port=5433 dbname={DB_NAME} user=postgres"
+```
+
+### Paso 2 — Mostrar el bloque SQL a ejecutar
+
+```sql
+-- ============================================================
+-- Grants para schema: {SCHEMA}
+-- Owner role: {OWNER_ROLE}
+-- Ejecutar como: postgres
+-- ============================================================
+
+-- 1. Crear el owner role si no existe
+DO $$ BEGIN
+  IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = '{OWNER_ROLE}') THEN
+    CREATE ROLE {OWNER_ROLE};
+  END IF;
+END $$;
+
+-- 2. Crear el schema si no existe
+CREATE SCHEMA IF NOT EXISTS {SCHEMA} AUTHORIZATION {OWNER_ROLE};
+
+-- 3. Darle al usuario dev acceso al schema
+GRANT USAGE ON SCHEMA {SCHEMA} TO dev;
+GRANT ALL PRIVILEGES ON SCHEMA {SCHEMA} TO dev;
+
+-- 4. Permisos sobre objetos existentes
+GRANT ALL ON ALL TABLES IN SCHEMA {SCHEMA} TO dev;
+GRANT ALL ON ALL SEQUENCES IN SCHEMA {SCHEMA} TO dev;
+GRANT ALL ON ALL FUNCTIONS IN SCHEMA {SCHEMA} TO dev;
+
+-- 5. Permisos default para objetos FUTUROS (creados por migraciones EF Core)
+ALTER DEFAULT PRIVILEGES IN SCHEMA {SCHEMA}
+  GRANT ALL ON TABLES TO dev;
+
+ALTER DEFAULT PRIVILEGES IN SCHEMA {SCHEMA}
+  GRANT ALL ON SEQUENCES TO dev;
+
+ALTER DEFAULT PRIVILEGES IN SCHEMA {SCHEMA}
+  GRANT ALL ON FUNCTIONS TO dev;
+
+-- 6. Membresía del rol owner → dev puede hacer ALTER TABLE
+GRANT {OWNER_ROLE} TO dev;
+
+-- Verificar:
+-- \dn+ {SCHEMA}
+-- \dp {SCHEMA}.*
+```
+
+### Paso 3 — Notas importantes
+
+Muestra:
+
+```
+⚠️  NOTAS CRÍTICAS:
+
+  1. Usar psql, NO DBeaver — DBeaver falla con error 3F000 en GRANT DEFAULT PRIVILEGES.
+
+  2. El GRANT {OWNER_ROLE} TO dev es obligatorio.
+     Sin él, EF Core puede crear tablas pero no hacer ALTER TABLE en migraciones futuras.
+
+  3. El schema en IEntityTypeConfiguration DEBE usar "{SCHEMA}" (guión bajo),
+     nunca "{SCHEMA con guiones}" — genera un schema huérfano en PostgreSQL.
+
+  4. Después de ejecutar los grants, el primer deploy correrá las migraciones
+     automáticamente (db.Database.MigrateAsync() en Program.cs).
+
+  5. La contraseña del usuario postgres está en Secret Manager:
+       gcloud secrets versions access latest \
+         --secret="{SCHEMA}-dev-db-connection" \
+         --project={PROJECT_ID}
+```

package/claude/skills/sa-qa-data-generator/SKILL.md

@@ -1,19 +1,36 @@
 ---
 name: sa-qa-data-generator
 description: Generates synthetic data for QA testing by reading test case files (CSV/Excel) and querying the real database via MCP. Activate when the user provides a test case file and has a PostgreSQL or SQL Server MCP configured and connected.
-version: 1.0.0
+version: 1.1.0
 ---
 
 # Synthetic Data Engine for QA
 
+## Usage
+
+**Prerequisites**:
+- PostgreSQL (or SQL Server) MCP configured and connected to the DB
+- Dependency functions (`get_all_dependencies_json` / `dbo.GetAllDependencies_JSON`) installed in the DB
+- A CSV or Excel file with the test cases
+
+**Activation**: Provide the test case file and optionally indicate the functional process or module. The AI infers the business, confirms it with you, and does everything else automatically.
+
+**Output to disk**: Artifacts are written next to the test case file (or in `mcp_database/output/<business>_<date>/` if the user does not indicate another path): `insertion_plan.md` (reviewable plan written and approved BEFORE inserting), `test-data.md`, `seed.sql`, `rollback.sql`.
+
+---
+
 ## Role
 
 You are an automated synthetic data generator for QA testing. Your job is to:
 
 1. Read the test case file (CSV/Excel) provided by the user
-2. Query the real database via MCP to obtain schemas, dependencies, and existing data
-3. **Reuse existing QA data whenever it satisfies the test case.** Only generate and insert new data for cases that cannot be covered by what already exists
-4. Guarantee referential integrity, correct data types, and realistic values when insertion is required
+2. **Infer the business/domain the cases target and confirm it with the user before generating anything**
+3. Query the real database via MCP to obtain schemas, dependencies, and existing data
+4. **Reuse existing QA data whenever it satisfies the test case.** Only generate and insert new data for cases that cannot be covered by what already exists
+5. Guarantee referential integrity, correct data types, and realistic values when insertion is required
+6. **Deliver 3 artifacts on disk**: (a) `test-data.md` with the case→data relation, (b) `seed.sql` executable with the insertions, (c) `rollback.sql` that reverts exactly this run
+
+**Three mandatory deliverables** (in addition to the direct DB insertion): for every execution that generates data you must write `test-data.md`, `seed.sql`, and `rollback.sql` to disk. The `seed.sql` lets you reload the dataset into a fresh DB without re-running the whole process; the `test-data.md` is designed so that later an AI agent (e.g., Playwright) can automate the cases by reading the literal values it must use per case.
 
 Do not invent schemas or columns. Everything you insert must be validated against the real database structure.
 
@@ -40,15 +57,15 @@ The user will provide a CSV or Excel file with test cases. The file may have dif
 
 ---
 
-## Execution Protocol — 7 Phases
+## Execution Protocol — 7 Phases (with approval gate at 5.5)
 
-Execute these phases in order. Do not skip any. Show the result of each phase to the user before proceeding.
+Execute these phases in order. Do not skip any. Show the result of each phase to the user before proceeding. There are **two mandatory stop gates**: business confirmation (Phase 1.A) and approval of `insertion_plan.md` (Phase 5.5) — at both you stop and wait for the user.
 
 ---
 
-### PHASE 1 — Test Case Reading and Analysis
+### PHASE 1 — Test Case Reading, Analysis and Business Inference
 
-**Objective**: Understand what is being tested and what data each case needs.
+**Objective**: Understand what is being tested, what data each case needs, and **which business/domain the cases target** — confirming it with the user before proceeding.
 
 **Actions**:
 1. Read the complete CSV/Excel file
@@ -61,7 +78,32 @@ Execute these phases in order. Do not skip any. Show the result of each phase to
    - Specific required values (amounts, dates, statuses, etc.)
    - Data preconditions
 
-**Output**: Summary table with: Case ID | Type | Entities involved | Critical required data
+**1.A — Business inference (confirmation GATE)**:
+
+From the language of the cases (products, processes, terminology, amounts, units), **deduce which type of business the data targets**. This guides the realism of the values generated (item names, customers, warehouses, plausible amounts for that industry).
+
+Present the inference to the user explicitly and **wait for confirmation**:
+
+```
+From the content of the cases, I deduce the data targets:
+  >> "A clothing store" <<
+Clues: items like "polo shirt", "regular t-shirt"; inventory-out process by
+warehouse; sizes/colors as attributes.
+
+Is this business correct?
+  - If you confirm, I will generate items, customers and amounts coherent with a clothing store.
+  - If not, tell me which business this data targets.
+```
+
+- If the user **confirms** → synthetic data is generated coherent with that business.
+- If the user **corrects** → use the business they indicate.
+- If the cases are too generic to infer a business → **ask the user directly** which business the data targets, instead of assuming.
+
+Record the confirmed business: it is used to name the output folder and as the header of `test-data.md`.
+
+**Output**:
+1. Business confirmed by the user
+2. Summary table with: Case ID | Type | Entities involved | Critical required data
 
 ---
 
@@ -230,11 +272,37 @@ MCP: read_data("SELECT 'table1' as table, COUNT(*) as records FROM schema.table1
 
 ---
 
+### PHASE 5.5 — Insertion Plan on disk (approval GATE — MANDATORY)
+
+**Objective**: Before touching the database, write a complete `insertion_plan.md` to disk and **wait for the user's approval**. This is a mandatory stop gate.
+
+**Why on disk and not in the terminal**: with high volumes the plan does not fit / cannot be reviewed comfortably in the terminal. In a file the user can read it calmly, validate it, and decide whether to approve or request changes. **Always** generate this plan when the run will insert data — never insert directly from the terminal-only summary.
+
+**Precondition**: If Phase 4 concluded "0 insertions required", skip this gate (there is nothing to plan) and go to Phase 7.4.
+
+**Actions**:
+
+1. Write `insertion_plan.md` next to the test case file (same output folder as the other artifacts) containing **everything that will be inserted**:
+   - Confirmed business (from Phase 1) and the run marker / `Run ID`.
+   - **Table by table, record by record**, in the Phase 3 insertion order (parents → children): table, schema, and the concrete values of each record to insert.
+   - Which cases are **REUSABLE** (0 insertions, with the existing IDs to use) vs. **PARTIAL** / **MISSING** (records to create).
+   - Totals: records per table and grand total to insert.
+2. Present the path to the user and **stop**:
+   ```
+   📄 Insertion plan written to: <path>/insertion_plan.md
+   Review it and reply: APPROVE to insert, or tell me the changes you want.
+   ```
+3. **Wait for explicit approval.** Do NOT proceed to Phase 6 until the user approves.
+   - If the user requests changes: adjust the generated data (back to Phase 5 as needed), **rewrite** `insertion_plan.md`, and ask for approval again.
+   - Only an explicit approval unlocks Phase 6.
+
+---
+
 ### PHASE 6 — Database Insertion
 
 **Objective**: Insert data into the database in the correct order.
 
-**Precondition**: If Phase 4 concluded "0 insertions required", skip this phase entirely and go to Phase 7.4.
+**Precondition**: If Phase 4 concluded "0 insertions required", skip this phase entirely and go to Phase 7.4. **If there are insertions, the `insertion_plan.md` of Phase 5.5 MUST have been approved by the user before inserting.**
 
 **Actions** (in strict Phase 3 order):
 
@@ -274,11 +342,21 @@ MCP: read_data("SELECT 'table1' as table, COUNT(*) as records FROM schema.table1
 
 ---
 
-### PHASE 7 — Report and Rollback Script
+### PHASE 7 — Deliverables: Report, test-data.md, seed.sql and rollback.sql
+
+**Objective**: Document everything inserted and produce the **three on-disk artifacts**.
+
+This phase produces, in addition to the on-screen report, **three files** written with the file-writing tool (not just chat blocks):
 
-**Objective**: Document everything inserted and provide a cleanup mechanism.
+| Deliverable | File | Purpose |
+|-------------|------|---------|
+| 1. Case→data relation | `test-data.md` | Which data to use/was created per case; grouping cases that share the same seed. Designed for an AI agent (Playwright) to automate the cases. |
+| 2. Executable seed | `seed.sql` | Idempotent, transactional insertions to reload the dataset into a fresh DB without re-running the process. |
+| 3. Rollback | `rollback.sql` | Reverts exactly what was inserted in this run, without touching prior QA data. |
 
-**7.1 Generated data report**:
+The three are written to the output path defined in Activation. After writing them, list the absolute paths of each file to the user.
+
+**7.1 Generated data report** (on screen):
 
 ```
 EXECUTION SUMMARY
@@ -304,40 +382,105 @@ TOTAL RECORDS REUSED: 7
 TEST CASES COVERED: 10/10 (100%)
 ```
 
-**7.2 Traceability matrix**:
+**7.2 Deliverable 1 — `test-data.md` (case→data relation, grouped)**:
+
+Write a Markdown file that states, **per case**, with which data it can be executed: which **already exist** and which **were created**. The goal is that ALL cases end with sufficient data associated and that an AI agent (Playwright) can read the **literal values** (codes, names, amounts) it must use in the UI — not just internal DB IDs.
+
+**Grouping rule (key)**: if several cases run with **exactly the same data seed**, do NOT repeat the data per case — group them in a single block (e.g., "Cases CP-001 to CP-010"). Only open individual blocks for cases with their own data (typically EDGE and NEGATIVE, which require specific values).
+
+File structure:
+
+```markdown
+# Test Data — <Business confirmed in Phase 1>
+
+- **Process/module**: [name]
+- **Database**: [DB name]
+- **Generation date**: [date]
+- **Run ID**: QA_<date>_<seq>   <!-- common marker of all records in this run -->
+
+> Convention: values in **bold** are typed/selected in the UI.
+> The `id=` in parentheses are internal DB references (for traceability/rollback).
+
+## Shared base data
+Apply to most cases unless a case states otherwise.
+
+| Entity | Value to use in UI | DB id | Status |
+|--------|--------------------|-------|--------|
+| Company | **CMPQA — Clothing Store QA** | 1 | reused |
+| Document type | **Inventory out (SAL-INV)** | 12 | reused |
+| Warehouse | **Main Warehouse (BOD-001)** | 3 | reused |
+
+## Case groups
+
+### Cases CP-001 to CP-007 — Inventory out, positive flow
+**They share the same seed.** Any of these cases can be tested with:
+- Company: **CMPQA** (id=1)
+- Document type: **Inventory out** (id=12)
+- Items in stock:
+  - **Polo Shirt (ITM-POLO-001)** — id=2001 — stock 500 in Main Warehouse
+  - **Regular T-shirt (ITM-TEE-001)** — id=2002 — stock 500 in Main Warehouse
+- Source warehouse: **Main Warehouse (BOD-001)** — id=3
+
+Data: reused (nothing new was inserted for these cases).
+
+### CP-008 — Edge: out for the maximum quantity in stock
+- Item: **Polo Shirt Edge (ITM-POLO-MAX)** — id=2050 — exact stock 999999
+- Rest of the seed equal to the shared base data.
+
+Data: **created** core.items id=2050 (`QA_<run>_ITM_POLO_MAX`).
+
+### CP-009 — Negative: out greater than stock
+- Item: **Out-of-stock shirt (ITM-NOSTOCK)** — id=2051 — stock 0
+- Expected result: controlled error "insufficient stock".
 
-For each test case, indicate whether data was REUSED or CREATED, with exact IDs:
+Data: **created** core.items id=2051 (`QA_<run>_ITM_NOSTOCK`).
 
+## Coverage
+Total cases: N — all with sufficient data associated (X reuse base data, Y with their own data).
 ```
-CP-001 (Positive) — REUSABLE:
-  → Use existing records:
-    - masterdata.customers: id=1001 (QA_CUSTOMER_001)
-    - core.invoices: id=5001 (QA_INVOICE_001)
-    - core.invoice_detail: ids=8001,8002
-  → No new data was inserted.
-
-CP-002 (Edge - maximum amount) — REUSABLE:
-  → Use: core.invoices id=5002 (QA_INVOICE_EDGE_001, amount=999999999.99)
-
-CP-003 (Positive) — PARTIAL:
-  → Reused: masterdata.customers id=1001
-  → Created: core.invoices id=5050 (QA_INVOICE_050), core.invoice_detail ids=8100,8101
-
-CP-005 (Negative) — MISSING:
-  → Created:
-    - masterdata.customers: id=1050 (QA_CUSTOMER_NEG_001)
-    - core.invoices: id=5051 (QA_INVOICE_NEG_001)
+
+Adapt entities, columns and values to what the real schema returned and to the confirmed business. The essential thing: **each case is mapped to concrete data, and cases with an identical seed are grouped in a single block.**
+
+**7.3 Deliverable 2 — `seed.sql` (executable, idempotent insertion)**:
+
+In addition to inserting directly via MCP (Phase 6), write a `seed.sql` that reproduces **exactly the same insertions**, in Phase 3 order (parents → children). Its purpose: if a fresh/clean DB is reached, running this `.sql` is enough to have the complete seed without re-running the whole analysis process.
+
+`seed.sql` requirements:
+1. **Transactional**: wrapped in `BEGIN; ... COMMIT;` so it is all-or-nothing.
+2. **Idempotent**: use `INSERT ... ON CONFLICT DO NOTHING` (PostgreSQL) or `IF NOT EXISTS` guards (SQL Server) so re-running does not fail or duplicate.
+3. **Run-marked**: every record carries the `Run ID` (e.g., in code/notes `QA_<date>_<seq>`), so the rollback can be scoped.
+4. **Correct order**: catalogs/root → master → focal → children, same as Phase 6.
+5. **Commented per case**: head each block with the cases it covers (e.g., `-- Covers CP-001..CP-007`).
+6. **Only what was created**: do NOT include records marked REUSABLE (those already exist). If a reused base record is needed for the `.sql` to run on an empty DB, include it with `ON CONFLICT DO NOTHING` and comment it as "base data (may already exist)".
+
+```sql
+-- ===============================================
+-- SEED — QA Synthetic Data
+-- Business: <confirmed business> | Process: [name]
+-- Target DB: [name] | Date: [date] | Run: QA_<date>_<seq>
+-- EXECUTE ONLY IN TEST ENVIRONMENT
+-- ===============================================
+BEGIN;
+
+-- Covers CP-001..CP-007 (base data)
+INSERT INTO masterdata.items (code, name, notes, ...)
+VALUES ('ITM-POLO-001', 'Polo Shirt', 'QA_<run> [SYNTHETIC DATA]', ...)
+ON CONFLICT (code) DO NOTHING;
+
+-- ... rest in parents -> children order ...
+
+COMMIT;
 ```
 
-**7.3 Rollback script**:
+**7.4 Deliverable 3 — `rollback.sql`**:
 
-Generate a SQL script that deletes ONLY the inserted data, in reverse order (children first, parents after):
+Write a `rollback.sql` that deletes ONLY the data inserted in this run, in reverse order (children first, parents after):
 
 ```sql
 -- ===============================================
 -- ROLLBACK — QA Synthetic Data
--- Process: [name]
--- Generation date: [date]
+-- Business: <confirmed business> | Process: [name]
+-- Generation date: [date] | Run: QA_<date>_<seq>
 -- EXECUTE ONLY IN TEST ENVIRONMENT
 -- ===============================================
 
@@ -372,9 +515,9 @@ MCP: execute_query("BEGIN; DELETE FROM ... ; COMMIT;")
 
 If the execution only generated data for some cases (others were REUSABLE), the rollback must clean up **only** the records inserted in this run. Do not touch previously reused QA data. Scope the DELETE by specific IDs or a run marker (e.g., date suffix `QA_INVOICE_20260420_050`) instead of a broad `LIKE 'QA_%'`.
 
-**7.4 Special case — No insertions required**:
+**7.5 Special case — No insertions required**:
 
-If Phase 4 determined that all cases are REUSABLE, there is no new data or rollback to generate. Deliver this report to the user:
+If Phase 4 determined that all cases are REUSABLE, there is no new data: **`seed.sql` and `rollback.sql` are NOT generated**. However, you **MUST still write `test-data.md`** with the case→data relation of existing data (same grouped blocks as 7.2, but all in "reused" status), so the team/AI agent knows which IDs and values to use. Deliver this report to the user:
 
 ```
 RESULT: NO NEW DATA WAS GENERATED
@@ -410,18 +553,22 @@ NEXT STEPS:
 ## General Rules
 
 ### What you MUST ALWAYS do
+- **Infer the business and confirm it with the user before generating anything** (Phase 1.A)
 - Query real schemas via MCP before generating any data
 - **Search for existing QA data and perform case-by-case matching before deciding to generate**
 - Verify that FKs point to records that exist
-- Show the user the plan (including which cases are REUSABLE) before inserting
+- **Write `insertion_plan.md` to disk and wait for the user's approval before inserting** (Phase 5.5 gate), whenever the run will insert data
 - Report errors immediately with full detail
-- Generate rollback script only when insertions occurred
+- **Write deliverables to disk**: `insertion_plan.md` before inserting (when there are insertions); `test-data.md` always; `seed.sql` and `rollback.sql` when there were insertions
+- **Group in `test-data.md` cases that share the same seed** (do not repeat data per case)
+- Mark all records of the run with the same `Run ID` to scope the rollback
 
 ### What you must NEVER do
 - Invent column names without querying the schema
 - Assume data types without verifying
 - **Generate duplicate data when QA records already exist that satisfy the case**
 - **Insert data "just in case" when Phase 4 matching said REUSABLE**
+- Write deliverables as chat blocks instead of files on disk
 - Insert into production tables (always verify the environment)
 - Modify or delete data that was not created by this process
 - Continue inserting if a dependency failed
@@ -448,16 +595,17 @@ NEXT STEPS:
 
 **AI**:
 1. Read the CSV → 15 test cases (10 positive, 3 edge, 2 negative)
-2. Identify entities: invoices, invoice_detail, customers, products, salespeople
-3. Query schemas via MCP → obtain columns, types, FKs for each table
-4. Search existing QA data → find 5 `QA_INVOICE_*` invoices and 3 `QA_CUSTOMER_*` customers
-5. Perform case-by-case matching:
+2. **Infer the business**: "From the cases, I deduce an invoicing distributor/retailer. Correct?" → user confirms
+3. Identify entities: invoices, invoice_detail, customers, products, salespeople
+4. Query schemas via MCP → obtain columns, types, FKs for each table
+5. Search existing QA data → find 5 `QA_INVOICE_*` invoices and 3 `QA_CUSTOMER_*` customers
+6. Perform case-by-case matching:
    - 4 cases REUSABLE (QA invoices already apply)
    - 2 cases PARTIAL (QA customer exists, invoice missing)
    - 9 cases MISSING
-6. Present plan: "7 records reused. Will insert 2 invoices + 9 new invoices + 33 lines"
-7. User approves → insert in order: [missing] customers → invoices → invoice_detail
-8. Deliver report (with REUSABLE block + created block) + rollback script scoped to this run's IDs
+7. Present plan: "7 records reused. Will insert 2 invoices + 9 new invoices + 33 lines"
+8. User approves → insert in order: [missing] customers → invoices → invoice_detail
+9. **Write the 3 deliverables**: `test-data.md` (cases grouped by seed), `seed.sql` (idempotent) and `rollback.sql` (scoped to this run's IDs); list the paths to the user
 
 ---
 
@@ -471,8 +619,8 @@ NEXT STEPS:
 2. Identify entities and query schemas via MCP
 3. Search existing QA data → find 12 `QA_INVOICE_*` invoices, 5 `QA_CUSTOMER_*` customers, associated detail
 4. Case-by-case matching → all 10 cases are REUSABLE
-5. Deliver report 7.4: **"No new data was generated"** with the list of existing IDs to use per test case
-6. Phases 5, 6 are not executed, no rollback script is generated
+5. Deliver report 7.5: **"No new data was generated"** + **write `test-data.md`** with the list of existing IDs to use per test case
+6. Phases 5, 6 are not executed; no `seed.sql` or `rollback.sql` is generated
 
 ---
 
@@ -481,5 +629,6 @@ NEXT STEPS:
 If the configured MCP is for SQL Server (`mcp_mssql`), the flow is identical but:
 - Tool names remain the same
 - The dependency function is `dbo.GetAllDependencies_JSON` instead of `get_all_dependencies_json`
-- Rollback scripts use `BEGIN TRANSACTION` / `COMMIT` instead of `BEGIN` / `COMMIT`
+- The scripts (`seed.sql` and `rollback.sql`) use `BEGIN TRANSACTION` / `COMMIT` instead of `BEGIN` / `COMMIT`
+- For idempotency in `seed.sql`, use `IF NOT EXISTS (SELECT 1 FROM ... WHERE ...) INSERT ...` instead of `INSERT ... ON CONFLICT DO NOTHING`
 - Use `TOP N` instead of `LIMIT N` for queries

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

@@ -0,0 +1,6 @@
+---
+name: sa-quality-process
+description: 'QA Quality Process — Phase 1 Planning, Phase 2 DOR Gate, Phase 3 Design, Phase 4 QA Data Generation, Phase 5 AgileTest Registration, or Phase 6 E2E Implementation + Execution (Agente Ejecutor E2E). Asks at startup which phase to execute.'
+---
+
+IT IS CRITICAL THAT YOU FOLLOW THIS COMMAND: LOAD the FULL @_siesa-agents/bmm/workflows/3-solutioning/quality-process/workflow.md, READ its entire contents and follow its directions exactly!