Escenario de Desarrollo del Mundo Real: El Flujo de Trabajo Gstack Completo desde Nueva Funcionalidad hasta Producción

Los cinco artículos anteriores introdujeron cada skill de Gstack individualmente — pero después de leerlos, puede que todavía tengas una pregunta:

"¿Cómo se encadenan realmente estos skills?"

Saber que /plan-ceo-review maneja las decisiones de producto y /review encuentra bugs a nivel de producción no es suficiente — necesitas saber dónde encaja cada skill en un ciclo de desarrollo real y qué hacer después de ejecutar cada uno.

Este artículo demuestra el flujo de trabajo completo usando un escenario concreto.

El Escenario

Estás construyendo una herramienta SaaS y quieres añadir una nueva funcionalidad: los usuarios pueden fusionar múltiples informes y exportarlos como un único PDF.

La solicitud llegó de la retroalimentación de unos 15 usuarios. Crees que es de alta prioridad — pero todavía no has empezado a escribir ningún código.

Paso 1: `/plan-ceo-review` — Pregunta Primero Si Vale la Pena Construirlo

Abre Claude Code y escribe:

/plan-ceo-review

Quiero añadir una funcionalidad de "exportación fusionada a PDF". Los usuarios pueden seleccionar múltiples informes, y el sistema los combina en un único PDF para descargar.
La solicitud viene de la retroalimentación de unos 15 usuarios, principalmente usuarios tipo consultor que regularmente necesitan entregar informes a clientes.

El modo CEO de Gstack te hará algunas preguntas:

Estos 15 usuarios — ¿cómo están resolviendo este problema ahora mismo? ¿Combinando PDFs manualmente? ¿Usando otra herramienta?
¿Es "exportación fusionada" su solución, o es su problema? ¿Es su verdadero dolor "entregar informes a clientes es tedioso"?
¿Hay posiblemente una solución más fundamental más allá de "exportación fusionada" — como dejar que los informes tengan un "enlace compartido" para que los clientes accedan directamente?
Si el requisito de fusión de PDF es válido, ¿el orden de fusión, las portadas de informes y las marcas de agua necesitan estar en v1, o entregamos primero la versión más sencilla?

Estas preguntas te fuerzan a confirmar una cosa antes de empezar: estás resolviendo el problema real del usuario, no el problema que asumiste que tenían.

Digamos que después de ejecutar esto confirmas: la fusión de PDF es genuinamente su necesidad central, v1 entrega la versión más sencilla (seleccionar informes + descarga fusionada), las funcionalidades avanzadas vienen después.

Paso 2: `/plan-eng-review` — Convierte "Qué Construir" en "Cómo Construirlo Correctamente"

Decisión bloqueada, cambia al modo ingeniero:

/plan-eng-review

Funcionalidad confirmada: los usuarios pueden marcar múltiples informes en el dashboard (hasta 10), hacer clic en "exportación fusionada", el sistema fusiona en segundo plano y notifica al usuario cuando la descarga está lista.
El informe promedio tiene 5-20 páginas, el informe máximo tiene 50 páginas.
Nuestro backend es Node.js + PostgreSQL, los informes están almacenados en S3.

El modo ingeniero de Gstack genera:

Diagrama de secuencia — el usuario activa → el backend recibe la solicitud → el trabajo en segundo plano comienza → obtiene informes de S3 → fusiona PDF → guarda de vuelta en S3 → notifica al usuario. El diagrama muestra los límites asíncronos.

Lista de casos extremos:

¿Qué pasa si la URL de S3 de un informe expira durante el proceso de fusión?
¿Qué pasa si el usuario activa de nuevo mientras el trabajo todavía está en ejecución?
¿Cuánto tiempo debe almacenarse el PDF fusionado? ¿Hay un mecanismo de limpieza?
¿Cuánto tiempo tardará la fusión de 10 informes? ¿Cuál debería ser el timeout?

Matriz de tests:

Test unitario: lógica de fusión de PDF
Test de integración: flujo completo del trabajo en segundo plano
E2E: el camino completo desde que el usuario selecciona informes hasta la descarga

Este output es tu documento de diseño de arquitectura antes de escribir cualquier código. Tenerlo como referencia cuando te encuentras con problemas durante la implementación es mucho más claro que preguntarle a Claude "cómo escribo esto" desde cero.

Paso 3: Implementación

Aquí es donde Gstack da un paso atrás y tú (y Claude) escribís código.

Usa Claude Code para implementar basándote en el diseño de /plan-eng-review. Puedes continuar la conversación cuando te encuentres con problemas técnicos, pero no necesitas ningún skill específico de Gstack — esta fase es implementación pura.

Cuando hayas terminado, confirma:

La funcionalidad principal funciona
Los tests unitarios básicos están escritos
Probado localmente, sin problemas obvios

Paso 4: `/review` — Encuentra los Problemas que Pasan el CI pero Explotan en Producción

/review

No se necesita contexto adicional. Gstack lee tu git diff y encuentra los problemas introducidos por este cambio.

Digamos que esta vez encuentra:

Crítico: Condición de carrera en la fusión de PDF bajo solicitudes concurrentes — si el usuario hace clic dos veces rápidamente, dos trabajos podrían activarse, creando cargos y resultados duplicados
Alto: Las URLs prefirmadas de S3 expiran después de 1 hora si el trabajo en segundo plano se ejecuta durante más de eso, pero el timeout está configurado a 2 horas
Medio: Sin mecanismo de limpieza para PDFs fusionados, los costes de S3 seguirán creciendo

Arreglas los problemas Crítico y Alto, abres un ticket para el Medio a manejar en el próximo sprint.

Paso 5: `/qa` — Deja que la IA Pruebe la Funcionalidad con un Navegador Real

/qa

Gstack analiza el git diff, identifica las páginas afectadas — principalmente la página de lista de informes y la página de estado de exportación en el dashboard — luego abre un navegador y prueba:

Selecciona tres informes, activa la fusión, confirma que el trabajo en segundo plano comienza
Espera a que el trabajo termine, confirma que aparece la notificación y que el enlace de descarga funciona
Descarga el PDF, confirma que el contenido es correcto
Prueba el caso extremo de seleccionar solo un informe
Prueba el flujo de seleccionar informes y luego cancelar

Genera una puntuación de salud al final. Digamos que es 87 — los flujos principales están funcionando, algunos problemas menores de UX (como que el texto del estado de carga no es suficientemente claro), pero nada bloqueante.

Paso 6: `/ship` — Entrega con Un Solo Comando

/ship

Gstack ejecuta la lista de verificación de lanzamiento completa:

✅ Sync main — la rama está sincronizada con main
✅ Ejecutar tests — todos los tests pasan
✅ Push de rama — empujado a remoto
✅ Abrir PR — PR creada con una descripción clara que cubre el alcance de los cambios, el enfoque de pruebas y el problema medio conocido

Revisas la PR y haces merge.

El Flujo de Trabajo Completo de un Vistazo

Nuevo requisito de funcionalidad
    ↓
/plan-ceo-review   ← confirmar "vale la pena construirlo", definir el alcance claramente
    ↓
/plan-eng-review   ← diseñar arquitectura, identificar casos extremos y modos de fallo
    ↓
Implementación (Claude Code + tú)
    ↓
/review            ← encontrar problemas a nivel de producción, arreglar críticos / altos
    ↓
/qa                ← pruebas en navegador, confirmar que la funcionalidad funciona a nivel de UI
    ↓
/ship              ← sync, test, push, PR — el pipeline completo
    ↓
Merge, entregar a producción

¿Cuánto Tiempo Lleva Este Flujo?

Un ciclo completo, seis pasos, sin contar el tiempo de implementación:

/plan-ceo-review: 10-15 minutos (conversación + reflexión)
/plan-eng-review: 10-20 minutos (las funcionalidades complejas necesitan más tiempo de output)
/review: 5-10 minutos (leer resultados + arreglar problemas críticos)
/qa: 5-15 minutos (depende del número de páginas afectadas)
/ship: 2-3 minutos

Total: 30-60 minutos, sin contar la implementación. Suena a mucho, pero los problemas que previenen estos seis pasos típicamente llevan mucho más tiempo limpiar.

No Toda Funcionalidad Necesita el Flujo Completo

Los cambios más pequeños pueden saltarse algunos pasos:

Arreglar un bug pequeño: directamente a /review + /ship, saltar el Plan Review
Cambios de copia o estilo: /qa para confirmar los visuales, luego /ship
Añadir una opción de configuración: /plan-eng-review (verificación rápida de arquitectura) + /review + /ship

El criterio es una pregunta: si este cambio sale mal, ¿cuánto tiempo y esfuerzo lleva arreglarlo? Cuanto mayor sea la respuesta, más vale la pena ejecutar el flujo completo.

La serie Gstack está ahora completa. Una persona, nueve modos cognitivos, un ritmo de desarrollo repetible — desde "vale la pena construirlo" hasta "entregando a producción," cada fase tiene una herramienta correspondiente, sin depender de la memoria ni de la suerte.

→ Volver a la Visión General del Curso Gstack para Principiantes

El Escenario

Paso 1: /plan-ceo-review — Pregunta Primero Si Vale la Pena Construirlo

Paso 2: /plan-eng-review — Convierte "Qué Construir" en "Cómo Construirlo Correctamente"

Paso 3: Implementación

Paso 4: /review — Encuentra los Problemas que Pasan el CI pero Explotan en Producción

Paso 5: /qa — Deja que la IA Pruebe la Funcionalidad con un Navegador Real

Paso 6: /ship — Entrega con Un Solo Comando