Perfil Expandido: Control Granular

Por: Artiko
openspecexpandedffcontinueavanzado

Perfil Expandido: Control Granular

Cuando necesitas mas control

El perfil Core (/opsx:propose) es ideal para la mayoria de cambios: describes que quieres y OpenSpec genera todo. Pero hay situaciones donde necesitas mas control:

  • Quieres revisar cada artefacto antes de generar el siguiente
  • El cambio es complejo y necesitas iterar sobre el design
  • Quieres crear el scaffold primero y generar artefactos en momentos distintos
  • Necesitas validar la implementacion formalmente antes de archivar

Para esto existe el perfil Expanded (llamado custom en versiones anteriores del CLI).

Activar el perfil Expanded

openspec config profile    # Seleccionar los workflows adicionales
openspec update            # Regenerar commands y skills

Esto agrega 6 comandos a los 6 del Core. Podes seleccionar cualquier subconjunto de workflows; para obtener todos los comandos expandidos, seleccionalos todos durante config profile.

Nota: /opsx:sync y /opsx:update son parte del perfil Core (no del Expanded), pero los explicamos en este capitulo por completitud junto al resto de comandos menos frecuentes.

Los comandos expandidos

/opsx:new - Scaffold del cambio

Crea solo la carpeta del cambio con metadata, sin generar artefactos.

Sintaxis: /opsx:new [nombre-cambio] [--schema <nombre>]

ArgumentoRequeridoDescripcion
nombre-cambioNoNombre en kebab-case (se pregunta si se omite)
--schemaNoSchema de workflow a usar (default: spec-driven)

Internamente ejecuta openspec new change <nombre>, que acepta:

Opcion CLIDescripcion
--description <texto>Descripcion para agregar al README.md del cambio
--schema <nombre>Schema de workflow (default: spec-driven)
/opsx:new setup-data-model
/opsx:new setup-data-model --schema mi-workflow

Genera solo el scaffold:

changes/setup-data-model/
    .openspec.yaml   # Metadata del cambio (schema, fecha)

/opsx:ff - Fast-Forward

Genera todos los artefactos restantes en orden de dependencias.

Sintaxis: /opsx:ff [nombre-cambio]

ArgumentoRequeridoDescripcion
nombre-cambioNoSe infiere del contexto o se pregunta
/opsx:ff setup-data-model

Similar a /opsx:propose pero sobre un cambio ya creado con /opsx:new. Se detiene cuando todos los artefactos requeridos para apply estan completos.

/opsx:continue - Un artefacto a la vez

Genera el siguiente artefacto en la cadena de dependencias.

Sintaxis: /opsx:continue [nombre-cambio]

ArgumentoRequeridoDescripcion
nombre-cambioNoSe infiere del contexto o se pregunta
/opsx:continue setup-data-model

Si el proposal esta hecho, genera las specs. Si las specs estan hechas, genera el design. Si hay multiples artefactos listos simultaneamente, crea el primero disponible.

Ideal cuando quieres revisar y ajustar cada artefacto antes de avanzar al siguiente.

/opsx:verify - Validacion formal

Valida que la implementacion cumple las especificaciones en tres dimensiones.

Sintaxis: /opsx:verify [nombre-cambio]

ArgumentoRequeridoDescripcion
nombre-cambioNoSe infiere del contexto o se pregunta
/opsx:verify setup-data-model
DimensionQue valida
CompletitudTodas las tareas completadas, todos los requisitos implementados
CorrectitudLa implementacion coincide con la intencion de los specs
CoherenciaLas decisiones del design reflejadas en el codigo

Los problemas se categorizan como CRITICAL, WARNING o SUGGESTION. Los warnings no bloquean el archivo, pero senalan posibles discrepancias.

Ejemplo de salida:

Verifying setup-data-model...

COMPLETENESS
✓ All 6 tasks in tasks.md are checked
✓ All requirements have corresponding code

CORRECTNESS
✓ Implementation matches spec intent
⚠ REQ-007: Card priority - no explicit default in schema

COHERENCE
✓ Design decisions reflected in code
✓ Naming conventions consistent with design.md

SUMMARY
Critical issues: 0
Warnings: 1
Ready to archive: Yes (with warnings)

/opsx:update - Revisar el plan de un cambio (perfil Core)

Revisa y reconcilia los artefactos de planificacion de un cambio existente sin cruzar a la implementacion. Introducido en v1.6.

Sintaxis: /opsx:update [nombre-cambio]

ArgumentoRequeridoDescripcion
nombre-cambioNoSe infiere del contexto o se pregunta
/opsx:update setup-data-model

Util cuando ya generaste los artefactos con /opsx:propose pero necesitas cambiar el alcance, ajustar el proposal o corregir las specs, y queres que el resto de artefactos (design, tasks) se mantengan coherentes con ese cambio. A diferencia de editar los .md a mano, /opsx:update propaga la revision por la cadena de dependencias. No implementa codigo: para eso sigue estando /opsx:apply.

/opsx:sync - Fusion de delta specs (perfil Core)

Fusiona las delta specs de un cambio en los specs principales sin archivar el cambio.

Sintaxis: /opsx:sync [nombre-cambio]

ArgumentoRequeridoDescripcion
nombre-cambioNoSe infiere del contexto o se pregunta
/opsx:sync setup-data-model

Util cuando tienes un cambio de larga duracion y quieres que los specs principales reflejen los avances antes de archivar, o cuando otros cambios paralelos necesitan ver la base actualizada. El cambio permanece activo despues del sync. /opsx:archive tambien ofrece hacer sync, asi que en la mayoria de casos no necesitas llamar sync manualmente.

/opsx:bulk-archive - Archivo en lote

Archiva multiples cambios completados simultaneamente.

Sintaxis: /opsx:bulk-archive [nombres-cambios...]

ArgumentoRequeridoDescripcion
nombres-cambiosNoCambios especificos (se seleccionan interactivamente si se omite)
/opsx:bulk-archive
/opsx:bulk-archive add-auth fix-login-bug

Detecta conflictos de specs entre cambios y los resuelve inspeccionando el codebase. Los cambios se archivan en orden cronologico de creacion.

/opsx:onboard - Tutorial guiado

Tutorial interactivo que usa tu codebase real. Sin argumentos.

Sintaxis: /opsx:onboard

Fases del tutorial: analisis del codebase, busqueda de oportunidad de mejora, creacion de cambio, generacion de artefactos, implementacion, verificacion y archivo. Toma entre 15-30 minutos.

Flujos de trabajo expandidos

Flujo rapido (similar a Core)

/opsx:new → /opsx:ff → /opsx:apply → /opsx:archive

Para cambios claros donde quieres el scaffold separado del contenido.

Flujo iterativo (maximo control)

/opsx:new → /opsx:continue (revisar) → /opsx:continue (revisar) → ...
→ /opsx:apply → /opsx:verify → /opsx:archive

Para cambios complejos donde cada artefacto merece atencion individual.

Flujo exploratorio

/opsx:explore → ... → /opsx:new → /opsx:continue → ...
→ /opsx:apply → /opsx:verify → /opsx:archive

Cuando empiezas sin claridad y vas cristalizando la idea.

Ejemplo: Iterando sobre el design

Imagina que generas los artefactos uno a uno para el modelo de datos:

/opsx:new setup-data-model

Generas el proposal:

/opsx:continue setup-data-model

Revisas el proposal. Se ve bien. Generas las specs:

/opsx:continue setup-data-model

Revisas las specs. Falta un escenario para validacion de nombres vacios. Lo agregas manualmente al archivo. Generas el design:

/opsx:continue setup-data-model

El design sugiere SQLite, pero tu quieres PostgreSQL. Editas design.md y regeneras las tasks:

/opsx:continue setup-data-model

Las tasks ahora reflejan PostgreSQL. Listo para implementar.

Este nivel de control no es necesario para cambios simples, pero es invaluable para cambios que afectan la arquitectura.

Framework de decision

SituacionComando recomendado
Cambio claro, quiero avanzar rapido/opsx:propose (Core)
Quiero scaffold primero, artefactos despues/opsx:new + /opsx:ff
Cambio complejo, quiero revisar cada paso/opsx:new + /opsx:continue
Quiero validacion formal pre-archive/opsx:verify
Multiples cambios listos para cerrar/opsx:bulk-archive

Resumen

  • El perfil Expanded agrega 6 comandos para control granular
  • /opsx:new crea solo el scaffold, /opsx:ff genera todo, /opsx:continue genera uno a la vez
  • /opsx:verify valida completitud, correctitud y coherencia
  • /opsx:update (Core) revisa y reconcilia el plan de un cambio existente sin implementar
  • /opsx:sync (Core) fusiona delta specs sin archivar (para cambios largos)
  • /opsx:onboard ofrece un tutorial guiado con tu codebase
  • El Core es suficiente para la mayoria de cambios; Expanded es para cuando necesitas precision

← Capitulo 4: Primer Cambio | Capitulo 6: Implementando con Apply →