Elegir el método de trabajo

Con IA no conviene construir por capas completas (toda la UI, después toda la BD, después toda la API): la sesión pierde el hilo, nada funciona hasta el final y los errores de diseño aparecen tarde. La base es construir por bloques: cada bloque cruza UI, datos y API, se prueba solo y queda usable. Lo que cambia según el proyecto es cuánto se define antes de empezar. La alternativa es backend primero por módulo (skill backend-quality-gate): no es por capas de todo el sistema, sino módulo por módulo, cerrando y probando la API antes de sus pantallas.

Quien decide es el usuario. La IA recomienda un método y dice por qué, pero muestra las otras opciones, el usuario escoge (aunque no sea la recomendada) y puede cambiar de método cuando quiera. La IA nunca impone un método ni sigue uno que el usuario no aprobó.

Pasos

1. Si existe docs/METODO.md, léelo y síguelo. No vuelvas a preguntar. Si el usuario pide cambiar de método, ve al paso 6. Si ves que el proyecto cambió de fase (por ejemplo, el spike ya validó la idea), sugiérelo en una línea; el cambio lo decide el usuario.
2. Averigua lo que falte. Primero mira el repo (¿hay código?, ¿hay docs/?). Pregunta solo lo que no puedas deducir, en un solo mensaje:
   • ¿La idea está clara o todavía se está descubriendo?
   • ¿Hay un cliente con alcance cerrado o una norma externa (facturación fiscal, pagos, ministerio)?
   • ¿Hay código existente con patrones que seguir?
   • ¿Cuántos flujos de usuario tiene la primera versión?
   • ¿Cuántas personas van a trabajar en el código? ¿Hay alguna parte con carga o tecnología muy distinta al resto (búsqueda, tiempo real, procesamiento pesado)? Solo si hace falta para decidir la arquitectura (ver abajo).
3. Recomienda un método de esta tabla. Tu recomendación va primero y con argumentos, no como una lista neutral.

Arquitectura. Junto con el método, di en una línea qué arquitectura recomiendas. Por defecto es un monolito modular (skill fullstack). Si hay dos o más señales de la skill microservicios (equipos que se pisan, un área con carga o tecnología muy distinta, despliegues independientes, aislar fallas como requisito), ofrece microservicios como opción y usa esa skill para el diseño. Si el usuario pide microservicios sin esas señales, dile el costo en corto: la decisión es suya. La arquitectura también la escoge el usuario y se anota en docs/METODO.md.

4. Presenta la decisión al usuario en un solo mensaje:

   • Recomendado: el método, 2 pros y 2 contras para ESTE proyecto (no genéricos).
   • Otras opciones: las 1 o 2 alternativas que también tienen sentido aquí, una línea cada una con cuándo convendrían más.
   • La pregunta: "¿Seguimos con el recomendado o prefieres otro?". El usuario también puede proponer su propia forma de trabajar.

   Si tienes la herramienta AskUserQuestion, haz la pregunta con ella: el método recomendado primero con (Recomendado) en la etiqueta y sus pros y contras en la descripción, y las alternativas como las otras opciones. Si la arquitectura o las herramientas ya las escogió el usuario con la skill crear-app, no las vuelvas a preguntar.

   No escribas código ni docs/METODO.md hasta que el usuario escoja.

5. Escribe docs/METODO.md con el método que el usuario escogió, sea o no el recomendado, usando la plantilla de abajo. Si escogió otro, anota tu recomendación y su motivo en una línea, sin insistir. Sigue con desarrollo-por-etapas, o con backend-quality-gate si escogió backend primero por módulo. Si es un spike, la regla del spike va en el archivo: se bota, no se convierte en producción.
6. Cambiar de método después. El usuario puede cambiarlo en cualquier momento ("ya no quiero bloques", "el spike ya validó la idea"). Entonces:
   • Di en corto qué implica el cambio para lo que ya está hecho (por ejemplo, qué bloques quedan a medias).
   • Actualiza docs/METODO.md: el método nuevo arriba y una línea en "Historial de cambios" con fecha, de qué a qué y por qué.
   • Ajusta docs/ETAPAS.md si la lista de bloques o la etapa actual cambian.

Cómo partir en bloques

• Un bloque es un flujo que un usuario puede completar: "iniciar sesión", "registrar estudiante", "cobrar una factura". "Módulo académico" no es un bloque.
• Para encontrar los bloques, escribe primero los escenarios en una línea: "la contadora necesita ver los ingresos del mes para cuadrar con el banco". Cada escenario (o grupo pequeño) es un bloque. El detalle de cada escenario se escribe en C1 de desarrollo-por-etapas, cuando le toca a ese bloque, no todos al principio.
• Si no se puede probar con un e2e de un flujo, es muy grande: pártelo.
• Bloque 0 siempre primero: repo, auth base, usuario, permisos, multi-tenant si aplica, base de datos, CI, deploy y un dato que viaje de la BD a una pantalla. Deja un módulo de ejemplo que los demás bloques copien.
• Ordena por dependencias y luego por riesgo: lo más incierto va temprano.
• Cada 3 o 4 bloques, una ronda de limpieza: /mapa-bloque sobre lo construido y refactor de lo que salga.

Plantilla de docs/METODO.md

# Método — <proyecto>

Decidido: <fecha>
Método: <spike | bloques con definición completa | bloque único | spec corto + bloques | definición cerrada + bloques | backend primero por módulo | otro que propuso el usuario>
Arquitectura: <monolito modular | monolito modular listo para extraer | microservicios (ver docs/ARQUITECTURA.md) | serverless | frontend + backend como servicio>
Herramientas: <estándar del kit (skill fullstack) | Next.js fullstack | solo API NestJS | otro: ...>
Escogido por: el usuario (recomendado por la IA: <sí | no, recomendó X porque ...>)
Por qué: <2 o 3 líneas con lo que respondió el usuario>
Alternativas consideradas: <las otras opciones que se mostraron>

## Bloques planeados (el avance se lleva en docs/ETAPAS.md)
| # | Bloque | Escenario en una línea | Depende de | Carpeta |
|---|--------|------------------------|------------|---------|
| 0 | Esqueleto | — | — | — |
| 1 | ... | <quién> necesita <qué> para <para qué> | 0 | src/... |

## Reglas transversales (las verifica cada puerta)
- Permisos: ...
- Multi-tenant: ...
- Auditoría: ...

## Cuándo revisar este método
- <por ejemplo: cuando el spike responda X>

## Historial de cambios
| Fecha | De | A | Por qué |
|-------|----|---|---------|