williamsnieves/landing-factory

Archiviere eine abgeschlossene Änderung im experimentellen Workflow.

Store-Auswahl: Wenn der Benutzer einen Store benennt (ein Store ist ein eigenständiges OpenSpec-Repository, das auf diesem Rechner registriert ist) oder die Arbeit in einem solchen liegt, führe openspec store list --json aus, um registrierte Store-IDs zu ermitteln, und übergib dann --store <id> an die Befehle, die Spezifikationen und Änderungen lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Behandle --store <id> nach der Auswahl als klebrig für den Rest des Workflows. Jedes nicht näher bezeichnete Beispiel dieser Befehle unten ist eine Kurzform: vor dem Ausführen das Flag anhängen. Führe beispielsweise openspec status --change "<name>" --json --store "<id>" aus, nicht die nicht näher bezeichnete Form, die unten gezeigt wird. Andere Befehle nehmen das Flag nicht an. Von Befehlen ausgegebene Hinweise tragen das Flag bereits; behalte es bei Folgemaßnahmen bei. Ohne einen Store arbeiten Befehle auf dem nächstgelegenen lokalen openspec/-Stammverzeichnis.

Projektprüfung: Diese Schritte erwarten ein Projekt, das bereits OpenSpec verwendet. Bestätige vor dem ersten Schritt, der etwas schreibt (new change, archive, sync specs oder dem Erstellen einer Artefaktdatei), dass das Projekt ein Stammverzeichnis hat: führe openspec list --json aus (mit --store <id>, wenn ein Store ausgewählt ist, da der Store dann das Stammverzeichnis ist) und lese root. Ein root-Objekt bedeutet, dass das Projekt eingerichtet ist. "root": null bedeutet, dass es nicht eingerichtet ist – es gibt kein openspec/-Verzeichnis hier, und ein Schreibvorgang wie openspec new change würde als Nebeneffekt eines erstellen. Der Befehl beendet sich auch mit einem Fehlercode ungleich Null, was die Antwort ist und kein defektes CLI, also lies das JSON, anstatt es erneut zu versuchen oder zu umgehen.

Ein "root": null ist nicht auf die Einrichtung bezogen: Wenn eine status-Fehlermeldung mit Declared in oder Invalid store declaration in beginnt und openspec/config.yaml (oder config.yml) dieses Projekts nennt, dann verwendet das Projekt OpenSpec über einen Store, den es deklariert, den dieser Rechner nicht auflösen kann (der Store ist nicht registriert oder die store:-Zeile ist fehlerhaft). Behandle es nicht als nicht initialisiert und überspringe die Zweige unten: Stoppe vor dem Schreiben und zeige dem Benutzer die message und den fix dieses Fehlers an.

Andernfalls, wenn kein Stammverzeichnis vorhanden ist, hängt das weitere Vorgehen davon ab, wie dieser Workflow erreicht wurde:

• Automatisch ausgewählt: Du hast diesen Workflow selbst ausgewählt, ohne dass der Benutzer OpenSpec genannt, diese Fähigkeit benannt oder ihren Slash-Befehl ausgeführt hat. Höre auf, OpenSpec zu verwenden, und beantworte die Anfrage normal, wie du es ohne installiertes OpenSpec tun würdest. Bitte den Benutzer nicht, etwas einzurichten, und erwähne keine OpenSpec-Einrichtung.
• Explizite OpenSpec-Anfrage: Der Benutzer hat OpenSpec genannt, diese Fähigkeit benannt oder ihren Slash-Befehl ausgeführt. Stoppe vor dem Schreiben und frage, wie weiter verfahren werden soll: dieses Projekt einrichten (openspec init), einen bereits vorhandenen Store ansprechen (--store <id>) oder für diese Anfrage ohne OpenSpec fortfahren. Warte auf seine Antwort.

Erstelle in beiden Zweigen niemals das Stammverzeichnis als Nebeneffekt: Führe openspec init erst aus, wenn der Benutzer danach fragt, erstelle keine openspec/-Dateien von Hand und lasse keinen Befehl sie erstellen.

<capability-path> ist das Spezifikationsverzeichnis relativ zu specs/ (z. B. user-auth oder identity/user-auth). Behalte den vollständigen Pfad von jeder Delta-Spezifikation bei, wenn du ihre Hauptspezifikation auflöst.

Eingabe: Optional einen Änderungsnamen angeben. Wenn nicht angegeben, prüfe, ob er aus dem Gesprächskontext abgeleitet werden kann. Bei vagen oder mehrdeutigen Angaben MUSST du nach verfügbaren Änderungen fragen.

Schritte

1. Die Änderung auswählen

   Wenn ein Name angegeben ist, verwende ihn. Andernfalls:

   • Aus dem Gesprächskontext ableiten, wenn der Benutzer eine Änderung erwähnt hat
   • Automatisch auswählen, wenn nur eine aktive Änderung existiert
   • Bei Mehrdeutigkeit openspec list --json ausführen, um verfügbare Änderungen zu erhalten, und den Benutzer bitten, eine auszuwählen

   Zeige beim Auffordern nur aktive Änderungen an (noch nicht archiviert). Füge das für jede Änderung verwendete Schema hinzu, falls verfügbar.

   Gib immer bekannt: "Verwende Änderung: " und wie man sie überschreibt (z. B. /opsx:archive <andere>).

   Lade die aktuellen Archiveingaben vor den bestehenden Archivprüfungen:

   Nachdem die ausgewählte Änderung aufgelöst und das Stammverzeichnis geplant wurde, führe Folgendes aus:

   openspec instructions archive --change "<name>" --json
   

   Behalte dieselben Flags für das ausgewählte Stammverzeichnis bei diesem Befehl. Diese Suche ist beratend und optional: Sie liefert nur zusätzliche Eingabeaufforderungen, daher darf sie das Archivieren niemals blockieren. Wenn sie mit einem Fehlercode ungleich Null beendet wird oder ungültiges JSON zurückgibt – zum Beispiel bei einer älteren CLI, die diesen Befehl noch nicht unterstützt –, setze den Archivierungs-Workflow ohne Kontext und ohne Betriebsanleitung fort. Melde keinen Fehler und stoppe nicht.

   Eine erfolgreiche Antwort kann beide optionalen Felder weglassen. Behandle context als erforderliche Eingabe auf Aufforderungsebene: Lies und berücksichtige sie und wende relevante Projektfakten, Konventionen und Einschränkungen an. Behandle operationGuidance als optionalen, ergänzenden Ratschlag: Lies und berücksichtige jeden Eintrag und folge Einträgen, die anwendbar und mit dem integrierten Archivierungs-Workflow kompatibel sind.

   Halte beide Felder getrennt von integrierten Schritten, expliziten Benutzerentscheidungen, aufgelösten Pfaden, CLI-Prüfungen und Befehlsverträgen. Wenn der Kontext mit einem dieser steuernden Eingaben in Konflikt steht, melde den Konflikt und behalte den steuernden Wert bei. Wenn eine Anleitung nicht anwendbar ist oder mit einer steuernden Eingabe in Konflikt steht, befolge sie nicht und erkläre warum. Leite keine Ersatzpfade, übersprungenen Aufforderungen oder Flags aus einem der beiden Felder ab und kopiere ihren Text nicht wörtlich in Spezifikationen, Änderungsartefakte oder Archivierungszusammenfassungen, es sei denn, der Benutzer bittet separat darum. Dies sind verhaltensbezogene Verträge auf Aufforderungsebene, keine durchsetzbaren Prüfungen.

2. Abschlussstatus der Artefakte prüfen

   Führe openspec status --change "<name>" --json aus, um den Abschlussstatus der Artefakte zu prüfen.

   Analysiere das JSON, um Folgendes zu verstehen:

   • schemaName: Der verwendete Workflow
   • planningHome, changeRoot, artifactPaths und actionContext: Pfad- und Bereichskontext
   • artifacts: Liste der Artefakte mit ihrem Status (done, skipped oder andere)

   Wenn Artefakte weder done noch skipped sind (übersprungene Artefakte erfüllen die Anforderung – die Änderung deklariert skip_specs):

   • Warnung anzeigen, die unvollständige Artefakte auflistet
   • Den Benutzer bitten zu bestätigen, ob er fortfahren möchte
   • Fortfahren, wenn der Benutzer bestätigt

3. Abschlussstatus der Aufgaben prüfen

   Führe openspec list --json mit denselben Flags für das ausgewählte Stammverzeichnis aus und suche den Eintrag in changes, dessen name exakt mit der ausgewählten Änderung übereinstimmt. Erfordere genau eine Übereinstimmung und nichtnegative ganze Zahlen totalTasks und completedTasks, mit completedTasks <= totalTasks. Die CLI löst die vom Schema verfolgten Aufgabendateien auf, einschließlich benutzerdefinierter Artefaktnamen, Ausgabepfade und Glob-Muster.