@tacuchi/agent-workflow-cli 11.0.0 → 12.0.0

package/skills/agent-workflow/standards/frontend-design/references/navigation-patterns.md

@@ -1,224 +0,0 @@
-# Patrones de navegación
-
-Principios de diseño para navegación en aplicaciones admin: sidebar, toolbar, breadcrumbs, tabs, routing, back navigation. Agnóstico a framework.
-
-Para el código del stack (routing, guards, lazy loading, store sincronizado con `NavigationEnd`), ver `coding-standards/references/<stack>.md`.
-
----
-
-## 1. Layout admin de 2 zonas
-
-Las aplicaciones admin siguen un layout persistente con 2 zonas fijas alrededor del contenido:
-
-```
-┌──────────────────────────────────────────────────────────┐
-│  Logo  [≡]     │   Breadcrumbs  |  Sucursal  Usuario  ⎋ │  ← toolbar (top)
-├─────────────┬──┴──────────────────────────────────────────┤
-│             │                                              │
-│  Sidebar    │  Contenido de la vista                       │
-│  (menu)     │  (title + action + filters + table/form)     │
-│             │                                              │
-│             │                                              │
-└─────────────┴──────────────────────────────────────────────┘
-```
-
-**Reglas:**
-
-- Toolbar fija en el top; sidebar fija a la izquierda.
-- El contenido de la vista se renderiza en el área central (`<router-outlet>`).
-- Sidebar colapsable: en desktop ocupa ~240 px expandida / ~60 px colapsada (solo íconos).
-- En mobile: sidebar se convierte en drawer overlay (`position: fixed` + backdrop).
-
----
-
-## 2. Sidebar
-
-**Comportamiento:**
-
-- **Colapsable** con toggle desde la toolbar. Estado persistente (store + opcional localStorage) para que sobreviva a navegación entre páginas.
-- **Ítems dinámicos** leídos de un catálogo central (no hardcoded por app). El catálogo expone qué ve cada usuario según su rol.
-- **Ítem activo destacado** con clase `.active` + color de fondo o borde lateral. Sincronizado con la ruta actual vía evento del router (`NavigationEnd` en Angular).
-
-**Estructura de cada ítem:**
-
-```html
-<a class="sidebar-item" [class.active]="isActive" [title]="!sidebarOpen ? label : null">
-  <span class="sidebar-icon"><i class="fa fa-users"></i></span>
-  <span class="sidebar-label" *ngIf="sidebarOpen">{{ label }}</span>
-</a>
-```
-
-**Reglas:**
-
-- Ícono a la izquierda, label a la derecha. Label se oculta en colapsado; tooltip (`title`) lo sustituye.
-- Máximo 1 nivel de anidación visible; si el menú crece, agrupar por secciones con separador.
-- Ítems ordenados por frecuencia de uso del rol dominante (no alfabéticamente).
-- Pie opcional con "Volver al home" o enlace al cambio de app.
-
----
-
-## 3. Toolbar (top bar)
-
-3 zonas horizontales:
-
-| Zona | Contenido |
-|------|-----------|
-| Izquierda | Logo + botón toggle del sidebar. |
-| Centro | Breadcrumbs (opcional — ver §5). |
-| Derecha (desktop) | Contexto (sucursal si es cambiable) + nombre usuario + avatar + logout. |
-| Derecha (mobile) | Solo avatar; al tap abre drawer con las opciones. |
-
-**Reglas:**
-
-- Logo siempre navegable al home (click → ruta raíz).
-- El **contexto** (sucursal activa, periodo contable, etc.) vive en la toolbar cuando es relevante al trabajo en curso y puede cambiarse globalmente.
-- **Avatar = iniciales** (primeras 2 letras del nombre, upper) si no hay foto. Badge redondo con color consistente por usuario.
-- Logout como enlace `⎋` o "Salir" — nunca oculto en un sub-menú innecesario.
-
----
-
-## 4. Título de página + acción primaria (page header)
-
-Cada vista del área de contenido abre con un header consistente:
-
-```html
-<div class="mb-4">
-  <div class="d-flex justify-content-between align-items-center flex-wrap gap-3">
-    <div>
-      <h2 class="fw-bold mb-1">Título de la vista</h2>
-      <p class="text-muted mb-0">Descripción de una línea.</p>
-    </div>
-    <button class="btn btn-primary">Acción primaria</button>
-  </div>
-</div>
-```
-
-**Reglas:**
-
-- `h2 fw-bold` para el título, `p text-muted` para la descripción de una sola línea.
-- Acción primaria top-right; si no hay, el header queda sin botón (no forzar uno).
-- `flex-wrap gap-3` para que el botón baje en mobile sin solaparse.
-
-**[shared-candidato] `page-header`** — se repite en 6+ vistas; amerita extracción con slots `[title]`, `[subtitle]`, `[action]`. Ver también `list-patterns.md` §2 y `form-patterns.md` §2.
-
----
-
-## 5. Breadcrumbs
-
-**Cuándo activarlos:**
-
-- Jerarquía de navegación es profunda (3+ niveles) y la ruta es relevante al usuario.
-- La URL no es suficientemente descriptiva (IDs en vez de nombres).
-
-**Cuándo omitirlos:**
-
-- App de 2 niveles (home → sección). El título de la vista ya indica dónde está el usuario.
-- Admin plano (todos los módulos al mismo nivel bajo `/admin`). El sidebar ya es la navegación principal.
-
-**Estructura cuando existen:**
-
-```html
-<nav class="breadcrumbs">
-  <a routerLink="/admin">Administración</a>
-  <span class="separator">›</span>
-  <a routerLink="/admin/usuario">Usuarios</a>
-  <span class="separator">›</span>
-  <span class="current">Editar</span>
-</nav>
-```
-
-**Reglas:**
-
-- Separador visual (`›`, `/`, `>`). Tipografía pequeña (`small`) + color atenuado para los links intermedios.
-- Último ítem (la vista actual) no es link; se destaca en negrita o color del texto base.
-- Derivados del router (no escritos a mano por vista) — para que nunca queden desincronizados con la URL real.
-
----
-
-## 6. Tabs dentro de una sección
-
-Cuando un módulo tiene 2-3 sub-vistas relacionadas (p. ej. "Sucursales" + "Carga masiva", o "Roles" + "Permisos"), usar tabs en vez de ítems separados del sidebar.
-
-```html
-<ul class="nav nav-tabs mb-4 px-2 bg-white rounded-top">
-  <li class="nav-item">
-    <a class="nav-link" routerLink="./roles" routerLinkActive="active">Roles</a>
-  </li>
-  <li class="nav-item">
-    <a class="nav-link" routerLink="./permisos" routerLinkActive="active">Permisos</a>
-  </li>
-</ul>
-<router-outlet></router-outlet>
-```
-
-**Reglas:**
-
-- **Tabs con routing** (`routerLink` + `routerLinkActive`) — cada tab es una URL propia, bookmarkeable y con back button funcional.
-- Evitar tabs con estado local (`[tab]="currentTab"` sin routing) cuando las sub-vistas son no triviales; el usuario pierde su lugar al recargar.
-- Máximo 3-4 tabs por sección. Si hay más, probablemente son módulos independientes que merecen sidebar.
-
-**[shared-candidato]:** el componente shared `nav-tabs` existe pero se usa mezclando los dos enfoques (routing vs state local). Documentar qué enfoque gana (routing) y migrar los que están en state local.
-
----
-
-## 7. Back navigation
-
-Para vistas que abren desde un listado (p. ej. `admin/usuario` → `admin/usuario/editar/:id`), ofrecer retorno explícito al listado:
-
-- **Opción A (recomendada):** link "← Volver a usuarios" en la parte superior del header, alineado con el título.
-- **Opción B:** botón `Cancelar` en el footer del formulario que navega a la ruta padre.
-
-**Reglas:**
-
-- El back siempre navega a la ruta **explícita** (router a `/admin/usuario`), no `history.back()` (comportamiento impredecible si el usuario llegó por deep link o recarga).
-- Usar un helper compartido para resolver la "ruta padre" desde la ruta actual (evita hardcodear). 
-
-**[shared-candidato] `back-button`** — observado reinventado en 3+ lugares (`volverHome()` en sidebar, `irHome()` en header, similar en sucursal). Extraer a un componente o servicio.
-
----
-
-## 8. Routing: lazy loading y rutas anidadas
-
-Cada módulo admin (usuario, sucursal, producto, accesos, etc.) vive como **módulo Angular lazy-loaded** bajo el layout padre:
-
-```ts
-{ path: 'usuario', loadChildren: () => import('./usuario/usuario.module').then(m => m.UsuarioModule) }
-```
-
-Cada módulo hijo define sus rutas anidadas (`lista`, `nuevo`, `editar/:id`, sub-tabs, modales con estado en URL si aplica).
-
-**Reglas:**
-
-- El layout admin (`admin-layout.component`) envuelve todas las rutas hijas con `<router-outlet>`, de forma que sidebar y toolbar persistan entre navegaciones.
-- Default redirect por módulo: `{ path: '', redirectTo: 'lista' }` para que `/admin/usuario` abra automáticamente el listado.
-- Guards a nivel de layout (autenticación, sesión) — no repetir en cada ruta hija.
-
-Detalles técnicos y ejemplo completo del routing: `coding-standards/references/angular-typescript.md` y `coding-standards/references/frontend-structure.md`.
-
----
-
-## 9. Stack del proyecto
-
-El proyecto usa **Angular + Bootstrap + ng-bootstrap**:
-
-- **Sidebar/toolbar:** componentes dedicados en `@presentation/admin/layout/` (`admin-layout`, `sidebar`, `toolbar`). Consumen `MenuCatalogService` para el catálogo dinámico.
-- **Tabs:** usar `nav-tabs` shared con `routerLink` + `routerLinkActive="active"`. La variante state-local existe pero es legado — no replicar.
-- **Breadcrumbs:** hay lógica en `AdminStore.breadcrumbs` (computed signal) pero **no se renderiza en la UI actual**. Si se activa, conectar el computed al template en `admin-layout`.
-- **wizard-footer** shared existe pero no se usa en admin. Reservado para futuros flujos multi-step.
-
----
-
-## 10. Checklist de replicación
-
-Al añadir un módulo nuevo bajo admin:
-
-- [ ] Lazy loading como módulo Angular (`loadChildren`).
-- [ ] Añadir ítem en el catálogo de menú (`MenuCatalogService`) con nombre, ícono y ruta.
-- [ ] Rutas anidadas dentro del módulo: `lista`, `nuevo`, `editar/:id` como mínimo.
-- [ ] Default redirect del módulo → `lista`.
-- [ ] Page header consistente en cada vista (`h2 fw-bold` + descripción + acción).
-- [ ] Si hay sub-vistas relacionadas, tabs con routing (no state local).
-- [ ] Back navigation explícito en las vistas de edición.
-- [ ] Sidebar/toolbar se heredan del layout padre — no crear otros.
-- [ ] Guards de sesión/autenticación a nivel de layout.
-- [ ] Revisar `shared/` antes de crear helpers de navegación.

package/skills/agent-workflow/standards/redaccion-simple/SKILL.md

@@ -1,128 +0,0 @@
----
-name: redaccion-simple
-description: "Guía transversal de redacción para artefactos agent-workflow. Reglas para escribir OBJECTIVE/TASKS/DECISIONS/EVIDENCE/FINDINGS/CONCLUSIONS/CHECKPOINT/STATUS/PROBLEM/IDEAS/DELIVERY (legacy ES = OBJETIVO/DECISIONES/EVIDENCIA/HALLAZGOS/CONCLUSIONES/PROBLEMA/ENTREGA) con frases cortas, listas sobre prosa, sin jerga. Activable cross-plugin como `agent-workflow:redaccion-simple`. Aplica a toda prosa que el AI produzca en contexto agent-workflow: artefactos `.md` de sesión, mensajes de commit, descripciones de PR, READMEs ad-hoc, respuestas en chat sobre temas agent-workflow. No requiere sesión activa."
-version: 2.0.1
----
-
-# Redacción simple — Guía transversal agent-workflow
-
-Reglas de estilo y formato para los artefactos que producen los plugins agent-workflow (core, dev, design, analyze).
-
-## Cuándo se invoca
-
-- Implícitamente al escribir cualquier `.md` dentro de una sesión agent-workflow (artefactos canónicos).
-- Implícitamente al producir prosa en contexto agent-workflow fuera de sesión activa: commit messages, descripciones de PR, READMEs ad-hoc, respuestas en chat sobre runtime/skills/sesiones agent-workflow.
-- Explícitamente con `Skill(agent-workflow:redaccion-simple)` desde un flow plugin o desde la skill agregadora `agent-workflow:rules`.
-- Referenciada desde `session`, `compact`, `resume` y los skills de los flow plugins.
-
-## Las 6 reglas
-
-1. **Frases cortas**: máximo ~15 palabras. Si pasa de 20, partir en dos.
-2. **Listas sobre prosa**: 3+ ideas paralelas van en bullets. Prosa solo para narrar.
-3. **Una idea por línea**: si el bullet usa "y" o ";" para meter una segunda idea, separar.
-4. **"Qué + por qué" en una línea**: formato `<qué>: <por qué corto>`. Sin párrafo aparte para el "por qué".
-5. **Sin jerga ni abreviaturas raras**: palabras comunes. Términos técnicos (MCP, C4) OK; abreviaturas inventadas (ej. "TLDR del CTX") no.
-6. **Sin relleno**: borrar "es importante notar que…", "cabe destacar…", "como se mencionó…", "en conclusión…". La idea va directo.
-
-## Palabras a evitar / preferir
-
-| Evitar | Preferir |
-|---|---|
-| "es importante notar que" | (borrar y empezar con la idea) |
-| "cabe destacar" | (borrar) |
-| "en otras palabras" | (borrar) |
-| "se procede a" | "vamos a" / verbo directo |
-| "implementar la funcionalidad de X" | "implementar X" |
-| "realizar la validación de" | "validar" |
-| "llevar a cabo" | "hacer" |
-| "a los efectos de" | "para" |
-| "en el marco de" | "en" |
-| "asimismo" | "también" |
-| "no obstante" | "pero" |
-| "previamente mencionado" | "antes" / "ya dicho" |
-| "TLDR", "FYI", "WIP" | escribir la palabra completa |
-
-## Ejemplos antes / después
-
-**1. Prosa redundante**
-
-Antes:
-> Es importante notar que los MCPs `<mcp-cert>` y `<mcp-prod>` constituyen hoy la única vía de acceso a la información de schema desde las sesiones de Claude Code. En el marco de la operatoria habitual, cada llamada implica un round-trip al servidor MCP además del consumo de tokens correspondiente al JSON de respuesta.
-
-Después (-50%):
-> Hoy las sesiones acceden al schema solo vía MCP `<mcp-cert>` y `<mcp-prod>`. Cada llamada cuesta un round-trip y los tokens del JSON.
-
-**2. Decisión densa**
-
-Antes:
-> Se decidió, luego de analizar las distintas alternativas, implementar la validación de roles a nivel del frontend exclusivamente, dado que el backend de mantenimiento no requiere conocer la lógica de permisos para operar correctamente, y además esto evita duplicar la regla de negocio en dos lugares distintos.
-
-Después:
-> **Decisión**: validar permisos solo en el frontend.
-> **Por qué**: el backend de mantenimiento no necesita la lógica; evita duplicar la regla.
-
-**3. Tarea con código inline**
-
-Antes:
-> - [ ] **T3**: Implementar el método `validarRol`.
->   ```java
->   public boolean validarRol(Usuario u, Rol r) {
->     if (u == null) throw new IllegalArgumentException("...");
->     ...
->   }
->   ```
-
-Después:
-> - [ ] **T3**: Implementar `validarRol(Usuario, Rol)` en `RolService`. Hecho cuando devuelve `true` para la matriz de `EVIDENCE.md § matriz-roles`.
-
-## Cuándo SÍ se permite prosa larga
-
-- `## Summary` de CONCLUSIONS.md (modality=technical): si la decisión necesita 4-6 oraciones para sostenerse.
-- Conclusión de causa raíz dentro de CONCLUSIONS.md (modality=incident): la cadena causal puede requerir un párrafo.
-- `## UX decisions` de DELIVERY: cuando explicar un tradeoff visual.
-
-En esos casos sigue aplicando "frases cortas": prosa de oraciones simples encadenadas, no oraciones largas.
-
-## Estructuras mínimas por artefacto
-
-Cada artefacto tiene una estructura fija. Cambia el contenido, no los headings que los parsers leen.
-
-| Artefacto | Headings | Tamaño objetivo |
-|---|---|---|
-| OBJECTIVE.md (legacy: OBJETIVO.md) | `## <Modality\|Type\|Requirement>`, `## <Question\|Brief\|Requirement>`, `## Context`, `## Acceptance criteria`, `## Origin` (opcional), `## Topics` (opcional dev) | 30-60 líneas |
-| TASKS.md | `## Plan summary`, `## Tasks`, `## Risks / external dependencies` | 40-100 (full); 20-40 (lite) |
-| DECISIONS.md (legacy: DECISIONES.md) | `## DEC-NNN: <título>` con `**Decisión**:` + `**Por qué**:` + opcionales | 3-6 líneas por decisión |
-| STATUS.md | campos planos + `## Branches por fuente`, `## Next step` o `## Cierre` | 15-25 líneas |
-| CHECKPOINT.md | `## Last action`, `## Next step`, `## Recent decisions`, `## Files touched`, `## Critical context to resume`, `## Refs` | 20-50 líneas |
-| EVIDENCE.md (legacy: EVIDENCIA.md) | `## Original question`, `## Sources consulted`, `## Raw finding N: <título>`, `## Notes / tentative hypotheses` | 40-150 líneas |
-| FINDINGS.md (legacy: HALLAZGOS.md) | `## Patterns identified`, `## Model decision`, `## What is NOT known (gaps)`, `## False positives discarded` (opcional) | 30-100 líneas |
-| CONCLUSIONS.md (cualquier modality, legacy: CONCLUSIONES.md) | `## Modality`, `## Summary`, `## Conclusions`, `## Recommendations`, `## Traceability`, `## Open` (opcional) | 60-200 líneas según modality y profundidad |
-| PROBLEM.md (legacy: PROBLEMA.md) | `## Statement`, `## Key constraints`, `## Success metrics` | 20-50 líneas |
-| IDEAS.md | `## Variant A/B/C` con Idea/Pros/Contras, `## Initial recommendation` | 60-120 líneas |
-| DELIVERY.md (legacy: ENTREGA.md) | `## Summary`, `## Components` (con `### <Component>`), `## Flows / interactions`, `## UX decisions`, `## Out of scope` | 150-300 líneas |
-
-Tamaño objetivo es **suave**: pasarlo está OK si se justifica.
-
-## Reglas operativas por artefacto
-
-- **OBJECTIVE**: `## Context` arranca con "Lo que NO está en la pregunta:". Sin sección `## Restricciones` separada.
-- **TASKS**: prohibido código inline. Si hace falta código, va en EVIDENCE y se referencia.
-- **DECISIONS**: si una DEC-NNN es obvia, no se registra. Sin SQL/código inline.
-- **STATUS**: sin `## Artefactos` enumerando archivos (`ls` ya lo hace). Sin `## Handoff sugerido` separado.
-- **CHECKPOINT**: si una sección no aplica, se borra entera. Sin placeholders vacíos.
-- **EVIDENCE**: cada hallazgo 4-8 líneas. Tablas solo si comparan más de 3 cosas.
-- **CONCLUSIONS**: sin `## Context` que repita el OBJECTIVE. Sin opciones falsas tipo "no hacer nada". Sin pseudocódigo. Cada `**CN**` con evidencia link; cada `**RN**` con responsable + cuándo.
-
-## Sandbox read-only
-
-Canon universal en `../session/references/sandbox-readonly-rules.md`. Esta skill es read-only por diseño — carga reglas de redacción, no escribe artefactos por sí misma. Los skills consumidores (`session`, `compact`, `resume`, etc.) son quienes producen el `.md`.
-
-En plan mode: describir en el plan file qué artefacto se redactaría (OBJECTIVE / TASKS / DECISIONS / EVIDENCE / FINDINGS / CONCLUSIONS / CHECKPOINT / STATUS / commit-msg / PR-description), qué reglas operativas aplican, y el tamaño objetivo en líneas. NO ejecuta `Write`, `Edit`, `MultiEdit` por sí misma — describe el contenido para que el consumidor lo materialice.
-
-Compatible con plan mode sin restricciones adicionales.
-
-## Referencias
-
-- Propuesta origen: `agent-workflow/docs/propuestas/001-simplificar-artefactos.md` (graduado de session005-analyze; el repo legacy era `core-workflow-plugin`).
-- Templates afectados: `agent-workflow-cli/src/application/templates/objective.ts` (canon EN; ES legacy `OBJETIVO.md` sigue siendo legible vía bilingual readers R1).
-- Skills consumidores: `session`, `compact`, `resume`, y los workflows `dev-workflow`/`design-workflow`/`analyze-workflow` (todos en `agent-workflow`).

package/skills/agent-workflow/standards/sql-rollback-generator/SKILL.md

@@ -1,158 +0,0 @@
----
-name: sql-rollback-generator
-description: "Genera `00-ROLLBACK.sql` único al root del bundle, leyendo los forwards ya escritos por `/agent-workflow:export-scripts` v5.0.0+. v3.0.0 BREAKING (session103): lee los archivos `NN-*.sql` consolidados (no `SCRIPTS.sql` por sesión); headers SQL mínimos (1-2 líneas); orden inverso del último forward al primero. Bloque `BEGIN; ... COMMIT;` único + bloque opcional `Fase 5 — Cleanup irreversible` después del COMMIT para operaciones no revertibles automáticamente (DROP COLUMN, TRUNCATE, ALTER COLUMN TYPE con pérdida). NO genera companions `.rollback.sql` ni sub-carpetas per-sesión."
-version: 3.0.0
----
-
-# SQL Rollback Generator — `00-ROLLBACK.sql` único, derivado de forwards
-
-Genera el rollback **derivado de los forwards consolidados**. Invocado por `/agent-workflow:export-scripts` v5.0.0+ después de escribir los archivos `NN-*.sql` del bundle.
-
-> v3.0.0 (session103) — lee los forwards ya escritos en vez de `SCRIPTS.sql` original. Headers minimal (1-2 líneas). Sin verbosidad de motivación/impacto.
-
-## When to use
-
-- **Disparado por `/agent-workflow:export-scripts`** después del Paso 5 (forwards escritos).
-- NL del usuario: "generar rollback", "script de reversa".
-- En plan-mode: simular el rollback de un cambio específico sin escribir archivos.
-
-## Sandbox read-only
-
-`../session/references/sandbox-readonly-rules.md`. Plan describe estructura del rollback sin escribir archivos.
-
-## Principios (v3.0.0)
-
-- **Input**: los archivos `NN-*.sql` forward ya escritos en el bundle (no `SCRIPTS.sql` original).
-- **Output único**: `<bundle-root>/00-ROLLBACK.sql`.
-- **Orden interno**: inverso del último forward al primero — si el bundle es `01-DDL-TABLES.sql, 02-DML.sql, 03-INSERTS.sql`, el rollback procesa `03 → 02 → 01`.
-- **Headers mínimos**: 2 líneas para el archivo, 1 línea por sentencia.
-- **Bloque transaccional único** `BEGIN; ... COMMIT;`.
-- **Bloque Fase 5** después del COMMIT (solo si hay irreversibles): operaciones que no se pueden revertir automáticamente.
-- **Idempotencia obligatoria**: `DROP ... IF EXISTS`, `CREATE OR REPLACE`.
-
-## Estructura del `00-ROLLBACK.sql`
-
-Header del archivo (2 líneas):
-
-```sql
--- 00-ROLLBACK.sql — bundle NNN-export-scripts-YYYY-MM-DD
--- Generado por agent-workflow sql-rollback-generator v3.0.0
-```
-
-Sub-bloque por sentencia (1 línea de comentario + SQL):
-
-```sql
--- Revierte: sessionXXX / stmt-id (forward: 02-DML.sql)
-ALTER TABLE esq_.tb_x ALTER COLUMN col_y TYPE varchar(80);
-```
-
-Bloque Fase 5 (al final, fuera de la transacción — solo si hay irreversibles):
-
-```sql
-COMMIT;
-
--- Fase 5 — Cleanup irreversible (manual)
--- sessionXXX / UPDATE esq_.tb_y sin backup automático: completar valores previos manualmente.
--- sessionYYY / TRUNCATE esq_.tb_z: pérdida total, sin reversa.
-```
-
-Sin templates `BEGIN; UPDATE … COMMIT;` comentados ni explicaciones largas. Solo una línea por irreversible identificando origen y razón.
-
-## Estrategias por tipo de operación
-
-### DDL de tablas
-
-| Forward | Rollback |
-|---|---|
-| `CREATE TABLE IF NOT EXISTS esq_.tb_x` | `DROP TABLE IF EXISTS esq_.tb_x;` |
-| `ALTER TABLE tb_x ADD COLUMN col_y ...` | `ALTER TABLE tb_x DROP COLUMN IF EXISTS col_y;` |
-| `CREATE INDEX idx_... ON tb_x(col)` | `DROP INDEX IF EXISTS idx_...;` |
-| `CREATE SEQUENCE esq_.seq_tb_x` | `DROP SEQUENCE IF EXISTS esq_.seq_tb_x;` |
-| `ALTER COLUMN col TYPE varchar(255)` (widen) | `ALTER COLUMN col TYPE varchar(80);` (con nota Fase 5 si datos exceden 80) |
-| `DROP TABLE tb_x` | **Irreversible** → Fase 5 (requiere backup previo a `esq_audit`) |
-
-### DDL de funciones
-
-| Forward | Rollback |
-|---|---|
-| `CREATE OR REPLACE FUNCTION fn_x(...)` | `DROP FUNCTION IF EXISTS fn_x(<firma>);` |
-| `DROP FUNCTION fn_x` | **Irreversible** → Fase 5 |
-
-### Migración de datos (UPDATE / DELETE)
-
-- Si el forward incluye backup explícito en `esq_audit.tb_bkp_*_sNNN` (visible en el forward consolidado): rollback `UPDATE … FROM esq_audit.tb_bkp_…`.
-- Si NO hay backup automático en el forward: **Fase 5**, con nota de una línea ("`sessionXXX` / UPDATE sin backup: completar valores previos manualmente").
-
-### Inserts
-
-```sql
-DELETE FROM esq_.tb_maestras WHERE campo_identificador IN (<lista>);
-```
-
-Usar claves naturales o rango de IDs conocido — nunca DELETE sin WHERE.
-
-### Irreversibles → Fase 5
-
-- `TRUNCATE TABLE`
-- `DROP COLUMN` sin respaldo previo
-- `DROP TABLE` sin respaldo previo
-- `ALTER COLUMN TYPE` con pérdida (varchar widen → narrow si datos exceden)
-- Cascadas destructivas (`DROP ... CASCADE`)
-- `DELETE`/`UPDATE` sin respaldo en `esq_audit`
-
-Cada uno aparece como **una sola línea** en la Fase 5, identificando origen + razón. Sin templates comentados ni explicaciones extensas.
-
-## Proceso (v3.0.0)
-
-1. Leer los archivos `NN-*.sql` forward escritos en el bundle (no `SCRIPTS.sql` original).
-2. Parsear cada bloque (un BEGIN/COMMIT por sentencia, identificada por `-- sessionXXX / stmt-id`).
-3. Para cada sentencia forward, clasificar el tipo y seleccionar estrategia (DDL / migración / inserts / irreversible).
-4. Generar el bloque rollback correspondiente (header de 1 línea + SQL inverso).
-5. Identificar irreversibles → moverlos a la Fase 5 al final.
-6. Componer el `00-ROLLBACK.sql` único con orden inverso (último forward → primero, dentro de cada uno última sentencia → primera).
-7. Escribir el archivo al root del bundle.
-
-## Notas de portabilidad
-
-PostgreSQL como motor primario. Para otros motores, ajustar sintaxis idempotente:
-
-| Concepto | PostgreSQL | Oracle | SQL Server |
-|---|---|---|---|
-| Drop idempotente | `DROP … IF EXISTS` | `DROP … (no IF EXISTS)` | `DROP … IF EXISTS` |
-| Recrear función | `CREATE OR REPLACE FUNCTION` | `CREATE OR REPLACE FUNCTION` | `CREATE OR ALTER PROCEDURE` |
-
-Si el destino no es Postgres, indicarlo en el header del archivo (línea adicional opcional).
-
-## Layout (post-export-scripts v5.0.0)
-
-```
-<docs>/scripts/NNN-export-scripts-YYYY-MM-DD/
-└── 00-ROLLBACK.sql                # este skill lo genera
-```
-
-Para context: el bundle plano del export incluye además `01-…`, `02-…`, etc. (forwards en orden ascendente, numeración continua) + `README.md` — todos al root, generados por `export-scripts`.
-
-**No se generan** desde v2.0.0:
-
-- Companions `.rollback.sql` por sentencia.
-- Sub-carpeta `<session>/rollback/` per-sesión.
-- Archivo `rollback-global.sql` separado.
-
-## Integración con otros skills
-
-- **`export-scripts`** v5.0.0+ — único invocador activo; pasa los forwards ya escritos.
-- **`sql-script-organizer`** — companion que organiza el `SCRIPTS.sql` por sesión.
-- **`coding-standards`** — reglas de estilo SQL.
-- **`session`** — este skill NO se invoca al cerrar una sesión individual; sólo desde export-scripts.
-
-## Histórico de versiones
-
-- **v3.0.0** (session103, 2026-05-28) — lee forwards ya escritos en vez de `SCRIPTS.sql` original; headers SQL minimal; Fase 5 sin templates comentados.
-- **v2.0.0** (session093) — `00-ROLLBACK.sql` único cross-session leyendo `SCRIPTS.sql`. Histórico.
-- **v1.0.0** y anteriores — companions `.rollback.sql` + per-sesión rollback. Histórico.
-
-## Recursos adicionales
-
-- **`references/rollback-patterns.md`** — recetas completas con ejemplos SQL.
-- **`references/irreversible-checklist.md`** — lista de irreversibles y protocolo.
-- **`references/release-rollback.md`** — algoritmos legacy (modo release, deprecation Fase 1).

package/skills/agent-workflow/standards/sql-rollback-generator/references/irreversible-checklist.md

@@ -1,161 +0,0 @@
-# Checklist de Operaciones Irreversibles
-
-Operaciones que no pueden revertirse automáticamente. Requieren protocolo especial antes de ejecutar.
-
----
-
-## Protocolo ante una operación irreversible
-
-Antes de ejecutar cualquier operación de esta lista:
-
-1. **Agregar `-- WARNING: IRREVERSIBLE`** en el header del forward script
-2. **Crear script de respaldo** si hay datos en riesgo (ver plantillas en `rollback-patterns.md`)
-3. **Registrar en `DECISIONS.md`** de la sesión:
-   - Qué se va a ejecutar
-   - Por qué no es reversible
-   - Qué backup existe (o por qué no aplica)
-   - Confirmación explícita del usuario
-4. **Generar rollback best-effort** con nota `-- RESTAURACIÓN MANUAL REQUERIDA` si el rollback automático no es posible
-5. **Checkpoint**: el usuario debe confirmar explícitamente antes de continuar
-
----
-
-## Lista de operaciones irreversibles
-
-### TRUNCATE TABLE
-
-```sql
--- WARNING: IRREVERSIBLE
--- Elimina TODOS los datos de la tabla sin posibilidad de rollback transaccional en algunos motores.
--- En PostgreSQL se puede envolver en BEGIN/COMMIT, pero el efecto es inmediato si se confirma.
--- Respaldo obligatorio en esq_audit antes de ejecutar.
-```
-
-**Mitigación**: `CREATE TABLE esq_audit.tb_bkp_x_sessionXXX AS SELECT * FROM esq_.tb_x;` antes.
-
----
-
-### DROP COLUMN sin respaldo previo
-
-```sql
--- WARNING: IRREVERSIBLE
--- La columna y sus datos se pierden permanentemente.
--- Respaldo: ALTER TABLE tb_x ADD COLUMN col_bkp ... + UPDATE SET col_bkp = col_original;
--- o bien: CREATE TABLE esq_audit.tb_bkp_x_col_sessionXXX AS SELECT id, col FROM tb_x;
-```
-
-**Mitigación**: copiar los valores a una columna temporal o tabla de backup antes del DROP.
-
----
-
-### DROP TABLE sin respaldo previo
-
-```sql
--- WARNING: IRREVERSIBLE
--- La tabla y todos sus datos, índices, constraints y sequences asociados se pierden.
--- Respaldo obligatorio: CREATE TABLE esq_audit.tb_bkp_x_sessionXXX AS SELECT * FROM esq_.tb_x;
-```
-
----
-
-### ALTER COLUMN TYPE con pérdida de precisión
-
-```sql
--- WARNING: IRREVERSIBLE
--- Cambiar de varchar(500) a varchar(50) trunca datos. Cambiar de numeric(18,4) a integer pierde decimales.
--- Verificar que no hay datos que excedan el nuevo tamaño/precisión ANTES de ejecutar.
-```
-
-**Mitigación**:
-```sql
--- Verificar antes:
-SELECT COUNT(*) FROM esq_.tb_x WHERE length(col_x) > 50;
-SELECT COUNT(*) FROM esq_.tb_x WHERE col_x != FLOOR(col_x);
-```
-
----
-
-### DROP ... CASCADE
-
-```sql
--- WARNING: IRREVERSIBLE
--- Elimina el objeto Y todos los objetos que dependen de él (views, funciones, constraints).
--- Listar dependencias antes: SELECT * FROM information_schema.constraint_column_usage WHERE table_name = 'tb_x';
-```
-
-**Mitigación**: antes de ejecutar, listar todas las dependencias y generar los scripts para recrearlas.
-
----
-
-### DELETE sin WHERE (o con WHERE muy amplio)
-
-```sql
--- WARNING: IRREVERSIBLE
--- Un DELETE sin cláusula WHERE o con condición demasiado amplia puede vaciar una tabla.
--- Respaldo obligatorio: CREATE TABLE esq_audit.tb_bkp_x_sessionXXX AS SELECT * FROM esq_.tb_x WHERE <condicion>;
-```
-
-**Verificación previa recomendada**:
-```sql
--- Ejecutar primero como SELECT para ver qué filas afecta:
-SELECT COUNT(*) FROM esq_.tb_x WHERE <condicion_del_delete>;
-```
-
----
-
-### UPDATE sin WHERE sobre tabla grande
-
-```sql
--- WARNING: ALTA SUPERFICIE DE IMPACTO
--- Un UPDATE sin WHERE o con condición muy amplia modifica todas las filas.
--- Si es intencional, documentarlo explícitamente en DECISIONS.md.
--- Respaldo obligatorio antes de ejecutar.
-```
-
----
-
-### Eliminar función sin versión anterior conocida
-
-```sql
--- WARNING: IRREVERSIBLE
--- Si no hay registro de la versión anterior de la función (no está en el repo ni en la sesión),
--- no es posible generar un rollback automático.
--- El rollback best-effort debe incluir el cuerpo actual en un comentario para restauración manual.
-```
-
----
-
-### Cambiar tipo de columna con conversión destructiva
-
-Por ejemplo: `varchar` → `integer` donde algunos valores no son números; `timestamp` → `date` perdiendo la hora.
-
-**Mitigación**:
-```sql
--- Verificar antes:
-SELECT col_x FROM esq_.tb_x WHERE col_x !~ '^\d+$';  -- filas que no son números
-```
-
----
-
-## Formato del header para scripts irreversibles
-
-```sql
--- Archivo: 001-elimina-col-legacy-tb-credito.sql
--- Sesión: sessionXXX-nombre-kebab (YYYY-MM-DD)
--- WARNING: IRREVERSIBLE — DROP COLUMN sin restauración automática posible
--- Respaldo: esq_audit.tb_bkp_credito_col_legacy_sessionXXX (creado en 000-backup.sql)
--- Decisión: DECISIONS.md DEC-XXX — aprobado por [usuario]
-BEGIN;
--- cuerpo del script
-COMMIT;
-```
-
----
-
-## Verificaciones antes de ejecutar en producción
-
-- [ ] El script de respaldo fue ejecutado y verificado (`SELECT COUNT(*) FROM esq_audit.tb_bkp_...`)
-- [ ] La decisión está registrada en `DECISIONS.md`
-- [ ] El usuario confirmó explícitamente la ejecución
-- [ ] Se tiene el rollback best-effort documentado (aunque sea manual)
-- [ ] Se notificó al equipo si el cambio afecta a otros servicios