Fix Decomposer

---
name: fix-decomposer
description: >
  Descompone un fix grande en porciones atomicas cuando el cambio es demasiado amplio para resolverse de una sola vez.
  Usa esta skill SIEMPRE que la skill fix-developer detecte que un fix supera los criterios de complejidad,
  o cuando el usuario mencione descomponer un fix, dividir un fix en partes, crear porciones de fix, o fix grande.
  La skill advierte al desarrollador, descompone el fix en porciones Front/Back, incluye una porcion de verificacion de regresion,
  y guarda todo en una carpeta de documentacion del modulo afectado.
---

# Fix Decomposer

Cuando un fix es demasiado grande para resolverse de forma quirúrgica, esta skill lo descompone en porciones atómicas documentadas, organizadas para ser desarrolladas con las skills de frontend-developer y backend-developer.

---

## Criterios para activar esta skill

Un fix se considera **grande** y debe descomponerse en porciones cuando cumple **al menos uno** de estos criterios:

- 📁 **Más de 3 archivos** a modificar
- 🗂️ **Afecta más de 1 módulo** del sistema
- 🗄️ **Requiere cambios en la base de datos** (migraciones, nuevos campos, nuevas tablas)

Cuando fix-developer detecta esto durante su análisis de impacto, debe pausar y derivar a esta skill:

> ⚠️ **Este fix es más grande de lo que parece.**
>
> Detecté que requiere {criterio/s que se cumplen: ej. modificar 5 archivos en 2 módulos distintos}. Encararlo como un fix simple tiene riesgo de introducir errores difíciles de rastrear.
>
> Te sugiero descomponerlo en porciones para resolverlo de forma ordenada y documentada. ¿Querés que lo descomponga?

Si el desarrollador acepta, continuar con el flujo de esta skill. Si prefiere seguir con el fix simple de todas formas, respetar la decisión y continuar con fix-developer.

---

## Formato de cada porción de fix

Cada porción se guarda como un archivo `.md` individual.

**Ruta:** `docs/historias-de-usuario/{modulo}-fix/porcion-{NNN}.md`

El nombre de la carpeta usa el nombre del módulo afectado en kebab-case seguido de `-fix`. Ejemplos: `modulo-operaciones-fix/`, `modulo-auth-fix/`, `modulo-stock-fix/`.

```markdown
# porcion-{NNN} — {Título descriptivo} [{FRONT|BACK|FRONT+BACK}]

**Módulo:** {nombre del módulo afectado}
**Tipo de porción:** Fix
**Porción original:** porcion-{NNN} *(porción de desarrollo que se está corrigiendo, si aplica. Si el fix no corrige una porción específica sino comportamiento general, escribir "N/A")*
**Par:** porcion-{NNN} *(si tiene par Front/Back, indicar el número. Si no tiene par, omitir)*
**Prerequisitos:** porcion-{NNN}, porcion-{NNN} *(porciones de fix que deben completarse antes. Si no hay, escribir "Ninguno")*

## Descripción

{Qué se implementa en esta porción, en el lenguaje más sencillo posible.}

## Estado actual vs estado esperado

**Hoy:** {qué hace o muestra actualmente — el comportamiento incorrecto}
**Debería:** {qué debería hacer o mostrar una vez aplicado el fix}

## Criterios de aceptación

- [ ] {criterio 1}
- [ ] {criterio 2}
- [ ] {criterio 3}
- [ ] El componente es responsive y se visualiza correctamente en mobile, tablet y desktop *(solo para porciones FRONT)*

## Pruebas

### Pruebas unitarias

- [ ] {prueba 1: qué se prueba y qué resultado se espera}
- [ ] {prueba 2}

### Pruebas de integración

- [ ] {prueba 1: qué interacción entre componentes/servicios se prueba y qué se espera}
- [ ] {prueba 2}
```

---

## Formato de la porción de regresión

La última porción de todo fix descompuesto es siempre una porción de **verificación de regresión**. No tiene desarrollo — es una checklist de pasos manuales que el dev ejecuta después de completar todas las porciones de fix para confirmar que nada se rompió.

```markdown
# porcion-{NNN} — Verificación de regresión [REGRESION]

**Módulo:** {nombre del módulo afectado}
**Tipo de porción:** Regresión
**Porción original:** N/A
**Prerequisitos:** todas las porciones de fix anteriores

## Descripción

Verificación manual de que el fix no introdujo nuevos errores en los flujos existentes del módulo {nombre}.

## Pasos de verificación

### Flujos del módulo afectado

1. {paso concreto: qué hacer y qué debería verse/pasar si está bien}
2. {paso concreto}
3. {paso concreto}

### Flujos de módulos relacionados *(si el fix tocó más de un módulo)*

1. {paso concreto en el módulo secundario afectado}
2. {paso concreto}

### Verificación de base de datos *(si el fix incluyó migraciones)*

1. {qué tabla/campo verificar y qué valor o estructura se espera encontrar}

## Resultado esperado

Si todos los pasos anteriores se comportan correctamente, el fix está completo y no introdujo regresiones.

**Una vez verificado, marcar esta porción como completada.**
```

---

## Flujo de trabajo

### Paso 1 — Analizar el fix y el proyecto

Leer el problema reportado y explorar el código afectado para entender:

- Qué módulos y archivos están involucrados
- Si requiere cambios en la BD
- Si hay porciones de desarrollo originales que se están corrigiendo (buscar en `docs/historias-de-usuario/` las porciones relacionadas)
- El orden lógico de resolución: qué debe arreglarse primero para que lo siguiente funcione

**Criterio FRONT vs BACK:** igual que en story-decomposer — el criterio es dónde se ejecuta el código, no si es visual. Contextos, hooks, layouts y stores son siempre FRONT aunque sean infraestructura.

---

### Paso 2 — Proponer el plan de porciones

Antes de generar los archivos, presentar el plan al desarrollador para que lo valide:

> **🔧 Propongo descomponer este fix en {N} porciones:**
>
> | # | Porción | Tipo | Par | Porción original | Prerequisitos |
> |---|---------|------|-----|-----------------|---------------|
> | porcion-001 | {título} | FRONT | porcion-002 | porcion-003 | Ninguno |
> | porcion-002 | {título} | BACK | porcion-001 | porcion-004 | Ninguno |
> | porcion-003 | {título} | BACK | — | N/A | porcion-002 |
> | porcion-004 | Verificación de regresión | REGRESION | — | N/A | todas |
>
> **Carpeta:** `docs/historias-de-usuario/{modulo}-fix/`
>
> ¿Este desglose tiene sentido? ¿Querés ajustar algo antes de generar los archivos?

Esperar confirmación antes de continuar.

---

### Paso 3 — Preguntar solo lo necesario

Si hay ambigüedades que impidan definir bien una porción, preguntar puntualmente. **Máximo 3 preguntas a la vez.**

---

### Paso 4 — Generar las porciones

Una vez aprobado el plan, generar cada porción siguiendo los formatos definidos arriba.

**Reglas al generar:**

- Descripción en lenguaje simple, comprensible para cualquier miembro del equipo
- El campo "Estado actual vs estado esperado" debe ser concreto y verificable, no genérico
- Criterios de aceptación verificables con Sí/No
- Mínimo 2 pruebas unitarias y 1 de integración por porción (excepto la porción de regresión)
- Edge cases obligatorios: al menos 2 casos borde por porción
- La porción de regresión siempre va última y cubre todos los flujos que podrían haberse afectado

---

### Paso 5 — Guardar los archivos

```bash
# Crear carpeta del fix
mkdir -p docs/historias-de-usuario/{modulo}-fix

# Guardar cada porción
# docs/historias-de-usuario/{modulo}-fix/porcion-001.md
# docs/historias-de-usuario/{modulo}-fix/porcion-002.md
# ...
# docs/historias-de-usuario/{modulo}-fix/porcion-00N.md  <- regresión siempre última
```

Confirmar al desarrollador:

> ✅ Generadas {N} porciones en `docs/historias-de-usuario/{modulo}-fix/`:
> - porcion-001.md — {título}
> - porcion-002.md — {título}
> - porcion-00N.md — Verificación de regresión
>
> Para desarrollar cada porción usá las skills **frontend-developer** y **backend-developer** en el orden sugerido.

---

## Reglas generales

- **La porción de regresión es obligatoria** — todo fix descompuesto termina con una porción de regresión, sin excepción
- **La regresión no tiene desarrollo** — es solo verificación manual, no se implementa código
- **Referencia a porción original siempre** — si el fix corrige algo desarrollado en una porción específica, debe quedar referenciado. Si no aplica, escribir "N/A"
- **Numeración desde 001** dentro de la carpeta del fix, independientemente de las porciones de la HU
- **Criterio FRONT vs BACK** — el código que se ejecuta en el cliente es siempre FRONT, el que se ejecuta en el servidor es siempre BACK
- **Si el dev rechaza descomponer** — respetar la decisión y continuar con fix-developer normalmente

---

## Relación con otras skills

- **Origen**: fix-developer detecta que el fix supera los criterios de complejidad y deriva a esta skill
- **Desarrollo**: una vez generadas las porciones, se desarrollan con **frontend-developer** y **backend-developer**
- **Regresión**: la porción de regresión se ejecuta manualmente por el dev, no requiere ninguna skill de desarrollo