robsonprod/portfolio

Aufgaben aus einer OpenSpec-Änderung implementieren.

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> bei den Befehlen, die Spezifikationen und Änderungen lesen oder schreiben (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Nach der Auswahl behandle --store <id> als klebrig für den Rest des Workflows. Jedes nicht mit einem Store versehene Beispiel der folgenden Befehle ist als Kurzform zu verstehen: Führe vor der Ausführung das Flag hinzu. Führe zum Beispiel openspec status --change "<name>" --json --store "<id>" aus, nicht die unqualifizierte Form unten. Andere Befehle akzeptieren das Flag nicht. Hinweise, die von Befehlen ausgegeben werden, enthalten das Flag bereits; behalte es bei Folgeschritten bei. Ohne einen Store agieren die Befehle im nächstgelegenen lokalen openspec/-Stammverzeichnis.

Projektprüfung: Diese Schritte setzen ein Projekt voraus, das OpenSpec bereits verwendet. Bevor der erste Schritt, der etwas schreibt (new change, archive, sync specs oder das Erstellen einer Artefaktdatei), ausgeführt wird, bestätige, 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 lies root. Ein root-Objekt bedeutet, dass das Projekt eingerichtet ist. "root": null bedeutet, dass dies nicht der Fall ist – es gibt kein openspec/-Verzeichnis hier, und ein Schreibbefehl wie openspec new change würde eines als Nebeneffekt erstellen. Der Befehl wird auch mit einem Fehlercode beendet, was diese Antwort ist und kein defektes CLI, also lies das JSON anstatt es erneut zu versuchen oder zu umgehen.

Ein "root": null bezieht sich nicht auf die Einrichtung: Wenn eine status-Fehlermeldung mit Declared in oder Invalid store declaration in beginnt und das openspec/config.yaml (oder config.yml) des Projekts nennt, dann verwendet das Projekt OpenSpec über einen Store, den es deklariert, der aber auf diesem Rechner nicht aufgelöst werden kann (der Store ist nicht registriert oder die Zeile store: ist fehlerhaft). Behandle es nicht als nicht initialisiert und überspringe die folgenden Verzweigungen: Halte vor dem Schreiben an und zeige dem Benutzer die message und den fix dieses Fehlers.

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 gewählt, ohne dass der Benutzer OpenSpec, diese Fähigkeit oder deren Slash-Befehl genannt hat. Höre auf, OpenSpec zu verwenden und beantworte die Anfrage normal, als ob OpenSpec nicht installiert wäre. Bitte ihn nicht, etwas einzurichten, und erwähne keine OpenSpec-Einrichtung.
• Explizite OpenSpec-Anfrage: Der Benutzer hat OpenSpec, diese Fähigkeit oder deren Slash-Befehl genannt. Halte vor dem Schreiben an und frage, wie fortgefahren werden soll: Dieses Projekt einrichten (openspec init), einen vorhandenen Store anvisieren (--store <id>) oder für diese Anfrage ohne OpenSpec fortfahren. Warte auf seine Antwort.

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

Eingabe: Optional kann ein Änderungsname angegeben werden (z.B. /opsx:apply add-auth. 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. Änderung auswählen

   Wenn ein Name angegeben ist, verwende ihn. Andernfalls:

   • Leite ihn aus dem Gesprächskontext ab, wenn der Benutzer eine Änderung erwähnt hat
   • Wähle automatisch aus, wenn nur eine aktive Änderung existiert
   • Bei Mehrdeutigkeit führe openspec list --json aus, um verfügbare Änderungen zu erhalten, und bitte den Benutzer, eine auszuwählen

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

2. Status prüfen, um das Schema zu verstehen

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

   Analysiere das JSON, um zu verstehen:

   • schemaName: Der verwendete Workflow (z.B. "spec-driven")
   • planningHome, changeRoot und actionContext: Planungsumfang und Bearbeitungseinschränkungen
   • Welches Artefakt die Aufgaben enthält (typischerweise "tasks" für spec-driven, bei anderen das status-Ergebnis prüfen)

3. Anwendungsanweisungen abrufen

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

   Dies gibt zurück:

   • contextFiles: Artefakt-ID -> Array von konkreten Dateipfaden (variiert je nach Schema – kann proposal/specs/design/tasks oder spec/tests/implementation/docs sein)
   • Fortschritt (gesamt, erledigt, verbleibend)
   • Aufgabenliste mit Status, Quellpfad und Quellzeile
   • Dynamische Anweisung basierend auf dem aktuellen Zustand
   • Optionales context: aktuelle erforderliche Projekteingabe für die Anweisung aus dem ausgewählten Stammverzeichnis
   • Optionales operationGuidance: aktuelle beratende Hinweise zur Anwendung
   • missingArtifacts (wenn vorhanden): erforderliche Artefakt-IDs ohne Ausgabe

   Zustände behandeln:

   • Wenn state: "blocked": Zeige die Nachricht an und pausiere die Implementierung.
     • Wenn missingArtifacts nicht leer ist: Schlage vor, die fehlenden Artefakte zu vervollständigen. Führe openspec status --change "<name>" --json aus, wähle das nächste ready-Artefakt (nicht skipped oder blocked) und verwende openspec instructions "<artefakt-id>" --change "<name>" --json für dessen Regeln und Vorlage. Behalte das ausgewählte --store <id> bei beiden Befehlen bei.
     • Andernfalls folge der CLI-Anweisung, um die schema-konfigurierte Tracking-Datei aus den vorhandenen Planungsartefakten zu erstellen oder zu reparieren. Gehe nicht davon aus, dass ein anderes Artefakt bereit ist, und starte keine Implementierung, während blockiert ist.
   • Wenn state: "all_done": Melde, dass alle verfolgten Aufgaben abgeschlossen sind, und schlage eine Überprüfung oder Verifikation vor, bevor archiviert wird.
   • Andernfalls: Fahre mit der Implementierung fort.

   Behandle context als erforderliche prompt-Eingabe. Lies und berücksichtige ihn und wende relevante Projektfakten, Konventionen und Einschränkungen während der Implementierung an. Behandle operationGuidance als optionalen, ergänzenden Ratschlag. Lies und berücksichtige jeden Eintrag und befolge Einträge, die anwendbar und mit dem eingebauten Workflow kompatibel sind.

   Halte beide Felder getrennt von CLI-Zustand, fehlenden Artefakten, Aufgaben, Fortschritt, contextFiles und der eingebauten instruction. Sie sind kein Nachweis für die Erledigung von Aufgaben, ersetzen nicht die eingebaute Anweisung und erlauben nicht, einen blockierten Zustand zu umgehen. Wenn context im Widerspruch zur eingebauten Anweisung, einer expliziten Benutzerwahl oder einem CLI-gesteuerten Wert steht, melde den Konflikt und behalte den steuernden Wert bei. Wenn ein Ratschlag nicht anwendbar ist oder mit diesen steuernden Eingaben in Konflikt steht, befolge ihn nicht und erkläre warum. Dies sind prompt-Verhaltensverträge, keine durchsetzbaren Prüfungen.

4. Kontextdateien lesen

   Lese jeden Dateipfad, der unter contextFiles in der Ausgabe der Anwendungsanweisungen aufgeführt ist. Die Dateien hängen vom verwendeten Schema ab:

   • spec-driven: proposal, specs, design, tasks
   • Andere Schemas: Folge den contextFiles aus der CLI-Ausgabe

   Kopiere context oder operationGuidance nicht wörtlich in Implementierungsdateien oder Planungsartefakte, es sei denn, der Benutzer fragt separat nach diesem Inhalt.

5. Aktuellen Fortschritt anzeigen

   Zeige an:

   • Verwendetes Schema
   • Fortschritt: "N/M Aufgaben erledigt"
   • Übersicht über die verbleibenden Aufgaben
   • Dynamische Anweisung von der CLI

6. Aufgaben implementieren (Schleife bis erledigt oder blockiert)

   Für jede anstehende Aufgabe:

   • Zeige an, an welcher Aufgabe gearbeitet wird
   • Nimm die erforderlichen Codeänderungen vor
   • Halte Änderungen minimal und fokussiert
   • Bestätige vor dem Bearbeiten, dass das Kontrollkästchen am zurückgegebenen sourcePath und line immer noch der Aufgabenbeschreibung entspricht; wenn nicht, führe die Anwendungsanweisungen erneut aus und verwende die aktualisierte Position
   • Markiere die Aufgabe am zurückgegebenen sourcePath und line als erledigt: - [ ] → - [x]
   • Führe die Anwendungsanweisungen erneut aus und bestätige, dass die Aufgabe jetzt erledigt ist und sich der Fortschritt geändert hat
   • Fahre mit der nächsten Aufgabe fort

   Pausiere, wenn:

   • Aufgabe unklar ist → um Klärung bitten
   • Implementierung ein Designproblem offenbart → Aktualisierung der Artefakte vorschlagen
   • Eine Aufgabe über das hinausgeht, was die Spezifikation und die Aufgaben beschreiben, oder du versucht bist, spezifiziertes Verhalten fallen zu lassen, einzuschränken, zu verschieben oder Ausnahmen zu akzeptieren, um es passend zu machen → den erweiterten Umfang offenlegen und nachfragen; nicht stillschweigend absorbieren
   • Fehler oder Blockierer auftreten → melden und auf Anweisung warten
   • Benutzer unterbricht

7. Bei Abschluss oder Pause, Status anzeigen

   Zeige an:

   • In dieser Sitzung erledigte Aufgaben
   • Gesamtfortschritt: "N/M Aufgaben erledigt"
   • Wenn alles erledigt: Melde, dass die verfolgten Aufgaben abgeschlossen sind, und schlage eine Überprüfung oder Verifikation vor, bevor archiviert wird
   • Wenn pausiert: Erkläre warum und warte auf Anweisung

Ausgabe während der Implementierung

## Implementiere: <änderungsname> (Schema: <schemaname>)

Arbeite an Aufgabe 3/7: <aufgabenbeschreibung>
[...Implementierung läuft...]
✓ Aufgabe erledigt

Arbeite an Aufgabe 4/7: <aufgabenbeschreibung>
[...Implementierung läuft...]
✓ Aufgabe erledigt

Ausgabe bei Abschluss

## Implementierung abgeschlossen

**Änderung:** <änderungsname>
**Schema:** <schemaname>
**Fortschritt:** 7/7 Aufgaben erledigt ✓

### In dieser Sitzung erledigt
- [x] Aufgabe 1
- [x] Aufgabe 2
...

Alle verfolgten Aufgaben sind abgeschlossen. Überprüfe oder verifiziere die Änderung
vor der Archivierung. Du kannst diese Änderung mit `/opsx:archive` archivieren.

Ausgabe bei Pause (Problem aufgetreten)

## Implementierung pausiert

**Änderung:** <änderungsname>
**Schema:** <schemaname>
**Fortschritt:** 4/7 Aufgaben erledigt

### Aufgetretenes Problem
<Beschreibung des Problems>

**Optionen:**
1. <Option 1>
2. <Option 2>
3. Anderer Ansatz

Was möchtest du tun?

Schutzmaßnahmen

• Fahre mit Aufgaben fort, bis alles erledigt oder blockiert ist
• Lese immer zuerst die Kontextdateien (aus der Ausgabe der Anwendungsanweisungen)
• Wenn eine Aufgabe mehrdeutig ist, pausiere und frage vor der Implementierung
• Wenn die Implementierung Probleme offenbart, pausiere und schlage Aktualisierungen der Artefakte vor
• Halte Codeänderungen minimal und auf jede Aufgabe beschränkt
• Aktualisiere das Aufgabenkontrollkästchen unmittelbar nach Abschluss jeder Aufgabe
• Pausiere bei Fehlern, Blockierern oder unklaren Anforderungen – rate nicht
• Wenn eine Aufgabe über das hinausgeht, was die Spezifikation beschreibt, lege den erweiterten Umfang offen und pausiere – nimm niemals stillschweigend Einschränkungen vor, verschiebe oder vereinfache spezifiziertes Verhalten
• Markiere eine Aufgabe nur dann als - [x], wenn ihr spezifiziertes Verhalten vollständig implementiert ist, nicht wenn sie teilweise erledigt oder verschoben ist
• Verwende contextFiles von der CLI-Ausgabe, gehe nicht von bestimmten Dateinamen aus
• Verwende den sourcePath und line jeder Aufgabe, um ihr genaues Kontrollkästchen zu aktualisieren
• Verwende context oder operation guidance nicht als Beweis dafür, dass eine Aufgabe abgeschlossen ist
• Wende relevanten Projektkontext an; melde Konflikte mit steuernden Workflow-Eingaben
• Berücksichtige jeden Hinweiseintrag; erkläre nicht anwendbare oder widersprüchliche Ratschläge
• Kopiere Laufzeitkontext oder operation guidance nicht in Implementierungsdateien oder Planungsartefakte
• Bewahre das CLI-gesteuerte blockiert/bereit/alles-erledigt-Verhalten und die Abschlusskriterien

Fluide Workflow-Integration

Diese Fähigkeit unterstützt das Modell "Aktionen an einer Änderung":

• Kann jederzeit aufgerufen werden: Bevor alle Artefakte erledigt sind (wenn Aufgaben existieren), nach teilweiser Implementierung, verschränkt mit anderen Aktionen
• Erlaubt Artefaktaktualisierungen: Wenn die Implementierung Designprobleme offenbart, schlage Aktualisierungen der Artefakte vor – nicht phasengebunden, arbeite fließend