Repo-grounded Change (Repobasierte Änderung)

Repobasierte Änderung (Repo-grounded Change)

Verwandle eine Optimierungsanfrage für ein bestehendes Projekt in eine bestätigte, implementierungsbereite Änderung und führe nur die genehmigte Option aus.

Interaktions- und Autorisierungsvertrag

• Überprüfe das aktuelle Repository, bevor du eine Lösung empfiehlst. Frage den Benutzer nicht nach Fakten, die aus Code, Tests, Konfiguration oder geltenden Produktdokumenten ermittelbar sind.
• Bleibe schreibgeschützt (read-only), bis der Benutzer eine Option oder Änderungsbasis explizit genehmigt hat. Diagnose und Repository-Inspektion autorisieren keine Änderungen.
• Erzwinge diesen Workflow nicht bei einer direkten, eindeutigen Implementierungsanfrage. Verwende die Abwägung, wenn der Benutzer zuerst eine Bewertung wünscht oder wenn eine Wahl das Verhalten, die Kompatibilität, das Risiko oder den Umfang wesentlich beeinflusst.
• Stelle nur entscheidungsrelevante Fragen. Verwende, wenn verfügbar, eine strukturierte Benutzereingabesteuerung; andernfalls kurze Optionscodes wie Q1-A.
• Biete normalerweise 2 oder 3 sich gegenseitig ausschließende, praktikable Optionen an. Setze die empfohlene Option an die erste Stelle und begründe, warum. Falls nur eine sichere Option existiert, erkläre, warum die Alternativen abgelehnt wurden, anstatt künstliche Wahlmöglichkeiten zu erfinden.
• Implementiere nach der Bestätigung die ausgewählte Option, ohne stillschweigend unzusammenhängende Bereinigungen hinzuzufügen. Wenn neue Repository-Fakten das genehmigte Verhalten, den Umfang, die Migration, Abhängigkeiten oder die Abnahmekriterien wesentlich ändern würden, stoppe und bitte um eine überarbeitete Entscheidung.

Belege und Entscheidungslabels

Halte Fakten von Interpretationen getrennt:

• Benutzerziel: das vom Benutzer genannte Problem und gewünschte Ergebnis.
• Code-Fakt: im aktuellen Quellcode, Test, Laufzeit oder Konfiguration beobachtetes Verhalten.
• Dokumenten-Fakt: Verhalten, das in der geltenden Produktspezifikation gefordert wird.
• Technische Empfehlung: eine Implementierungsempfehlung, die das beabsichtigte Produktverhalten bewahrt.
• Produktannahme: eine reversible Annahme, die bestätigt werden muss.
• Ungeklärt: eine offene Wahl, die die Implementierung blockiert.
• Bestätigt: die vom Benutzer explizit genehmigte Option oder Basis.
• Diesmal nicht geändert: Verhalten oder Code, der absichtlich außerhalb der genehmigten Änderung liegt.

Sofern der Benutzer nichts anderes angibt, verwende diese Autoritätsreihenfolge:

1. Aktuelle explizite Benutzeranweisungen.
2. In der aktuellen Aufgabe explizit bestätigte Entscheidungen.
3. Die geltende genehmigte Produktspezifikation.
4. Aktueller Code und Tests für das bestehende Verhalten.
5. README-Dateien und historische Dokumente.

Lege Konflikte offen; wähle nicht stillschweigend eine Quelle aus.

Arbeitsablauf (Workflow)

1. Ermittle das aktuelle Verhalten

Lies references/discovery-and-impact.md. Überprüfe nur die Repository-Bereiche, die nötig sind, um das Problem zu reproduzieren oder zu erklären. Schütze bestehende Benutzeränderungen und stelle die aktuelle Testbasis her, wenn es angemessen ist.

Berichte das aktuelle Verhalten, die Benutzerauswirkungen, relevante Code-Grenzen und fehlende Belege, bevor du die Optionen präsentierst.

2. Kläre das Änderungsziel

Übersetze die Anfrage in beobachtbare Ergebnisse und Einschränkungen. Kläre nur Punkte, die die Option, den Umfang, die Kompatibilitätsstrategie oder die Abnahmeergebnisse ändern können.

Behandle wörtliche UI-Textbausteine nicht als erforderlichen Implementierungsmechanismus, wenn dadurch falsche Interaktionssemantiken eingeführt würden. Erkläre den Unterschied und biete eine repository-kompatible Option an.

3. Vergleiche praktikable Optionen

Lies references/options-and-clarification.md. Vergleiche die Produkt- und Engineering-Auswirkungen, einschließlich Benutzererfahrung, bewahrtes Verhalten, Zustands- und Datenkompatibilität, Barrierefreiheit, Testauswirkungen, Implementierungsaufwand, Rücknahme-Schwierigkeit und relevante Risiken.

4. Erstelle die empfohlene Änderungsspezifikation

Lies references/change-spec-and-acceptance.md. Die empfohlene Option muss direkt von Codex ausführbar sein und Folgendes enthalten:

• Zielverhalten und Interaktion;
• betroffene Module, Komponenten, Dateien, Schnittstellen und Zustände;
• Kompatibilitäts-, Persistenz-, Migrations-, Degradations- und Rücknahme-Handling, wo relevant;
• Verhalten und Daten, die bewahrt werden müssen;
• explizite Ausnahmen;
• Testplan und beobachtbare Abnahmekriterien.

Ändere in diesem Schritt keinen Code.

5. Hole die explizite Genehmigung ein

Präsentiere die Empfehlung und verbleibende Entscheidungen. Stoppe, nachdem du den Benutzer gebeten hast, eine Option auszuwählen oder die kleinste notwendige Klärungsrunde zu beantworten.

Fasse nach der Antwort die bestätigte Option, Benutzeränderungen, ungeklärte Angelegenheiten, nachgelagerte Auswirkungen und die endgültige Abnahmebasis zusammen. Beginne mit der Implementierung erst, wenn die Antwort die Ausführung klar autorisiert, wie z. B. Bestätige Option A oder Führe wie empfohlen aus.

6. Implementiere die genehmigte Option

Überprüfe den schmutzigen Arbeitsbaum, bewahre unzusammenhängende Änderungen und führe die kleinste kohärente Implementierung durch. Kommentare sollen nicht offensichtliche Invarianten oder Kompatibilitätsentscheidungen erklären, nicht den Code wiederholen.

Lösche keine zugrundeliegenden Domaindaten, nur weil ihre UI-Darstellung entfernt wird, es sei denn, die Löschung wurde explizit genehmigt. Wenn persistierte Zustände, Routen, Schemas oder Enums geändert werden, behandle Legacy-Werte, wenn das Repository darauf hinweist, dass sie existieren könnten.

7. Verifiziere und berichte

Führe zuerst gezielte Tests durch, dann angemessene repository-weite Prüfungen wie Typprüfung, Linting, vollständige Tests, Build und UI-Interaktion oder visuelle Verifikation. Behaupete nicht, ein Check sei bestanden, wenn er nicht ausgeführt werden konnte.

Berichte das implementierte Ergebnis, die Hauptdateien, Verifikationsbelege, bekannte Einschränkungen und etwaige bestehende Vorwarnungen. Falls eine angeforderte Validierungsoberfläche nicht verfügbar ist, lege dies offen und umgehe kein ausdrücklich ausgewähltes Tool oder keine Umgebung ohne Genehmigung.

Zwingende Abbruchbedingungen

Stoppe und fordere eine Entscheidung an, wenn:

• zwei praktikable Optionen wesentlich unterschiedliches Benutzerverhalten erzeugen;
• die Implementierung eine nicht genehmigte Abhängigkeit, Integration, Anmeldedaten, Migration, destruktive Aktion oder Geschäftsregeländerung erfordert;
• aktuelle Benutzeränderungen sich mit der erforderlichen Änderung überschneiden und nicht sicher bewahrt werden können;
• Repository-Fakten der genehmigten Option widersprechen;
• Abnahmekriterien nicht beobachtbar gemacht werden können;
• die sichere Durchführung der Änderung eine Erweiterung des genehmigten Umfangs erfordern würde.

Schwierigkeit, Dauer oder übliche Implementierungsdetails sind kein Grund, eine bestätigte Entscheidung wieder zu öffnen.

Abschlusskriterien

Der Workflow ist nur dann abgeschlossen, wenn die ausgewählte Option im Rahmen des genehmigten Umfangs implementiert ist, Kompatibilitätsentscheidungen getroffen wurden, Abnahmekriterien auf beobachtbare Belege abbildbar sind, relevante Prüfungen durchgeführt wurden und Einschränkungen ehrlich berichtet wurden.