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).