AmanVarshney01/tcut

Sincroniza especificaciones delta desde un cambio hacia las especificaciones principales.

Esta es una operación dirigida por el agente: leerás las especificaciones delta y editarás directamente las especificaciones principales para aplicar los cambios. Esto permite una fusión inteligente (por ejemplo, añadir un escenario sin copiar todo el requisito).

Selección de almacén: Si el usuario nombra un almacén (un repositorio OpenSpec independiente registrado en esta máquina) o el trabajo está en uno, ejecuta openspec store list --json para descubrir los IDs de almacenes registrados, luego pasa --store <id> en los comandos que leen o escriben especificaciones y cambios (new change, status, instructions, list, show, validate, archive, doctor, context). Otros comandos no toman esta bandera. Las sugerencias impresas por los comandos ya incluyen la bandera; mantenla en los seguimientos. Sin un almacén, los comandos actúan sobre la raíz local más cercana de openspec/.

Entrada: Opcionalmente, especifica un nombre de cambio. Si se omite, verifica si se puede deducir del contexto de la conversación. Si es vago o ambiguo, DEBES preguntar por los cambios disponibles.

Pasos

1. Si no se proporciona un nombre de cambio, solicitar selección

   Ejecuta openspec list --json para obtener los cambios disponibles. Usa la herramienta AskUserQuestion para que el usuario seleccione.

   Muestra los cambios que tienen especificaciones delta (bajo el directorio specs/).

   IMPORTANTE: No adivines ni selecciones automáticamente un cambio. Siempre deja que el usuario elija.

2. Resolver el contexto del cambio

   Ejecuta:

   openspec status --change "<nombre>" --json
   

3. Encontrar especificaciones delta

   Usa artifactPaths.specs.existingOutputPaths del JSON de estado como la lista de archivos de especificaciones delta.

   Cada archivo de especificación delta contiene secciones como:

   • ## ADDED Requirements - Nuevos requisitos para añadir
   • ## MODIFIED Requirements - Cambios a requisitos existentes
   • ## REMOVED Requirements - Requisitos para eliminar
   • ## RENAMED Requirements - Requisitos para renombrar (formato FROM:/TO:)

   Si no se encuentran especificaciones delta, informa al usuario y detente.

4. Para cada especificación delta, aplicar cambios a las especificaciones principales

   Para cada ruta de especificación delta de capacidad local al repositorio devuelta por el CLI:

   a. Leer la especificación delta para entender los cambios previstos

   b. Leer la especificación principal en openspec/specs/<capacidad>/spec.md (puede que aún no exista)

   c. Aplicar cambios de forma inteligente:

   ADDED Requirements:

   • Si el requisito no existe en la especificación principal → añadirlo
   • Si el requisito ya existe → actualizarlo para que coincida (tratar como MODIFIED implícito)

   MODIFIED Requirements:

   • Encontrar el requisito en la especificación principal
   • Aplicar los cambios - esto puede incluir:
     • Añadir nuevos escenarios (no es necesario copiar los existentes)
     • Modificar escenarios existentes
     • Cambiar la descripción del requisito
   • Preservar escenarios/contenido no mencionado en la delta

   REMOVED Requirements:

   • Eliminar todo el bloque del requisito de la especificación principal

   RENAMED Requirements:

   • Encontrar el requisito FROM, renombrarlo a TO

   d. Crear nueva especificación principal si la capacidad aún no existe:

   • Crear openspec/specs/<capacidad>/spec.md
   • Añadir sección de Propósito (puede ser breve, marcar como TBD)
   • Añadir sección de Requisitos con los requisitos ADDED

5. Mostrar resumen

   Después de aplicar todos los cambios, resume:

   • Qué capacidades se actualizaron
   • Qué cambios se hicieron (requisitos añadidos/modificados/eliminados/renombrados)

Formato de referencia de especificación delta

## ADDED Requirements

### Requirement: Nueva Funcionalidad
El sistema DEBE hacer algo nuevo.

#### Scenario: Caso básico
- **WHEN** el usuario hace X
- **THEN** el sistema hace Y

## MODIFIED Requirements

### Requirement: Funcionalidad Existente
#### Scenario: Nuevo escenario a añadir
- **WHEN** el usuario hace A
- **THEN** el sistema hace B

## REMOVED Requirements

### Requirement: Funcionalidad Obsoleta

## RENAMED Requirements

- FROM: `### Requirement: Nombre Antiguo`
- TO: `### Requirement: Nombre Nuevo`

Principio clave: Fusión inteligente

A diferencia de la fusión programática, puedes aplicar actualizaciones parciales:

• Para añadir un escenario, solo incluye ese escenario bajo MODIFIED - no copies escenarios existentes
• La delta representa la intención, no un reemplazo completo
• Usa tu criterio para fusionar los cambios de manera sensata

Salida en caso de éxito

## Especificaciones sincronizadas: <nombre-cambio>

Especificaciones principales actualizadas:

**<capacidad-1>**:
- Requisito añadido: "Nueva Funcionalidad"
- Requisito modificado: "Funcionalidad Existente" (añadido 1 escenario)

**<capacidad-2>**:
- Nuevo archivo de especificación creado
- Requisito añadido: "Otra Funcionalidad"

Las especificaciones principales están actualizadas. El cambio permanece activo: archívalo cuando la implementación esté completa.

Medidas de seguridad

• Lee tanto las especificaciones delta como las principales antes de hacer cambios
• Preserva el contenido existente no mencionado en la delta
• Si algo no está claro, pide aclaración
• Muestra lo que estás cambiando a medida que avanzas
• La operación debe ser idempotente: ejecutarla dos veces debe dar el mismo resultado