Codex richtig
nutzen.

In Codex einfügen. Diesen Prompt können Sie vor dem Einrichten des Beispielprojekts verwenden.

Ich möchte mit dem Aufgabenplaner aus diesem Buch lernen, eine kleine
Softwareänderung verständlich zu beauftragen und selbst zu prüfen.
Ich kann Dateien kopieren und einen Browser bedienen. Weitere technische
Kenntnisse sollst du nicht voraussetzen.

Erkläre mir in höchstens sechs Punkten, was ich dafür vorbereiten muss.
Unterscheide meinen Codex-Zugang, den Projektordner und die Laufzeit Node.js.
Erfinde keine Angaben über meinen Account oder installierte Programme.
Frage nur nach Informationen, die für den nächsten Schritt notwendig sind.
Installiere und ändere noch nichts.

Erwartetes Ergebnis: Eine kurze Vorbereitungsliste. Unbekannte Voraussetzungen bleiben ausdrücklich offen, bis sie am eigenen Rechner geprüft wurden.

In Codex einfügen. Ein kurzer Folgeprompt zu Ihrem Einstieg.

Ich möchte mit dem Buchbeispiel arbeiten. Stelle mir höchstens drei kurze
Fragen zu meinen Erfahrungen mit Projektordnern, Terminal und Tests.
Empfiehl danach einen Einstieg: Vorbereitung ab Kapitel 2 oder Filterübung
ab Kapitel 7. Begründe ihn an meinen Antworten und nenne nur die erste Aufgabe.
Erzeuge noch keinen Code.

Erwartetes Ergebnis: Eine begründete Einstiegsempfehlung, keine neue Projektidee und keine zusätzliche Werkzeugliste.

In Codex einfügen. Der kopierte Aufgabenplaner ist als Projektordner zugänglich.

Prüfe nur lesend den aktuellen Arbeitsordner.
Nenne seinen vollständigen Pfad und prüfe, ob diese Einträge vorhanden sind:
start, fertig, fehler, tests, server.mjs und README.md.
Lies die README und start/AGENTS.md.
Erkläre in vier kurzen Sätzen, welcher Ordner meine Arbeitsfassung ist,
welcher die Referenz enthält und wie ich das Beispiel starte.
Wenn Dateien fehlen, nenne sie. Suche nicht eigenständig in fremden Projekten.
Ändere noch nichts.

Erwartetes Ergebnis: Der Pfad Ihrer Kopie und die Bestätigung der benötigten Dateien. Ein fehlender Eintrag muss vor der nächsten Übung geklärt werden.

In Codex einfügen. Wenn die Anwendung nicht erreichbar ist, geben Sie Codex diesen Auftrag.

Prüfe, warum der lokale Aufgabenplaner nicht erreichbar ist.
Kontrolliere Arbeitsordner, Node.js, server.mjs und die Servermeldung.
Wenn Port 4177 belegt ist, beende keinen unbekannten Prozess.
Nutze einen anderen freien lokalen Port, falls nötig, und nenne die
vollständige Adresse meiner Startfassung.
Ändere keine Anwendungsdateien und installiere keine Pakete.
Berichte die beobachtete Ursache oder kennzeichne sie als noch unklar.

Erwartetes Ergebnis: Eine beobachtete Ursache und ein begrenzter nächster Schritt. Bei anderem Port muss auch die Browseradresse angepasst werden.

In Codex einfügen. Arbeiten Sie in Ihrer eigenen Kopie des Aufgabenplaners, zunächst noch ohne Filterergänzung.

Lies start/AGENTS.md und start/index.html.
Ersetze ausschließlich den erklärenden Absatz unter der großen Überschrift
in start/index.html durch:
Mein lokaler Aufgabenplaner. Aufgaben bleiben in diesem Browser gespeichert.

Ändere keine Logik, keine anderen Texte und keine Referenzdateien.
Zeige mir danach den alten und den neuen Absatz.
Führe die vorhandenen Modelltests gegen start aus und nenne ihre Ergebnisse.
Wenn der Filter bereits ergänzt wurde, aktiviere auch die Filtertests.
Wenn der Server läuft, nenne die Adresse, an der ich die Änderung sehe.

Erwartetes Ergebnis: Ein geänderter Absatz in der Arbeitsfassung und beim unveränderten Testumfang weiterhin vier bestandene Grundtests. Bei bereits ergänztem Filter oder zusätzlichen Tests ist die Anzahl entsprechend höher. Der neue Text ist nach dem Neuladen unter /start/ sichtbar.

In Codex einfügen. Nach der kleinen Textänderung.

Prüfe die gerade ausgeführte Textänderung in start/index.html.
Bestätige, ob genau der erklärende Absatz unter der Hauptüberschrift
geändert wurde. Liste weitere Änderungen auf, falls es welche gibt.
Erkläre mir in höchstens vier Sätzen, wie ich die richtige Fassung im Browser
erkenne und welches vorhandene Verhalten ich kurz gegenprüfen sollte.
Ändere bei dieser Prüfung nichts.

Erwartetes Ergebnis: Eine begrenzte Prüfung mit Fundstelle. Falls mehr geändert wurde, ist das sichtbar und kann gezielt besprochen werden.

In Codex einfügen. Dieser Auftrag erstellt zunächst nur ein Briefing.

Ich möchte im Aufgabenplaner schneller erkennen, was noch offen ist.
Lies den Startstand und formuliere daraus ein kurzes Änderungsbriefing.

Es soll drei Ansichten geben: Alle, Offen und Erledigt.
Aufgaben müssen gespeichert bleiben. Anlegen und Abhaken sollen weiterhin funktionieren.

Gib mir: Ziel in einem Satz, betroffene Dateien, drei normale Prüffälle,
einen Fall ohne Treffer und höchstens zwei noch offene Entscheidungen.
Beschränke die geplante Umsetzung auf start; fertig und fehler bleiben unverändert.
Schreibe noch keinen Code und erfinde keine zusätzlichen Funktionen.

Erwartetes Ergebnis: Ein Briefing für den Filter. Die offenen Entscheidungen sollen das Ergebnis tatsächlich beeinflussen, beispielsweise den Hinweis bei leerer Auswahl.

In Codex einfügen. Nach dem Briefing aus P04-01 im selben Chat.

Prüfe das gerade formulierte Filterbriefing gegen den tatsächlichen Startstand.
Markiere unklare oder widersprüchliche Anforderungen.
Unterscheide notwendige Änderungen von optionalen Verbesserungen.
Kürze das Briefing auf einen direkt ausführbaren Arbeitsauftrag.
Erhalte alle Prüfbedingungen und die Vorgabe, die Referenzfassungen nicht zu ändern.
Setze den Auftrag noch nicht um.

Erwartetes Ergebnis: Ein kompakter, konsistenter Auftrag. Optionale Wünsche sind getrennt und werden nicht still zu Pflichtfunktionen.

In Codex einfügen. Im kopierten Aufgabenplaner.

Lies die für diesen Arbeitsordner geltenden Projektanweisungen sowie
start/AGENTS.md ausdrücklich.
Liste die gelesenen Dateien mit ihrem Pfad auf.
Erkläre, welche Regeln für Änderungen an start gelten und ob sie sich
widersprechen. Unterscheide Dateiinhalte von technischen Berechtigungen.
Ändere noch keine Regeln oder Einstellungen.

Erwartetes Ergebnis: Eine Liste mit echten Fundstellen und eine kurze Erklärung des Geltungsbereichs. Codex soll keine unbekannten Regeln erfinden.

In Codex einfügen. Nur in Ihrer Übungskopie.

Ergänze start/AGENTS.md um eine kurze, eindeutige Prüfregel:
Bei Änderungen an start muss der Test gegen start laufen.
Vor der Filterergänzung laufen die vorhandenen Grundtests, ursprünglich vier.
Nach der Filterergänzung müssen alle Modelltests mit FILTER_TESTS=1
aktiviert werden: ursprünglich vier Grundtests und fünf weitere Filtertests.
Später ergänzte Tests müssen ebenfalls laufen. Änderungen an Oberfläche
oder Bedienung benötigen zusätzlich eine passende Browserprüfung.
Ein Test der Referenz fertig gilt nicht als Prüfung von start.

Prüfe vorher, ob eine gleichwertige Regel bereits vorhanden ist.
Vermeide doppelte Regeln und ändere keine Anwendungsdateien.
Zeige mir danach die Ergänzung.

Erwartetes Ergebnis: Eine knappe neue Regel oder die Feststellung, dass sie bereits vorhanden ist. Keine zweite Sammlung mit demselben Inhalt.

In Codex einfügen. Im kopierten Aufgabenplaner, vor Kapitel 7.

Erstelle einen kurzen Plan für die drei Aufgabenfilter in start.
Lies die vorhandenen Dateien und start/AGENTS.md.

Gliedere die Arbeit in höchstens vier Schritte.
Jeder Schritt braucht ein sichtbares Ergebnis, die betroffenen Dateien
und eine passende Prüfung.

Erhalte Anlegen, Abhaken und lokalen Speicher.
Suche, Anmeldung, Synchronisation und Veröffentlichung gehören nicht dazu.
Nenne Voraussetzungen und höchstens zwei offene Entscheidungen.
Schreibe den Plan zunächst in die Antwort. Ändere noch keinen Code.

Erwartetes Ergebnis: Ein Plan, dessen Schritte zu den vorhandenen Projektdateien passen. Er enthält Prüfungen und keine zusätzlichen Funktionen als versteckte Voraussetzungen.

In Codex einfügen. Nachdem Sie den Plan gelesen und bei Bedarf korrigiert haben.

Speichere den besprochenen Filterplan als PLAN.md im Übungsordner.
Falls die Datei bereits existiert, lies sie zuerst und ergänze sie gezielt.

Halte fest: Ziel, höchstens vier Schritte, Abnahmekriterien und spätere Ideen.
Schreibe noch nicht ausgeführte Arbeiten als geplant.
Füge keine Zeitgarantien und keine erledigten Tests hinzu.
Beginne in diesem Schritt noch nicht mit der Implementierung.

Erwartetes Ergebnis: Eine kurze Planungsdatei. Sie beschreibt den beabsichtigten Weg, nicht einen bereits erreichten Zustand.

In Codex einfügen. Voraussetzung: Ihre Kopie von beispiele/aufgabenplaner ist als Arbeitsordner zugänglich. Dieser Einstieg geht von start ohne Filterergänzung aus; für die Wiederaufnahme eines bearbeiteten Stands verwenden Sie P07-05.

Prüfe den Aufgabenplaner in diesem Arbeitsordner.
Lies start/AGENTS.md und die Dateien der Startfassung.
Prüfe, ob Node.js verfügbar ist, und führe die Grundtests aus,
beim gelieferten Testumfang vier:
VERSION=start node --test tests/model.test.mjs

Passe die Schreibweise des Befehls an mein Betriebssystem an, falls nötig.
Starte anschließend den lokalen Server mit node server.mjs.
Nutze einen laufenden Server nur, wenn er nachweislich genau diese
Arbeitskopie ausliefert. Dieselbe Oberfläche allein reicht als Nachweis nicht.
Beende keinen fremden Prozess. Falls der Port anderweitig belegt ist,
verwende einen freien Port und nenne die angepasste Adresse.

Ändere noch keine Anwendungsdateien und installiere keine Pakete.
Nenne mir die Adresse der Startfassung und in höchstens fünf Sätzen:
Was funktioniert bereits, was fehlt noch und was soll ich jetzt öffnen?
Wenn eine Voraussetzung fehlt, erkläre den nächsten nötigen Schritt.

Erwartetes Ergebnis: Eine Startadresse und einen kurzen Bericht. Bei unverändertem Startstand bestehen vier Grundtests. Der Filter ist noch nicht vorhanden. Wenn Node.js fehlt oder der Server nicht gestartet werden konnte, muss Codex das ausdrücklich nennen.

Arbeiten Sie weiter in der Kopie des gesamten Beispielordners, die Sie in Abschnitt 7.1 geöffnet haben. Lassen Sie Codex dort nur die angegebenen Dateien innerhalb von start bearbeiten. Eine weitere Kopie ist für diesen Schritt nicht nötig. Der Server zeigt dann unter /start/ Ihren Arbeitsstand. Die mitgelieferte Fassung unter /fertig/ dient zum Vergleich.

In Codex einfügen. Voraussetzung: Codex arbeitet in Ihrer Kopie des Beispielordners.

Ergänze im Unterordner start des Aufgabenplaners die Filter
Alle, Offen und Erledigt. Lies zuerst start/AGENTS.md und die vorhandenen Dateien.

Ausgangslage:
Es gibt drei Beispielaufgaben. Briefing prüfen und Angebot senden
sind offen. Termin bestätigen ist erledigt.

Gewünschtes Verhalten:
- Alle zeigt alle Aufgaben in der bisherigen Reihenfolge.
- Offen zeigt nur Aufgaben mit done: false.
- Erledigt zeigt nur Aufgaben mit done: true.
- Der aktive Filter ist erkennbar und mit der Tastatur bedienbar.
- Ohne Treffer erscheint ein zur Auswahl passender Hinweis.
- Filterwechsel verändern den gespeicherten Aufgabenbestand nicht.
- Anlegen, Abhaken und Neuladen funktionieren weiterhin.

Behalte HTML, CSS und JavaScript ohne neue Laufzeitpakete bei.
Bearbeite nur start/index.html, start/app.js und start/model.mjs.
Die Referenzordner fertig und fehler bleiben unverändert.

Prüfe Normalfälle, einen leeren Filter und den Erhalt der gespeicherten
Aufgaben. Unterscheide ausgeführte Tests von vorgeschlagenen Tests.
Berichte die geänderten Dateien und die beobachteten Ergebnisse.
Nenne am Ende die Browseradresse meiner bearbeiteten Startfassung.

Erwartetes Ergebnis: Drei Filter in Ihrer Fassung unter /start/. Bei den ursprünglichen Beispieldaten zeigt Alle drei Aufgaben, Offen zwei und Erledigt eine. Der Referenzordner fertig bleibt unverändert.

In Codex einfügen. Verwenden Sie diesen Prompt nach dem Umsetzungsauftrag im selben Projekt.

Prüfe meine bearbeitete Fassung im Unterordner start.
Prüfe nicht nur die mitgelieferte Referenzlösung fertig.

Führe alle Modelltests gegen start aus, einschließlich später
ergänzter Tests. Der gelieferte Stand enthält neun Tests:
VERSION=start FILTER_TESTS=1 node --test tests/model.test.mjs
Passe die Schreibweise an mein Betriebssystem an, falls nötig.

Prüfe zusätzlich im Browser, sofern du ihn bedienen kannst:
1. Alle zeigt die drei ursprünglichen Beispielaufgaben.
2. Offen zeigt Briefing prüfen und Angebot senden.
3. Erledigt zeigt Termin bestätigen.
4. Ein Filterwechsel verändert die gespeicherten Aufgaben nicht.
5. Abhaken, Anlegen und Neuladen erhalten die Aufgaben.
6. Ohne Treffer erscheint ein verständlicher Hinweis.

Nutze für diese Prüfung frische Testdaten in einem separaten
Browserkontext. Lösche keine Daten aus meinem normalen Browser.
Die vorhandene Browser-Suite prüft Referenzstände. Melde ihren Erfolg
nicht als Prüfung meiner veränderten Startfassung.

Ändere bei dieser Prüfung noch keinen Code.
Berichte kurz: bestanden, fehlgeschlagen, nicht geprüft.
Wenn du den Browser nicht bedienen kannst, gib mir eine kurze Klickfolge
für die noch offene Prüfung. Nenne bei Fehlern den betroffenen Schritt.

Erwartetes Ergebnis: Beim gelieferten Testumfang neun bestandene Modelltests gegen start und einen klar abgegrenzten Browserbericht. Nach eigenen Testergänzungen kann die Anzahl höher sein. „Nicht geprüft“ ist kein bestandener Test. Für die kurze eigene Sichtprüfung folgen die Schritte darunter.

In Codex einfügen. Dieser Kasten gehört zur absichtlichen Fehlervariante im Unterordner fehler Ihrer Übungskopie.

In der Übungsfassung fehler ist der Filter Offen falsch.
Mit den drei ursprünglichen Aufgaben zeigt er Termin bestätigen.
Erwartet sind Briefing prüfen und Angebot senden.

Lies fehler/AGENTS.md und prüfe die Auswahlbedingung in fehler/model.mjs.
Korrigiere nur diese Bedingung.
Erhalte die gespeicherten Aufgaben und die übrigen Funktionen.
Führe vor und nach der Korrektur die Tests gegen fehler aus:
VERSION=fehler node --test tests/model.test.mjs
Passe die Schreibweise an mein Betriebssystem an, falls nötig.
Zeige, welche Tests zuerst fehlschlagen und danach bestehen.

Erwartetes Ergebnis: Eine Änderung der Filterbedingung und neun bestandene Tests gegen die korrigierte Übungsfassung. Zuvor schlagen bei der gelieferten Fehlervariante zwei Tests fehl.

In Codex einfügen. Im selben Übungsprojekt, auch in einem späteren Chat:

Lies start/AGENTS.md und prüfe den aktuellen Stand des Aufgabenplaners.
Fasse in höchstens fünf Punkten zusammen:
Was ist umgesetzt, welche Tests bestehen jetzt, was ist offen?
Führe dafür die Tests gegen meine Fassung aus:
VERSION=start FILTER_TESTS=1 node --test tests/model.test.mjs
Passe die Schreibweise an mein Betriebssystem an, falls nötig.

Ändere noch keine Dateien. Schlage genau einen kleinen nächsten Schritt
vor und nenne das sichtbare Ergebnis, an dem ich ihn prüfen kann.

Erwartetes Ergebnis: Einen aktuellen Stand und einen begrenzten Vorschlag. Codex soll noch keine weitere Funktion ergänzen.

In Codex einfügen. Im Aufgabenplaner; die Fassung fehler ist noch unverändert.

Untersuche die absichtliche Fehlervariante unter fehler.
Bei den drei ursprünglichen Aufgaben zeigt der Filter Offen die Aufgabe
Termin bestätigen. Erwartet sind Briefing prüfen und Angebot senden.

Lies fehler/AGENTS.md und die relevante Logik.
Führe VERSION=fehler node --test tests/model.test.mjs aus.
Passe den Befehl an das Betriebssystem an, falls nötig.

Ändere noch nichts. Nenne die genaue Fundstelle, die beobachteten Testfehler
und die kleinste plausible Korrektur. Trenne Beobachtung und Vermutung.

Erwartetes Ergebnis: Zwei fehlgeschlagene Tests und eine Erklärung der falschen Auswahlbedingung. Die Anwendung bleibt zunächst unverändert.

In Codex einfügen. Nach P08-01 im selben Projekt.

Korrigiere nur die bestätigte falsche Auswahlbedingung in fehler/model.mjs.
Erhalte alle Aufgaben und ändere keine anderen Funktionen.
Führe danach dieselben Modelltests gegen fehler erneut aus, beim
gelieferten Testumfang neun. Passe die Befehle an mein Betriebssystem an.
Berichte vorher und nachher: Anzahl bestandener und fehlgeschlagener Tests.
Zeige mir die geänderte Zeile und den Browserfall, den ich wiederholen soll.

Erwartetes Ergebnis: Die eine Bedingung ist korrigiert; beim gelieferten Testumfang bestehen alle neun Tests. Im Browser zeigt Offen anschließend die beiden offenen Aufgaben.

In Codex einfügen. Bei einem eigenen Fehler mit noch unklarer Ursache.

Die Ursache ist noch nicht ausreichend belegt.
Untersuche nur den zuletzt beschriebenen fehlerhaften Ablauf.
Nenne höchstens drei mögliche Ursachen und für jede eine konkrete Prüfung,
mit der sie bestätigt oder ausgeschlossen werden kann.
Führe die möglichen, nicht verändernden Prüfungen aus.
Ändere keinen Code auf Verdacht und behaupte keine Ursache ohne Beobachtung.

Erwartetes Ergebnis: Eine kleine Diagnosefolge mit Befunden. Eine offene Ursache bleibt offen, bis eine Prüfung sie trägt.

In Codex einfügen. Nach der Filterergänzung in Ihrer Arbeitsfassung.

Vergleiche meine Arbeitsfassung start mit dem gelieferten Referenzstand fertig.
Erkläre die Unterschiede nach Datei und sichtbarer Wirkung.
Berücksichtige, dass ich den Einleitungsabsatz oder die Projektregeln in
früheren Übungen bewusst geändert haben kann.

Kennzeichne jede Abweichung als beabsichtigte Variante, möglicher Fehler
oder noch ungeklärt. Belege sie mit der Fundstelle.
Ändere bei diesem Vergleich keine Dateien und gleiche nichts automatisch an.

Erwartetes Ergebnis: Ein verständlicher Unterschiedsbericht. Eine Abweichung wird begründet, statt allein wegen eines anderen Wortlauts als Fehler zu gelten.

In Codex einfügen. Wenn die Änderung und ihre Unterschiede vorliegen.

Prüfe die Filteränderung in start gegen die vereinbarten Kriterien.
Berücksichtige alle geänderten und neu hinzugefügten Dateien.
Suche nach unbeabsichtigten Funktionsänderungen und fehlenden Prüfungen.

Berichte nur konkrete Befunde mit Fundstelle und Auswirkung.
Trenne Fehler von optionalen Verbesserungen.
Nenne zum Schluss: übernehmbar, noch zu korrigieren oder nicht ausreichend geprüft.
Ändere nichts und erstelle keinen Commit oder Push.

Erwartetes Ergebnis: Eine begründete Einschätzung. „Übernehmbar“ muss auf Auftrag und Prüfungen bezogen sein, nicht auf allgemeines Vertrauen in den Code.

In Codex einfügen. Im Aufgabenplaner.

Prüfe, welche Tests für meine aktuelle Arbeitsfassung start relevant sind.
Lies tests/model.test.mjs und die vorhandene Filterimplementierung.
Wenn der Filter schon umgesetzt ist, aktiviere alle Modelltests
gegen start, einschließlich später ergänzter Tests. Ursprünglich sind es neun.
Wenn er noch fehlt, benenne die fehlende Funktion und trenne Grundtests
von den erwartbar fehlschlagenden Filtertests.

Führe die passende Prüfung aus. Nenne den vollständigen Befehl,
das Zielverzeichnis und die tatsächlich ausgeführten Testfälle.
Ändere keine Tests, nur damit ein Lauf grün wird.

Erwartetes Ergebnis: Ein Testbericht, dessen Ziel zu Ihrer Arbeitsfassung passt. Fehlende Funktionen werden nicht durch abgeschaltete Prüfungen verborgen.

In Codex einfügen. Optionale Übung in Ihrer eigenen Kopie.

Ergänze in tests/model.test.mjs genau einen Verhaltenstest:
Wird dieselbe Aufgabe zweimal umgeschaltet, entspricht der resultierende
Bestand wieder dem ursprünglichen Bestand.
Prüfe innerhalb dieses Falls auch den Zwischenstand: Nach dem ersten
Umschalten muss der Erledigt-Zustand tatsächlich gewechselt haben.
Vergleiche die Eingabeliste vor und nach jedem Aufruf mit einer unabhängigen
Kopie. Auch die Eingabe des zweiten Aufrufs muss unverändert bleiben.

Verwende die vorhandene Testbibliothek und vorhandene Funktionen.
Ändere keine Anwendungslogik und keine bestehenden Erwartungen.
Führe die Tests gegen start und fertig aus; bei start aktivierst du die
Filtertests nur, wenn der Filter dort bereits implementiert ist.
Berichte die neue Anzahl der Tests und die Ergebnisse.

Erwartetes Ergebnis: Ein zusätzlicher Test für eine konkrete Eigenschaft. Beim unveränderten Startstand steigt die Zahl von vier auf fünf, beim Filterstand von neun auf zehn. Historische Angaben von neun Tests beziehen sich weiterhin auf den ursprünglichen Testumfang.

In Codex einfügen. Voraussetzung: Der Filter in start funktioniert bereits.

Verbessere in meiner Arbeitsfassung start genau diesen Ablauf:
Wenn unter Erledigt eine neue offene Aufgabe angelegt wird, erscheint
zusätzlich zur aktualisierten Gesamtzahl die Meldung:
Aufgabe angelegt. Unter Offen sichtbar.

Die Aufgabe bleibt offen. Zeige die Erfolgsmeldung nur, wenn die neue
Aufgabe erfolgreich im Browserspeicher abgelegt wurde. Bei einem Speicherfehler
muss die vorhandene Warnung sichtbar bleiben; zeige dann keinen Erfolg an.
Wechsle den Filter nicht automatisch.
Kennzeichne die Statusmeldung so, dass assistive Technik sie erkennen kann,
beispielsweise mit role="status". Behaupte ohne Prüfung mit einem Screenreader
keine bestätigte Sprachausgabe.
Wenn der neue Titel ungültig ist, zeige keinen Erfolg an.
Entferne die bisherige Erfolgsmeldung bei neuer Eingabe, Filterwechsel
oder erneutem Abhaken. Speicherwarnungen müssen dabei erhalten bleiben.

Lies zuerst die vorhandene Meldungs- und Speicherlogik.
Ändere nur die dafür nötigen Stellen in start.
Prüfe den normalen Fall, ein vollständig leeres Feld, nur Leerzeichen
und unveränderte Speicherung. Prüfe auch eine ungültige Eingabe direkt
nach einer erfolgreichen Eingabe, damit kein alter Erfolg stehen bleibt.
Nenne Browserprüfungen ausdrücklich als offen, wenn du sie nicht ausführen kannst.

Erwartetes Ergebnis: Eine präzise Rückmeldung nach erfolgreichem Anlegen und Speichern unter Erledigt. Die vorhandene Filterwirkung bleibt gleich, und Fehlermeldungen behalten Vorrang.

In Codex einfügen. Nach der Meldungsänderung in start.

Prüfe meine geänderte Fassung start im Browser, soweit Browsersteuerung
verfügbar ist. Nutze einen separaten Kontext mit synthetischen Daten.

Prüfe: neue Aufgabe unter Erledigt, leeres Pflichtfeld, nur Leerzeichen,
ungültige Eingabe nach vorherigem Erfolg, Wechsel auf Offen,
Neuladen, Tastaturbedienung und eine schmale Ansicht von 390 Pixeln.
Prüfe in einem isolierten Testkontext auch einen gezielt fehlschlagenden
Speicheraufruf und bereits beschädigte Speicherdaten. Verändere dafür keine
normalen Browserdaten und keine Anwendungsdateien. Wenn diese Simulation
nicht möglich ist, melde genau diese Fälle als ungeprüft.
Achte darauf, dass eine Erfolgsmeldung keine Fehlermeldung verdeckt.
Vergleiche den gespeicherten Bestand vor und nach reinen Filterwechseln.

Ändere bei dieser Prüfung keine Projektdateien. Testdaten und simulierte
Speicherfehler dürfen nur den separaten Testkontext betreffen.
Berichte beobachtete Ergebnisse und nicht ausgeführte Fälle getrennt.
Wenn keine Browsersteuerung möglich ist, gib mir eine kurze manuelle Prüfliste.

Erwartetes Ergebnis: Ein Bericht zur geänderten Fassung mit konkreten Beobachtungen. Fehlende Browsermöglichkeiten werden nicht durch eine behauptete Sichtprüfung ersetzt.

In Codex einfügen. Die Filter in Ihrer Arbeitsfassung start funktionieren bereits. Die Meldungsübung aus Kapitel 11 ist für diese Übung keine Voraussetzung.

Lies start/app.js und start/model.mjs.
Prüfe, ob sich die Auswahl der Leerzustandsmeldung verständlicher ausdrücken lässt.
Schlage höchstens eine kleine Überarbeitung vor.

Erkläre: Welche Stelle wird leichter verständlich, welche Dateien wären
betroffen und welche bestehenden Prüfungen müssen danach gleich bleiben?
Wenn die aktuelle Fassung bereits ausreichend klar ist, sage das.
Ändere noch keinen Code und schlage keinen vollständigen Umbau vor.

Erwartetes Ergebnis: Eine begründete lokale Empfehlung oder ein begründetes Belassen des Codes. Der Aufwand muss einem konkreten Verständlichkeitsgewinn dienen.

In Codex einfügen. Nur wenn P12-01 einen nachvollziehbaren Nutzen gezeigt hat.

Setze die besprochene kleine Vereinfachung der Leerzustandslogik in start um.
Ändere weder Texte noch Filterverhalten, Speicherung oder Bedienung.
Verwende keine neuen Pakete und keine zusätzliche Architekturschicht.

Führe vor und nach der Änderung die passenden Tests gegen start aus.
Prüfe die drei Leerzustandsmeldungen zusätzlich am tatsächlichen Verhalten.
Berichte die geänderten Stellen und die Vergleichsergebnisse.
Wenn eine Prüfung nicht ausführbar ist, kennzeichne sie als offen.

Erwartetes Ergebnis: Eine kleine strukturelle Änderung mit unveränderten Meldungen und Funktionen. Die Prüfung bezieht sich auf den Stand nach der Überarbeitung.

In Codex einfügen. Zum Ende einer Arbeitseinheit im Übungsprojekt.

Erstelle oder aktualisiere STATUS.md im Übungsordner.
Prüfe dafür den aktuellen Dateistand und die vorhandenen Testnachweise.

Halte knapp fest:
1. Ziel des Projekts und bearbeitete Fassung.
2. Was tatsächlich umgesetzt ist.
3. Welche Prüfungen ausgeführt wurden, mit Befehl und Ergebnis.
4. Was offen oder nicht geprüft ist.
5. Genau ein sinnvoller nächster Schritt.

Ordne jeden Nachweis dem geprüften Dateistand zu. Ein früher bestandener Test
ist ohne passende Dateien kein aktueller Nachweis. Führe für diese Notiz
keine neuen Tests aus; markiere fehlende aktuelle Prüfungen als offen.
Erfinde keine Testresultate und kopiere keinen vollständigen Chatverlauf.
Ändere nur die Statusnotiz.

Erwartetes Ergebnis: Eine kurze, prüfbare Übergabe. Ein nur vorgeschlagener Schritt erscheint unter offen und nicht unter erledigt.

In Codex einfügen. Im Projektchat nach einer Pause.

Lies STATUS.md, falls vorhanden, sowie start/AGENTS.md und den aktuellen Code.
Vergleiche die Notiz mit dem tatsächlichen Stand.
Führe die passenden Tests gegen start aus.

Berichte in höchstens sechs Punkten: bestätigt, abweichend, offen.
Schlage den nächsten kleinen Schritt vor, der zum dokumentierten Ziel passt.
Ändere in diesem Schritt keine Projektdateien und beginne keine neue Funktion.
Erkläre widersprüchliche Notizen, statt sie stillschweigend zu überschreiben.

Erwartetes Ergebnis: Eine aktualisierte Orientierung. Widersprüche zwischen früherer Notiz und heutigen Dateien werden sichtbar.

In Codex einfügen. Nach einem geprüften lokalen Ergebnis.

Erstelle oder aktualisiere UEBERGABE.md für den aktuellen Aufgabenplaner.
Lies eine vorhandene Anleitung zuerst und erhalte weiterhin gültige Angaben.
Lies dafür die tatsächlichen Dateien und STATUS.md, falls vorhanden.

Beschreibe auf höchstens einer Seite:
- Zweck und bearbeitete Fassung.
- Voraussetzungen und dokumentierte Testumgebung.
- Startbefehl, Browseradresse und Beenden des Servers.
- Testbefehle für genau diese Fassung.
- Lokaler Browserspeicher und seine Grenzen.
- Offene Prüfungen und nicht enthaltene Funktionen.

Gib keine produktive Freigabe und verspreche keine Cloud-Synchronisation.
Ändere nur diese Anleitung und erfinde keine geprüften Betriebssysteme.

Erwartetes Ergebnis: Eine Anleitung, die zum aktuellen Arbeitsstand passt. Die tatsächliche Fassung und offene Einschränkungen sind eindeutig.

In Codex einfügen. Wenn UEBERGABE.md vorliegt.

Prüfe UEBERGABE.md gegen den aktuellen Projektordner.
Kontrolliere, ob alle genannten Dateien vorhanden sind und die Befehle zu
den vorhandenen Skripten und Voraussetzungen passen. Kennzeichne Befehle,
die du nur gelesen, aber nicht ausgeführt hast.
Trenne Voraussetzungen für den normalen Betrieb von optionalen Testwerkzeugen.

Liste fehlende Dateien, unklare Fassungsnamen und unbelegte Aussagen auf.
Prüfe außerdem, ob versehentlich private Daten, lokale Geheimnisse oder
nicht benötigte Laufzeitordner in das geplante Paket geraten würden.
Gib sensible Inhalte nicht in der Antwort wieder, sondern nenne nur die Fundstelle.
Erstelle noch kein öffentliches Paket und lade nichts hoch.

Erwartetes Ergebnis: Ein kurzer Übergabecheck mit konkreten Fundstellen. Eine lesende Prüfung ersetzt nicht den Startversuch aus Abschnitt 14.2. Veröffentlichung bleibt eine eigenständige Entscheidung.

In Codex einfügen. Nach Ihrer eigenen Umsetzung und Prüfung.

Erstelle einen knappen Abschlussbericht zu meiner Filterübung.
Verwende den tatsächlichen Stand und die verfügbaren Prüfresultate.

Gliedere in Ausgangslage, Auftrag, Änderungen, ausgeführte Prüfungen,
offene Punkte und nächster Schritt.
Beziehe dich auf meine bearbeitete Fassung start.
Übernimm keine Testzahlen aus dem Buch, wenn sie nicht für diesen Stand gelten.
Kennzeichne historische Referenznachweise ausdrücklich.
Ändere keine Anwendung und veröffentliche nichts.

Erwartetes Ergebnis: Ein nachvollziehbarer Bericht über Ihre eigene Arbeit. Er bleibt auch dann brauchbar, wenn Ihr Verlauf vom Pilotdurchlauf abweicht.

In Codex einfügen. Wenn eine Antwort den erreichten Stand nicht eindeutig benennt.

Fasse den tatsächlichen Stand der gerade beauftragten Aufgabe zusammen.
Antworte in vier Punkten:
1. Was wurde wirklich geändert?
2. Welche Prüfung wurde mit welchem Ergebnis ausgeführt?
3. Was wurde nicht geprüft oder ist noch offen?
4. Was kann ich jetzt selbst öffnen oder ausführen?

Erfinde keine Ergebnisse und ändere in dieser Antwort keine weiteren Dateien.

Erwartetes Ergebnis: Ein überprüfbarer Abschluss. Offene Arbeit wird sichtbar, ohne dass sofort ein weiterer Umbau beginnt.

In Codex einfügen. Im Übungsprojekt, auch nach einer Unterbrechung. Wenn Codex die Prompt-IDs nennen soll, stellen Sie ihm zusätzlich den Prompt-Index oder die entsprechende Buchstelle bereit.

Lies meinen aktuellen Projektstand und STATUS.md, falls vorhanden.
Ordne ihn dem Lernweg zu: Vorbereitung, Filter, Prüfung, Fehlersuche,
Überarbeitung oder Übergabe.

Schlage genau eine nächste Etappe vor.
Nenne den passenden Prompt aus dem Buch, das erwartete Ergebnis und
höchstens drei Prüfpunkte. Nutze nur Prompt-IDs, die du aus den vorhandenen
Buchhinweisen kennst; sonst beschreibe die Aufgabe ohne erfundene ID.
Erstelle keinen Code und keine neue Funktion.

Erwartetes Ergebnis: Eine nächste Aufgabe passend zum tatsächlichen Stand. Der Plan setzt nicht voraus, dass alle früheren Etappen abgeschlossen sind.