# Flujo de trabajo con gstack

# Flujo de trabajo con gstack

## Qué es
`gstack` es el paquete de skills (`/spec`, `/qa`, `/review`, etc.) instalado para apoyar el ciclo de desarrollo. **Programar el código en sí no tiene skill** — eso se pide directo, sin slash, como cualquier otro pedido.

## ⚠️ Excepciones de este proyecto (leer antes de usar `/ship`, `/qa` o un flujo que toque varios repos)

1. **No usar `/ship` para pushear o abrir PR automático.**
   CLAUDE.md dice: *"Los commits los hace el usuario — Claude solo edita archivos."*
   `/ship` sincroniza, testea y audita cobertura sin problema, pero el commit/push/PR lo confirmas tú explícitamente antes de que se ejecute.

2. **Son 3 repos independientes, no uno solo.**
   `team-safety-backend`, `team-safety-frontend` y `team-safety-bot` son cada uno su propio git. La raíz `E:\Ejercicios\ts` **no** es un repo.
   Si una feature toca 2 repos (ej. endpoint nuevo + pantalla que lo consume), corre el flujo (`/review`, `/ship`, etc.) **una vez por repo**, no una sola vez para todo el cambio.

3. **`/qa` (navegador) no aplica al repo `bot`.**
   `team-safety-bot` no tiene UI propia — es Puppeteer automatizando el portal del Ministerio. Para bugs ahí: `/investigate` + prueba manual contra el portal, no `/qa`.

---

## Uso cotidiano

**`/review`** — revisa el diff actual como ingeniero senior buscando bugs que pasan CI pero rompen en producción. Si encuentra algo, lo corrige.
> Ejemplo: tocaste `approveCourse` → `/review` → detecta que la aprobación masiva no valida el examen médico y lo corrige.

**`/qa-only`** — abre el navegador, prueba lo que tocaste, entrega la lista de bugs sin corregir nada.
> Ejemplo: cambiaste el formulario de inscripción → `/qa-only` → "el botón Guardar queda habilitado sin adjuntar la planilla" — decides si lo arreglas o pasas a `/qa`.

**`/diagram`** — genera un diagrama (mermaid/excalidraw/svg) desde una descripción en texto.
> Ejemplo: `/diagram el flujo del QR desde inscripción hasta firma del aprendiz` → diagrama de secuencia, sin herramienta externa.

---

## Para un bug

1. **`/investigate`** + descripción del síntoma → rastrea causa raíz antes de tocar código.
   > Ejemplo: "el ícono de requisitos no se actualiza al cerrar el modal" → causa: `onModalRequirementClose` no recargaba la lista.
2. **Corregir** — con la causa identificada, aplicas el fix.
3. **`/review`** — valida que el fix no rompa nada nuevo.
4. **`/qa`** — reproduce el bug original en navegador, confirma que ya no pasa, deja un test de regresión.
   > Ejemplo: tras el fix del ícono → `/qa` abre el modal, lo cierra, confirma que el ícono ya refleja el estado real.

---

## Para módulo/servicio nuevo desde cero (grande)

1. **`/spec`** — convierte la idea en spec ejecutable (problema, alcance, criterios de aceptación).
   > Ejemplo: `/spec necesito digitalizar el examen escrito del curso Coordinador (F-GF-36)` → casos de uso, modelo de datos, qué queda fuera de alcance.
2. **`/autoplan`** — encadena revisión de producto, diseño y arquitectura sobre esa spec.
   > Ejemplo: devuelve "falta el estado de calificación pendiente en la UI".
3. **Implementar** — con el plan validado. Si el alcance debe quedar contenido a una carpeta, `/guard <ruta>` antes de arrancar.
   > Ejemplo: `/guard team-safety-backend/src/main/java/com/teamsafety/service/coordinador` evita que el modelo toque por error el módulo de certificados.
4. **`/review` → `/qa` → `/cso`** — mismo review y qa de siempre; `/cso` audita OWASP Top 10.
   > Ejemplo `/cso`: detecta que el nuevo endpoint no valida que el coach solo vea sus propios cursos.
5. **`/document-release`** — actualiza docs para que coincidan con lo shippeado.
6. **`/ship`** — hasta dejar el cambio probado y listo; **el commit/push lo confirmas tú** (ver excepción #1).

---

## Para feature nueva en un módulo existente

1. **`/spec`** con alcance acotado.
   > Ejemplo: `/spec agregar exportación a Excel en el listado de asistencia`.
2. **`/plan-eng-review`** — mirada de arquitectura: qué se reutiliza, qué edge cases hay.
   > Ejemplo: "ya existe lógica de export en `CertificateService`, reusar el mismo patrón en vez de crear uno nuevo".
3. **`/plan-design-review`** (solo si tiene UI) — audita el plan de diseño antes de implementar.
   > Ejemplo: marca "falta definir el estado de carga mientras se genera el Excel".
4. **Implementar → `/review` → `/qa` → `/cso` → `/document-release` → `/ship`** — igual que el flujo grande.

---

## Para actualizar algo que ya existe

1. **`/plan-eng-review`** (si el cambio toca varias partes) — chequea qué más consume esa función antes de tocarla.
   > Ejemplo: vas a cambiar `evaluate-rule` (vigencia PILA) → revisa que Planilla y ARL usan la misma regla antes de modificarla.
2. **`/guard`** (opcional) — si quieres que el cambio no se escape del archivo/módulo puntual.
3. **Implementar** — el cambio en sí.
4. **`/review`** — valida que no rompiste nada al modificar.
5. **`/qa`** — prueba el comportamiento nuevo y que lo viejo alrededor sigue funcionando.
   > Ejemplo: actualizaste el cálculo de vigencia → `/qa` prueba un registro nuevo y uno viejo, confirma que el resultado no cambió donde no debía.
6. **`/document-release`** (solo si el cambio es visible para otros, no un detalle interno).