Eje vertical
Rigor — cuánta ceremonia
Lean, Standard o Strict. Calibra la profundidad del análisis, cuántas lentes usa la revisión y qué verificaciones entran — según lo que esté en juego.
Metodología y rigor
El proceso se calibra — y habla el idioma de tu equipo
Cambiar la etiqueta de un botón y reescribir el motor de cobros no merecen la misma ceremonia. Y un equipo que habla en sprints y story points no debería tener que traducirlo todo para adoptar una herramienta. Spaccy tiene dos controles para esto, y son independientes.
Eje horizontal
Metodología — qué idioma
Standard, Agile o Enterprise. Cambia el vocabulario, los artefactos, la agrupación y la pantalla que abre el cockpit — para encajar con el proceso que tu equipo ya sigue.
Son ortogonales: un equipo ágil puede subir a Strict en una feature de pagos sin dejar de hablar de story y sprint. Elegir uno no ata el otro.
El eje vertical
Tres niveles de rigor, acumulativos
El mismo conjunto de comandos, con más o menos profundidad. Cada nivel contiene al anterior — subir nunca cambia una verificación por otra, solo añade.
Lean
CRUD, ajustes, correcciones de bajo riesgo
Lo esencial y nada más: la intención, los criterios de aceptación y la revisión estructural. Las secciones de análisis profundo, matriz de riesgo y verificación cruzada quedan fuera — no porque no importen, sino porque para cambiar una etiqueta cuestan más de lo que valen.
Standardpor defecto
El trabajo del día a día
El equilibrio por defecto: propuesta completa, especificación con invariantes y trazabilidad, revisión en tres lentes independientes — estructural, cazadora de casos límite y detectora de brechas de verificación. Es el nivel en que nace la mayoría de las features.
Strict
Pagos, dato sensible, lo que no puede fallar
Todo lo de Standard más la lente adversarial: el revisor asume que el código está mal y trata de probarlo. Para cada criterio de aceptación, busca el camino que lo viola. Entran también las secciones de amenaza, privacidad y trazabilidad completa requisito → prueba.
El eje horizontal
Tres metodologías, un solo producto
Metodología no es un tema de colores: cambia el comando con el que especificas, el nombre de cada artefacto, qué se agrupa por qué y la pantalla en la que abre el cockpit. Todo eso es configuración — ninguna línea del producto cambia.
| Aspecto | Standard | Agile | Enterprise |
|---|---|---|---|
| Especificas con | /proposal | /story | /proposal |
| La unidad se llama | Feature · Fase | Story · Incremento | RFC · Elemento de trabajo |
| Agrupación temática | Tema (desactivado) | Epic | Capability |
| Agrupación temporal | Milestone | Sprint (2 semanas) | Program Increment |
| El backlog se prioriza por | — (desactivado) | MoSCoW | WSJF |
| Estimación | — (desactivada) | Story points (Fibonacci) | Esfuerzo (talla de camiseta) |
| El cockpit abre en | Lista | Kanban + velocidad | Trazabilidad + cumplimiento |
| Rigor que viene incluido | Standard | Lean | Strict |
Cada metodología es un archivo de configuración que hereda de otra y activa o desactiva roles — crear la tuya cuesta un archivo, no un fork. El rigor de la última fila es solo el punto de partida: los dos ejes siguen siendo independientes.
Lo que cambia para el equipo
La herramienta se adapta al equipo — no al revés
El cockpit habla el idioma de tu ceremonia
En un equipo ágil el panel abre en kanban, con velocidad y story points; en un equipo enterprise, en matriz de trazabilidad y cumplimiento. No es un tema visual: es la unidad de trabajo, la agrupación y la métrica cambiando juntas. Nadie tiene que traducir "fase" a "sprint" de memoria en la reunión.
Nadie aprende un vocabulario nuevo
Lo que el equipo ya llama story sigue siendo story — en los artefactos, en el cockpit y en los comandos. Adoptar Spaccy deja de costar una migración de idioma, que es donde mueren la mayoría de las herramientas de proceso: el equipo vuelve al vocabulario antiguo en dos semanas y la herramienta se convierte en teatro.
Las ceremonias ganan su propio comando
La daily sale lista del repositorio — ayer, hoy y bloqueos leídos del git y del historial, no de la memoria de cada uno. Una incertidumbre técnica se convierte en un experimento con plazo cerrado, que reporta el hallazgo y no genera ninguna especificación. El ritual deja de depender de quién se acordó de prepararlo.
/standup/spike
La convención es del equipo; la preferencia es tuya
El nivel de rigor tiene tres capas de configuración: el valor por defecto del producto, la convención del equipo — versionada en git, revisada en code review como cualquier archivo — y tu preferencia personal, que se queda en tu máquina y no va al repositorio. Discrepar del equipo no exige convencer al equipo.
Lo que cambia para los agentes de IA
El agente recibe el contrato correcto, sin un prompt distinto
La dosificación no es una petición educada al modelo — es la instrucción que recibe cambiando de tamaño. El agente no decide su propio rigor.
Una única fuente de instrucciones, dosificada por marcado
No existe una versión ágil y otra enterprise de cada comando que mantener sincronizadas — existe una, con cada sección marcada por el nivel en que entra. Subir o bajar el rigor activa y desactiva fragmentos de la misma instrucción. Es lo que evita el destino habitual de este tipo de sistema: tres variantes divergiendo en silencio hasta que ninguna es correcta.
Los niveles son acumulativos, nunca alternativos
Strict contiene a Standard, que contiene a Lean. Subir el rigor solo añade — nunca cambia una verificación por otra. Puedes subir el nivel de una feature crítica sabiendo que nada de lo que ya se verificaba dejó de verificarse.
Cambiar de metodología no reescribe el pipeline
La especificación — venga de una propuesta formal o de una user story — emite el mismo contrato de intención. El resto del camino (especificar, implementar, revisar) lee el contrato y no sabe de qué origen vino. Por eso la metodología es un archivo de configuración y no un fork del producto.
El dial no baja donde apagarlo costaría corrección
Seis motores son inmunes al nivel de rigor: los que rotan el historial, reorganizan módulos, preparan el entorno, crean rama de sesión y eliminan código obsoleto. Son justo los que escriben encima de trabajo existente — en ellos, "más ligero" significaría "sin la verificación que impide la pérdida". El rigor dosifica ceremonia, nunca seguridad.
Los dos ejes vienen configurados en Standard — si no cambias nada, eso es lo que se ejecuta. Solicita acceso anticipado y ajústalo cuando el trabajo lo pida.