dev-discipline

Dev-Disziplin

„Fertig“ wird durch ein externes Signal erklärt, das du nicht beeinflusst hast. Eine geschriebene Regel benennt nur eine Fehlerklasse; eine Prüfung im Tor stoppt sie. Tritt eine Klasse wiederholt auf, füge die Prüfung im selben Commit hinzu. $DD = der Ordner scripts/ neben dieser Datei (Exit 0 BESTANDEN, 1 FEHLGESCHLAGEN, 2 NICHT_BEWIESEN).

Strenge nach Oberfläche. Volle Schleife für Dinge, die beurteilen (Tests, Validatoren, Schwellenwerte, CI), Geld und numerische Formeln, Migrationen, Authentifizierung, stille Fehler. Eine lokale Korrektur von ~10 Zeilen mit einem Spezifikationsliteral: prove_fix.py, 2–3 selbst geschriebene Mutanten der Fehlerklasse, ein Lauf auf einer Eingabe, die du während der Arbeit nicht verwendet hast. Prosa, UI-Aussehen, Dokumentation, Prototypen: führe die Tests und einen Rauchtest aus. Keine Tests oder kein Ausführer: füge einen minimalen Test in einem eigenen Commit hinzu (Setup, keine Abschwächung).

Schleife

1. Messen vor dem Bearbeiten: ein Befehl, den du vorher und nachher vergleichen wirst. Leite den Umfang aus Rohdaten ab, nicht aus Zusammenfassungen oder Erinnerungen. Liste die gesamte Klasse auf: jede Instanz, die die gleiche Wurzel teilt. → references/debugging.md
2. Behebe die Ursache auf dem Pfad, den der Fehler genommen hat. Eine Abfangen oben ist keine Korrektur. Regression: git bisect run. Nach drei fehlgeschlagenen Versuchen wechsle den Ansatz oder Kontext. Neue Entität, Geld-/Datenfluss oder Migration: zuerst eine 5–10-zeilige Designnotiz (debugging.md §10).
3. Beweise den Test: rot auf dem Eltern-Commit durch eine Assertion (ImportError, Sammlungsfehler, Überspringen = NICHT_BEWIESEN), grün auf der Korrektur, wieder rot nach Rückgängigmachen der Codeänderung: $DD/prove_fix.py. Eine neue Prüfung feuert auf einer schlechten Eingabe und bleibt bei einer guten still. Bei Geld und Zahlen ist der erwartete Wert ein Spezifikationsliteral (# oracle: <quelle>).
4. Tor: der Test läuft im CI im selben Commit; Überspringen, Timeout und „0 Tests“ sind nicht BESTANDEN; Ausschlusslisten schrumpfen nur; eine Schleife über einen Glob oder ein Register bestätigt, wie viele Elemente gefunden wurden. → gate-integrity.md
5. Abnahme anhand der Zusammenfassungszeile des Ausführers des letzten Laufs auf exakt demselben Code, nicht anhand des $? einer Pipeline.
6. Abschluss mit einer Prüfung, die der Autor nicht beeinflusst hat: andere Daten, ein schreibgeschützter Produktions-Rauchtest, ein unabhängiges Orakel, wobei die Erwartung zuerst niedergeschrieben wurde. Eine Klasse, die es findet, kommt in das Tor. → proof-and-oracles.md

Das Orakel und sein Schutz

• Ein Orakel teilt keinen Code mit dem, was es prüft. Goldene Dateien und Selbst-Parität beweisen Konsistenz, nicht Korrektheit.
• Ein Verifikationsskript ist Code unter Test: führe es auf einer guten und einer schlechten Eingabe aus; gib aus, wie viele Elemente es geprüft hat.
• Tests, Snapshots, erwartete Werte und CI ändern sich nur per Vertrag: dem Auftrag, oder, wenn du allein arbeitest, einer Benutzeranfrage, die die Änderung benennt (neue Spezifikation, Ticket, Wert) plus eine Zeile, die vor dem Bearbeiten geschrieben wurde (welche Tests sich ändern, woher der neue Wert kommt). „Mach es grün“ ist kein Vertrag: ein Test, der der Spezifikation widerspricht, bleibt wie er ist, und die Antwort ist SPEC_CONFLICT. Wertänderungen gehen in einen separaten test: Commit. Überspringungen, gelöschte Assertions, eingeschränkte Abdeckung benötigen einen genannten Grund. Stimme niemals Code ab, um eine erwartete Zahl zu treffen. Beurteile das endgültige Diff, nicht das Bearbeitungswerkzeug: $DD/guard_diff.py (zunächst beratend). Eine Prüfung, die legitime Arbeit blockiert, ist ein Fehler: melde BLOCKED, umgehe sie niemals. → oracle-protection.md

Autonomie

Standardmäßig weitermachen. Frage nur bei Irreversiblen (Sicherheit, Zahlungen, Schreibvorgänge in Produktionsdaten, Berechtigungen) oder bei einem Konflikt mit dem Ziel. Bei einer Gabelung wähle eine aus, dokumentiere warum, die Zahlen beider Messungen und wie rückgängig zu machen ist, und fahre fort. Blockiert: schließe alles Unabhängige ab, dann beende mit einer Zeile, die die Aktion und den benötigten Befehl nennt.

Bericht

• Jedes Kriterium BESTANDEN | FEHLGESCHLAGEN | NICHT_BEWIESEN mit Befehl, Exit-Code und Ausgabezeile; plus nicht_geprüft.
• Urteil: DONE, BLOCKED(grund), SPEC_CONFLICT(test, quelle), IMPOSSIBLE, NOT_REPRODUCED. Ein ehrlicher Nicht-Fertig-Exit ist ein Erfolg; ein stilles Überspringen ist ein Fehler. Benenne Teilzustände („Abfangen hinzugefügt, Ursache aktiv“).
• Jede Zahl kommt mit ihrem Befehl aus dem letzten Lauf. Führe Zahlen, die ein Unteragent meldet, erneut aus ($DD/reexec_claims.py).
• Commit-Body = Beweisprotokoll: Vorher/Nachher-Messung, Tor-Zeile, was nicht fertig ist und wo es hin ist.

Rote Flaggen

Ich stelle fest	Ich tue
Grün ohne ein Rot auf dem Eltern-Commit	prove_fix.py
Zitieren einer Zahl eines Unteragenten oder meiner Erinnerung	führe es erneut aus
Bearbeiten eines Tests oder Schwellenwerts ohne Vertrag	Vertragszeile oder SPEC_CONFLICT
skip, retry, sleep, noqa um grün zu bekommen	finde die Ursache, mache es deterministisch (refactor-flaky.md)
Kurz davor, etwas Reversibles zu fragen	entscheide, dokumentiere, fahre fort

Mehr: delegation.md (Unteragenten, Prüfer, Aufträge), release.md (Auslieferungen), process-ledger.md, evidence.md.