AmanVarshney01/tcut

Revisa los artefactos de planificación existentes de un cambio y mantenlos coherentes. Nunca edites código.

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

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

Pasos

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

   Ejecuta openspec list --json para obtener los cambios disponibles ordenados por el más recientemente modificado. Luego usa la herramienta AskUserQuestion para permitir que el usuario seleccione qué cambio actualizar.

   Presenta los 3-4 cambios más recientemente modificados como opciones, mostrando:

   • Nombre del cambio
   • Esquema (del campo schema si está presente, si no, "spec-driven")
   • Estado (ej., "0/5 tareas", "completo", "sin tareas")
   • Qué tan recientemente fue modificado (del campo lastModified)

   Marca el cambio más recientemente modificado como "(Recomendado)" ya que es probablemente lo que el usuario quiere actualizar.

   IMPORTANTE: NO adivines ni auto-selecciones un cambio. Siempre deja que el usuario elija.

2. Obtén los artefactos del cambio

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

   Analiza el JSON para entender el estado actual. La respuesta incluye:

   • schemaName: El esquema de flujo de trabajo que se está usando (ej., "spec-driven")
   • artifacts: Arreglo de artefactos con su estado ("done", "ready", "blocked")
   • isComplete: Booleano que indica si todos los artefactos están completos
   • planningHome, changeRoot, artifactPaths, y actionContext: contexto de ruta y ámbito. Úsalos en lugar de asumir rutas locales del repositorio.

   Los IDs y rutas de los artefactos provienen del esquema activo; NO los asumas y NO hagas bifurcaciones basadas en nombres de artefactos hardcodeados. Los esquemas personalizados deben funcionar sin cambios.

   Los archivos a editar son artifactPaths.<id>.existingOutputPaths: los archivos concretos que existen en disco, ya expandidos con globs para artefactos glob (ej., specs/**/*.md). NO escribas en resolvedOutputPath: para un artefacto glob sigue siendo el patrón glob, no un archivo real.

3. Entiende la solicitud

   • Si el usuario pidió una revisión específica ("el diseño ahora usa X"), esa es la edición inicial.
   • Si solo dijo "actualiza" / "haz esto coherente", trátalo como una revisión de coherencia: lee los artefactos existentes y verifícalos entre sí en busca de contradicciones, lagunas y duplicaciones.

4. Lee y reconcilia

   • Lee el(los) artefacto(s) que toca la solicitud y los otros artefactos existentes del cambio.
   • Aplica la edición solicitada. Luego verifica cada otro artefacto existente contra ella - en CUALQUIER dirección: una edición en un artefacto posterior puede requerir revisar uno anterior, no solo al revés. El orden de construcción es un orden de lectura útil, no una restricción sobre qué artefactos pueden revisarse.
   • Nota todo lo que ahora sea inconsistente, faltante o contradictorio.
   • Revisa solo los archivos que ya existen (existingOutputPaths). NO crees artefactos que aún no existan y NO inventes nuevos archivos bajo un artefacto glob; anótalos y señálale al usuario que use /opsx:continue para crearlos.
   • Si el cambio ya es coherente, dilo y no hagas ediciones.

5. Confirma y aplica, un artefacto a la vez

   • Muestra cada revisión propuesta y el porqué. Escribe solo después de la confirmación del usuario.
   • Si el usuario rechaza una revisión, no la escribas; deja ese artefacto sin cambios.
   • Cuando se necesite una reescritura sustancial, obtén primero las reglas y la plantilla de ese artefacto:

     openspec instructions <id-artefacto> --change "<nombre>" --json
     

6. Señala el siguiente paso (solo orientación - NUNCA actúes sobre él)

   • Artefactos aún faltantes -> sugiere /opsx:continue para crearlos.
   • Cambio ya implementado (tareas marcadas / ya aplicado) -> el código puede que ya no coincida con el plan revisado; sugiere /opsx:apply para llevar el delta al código.
   • Todo hecho e implementado -> sugiere /opsx:archive.

Salida

Después de cada invocación, muestra:

• Qué artefactos se revisaron (y qué revisiones propuestas fueron rechazadas)
• Cualquier cosa diferida a /opsx:continue (artefactos o archivos aún no creados)
• Dónde se encuentra el cambio y el siguiente comando recomendado

Guardarraíles

• Solo artefactos de planificación - NUNCA edites código de implementación. Si el plan revisado implica cambios de código, detente y señala /opsx:apply.
• Usa los IDs y rutas de artefactos reportados por openspec status; nunca hagas bifurcaciones basadas en nombres de artefactos hardcodeados.
• Edita solo los archivos concretos en existingOutputPaths; nunca escribas en un resolvedOutputPath de tipo glob.
• No avances la frontera de construcción: sin nuevos artefactos, sin nuevos archivos bajo artefactos glob - ese es trabajo de /opsx:continue.
• Confirma cada edición con el usuario antes de escribir.
• Si la solicitud cambia la intención del cambio en lugar de refinarlo, recomienda empezar de nuevo con /opsx:new (la heurística "Actualizar vs. Empezar de nuevo").