@tacuchi/agent-workflow-cli 11.0.1 → 12.0.0

package/skills/agent-workflow/standards/sql-script-organizer/references/bundle-readme-template.md

@@ -1,82 +0,0 @@
-# Plantilla — README del Bundle SQL
-
-Usar esta plantilla para generar `scripts/bundle/README.md` al finalizar la reorganización.
-
----
-
-```markdown
-# Bundle SQL — sessionXXX: [nombre de sesión]
-
-## Información
-
-- **Sesión:** sessionXXX-[nombre-kebab]
-- **Fecha de bundle:** YYYY-MM-DD
-- **Motor de BD:** PostgreSQL [versión si se conoce]
-- **Esquemas afectados:** esq_[dominio1], esq_[dominio2]
-
-## Resumen
-
-[1-2 líneas describiendo qué hace este bundle en conjunto]
-
-## Orden de ejecución (forward)
-
-Ejecutar en este orden exacto. Cada script usa `BEGIN`/`COMMIT`.
-
-### 01 — DDL de Tablas
-
-| # | Archivo | Descripción |
-|---|---|---|
-| 1 | `01-ddl-tablas/001-crea-tb-x.sql` | [descripción breve] |
-| 2 | `01-ddl-tablas/002-agrega-col-tb-y.sql` | [descripción breve] |
-
-### 02 — DDL de Funciones / SP
-
-| # | Archivo | Descripción |
-|---|---|---|
-| 1 | `02-ddl-funciones/001-crea-fn-z.sql` | [descripción breve] |
-
-### 03 — Migración de Datos
-
-> Ejecutar scripts de respaldo (`000-backup-*.sql`) primero.
-
-| # | Archivo | Descripción |
-|---|---|---|
-| 1 | `03-migracion/000-backup-tb-x.sql` | Respaldo previo en esq_audit |
-| 2 | `03-migracion/001-migra-estado-x.sql` | [descripción breve] |
-
-### 04 — Inserts Nuevos
-
-| # | Archivo | Descripción |
-|---|---|---|
-| 1 | `04-inserts/001-inserta-maestras.sql` | [descripción breve] |
-
-## Rollback
-
-Para revertir **toda** la sesión: ejecutar `rollback/00-rollback-global.sql`.
-
-Para revertir **un script específico**: ejecutar el `.rollback.sql` acoplado al lado del forward.
-
-**Orden de rollback** (inverso al forward): 04 → 03 → 02 → 01.
-
-## Operaciones irreversibles
-
-<!-- Listar si aplica. Si no hay ninguna, eliminar esta sección. -->
-
-| Script | Operación | Riesgo | Mitigation |
-|---|---|---|---|
-| `01-ddl-tablas/002-elimina-col-legacy.sql` | DROP COLUMN | Pérdida de datos | Backup en esq_audit antes de ejecutar |
-
-## Dependencias externas
-
-<!-- Scripts o estados de BD que deben existir ANTES de ejecutar este bundle -->
-
-- [Ej: `tb_maestra_detalle` debe tener el `codprog` X con los estados Y, Z]
-- [Ej: El feature flag `FLAG_NUEVA_FUNCIONALIDAD` debe estar activo]
-
-## Notas de ejecución
-
-<!-- Cualquier instrucción manual necesaria antes o después del bundle -->
-
-- [Ej: Detener el servicio X antes de ejecutar `03-migracion/`]
-- [Ej: Refrescar la caché de parámetros después de `04-inserts/`]
-```

package/skills/agent-workflow/standards/sql-script-organizer/references/categorization-rules.md

@@ -1,122 +0,0 @@
-# Reglas de Categorización de Scripts SQL
-
-## Patrones de detección por categoría
-
-### `01-ddl-tablas/` — Estructura de tablas
-
-| Patrón | Ejemplos |
-|---|---|
-| `CREATE TABLE` | `CREATE TABLE IF NOT EXISTS esq_credito.tb_solicitud (...)` |
-| `DROP TABLE` | `DROP TABLE IF EXISTS esq_credito.tb_solicitud_bkp;` |
-| `ALTER TABLE ... ADD COLUMN` | `ALTER TABLE esq_credito.tb_credito ADD COLUMN flag_activo integer;` |
-| `ALTER TABLE ... DROP COLUMN` | `ALTER TABLE esq_credito.tb_credito DROP COLUMN IF EXISTS col_legacy;` |
-| `ALTER TABLE ... ALTER COLUMN` | `ALTER TABLE tb_x ALTER COLUMN monto_total TYPE numeric(18,4);` |
-| `ALTER TABLE ... RENAME` | `ALTER TABLE esq_credito.tb_x RENAME COLUMN col_vieja TO col_nueva;` |
-| `CREATE INDEX` | `CREATE INDEX IF NOT EXISTS idx_tb_credito_cliente ON esq_credito.tb_credito(id_cliente);` |
-| `DROP INDEX` | `DROP INDEX IF EXISTS esq_credito.idx_tb_credito_legacy;` |
-| `CREATE SEQUENCE` | `CREATE SEQUENCE IF NOT EXISTS esq_credito.seq_tb_nueva;` |
-| `DROP SEQUENCE` | `DROP SEQUENCE IF EXISTS esq_credito.seq_tb_legacy;` |
-| `CREATE TABLE ... AS SELECT` | Reconstrucción desde backup |
-| Constraint `ADD/DROP` | `ALTER TABLE tb_x ADD CONSTRAINT pk_tb_x PRIMARY KEY (id_x);` |
-
-### `02-ddl-funciones/` — Funciones y Stored Procedures
-
-| Patrón | Ejemplos |
-|---|---|
-| `CREATE [OR REPLACE] FUNCTION` | `CREATE OR REPLACE FUNCTION esq_credito.fn_calcular_cuota(...)` |
-| `CREATE [OR REPLACE] PROCEDURE` | `CREATE OR REPLACE PROCEDURE esq_credito.sp_genera_credito(...)` |
-| `DROP FUNCTION` | `DROP FUNCTION IF EXISTS esq_credito.fn_legacy(integer, numeric);` |
-| `DROP PROCEDURE` | `DROP PROCEDURE IF EXISTS esq_credito.sp_legacy(integer);` |
-| `CREATE [OR REPLACE] VIEW` | Vistas con lógica de negocio compleja |
-| `DROP VIEW` | `DROP VIEW IF EXISTS esq_credito.vw_resumen_credito;` |
-
-> **Nota**: La firma completa (incluyendo tipos de parámetros) es necesaria en `DROP FUNCTION`/`DROP PROCEDURE` para evitar ambigüedad en PostgreSQL.
-
-### `03-migracion/` — Transformación de datos existentes
-
-| Patrón | Ejemplos |
-|---|---|
-| `UPDATE` sobre tabla existente | `UPDATE esq_credito.tb_credito SET estado = 1 WHERE estado IS NULL;` |
-| `INSERT ... SELECT ...` | Copiar/transformar datos entre tablas |
-| `DELETE` sobre datos existentes | `DELETE FROM tb_x WHERE fecha_registro < '2020-01-01';` |
-| Relleno de nueva columna | `UPDATE tb_x SET nueva_col = fn_calcula(otra_col);` |
-| Normalización de datos | Separar una columna en múltiples, fusionar tablas |
-| Migración de tipo de dato | Copiar valores transformados antes de cambiar tipo |
-
-> **Importante**: Cualquier script de migración debe ir precedido de un `000-backup-<tabla>.sql` que respalde las filas afectadas a `esq_audit`.
-
-### `04-inserts/` — Datos nuevos (seeds / catálogos)
-
-| Patrón | Ejemplos |
-|---|---|
-| `INSERT INTO ... VALUES (...)` | Registros de `tb_maestra_detalle`, roles, perfiles |
-| Seeds de configuración | Parámetros iniciales, valores de lookup |
-| Datos de referencia | Países, monedas, estados de proceso |
-| `INSERT ... ON CONFLICT DO NOTHING` | Idempotent inserts de catálogos |
-| `INSERT ... ON CONFLICT DO UPDATE` | Upserts de configuración |
-
----
-
-## Edge cases y scripts mixtos
-
-### Script con DDL + DML (mezcla)
-
-Si un script crea una tabla Y la puebla inmediatamente (patrón común en seeds):
-
-**Opción A (recomendada)**: Dividir en dos scripts — `01-ddl-tablas/001-crea-tb-x.sql` + `04-inserts/001-inserta-tb-x.sql`.
-
-**Opción B**: Si la división no tiene sentido semántico (ej: tabla temporal de trabajo que se llena y elimina en la misma operación), clasificar según la operación **dominante**. Documentar en el `README.md` del bundle.
-
-### Scripts de respaldo previo (`000-backup-*.sql`)
-
-Los scripts de respaldo pertenecen a la misma categoría que su script de migración:
-- `03-migracion/000-backup-tb-credito.sql` precede a `03-migracion/001-migra-estado.sql`
-- Numeración especial `000` para indicar que va primero dentro de la categoría
-
-### Funciones de apoyo temporal
-
-Si un script `03-migracion` usa una función **solo dentro de ese script** (creada y eliminada en el mismo archivo), **no** moverla a `02-ddl-funciones/`. Usar un bloque `DO $$ ... $$` o una CTE en su lugar, siguiendo la regla "sin funciones utilitarias efímeras".
-
-### Scripts de versionado de funciones (`_v2`, `_v3`)
-
-Al actualizar una función a una nueva versión:
-- `02-ddl-funciones/001-actualiza-fn-x-v2.sql` → `CREATE OR REPLACE FUNCTION fn_x(...)`
-- El rollback contiene la versión anterior (`v1`) para restaurar en caso necesario
-- **No eliminar** la versión anterior hasta confirmar que `v2` funciona en producción
-
-### Views
-
-Clasificar en `02-ddl-funciones/` (mismo directorio que funciones). Las views son DDL de objetos de BD, no migración de datos.
-
----
-
-## Resolución de dependencias entre categorías
-
-Al renumerar, verificar:
-
-1. `03-migracion` no puede referenciar una columna creada en `01-ddl-tablas` si ese script aún no fue ejecutado
-2. `04-inserts` no puede insertar en una tabla que existe solo en `01-ddl-tablas` del mismo bundle (al ejecutar prod, ir en orden)
-3. `02-ddl-funciones` puede depender de tablas de `01-ddl-tablas` — verificar que la función no se crea antes que su tabla
-
-Si se detecta una dependencia circular o un orden imposible, dividir el bundle en sub-bundles y documentarlo en `README.md`.
-
----
-
-## Nomenclatura de archivos
-
-Formato: `NNN-verbo-sustantivo-objetivo.sql`
-
-| Elemento | Regla | Ejemplos |
-|---|---|---|
-| `NNN` | 3 dígitos, cero-padded dentro de la categoría | `001`, `002`, `010` |
-| `verbo` | acción que realiza el script | `crea`, `elimina`, `modifica`, `migra`, `inserta`, `actualiza`, `agrega` |
-| `sustantivo` | objeto principal afectado | `tb-credito`, `fn-calcular-cuota`, `sp-genera-credito` |
-| `objetivo` | detalle adicional si es necesario | `columna-estado`, `v2`, `sesion-inicial` |
-
-Ejemplos válidos:
-- `001-crea-tb-solicitud.sql`
-- `002-agrega-columna-flag-activo-tb-credito.sql`
-- `001-crea-fn-calcular-cuota-v2.sql`
-- `001-migra-estado-credito.sql`
-- `000-backup-tb-credito.sql`
-- `001-inserta-maestras-estado-solicitud.sql`

package/skills/agent-workflow/standards/sql-script-organizer/references/consolidation-cross-session.md

@@ -1,125 +0,0 @@
-# Consolidación cross-session (release) y modo por tema
-
-Detalles del comportamiento de `sql-script-organizer` cuando es invocado por `release` (cross-session) o por `release-scripts` (por tema). El SKILL.md tiene el resumen; este archivo tiene el procedimiento completo.
-
-## Modo consolidación cross-session (delegado por `release`)
-
-Produce un bundle único que abarca múltiples sesiones en `docs/release/NNN-release-YYYY-MM-DD/scripts/`.
-
-### Entrada
-
-Lista de bundles fuente en orden cronológico de sesión:
-- Sesiones cerradas: `docs/scripts/NNN-sessionXXX-*/` (ya graduados).
-- Sesiones abiertas: `.workflow/sessions/sessionXXX-*/scripts/bundle/` o `scripts/` flat (organizar antes).
-
-### Proceso
-
-1. **Validar organización** de cada bundle fuente. Si flat, aplicar el proceso estándar de las 4 categorías antes.
-2. **Crear estructura destino** con `01-ddl-tablas/`, `02-ddl-funciones/`, `03-migracion/`, `04-inserts/`, `rollback/`.
-3. **Copiar scripts preservando orden**:
-   - Sesiones cronológicas (session001 → session002 → …).
-   - Dentro de cada sesión, orden 01→02→03→04.
-   - Renumerar `NNN` continuo dentro de la categoría.
-   - Header de origen:
-     ```sql
-     -- Origen: sessionXXX-nombre · docs/scripts/NNN-sessionXXX-nombre/03-migracion/001-xyz.sql
-     -- Consolidado en release NNN (YYYY-MM-DD)
-     ```
-   - El `.rollback.sql` viaja con su forward.
-4. **No fusionar** scripts distintos en un único archivo.
-5. **Resolver conflictos cross-sesión**: documentar en `scripts/README.md` si una migración depende de algo reemplazado.
-6. **Generar `scripts/README.md`** con:
-   - Secuencia de ejecución lineal.
-   - Tabla "script en release | sesión origen | script original".
-   - Listado de irreversibles.
-7. **Delegar a `sql-rollback-generator`** para el rollback global.
-
-### Qué NO hacer
-
-- Modificar scripts originales en `docs/scripts/NNN-sessionXXX-*/` — son memoria permanente.
-- Mezclar sentencias de scripts distintos.
-- Renombrar categorías — siempre 01→02→03→04.
-- Saltar sesiones sin registrarlo.
-
-### Layout del bundle consolidado
-
-```
-docs/release/NNN-release-YYYY-MM-DD/scripts/
-├── README.md                          (mapeo sesión → script + secuencia)
-├── 01-ddl-tablas/
-│   ├── 001-crea-tb-x.sql              (origen: session001)
-│   ├── 001-crea-tb-x.rollback.sql
-│   ├── 002-crea-tb-y.sql              (origen: session003)
-│   └── 002-crea-tb-y.rollback.sql
-├── 02-ddl-funciones/
-│   └── ...
-├── 03-migracion/
-│   ├── 000-backup-tb-x.sql            (origen: session001)
-│   ├── 001-migra-col-z.sql
-│   ├── 001-migra-col-z.rollback.sql
-│   └── ...
-├── 04-inserts/
-│   └── ...
-└── rollback/
-    └── 00-rollback-release.sql        (sql-rollback-generator)
-```
-
-### Confirmación
-
-Si el usuario no confirmó producir el bundle consolidado, NO crear la carpeta. Referenciar bundles graduados por sesión y listar ejecución lineal.
-
-## Modo por tema consolidado (delegado por `release-scripts`)
-
-Reutiliza la clasificación 01→04 pero la aplica **dentro de cada tema** y **consolida** todos los scripts de una misma `(tema, categoría)` en un único `.sql`.
-
-### Layout destino
-
-```
-docs/release/NNN-release-YYYY-MM-DD/scripts-por-tema/
-└── tema-<slug>/
-    ├── 01-ddl-tablas.sql              (consolidado, BEGIN/COMMIT único)
-    ├── 01-ddl-tablas.rollback.sql     (consolidado inverso)
-    ├── 02-ddl-funciones.sql
-    ├── 02-ddl-funciones.rollback.sql
-    ├── 03-migracion.sql
-    ├── 03-migracion.rollback.sql
-    ├── 04-inserts.sql
-    ├── 04-inserts.rollback.sql
-    └── rollback-tema-<slug>.sql       (revierte el tema completo)
-```
-
-### Qué cambia respecto al modo estándar
-
-- **Consolidación**: N scripts de `(tema, categoría)` se concatenan en un único archivo. Eliminar `BEGIN;`/`COMMIT;` de cada uno; añadir `BEGIN;` único al inicio y `COMMIT;` al final. Transacción atómica por categoría del tema.
-- **Trazabilidad**: separador `-- === [i/N] <nombre-original> ===` + ruta canónica.
-- **Sin subcarpetas por categoría**: el nombre de archivo ya indica la categoría.
-- **Categorías vacías** no se crean.
-- **Scripts fuente preservados opt** con `--keep-parts` → `parts/<categoria>/*.sql`.
-- **Orden cross-tema**: en `ORDER.md` (resuelto por `release-scripts`).
-
-### Qué NO cambia
-
-- Las 4 categorías y sus patrones.
-- Las reglas de estilo SQL.
-- El bundle plano sigue generándose igual; el modo por-tema es aditivo.
-
-### Formato del archivo consolidado
-
-```sql
--- Tema: <slug>
--- Categoría: 01-ddl-tablas
--- Release: NNN (YYYY-MM-DD)
--- Consolidado: <nombre1>.sql, <nombre2>.sql, …
-
-BEGIN;
-
--- [1/N] <nombre>.sql (origen: sessionXXX)
-<contenido sin BEGIN/COMMIT>
-
--- [2/N] <nombre>.sql (origen: sessionXXX)
-<contenido>
-
-COMMIT;
-```
-
-Ver `release-scripts/SKILL.md` y `release-scripts/references/theme-detection.md` para asignación script→tema.

package/skills/agent-workflow/standards/sql-script-organizer/references/scripts-sql-format.md

@@ -1,140 +0,0 @@
-# SCRIPTS.sql — spec canónica del archivo
-
-Spec del archivo único `SCRIPTS.sql` que vive en `.workflow/sessions/<folder>/` desde `sql-script-organizer` v1.0.0 (decisión F-D + G1 de session062).
-
-## Path canónico
-
-```
-.workflow/sessions/sessionXXX-<flow>-<slug>/SCRIPTS.sql
-```
-
-- Filename: **SCRIPTS.sql** en mayúsculas (uppercase EN, igual que CHECKPOINT.md, TASKS.md, etc.).
-- Encoding: UTF-8 sin BOM.
-- Line endings: LF.
-
-## Estructura del archivo
-
-```sql
--- ============================================================================
--- SCRIPTS.sql — sessionXXX-<flow>-<slug>
--- ============================================================================
--- Consolida todas las sentencias SQL aplicadas durante esta sesión.
--- Markers @category y @stmt los lee /agent-workflow:export-scripts para separar el bundle.
--- ----------------------------------------------------------------------------
-
-BEGIN;
-
--- @category: 01-ddl-tablas
--- @stmt: 001-crear-tabla-usuarios
-CREATE TABLE IF NOT EXISTS esq_credito.tb_usuarios (
-  id          BIGSERIAL PRIMARY KEY,
-  cod_usuario VARCHAR(20) NOT NULL UNIQUE,
-  estado      CHAR(1) NOT NULL DEFAULT 'A'
-);
-
--- @category: 02-ddl-funciones
--- @stmt: 002-fn-obtener-usuario
-CREATE OR REPLACE FUNCTION esq_credito.fn_obtener_usuario(p_cod VARCHAR)
-RETURNS TABLE(...)
-LANGUAGE plpgsql AS $$
-BEGIN
-  ...
-END;
-$$;
-
--- @category: 04-inserts
--- @stmt: 003-insert-usuarios-seed
-INSERT INTO esq_credito.tb_usuarios (cod_usuario, estado)
-VALUES ('admin', 'A'), ('soporte', 'A')
-ON CONFLICT (cod_usuario) DO NOTHING;
-
-COMMIT;
-```
-
-## Markers
-
-### `@category` — obligatorio
-
-Clasifica la sentencia para la separación post-hoc en el bundle export-scripts:
-
-| Marker | Patrones de detección |
-|---|---|
-| `01-ddl-tablas` | `CREATE TABLE`, `DROP TABLE`, `ALTER TABLE`, `CREATE INDEX`, `CREATE SEQUENCE` |
-| `02-ddl-funciones` | `CREATE [OR REPLACE] FUNCTION`, `CREATE [OR REPLACE] PROCEDURE`, `DROP FUNCTION`, `DROP PROCEDURE` |
-| `03-migracion` | `UPDATE`, `INSERT ... SELECT ...`, `DELETE` sobre datos existentes |
-| `04-inserts` | `INSERT INTO ... VALUES`, seeds de catálogos, datos de configuración inicial |
-
-Valor exacto, lowercase. Una categoría por marker (no listas).
-
-### `@stmt` — obligatorio
-
-Slug determinístico para que `export-scripts` derive el filename del archivo separado:
-
-- Formato: `NNN-verbo-objetivo` (3 dígitos + kebab-case, ≤5 palabras útiles).
-- Único dentro del SCRIPTS.sql.
-- Orden cronológico recomendado pero NO requerido (export-scripts ordena por categoría al separar).
-- Ejemplo: `001-crear-tabla-usuarios`, `015-poblar-catalogo-roles`.
-
-### `@objeto` y `@alcance` — opcionales
-
-Si la sentencia merece doc:
-
-```sql
--- @category: 01-ddl-tablas
--- @stmt: 001-crear-tabla-usuarios
--- @objeto: Tabla central de identidades. UNIQUE en cod_usuario.
--- @alcance: solo esq_credito; trigger de auditoría en sesión separada.
-CREATE TABLE ...
-```
-
-`export-scripts` usa estos al generar el header canónico del archivo separado.
-
-## Reglas de idempotencia
-
-Cada sentencia debe ser idempotente:
-
-- **DDL**: `CREATE TABLE IF NOT EXISTS`, `DROP ... IF EXISTS`, `CREATE OR REPLACE`.
-- **Inserts**: `ON CONFLICT (...) DO NOTHING` o `ON CONFLICT DO UPDATE`.
-- **Migraciones de datos**: backup en `esq_audit.tb_bkp_<x>_sNNN` antes de UPDATE/DELETE masivo; ver `sql-rollback-generator` para política.
-- **Funciones**: `CREATE OR REPLACE FUNCTION` siempre.
-
-Re-ejecutar el archivo completo no debe fallar.
-
-## Transaccionalidad
-
-`BEGIN;` al inicio del archivo, `COMMIT;` al final. **Una sola transacción** global por sesión.
-
-Si una sentencia requiere transacción aparte (ej. `CREATE INDEX CONCURRENTLY`), comentar con `-- @transaction: none` y mover fuera del BEGIN/COMMIT global. Casos raros; documentar.
-
-## Concatenación con sessions previas
-
-`SCRIPTS.sql` representa **lo que esta sesión cambia**. NO incluye:
-- Scripts heredados de sesiones previas (esos ya viven en sus propios SCRIPTS.sql).
-- Scripts del baseline del workspace.
-
-`export-scripts` con `--sessions NNN,MMM` combina varios SCRIPTS.sql en el bundle final.
-
-## Edición durante la sesión
-
-Permitido:
-- Append de nuevas sentencias al final (antes del COMMIT).
-- Editar sentencias existentes para corregir (preservar `@stmt` del statement; el slug es estable).
-- Eliminar sentencias descartadas (no preservar history en backlog SQL; usar `BACKLOG.md` para anotar lo descartado).
-
-No permitido:
-- Reordenar sentencias por estética (orden = cronológico). Si el orden de ejecución importa, dejarlo al separador post-hoc.
-- Mezclar 2 sentencias en un solo bloque marker (un `@stmt` = una sentencia).
-
-## Verificación pre-cierre
-
-Antes de cerrar la sesión:
-1. `agent-workflow session-artifacts --code NNN` reporta `scripts_sql_present: true` (si esperabas SQL).
-2. El archivo abre con `BEGIN;` y cierra con `COMMIT;`.
-3. Cada sentencia tiene `@category` y `@stmt`.
-4. Re-ejecutar el archivo en cert no falla (manual; el AI nunca ejecuta).
-
-## Migración desde layout legacy
-
-Si la sesión tiene `scripts/01-ddl-tablas/*.sql` etc. (layout pre-v1.0.0), invocar `/agent-workflow:migrate --upgrade-topology`. El skill `migrate` lee los archivos en orden 01→04, concatena en SCRIPTS.sql con markers `@category` derivado de la carpeta y `@stmt` del filename original. Idempotente: si ya existe SCRIPTS.sql, no sobreescribe.
-
-Ver `agent-workflow/skills/migrate/SKILL.md` capability 11.

package/skills/agent-workflow/standards/testing-strategy/SKILL.md

@@ -1,113 +0,0 @@
----
-name: testing-strategy
-description: Skill de referencia para la estrategia de testing (selección de niveles unit/integración/e2e, comandos de ejecución por stack). Invocado internamente por el skill session durante la Fase 4 (validación). No se activa por lenguaje natural.
-version: 0.1.0
----
-
-# Testing Strategy
-
-Gestión de niveles de prueba flexibles dentro de sesiones de desarrollo. El usuario elige el nivel en cualquier momento y puede cambiarlo durante la sesión. Los niveles se adaptan al stack detectado del proyecto.
-
-## Regla de ejecución
-
-Por defecto, no ejecutar pruebas automáticamente. Primero preguntar si:
-- el usuario quiere que el plugin las ejecute
-- el usuario las correrá manualmente
-- no hace falta correrlas en esta sesión
-
-(Salvo `Validation mode: auto` en `~/.workflow/user-config.md`.)
-
-## Niveles de prueba — Backend (Spring Boot / Java)
-
-### Nivel a) Unitarios
-- **Framework:** JUnit 5 + Mockito
-- **Alcance:** Lógica de negocio aislada (services, utils, mappers)
-- **Cuándo usarlo:** Fix rápido, cambio puntual, lógica sin dependencias externas
-- **Comando:** `./mvnw test -Dtest=ClaseTest` (Windows: `mvnw.cmd test`)
-
-### Nivel b) Unitarios + API
-- **Framework:** JUnit 5 + Mockito + MockMvc
-- **Alcance:** Nivel a) + Controllers (endpoints REST)
-- **Cuándo usarlo:** Endpoint nuevo o modificado
-- **Comando:** `./mvnw test`
-
-### Nivel c) Completo
-- **Framework:** JUnit 5 + Mockito + MockMvc + @SpringBootTest
-- **Alcance:** Nivel b) + Tests de integración con contexto Spring completo
-- **Cuándo usarlo:** Feature completa, flujo crítico, integración entre capas
-- **Comando:** `./mvnw verify`
-
-## Niveles de prueba — Frontend (Angular)
-
-### Nivel a) Unitarios
-- **Framework:** Jasmine + Karma (o Jest según config)
-- **Alcance:** Services, pipes, utils aislados
-- **Comando:** `ng test --watch=false`
-
-### Nivel b) Unitarios + Componentes
-- **Framework:** Jasmine + TestBed + ComponentFixture
-- **Alcance:** Nivel a) + componentes con template rendering
-- **Comando:** `ng test --watch=false`
-
-### Nivel c) Completo
-- **Framework:** Nivel b) + tests e2e (Cypress/Playwright si está configurado)
-- **Alcance:** Flujos completos de usuario
-- **Comando:** `npm run e2e` o según configuración del proyecto
-
-## Selección de nivel
-
-Preguntar al usuario solo cuando realmente se vaya a validar desde el plugin. Adaptar las opciones al stack:
-
-**Backend:**
-```
-¿Qué nivel de pruebas aplicamos?
-  a) Unitarios — JUnit 5 + Mockito (rápido)
-  b) Unitarios + API — + MockMvc controllers
-  c) Completo — + @SpringBootTest integración
-```
-
-**Frontend:**
-```
-¿Qué nivel de pruebas aplicamos?
-  a) Unitarios — Services y pipes aislados
-  b) Unitarios + Componentes — + TestBed rendering
-  c) Completo — + e2e si está configurado
-```
-
-El usuario puede cambiar de nivel en cualquier momento o decidir no ejecutar pruebas desde el plugin.
-
-## Convenciones de nomenclatura
-
-**Java:** Clase `[Objetivo]Test.java`, método `[metodo]_[escenario]_[resultado]`. Estructura Arrange-Act-Assert.
-**Angular:** Archivo `[nombre].spec.ts`, bloques `describe`/`it`. Usar TestBed para componentes.
-
-Para ejemplos completos de código, consultar `references/test-levels.md`.
-
-## Ejecución y registro
-
-1. Confirmar primero que el usuario quiere ejecución desde el plugin
-2. Ejecutar el comando según stack y nivel
-3. Registrar en `TEST_LOG.md` solo si el usuario pidió registro formal o la ejecución se hizo desde el plugin
-4. Si el usuario ya validó manualmente, no repetir por defecto; anotar una línea breve solo si aporta trazabilidad
-5. Si hay fallos y el usuario quiere continuar, corregir y re-ejecutar
-
-## Detección automática de comando
-
-1. `mvnw`/`mvnw.cmd` → `./mvnw test` (nunca `mvn` directo)
-2. `gradlew` → `./gradlew test`
-3. `angular.json` → `ng test --watch=false`
-4. `package.json` con script test → `npm test`
-5. Si el bloque `AW-PROJECT → Stack` declara un override de build o wrapper distinto, usarlo.
-
-## Sandbox read-only
-
-Canon universal en `../session/references/sandbox-readonly-rules.md`. Esta skill es read-only por diseño — selecciona niveles de test y resuelve comandos por stack, no ejecuta tests ni edita código fuente.
-
-En plan mode: describir en el plan file qué niveles aplicarían (unit / integración / e2e), el comando resuelto (`./mvnw test`, `ng test --watch=false`, `npm test`, etc.) y los refs de ejemplos por stack. NO ejecuta `Bash` con el test runner, NO escribe TEST_LOG.md ni código de tests por sí misma.
-
-Compatible con plan mode sin restricciones adicionales.
-
-## Recursos adicionales
-
-### Archivos de referencia
-- **`references/test-levels.md`** — Ejemplos completos de código por stack y nivel, patrones TestBuilder, resumen de comandos