AmanVarshney01/tcut

Überarbeitet die vorhandenen Planungsartefakte eines Änderungsvorschlags und hält sie kohärent. Bearbeitet niemals Code.

Store-Auswahl: Wenn der Benutzer einen Store nennt (ein Store ist ein eigenständiges, auf diesem Rechner registriertes OpenSpec-Repository) oder die Arbeit in einem solchen liegt, führen Sie openspec store list --json aus, um registrierte Store-IDs zu ermitteln, und übergeben Sie dann --store <id> an die Befehle, die Spezifikationen und Änderungen lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context). Andere Befehle akzeptieren dieses Flag nicht. Hinweise, die von Befehlen ausgegeben werden, enthalten das Flag bereits; behalten Sie es bei Folgefragen bei. Ohne einen Store agieren die Befehle im nächstgelegenen lokalen openspec/-Verzeichnis.

Eingabe: Optional kann ein Änderungsname angegeben werden. Wird er weggelassen, prüfen Sie, ob er aus dem Gesprächskontext abgeleitet werden kann. Bei vagen oder mehrdeutigen Angaben MÜSSEN Sie mit einer Liste verfügbarer Änderungen nachfragen.

Schritte

1. Wenn kein Änderungsname angegeben wurde, zur Auswahl auffordern

   Führen Sie openspec list --json aus, um die verfügbaren Änderungen, sortiert nach der letzten Änderung, zu erhalten. Verwenden Sie dann das AskUserQuestion-Tool, um den Benutzer die zu aktualisierende Änderung auswählen zu lassen.

   Präsentieren Sie die 3-4 zuletzt geänderten Änderungen als Optionen und zeigen Sie:

   • Änderungsname
   • Schema (aus dem Feld schema falls vorhanden, sonst "spec-driven")
   • Status (z. B. "0/5 Aufgaben", "abgeschlossen", "keine Aufgaben")
   • Wie lange ist die letzte Änderung her (aus dem Feld lastModified)

   Markieren Sie die zuletzt geänderte Änderung als "(Empfohlen)", da sie wahrscheinlich diejenige ist, die der Benutzer aktualisieren möchte.

   WICHTIG: Raten Sie nicht und wählen Sie nicht automatisch eine Änderung aus. Lassen Sie den Benutzer immer wählen.

2. Die Artefakte der Änderung abrufen

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

   Parsen Sie das JSON, um den aktuellen Zustand zu verstehen. Die Antwort enthält:

   • schemaName: Das verwendete Workflow-Schema (z. B. "spec-driven")
   • artifacts: Array von Artefakten mit ihrem Status ("done", "ready", "blocked")
   • isComplete: Boolescher Wert, der angibt, ob alle Artefakte vollständig sind
   • planningHome, changeRoot, artifactPaths und actionContext: Pfad- und Bereichskontext. Verwenden Sie diese anstelle von Annahmen über repo-lokale Pfade.

   Die Artefakt-IDs und -Pfade stammen aus dem aktiven Schema – nehmen Sie sie NICHT an und verzweigen Sie nicht auf hartcodierte Artefaktnamen. Benutzerdefinierte Schemas müssen unverändert funktionieren.

   Die zu bearbeitenden Dateien sind artifactPaths.<id>.existingOutputPaths – die konkreten Dateien, die auf der Festplatte existieren, bereits für Glob-Artefakte expandiert (z. B. specs/**/*.md). Schreiben Sie NICHT in resolvedOutputPath: Bei einem Glob-Artefakt ist dies immer noch das Glob-Muster, keine echte Datei.

3. Die Anforderung verstehen

   • Wenn der Benutzer eine bestimmte Überarbeitung angefordert hat ("das Design verwendet jetzt X"), ist dies der Ausgangspunkt für die Bearbeitung.
   • Wenn er nur "aktualisieren" / "dies kohärent machen" gesagt hat, behandeln Sie es als Kohärenzprüfung: Lesen Sie die vorhandenen Artefakte und prüfen Sie sie gegenseitig auf Widersprüche, Lücken und Doppelungen.

4. Lesen und abgleichen

   • Lesen Sie das/die Artefakt(e), die die Anfrage betrifft, sowie die anderen vorhandenen Artefakte der Änderung.
   • Wenden Sie die angeforderte Bearbeitung an. Überprüfen Sie dann jedes andere vorhandene Artefakt dagegen – in JEDER Richtung: Eine Bearbeitung an einem späteren Artefakt kann die Überarbeitung eines früheren erforderlich machen, nicht nur umgekehrt. Die Build-Reihenfolge ist eine nützliche Lesereihenfolge, keine Einschränkung, welche Artefakte überarbeitet werden dürfen.
   • Notieren Sie alles, was jetzt inkonsistent, fehlend oder widersprüchlich ist.
   • Überarbeiten Sie nur Dateien, die bereits existieren (existingOutputPaths). Erstellen Sie KEINE Artefakte, die noch nicht existieren, und erfinden Sie keine neuen Dateien unter einem Glob-Artefakt – notieren Sie sie und verweisen Sie den Benutzer auf /opsx:continue, um sie zu erstellen.
   • Wenn die Änderung bereits kohärent ist, sagen Sie dies und nehmen Sie keine Bearbeitungen vor.

5. Bestätigen und anwenden, ein Artefakt nach dem anderen

   • Zeigen Sie jede vorgeschlagene Überarbeitung und den Grund dafür. Schreiben Sie erst, nachdem der Benutzer bestätigt hat.
   • Wenn der Benutzer eine Überarbeitung ablehnt, schreiben Sie sie nicht – lassen Sie dieses Artefakt unverändert.
   • Wenn eine umfangreiche Überarbeitung erforderlich ist, rufen Sie zuerst die Regeln und die Vorlage für dieses Artefakt ab:

     openspec instructions <artifact-id> --change "<name>" --json
     

6. Auf den nächsten Schritt hinweisen (nur zur Orientierung – NIEMALS danach handeln)

   • Noch fehlende Artefakte -> schlagen Sie /opsx:continue vor, um sie zu erstellen.
   • Änderung bereits implementiert (Aufgaben abgehakt / bereits angewendet) -> der Code stimmt möglicherweise nicht mehr mit dem überarbeiteten Plan überein; schlagen Sie /opsx:apply vor, um die Abweichung in den Code zu übertragen.
   • Alles erledigt und implementiert -> schlagen Sie /opsx:archive vor.

Ausgabe

Zeigen Sie nach jedem Aufruf an:

• Welche Artefakte überarbeitet wurden (und welche vorgeschlagenen Überarbeitungen abgelehnt wurden)
• Alles, was an /opsx:continue delegiert wurde (noch nicht erstellte Artefakte oder Dateien)
• Wo die Änderung steht und der empfohlene nächste Befehl

Leitplanken

• Nur Planungsartefakte – bearbeiten Sie NIEMALS Implementierungscode. Wenn der überarbeitete Plan Codeänderungen impliziert, stoppen Sie und verweisen Sie auf /opsx:apply.
• Verwenden Sie die von openspec status gemeldeten Artefakt-IDs und -Pfade; verzweigen Sie niemals auf hartcodierte Artefaktnamen.
• Bearbeiten Sie nur die konkreten Dateien in existingOutputPaths; schreiben Sie niemals in einen Glob-resolvedOutputPath.
• Erweitern Sie die Build-Grenze nicht: keine neuen Artefakte, keine neuen Dateien unter Glob-Artefakten – das ist die Aufgabe von /opsx:continue.
• Bestätigen Sie jede Bearbeitung vor dem Schreiben mit dem Benutzer.
• Wenn die Anfrage die Absicht der Änderung ändert, anstatt sie zu verfeinern, empfehlen Sie, mit /opsx:new neu zu beginnen (die Heuristik "Aktualisieren vs. Neu beginnen" ).