Old Coder: Reviews von SPEC und EVIDENCE statt Code

Was das Old Coder Skill tatsächlich verändert

Das Old Coder Skill ersetzt Code-Reviews durch Dokumenten-Reviews. Ihr Coding-Agent erstellt zuerst eine SPEC, bevor er Code schreibt. Sie genehmigen dieses Dokument, und erst danach implementiert der Agent die Änderung. Anschließend prüft er seine eigene Arbeit mit einem festen Stapel automatisierter Prüfungen, der Gauntlet genannt wird. Danach erhalten Sie einen EVIDENCE-Bericht mit den exakten Befehlen und den tatsächlichen Zahlen. Sie lesen zwei Dokumente. Den Diff lesen Sie nie.

Dieser Tausch funktioniert nur, wenn die beiden Dokumente dasselbe Vertrauen schaffen wie früher der Diff. Die SPEC schafft dieses Vertrauen, weil Sie sie genehmigt haben, bevor Code vorhanden war. Sie konnte daher nicht auf bereits geschriebenen Code zugeschnitten werden. Der EVIDENCE-Bericht schafft dieses Vertrauen, weil jede Zahl daraus einem Befehl entstammt, den Sie selbst ausführen und dabei beobachten können, wie derselbe Wert erzeugt wird. Wenn eine der beiden Hälften nachlässt, haben Sie das Review durch eine Zusammenfassung eines Reviews ersetzt. Das ist schlechter, als den Diff zu lesen, weil der Vorgang abgeschlossen wirkt.

Das Skill besteht aus einfachem Markdown. Es funktioniert daher mit jedem Agenten, der schriftliche Anweisungen befolgt: Claude Code, Codex CLI, Cursor oder Ihre eigene Schleife. Es gehört zur selben Familie wie das Persona-Skill für den faulen Senior-Entwickler mit Pferdeschwanz. Wenn dieses Dateiformat für Sie neu ist, erklärt was ein Agent-Skill ist und wie ein Agent es lädt die technischen Grundlagen.

Die SPEC ist die eine Entscheidung, die Sie noch treffen

Die SPEC ist ein Testplan, der erstellt wird, bevor der Code existiert. Die Skill-Datei verlangt, dass sie vier Punkte enthält.

• Konkrete Szenarien: Eingaben, erwartete Ausgaben, Grenzfälle und Fehlerfälle. divide(1, 0) raises ZeroDivisionError with message X, nicht lediglich „behandelt ungültige Eingaben“.
• Negative Einschränkungen: Was sich nicht ändern darf, zum Beispiel vorhandene Tests und Signaturen der öffentlichen API.
• Einen Einrichtungsplan: jedes Tool und jede neue Abhängigkeit, jeweils mit einer Zeile zur Begründung.
• Einen absoluten Dateipfad, damit Sie die Datei ohne Suche öffnen können.

Am Einrichtungsplan zeigt sich, wie aktuell das Trainingswissen eines Modells ist. Ein aus dem Gedächtnis abgerufenes Tool oder eine festgelegte Version kann bereits ein Jahr veraltet sein. Deshalb ist es hilfreich, dem Agenten eine selbst gehostete SearXNG-Instanz für die Websuche bereitzustellen und ihn die aktuellen Versionen prüfen zu lassen, bevor er sie vorschlägt.

Genehmigen Sie die SPEC und committen Sie sie anschließend. Eine SPEC, die nach der Genehmigung bearbeitet werden kann, ist kein Vertrag. Der Commit ermöglicht es Ihnen, später zu prüfen, ob die Nachweise anhand genau der von Ihnen freigegebenen SPEC erhoben wurden.

Dies ist die einzige verbleibende Ja-oder-Nein-Entscheidung. Genau darin liegt ihr Zweck und auch ihr Risiko. Behandeln Sie sie wie eine Änderung an der Produktionsumgebung, denn das ist sie. Wenn Sie bereits ein explizites Genehmigungsgate vor Agent-Aktionen verwenden, lässt sich die Genehmigung der SPEC an derselben Stelle in Ihren Workflow einordnen.

Der EVIDENCE-Bericht: Zahlen mit den zugehörigen Befehlen

Den EVIDENCE-Bericht lesen Sie am Ende. Die Fähigkeit erfordert, dass jedes spezifizierte Verhalten dem Test zugeordnet wird, der es verifiziert. Jede Schicht der Prüfserie muss mit dem ausgeführten Befehl und dem tatsächlichen Ergebnis dokumentiert werden. Jede Zahl muss aus einem neuen Lauf nach der letzten Codeänderung stammen. Jede übersprungene Schicht muss mit ihrer Begründung aufgeführt werden. Adjektive sind keine Belege. „Alle 50 Tests bestanden, Abdeckung 49/49 Anweisungen“ ist ein Ergebnis. „Gut getestet“ ist kein Ergebnis.

Der Demo-Bericht im Repository, demo-rate-limiter/evidence.md, identifiziert seinen Quellstand durch einen Commit und einen sha256-Tree-Hash. Diese Zeile ist wichtiger, als es zunächst scheint. Sie zeigt, aus welchen exakten Bytes die Zahlen hervorgegangen sind. Ohne diese Angabe kann ein Bericht unbemerkt einen nicht mehr vorhandenen Arbeitsstand beschreiben. Die Demo zeigt diese Abweichung selbst. Beim Commit acc5a89 nannte der Bericht den Quellstand 8b88bda und 41 bestandene Tests. Unter main, mit Stand vom 12. Oktober 2026, nennt er den Commit 42528d9, den Tree-Hash 5aa96ec5487c957c und 50 bestandene Tests. Die Abdeckung blieb mit 49/49 Anweisungen und 20/20 Verzweigungen unverändert.

Drei Regeln gegen Manipulation halten den Bericht verlässlich. Die Skill-Datei formuliert sie absolut. Schwächen Sie niemals einen Test, damit er bestanden wird: keine verallgemeinerten Assertions und keine erhöhten Toleranzen. Ändern Sie niemals einen Test und die Implementierung im selben Schritt, um einen grünen Status zu erreichen. Eine gleichzeitige Änderung verbirgt, welche Seite fehlerhaft war. Berichten Sie niemals über eine Schicht, die nicht ausgeführt wurde: „übersprungen, kein Tool verfügbar, stattdessen manuelle Mutation“ erhält das Vertrauen. Ein erfundenes Ergebnis zerstört das gesamte Verfahren.

Installieren Sie den Skill und fixieren Sie den installierten Commit

Das Repository ist AmazingAng/old-coder und steht unter der MIT-Lizenz. Die README enthält eine einzeilige Installation über die skills CLI. Der Befehl nennt den Skill, weil das Repository inzwischen auch einen zweiten Skill, old-coder-api, für das Design von HTTP- und JSON-APIs enthält:

npx skills add https://github.com/amazingang/old-coder --skill old-coder

Damit wird die Version installiert, die main zum Zeitpunkt der Ausführung enthält. Auch die CLI selbst wird weiterentwickelt. Prüfen Sie, wo die Dateien abgelegt wurden, bevor Sie annehmen, dass der Skill aktiv ist:

ls ~/.claude/skills/old-coder/

Sie sollten SKILL.md und ein Verzeichnis references/ sehen. Wenn dort nichts vorhanden ist, befindet sich der Skill nicht an dem Ort, an dem Claude Code danach sucht. Die skills CLI installiert pro Agent: Der globale Pfad von Claude Code ist ~/.claude/skills/. ~/.agents/skills/ gehört dagegen zu anderen Agents wie Codex. Ein Skill, der nur dort abgelegt wurde, liegt zwar auf der Festplatte, wird von Claude Code aber nicht geladen. Mit npx skills@latest add ... verwenden Sie keine veraltete zwischengespeicherte Version der CLI.

Bevorzugen Sie den manuellen Weg, weil Sie damit dokumentieren können, was Sie installiert haben:

git clone https://github.com/AmazingAng/old-coder.git
cd old-coder
git checkout acc5a89
git rev-parse HEAD
mkdir -p ~/.claude/skills
cp -r skills/old-coder ~/.claude/skills/

acc5a89 war am 17 August 2026 der aktuelle Stand von main. main wurde seitdem auf a0eb529 aktualisiert, das am 18 August 2026 und weiterhin am 12 October 2026 der aktuelle Stand war. Wählen Sie einen eigenen Commit und dokumentieren Sie ihn. Das Repository wird aktiv weiterentwickelt. Die Referenz für die Testsuite, die Vorlagen und das Protokoll des Verifiers wurden bereits auf andere Dateien verteilt. Wenn Ihre EVIDENCE-Berichte nicht angeben, welche Skill-Version sie bewertet hat, können Sie eine Änderung in Ihrem Code nicht von einer Änderung der Regeln unterscheiden. Speichern Sie diesen Commit-Hash neben der SPEC im selben Repository wie den Code, für den sie gilt.

Bei einem Agent, der ~/.claude/skills nicht liest, fügen Sie skills/old-coder/SKILL.md und skills/old-coder/references/gauntlet.md in dessen System-Prompt oder Regeldatei ein. Das ist die vollständige Integration.

Was innerhalb des Gauntlets ausgeführt wird

Der Gauntlet ist ein Stapel von Schichten, die ausgeführt werden, sobald das Verhalten jeder Spezifikation erfolgreich ist. Die Skill benennt diese Schichten:

• Die vollständige Testsuite für Regressionen. Es darf keine neuen Fehler geben. Bereits vorhandene Fehler werden zuvor als Baseline erfasst.
• Statische Typprüfung sowie Linting und Formatprüfung für ganze Fehlerklassen und gegen Abweichungen.
• Coverage der geänderten Zeilen. Bei Unterschreitung des Schwellenwerts muss der Prozess mit einem Fehlercode beendet werden.
• Mutation Testing für Tests, die nichts verifizieren.
• Property-based Tests für Grenzfälle, die niemand bedacht hat.
• Ein Komplexitätsbudget, eine echte Ausführung des eigentlichen Programms, ein Scan der Software-Lieferkette und auf Secrets sowie ein Lauf zur Prüfung der Testsuite in zufälliger Reihenfolge.
• Domänenspezifische Schichten, die anhand des Risikos der Aufgabe ausgewählt werden: Stresstests für Nebenläufigkeit, API-Kompatibilität, Rollback-Probeläufe und Latenz-Benchmarks.

Die Demo bindet diese Schichten in einem Skript, demo-rate-limiter/tools/gauntlet.sh, gegen eine in requirements-dev.txt festgelegte Toolchain ein: pytest, pytest-cov, coverage, hypothesis, mypy, ruff, pip-audit und pytest-randomly. Jedes Paket ist auf eine exakte Version festgelegt (pytest 9.1.1, ruff 0.16.0, Stand Oktober 2026). Führen Sie das Skript aus:

cd demo-rate-limiter
python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
./tools/gauntlet.sh

Das Skript gibt pro Schicht ein Banner aus, beispielsweise === tests + coverage === und === mutation ===, und endet mit === gauntlet: all layers green ===. Es wird unter set -e ausgeführt. Daher beendet die erste fehlerhafte Schicht das Skript, und das abschließende Banner wird nicht ausgegeben. Das abschließende Banner ist die Prüfung: Es bedeutet, dass jede darüber aufgeführte Schicht mit Exit-Code 0 beendet wurde. So liest sich das Skript unter acc5a89. Unter dem aktuellen main wird jede Schicht über einen run_layer-Helper ausgeführt. Dadurch enthalten die Banner die ID der Schicht, beispielsweise === tests-coverage ===. Außerdem schlägt ein abschließender Schritt den Lauf fehl, wenn eine erwartete Schicht nie ausgeführt wurde. Eine übersprungene Schicht kann dadurch nicht mehr unbemerkt erfolgreich durchlaufen.

Ein Detail dieses Skripts sollten Sie in Ihre eigenen Skripte übernehmen. Die Coverage-Schicht ist so geschrieben:

pytest -q --cov=ratelimiter --cov-report=term-missing --cov-fail-under=100

Ohne --cov-fail-under gibt pytest --cov einen Prozentsatz aus und beendet sich mit Exit-Code 0, unabhängig davon, wie weit die Coverage gesunken ist. Das ist eine Fail-open-Schicht in einem Skript, dessen erste Zeile verspricht, beim ersten Fehler anzuhalten. Eine Gauntlet-Schicht, die nicht fehlschlagen kann, ist reine Dekoration.

Was Mutationstests gegenüber Coverage zusätzlich leisten

Coverage beantwortet eine Frage: Wurde diese Zeile von der Testsuite ausgeführt? Die entscheidende Frage beantwortet Coverage jedoch nicht: Wäre eine Assertion fehlgeschlagen, wenn die Zeile fehlerhaft gewesen wäre? Ein Test, der eine Funktion aufruft und nichts prüft, meldet für jede berührte Zeile vollständige Coverage. Coverage erkennt nicht getesteten Code. Sie erkennt keine Tests, die nichts testen.

Mutationstests beantworten die zweite Frage direkt. Der Code wird absichtlich geändert, jeweils mit einer kleinen Änderung, und die Testsuite wird erneut ausgeführt. Schlägt die Testsuite fehl, ist das Mutant getötet. Das bedeutet, dass eine Assertion dieses Verhalten geprüft hat. Läuft die Testsuite weiterhin erfolgreich durch, hat der Mutant überlebt: Die Zeile wurde ausgeführt, aber das Ergebnis wurde nicht geprüft.

Die Demo erledigt dies mit tools/mutants.py. Das Tool fügt in src/ratelimiter/__init__.py nummerierte Einzeländerungen ein, führt nach jeder Änderung pytest aus und stellt die Datei anschließend wieder her. Die Änderungen entsprechen den Fehlern, die einem müden Menschen passieren: >= wird zu >, oder ein Rückgabewert wird verworfen.

Die Kill-Regel in diesem Runner ist der Punkt, den die meisten selbst geschriebenen Mutationstests falsch implementieren. Nur der Exit-Code 1 von pytest zählt als Kill, weil 1 bedeutet, dass die Tests ausgeführt wurden und mindestens einer fehlgeschlagen ist. Exit-Code 0 bedeutet, dass der Mutant überlebt hat. Jeder andere Wert, etwa ein Fehler beim Einsammeln der Tests oder gar keine eingesammelten Tests, bedeutet, dass nichts verifiziert wurde, und darf nicht gezählt werden. Ein Skript, das jeden „nonzero“-Wert als Kill behandelt, wertet seine eigenen Abstürze als Erfolge. Diese Zahl kann dann nur noch steigen.

In derselben Datei stehen zwei weitere wichtige Details. Der Mutant M11 fehlt in der Liste, weil er äquivalent ist: Wenn statt aller abgelaufenen Einträge nur ein abgelaufener Eintrag entfernt wird, ist das beobachtbare Verhalten bei einer monotonen Uhr identisch. Daher kann kein Test diesen Mutanten jemals töten. Außerdem setzt der Runner PYTHONDONTWRITEBYTECODE=1, während das Testverfahren zuvor jedes __pycache__ löscht. Zwei Mutanten mit identischer Größe, die in derselben Sekunde geschrieben werden, können denselben gecachten .pyc verwenden. Dann übernimmt der zweite Mutant das Ergebnis des ersten.

Aus diesem Grund führt das Testverfahren vor dem eigentlichen Mutationstest eine Negativkontrolle aus:

.venv/bin/python tools/mutants.py --negative-control
.venv/bin/python tools/mutants.py

Die Kontrolle führt zwei Mutanten unter einem festgelegten Änderungszeitpunkt aus: einen, der getötet werden muss, und einen strikt äquivalenten, der überleben muss. Werden beide als getötet gemeldet, ist der Bytecode-Cache zwischen den Durchläufen durchgesickert. Dann sind alle Kill-Zähler im Bericht zu hoch. Dadurch wird die Regel dieses Skills zu Prüfprogrammen konkret. pytest und mypy haben ihr Fehlerverhalten über viele Jahre bewiesen. Ein Skript, das Sie letzte Woche geschrieben haben, hat das noch nicht. Weisen Sie daher nach, dass es fehlschlagen kann, bevor Sie ihm bei einem erfolgreichen Durchlauf vertrauen, und dokumentieren Sie diesen Nachweis in EVIDENCE.

[
  {
    "label": "Scenario tests",
    "mutants_killed": 22,
    "mutants_run": 22
  },
  {
    "label": "Property tests",
    "mutants_killed": 3,
    "mutants_run": 22
  }
]

Der EVIDENCE-Bericht der Demo zeigt, warum eine einzelne aggregierte Zahl weiterhin wichtige Informationen verbirgt. Die Szenario-Testsuite tötete 22 von 22 Mutanten. Die eigenschaftsbasierten Tests wurden allein gegen dieselben Mutanten erneut ausgeführt und töteten 3. Ein Kill wird dem Test zugerechnet, der zuerst fehlschlägt. Daher bestätigt ein perfektes Gesamtergebnis die Testsuite als Ganzes, sagt aber nichts über eine einzelne darin enthaltene Ebene aus. Diese Eigenschaften sind weiterhin sinnvoll, weil sie Eingabeformen erkennen, die niemand einzeln aufgelistet hat. Sie tragen jedoch nicht die Hauptlast bei der Korrektheitsprüfung. Das erfahren Sie nur, wenn Sie jede Ebene für sich messen.

Führen Sie die vollständige Prüfung auf einem Server aus, nicht auf Ihrem Laptop

Ein EVIDENCE-Bericht ist eine Behauptung, dass bestimmte Befehle bestimmte Zahlen erzeugt haben. Diese Behauptung ist nur überprüfbar, wenn jemand anderes dieselben Zahlen erzeugen kann. Ein Laptop ist dafür der ungeeignetste Ort. Ihre Python-Version stammt aus einem anderen Patch-Release, und Ihre PATH enthält Werkzeuge, die auf dem nächsten Rechner möglicherweise fehlen. Mutationstests verschärfen das Problem, weil die gesamte Testsuite einmal pro Mutant erneut ausgeführt wird. Allein die Liste der Demo bedeutet daher 22 zusätzliche Testläufe.

Führen Sie das Ganze in einem Container auf einem VPS aus. Der Container legt Betriebssystem und Interpreter fest. Das angeheftete requirements-dev.txt legt die Werkzeuge fest. Der VPS stellt einen Rechner bereit, auf dem nicht gleichzeitig Ihr Browser läuft.

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends \
      python3 python3-venv git ca-certificates \
 && rm -rf /var/lib/apt/lists/*
WORKDIR /work

docker build -t gauntlet:24.04 .
docker run --rm -v "$PWD:/work" -w /work/demo-rate-limiter gauntlet:24.04 \
  sh -c 'python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e . && ./tools/gauntlet.sh'

Ein erfolgreicher Lauf endet mit === gauntlet: all layers green ===. Zwei Schritte benötigen eine ausgehende Netzwerkverbindung: die Installation der angehefteten Werkzeuge mit pip und die pip-audit-Schicht. Sie prüft Ihre Abhängigkeiten über einen Dienst auf bekannte Sicherheitslücken. Bei einem Offline-Lauf wird diese Schicht nicht stillschweigend übersprungen. Der Lauf schlägt fehl. Das ist das gewünschte Verhalten für ein Gate.

Für einen Lauf bei jedem Push wird dasselbe Skript zu einem CI-Jobschritt. Das Repository führt seine eigene vollständige Prüfung mit GitHub Actions auf ubuntu-latest und mit Python 3.12 aus. Ausgelöst wird sie durch Pushes auf main und durch Pull Requests. Setzen Sie runs-on auf einen selbst gehosteten Runner. Dann wird der Job stattdessen auf Ihrem VPS ausgeführt. Lassen Sie den Trigger für pull_request weg, wenn Sie Folgendes ausführen:

name: gauntlet
on:
  push:
    branches: [main]
jobs:
  gauntlet:
    runs-on: self-hosted
    defaults:
      run:
        working-directory: demo-rate-limiter
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: python -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
      - run: ./tools/gauntlet.sh

Behalten Sie den Trigger für Pushes auf Branches bei, die Sie kontrollieren. Ein selbst gehosteter Runner, der auch Pull Requests aus Forks erstellt, führt fremden Code mit den Zugangsdaten Ihres Runners auf Ihrem Server aus. Dieselbe Überlegung gilt für den Agent selbst: Geben Sie ihm eine verworfene VM, die Sie löschen können, statt Ihrer Workstation. Wenn das Ergebnis der vollständigen Prüfung dort ankommen soll, wo die Änderung besprochen wird, binden Sie es in einen selbst gehosteten PR-Review-Agenten ein.

Wo dieser Ansatz scheitert

Der erste Fehler ist struktureller Natur, und kein Tool kann ihn beseitigen. Die Prüfkette macht die in Ihrer SPEC festgelegten Einschränkungen als ausführbare Nachweise sichtbar. Sie kann nicht feststellen, ob die SPEC korrekt war. Genehmigen Sie eine SPEC, die eine falsche Anforderung festschreibt, erhalten Sie einen fehlerfreien EVIDENCE-Bericht für das falsche Programm: vollständige Abdeckung, jeder Mutant erkannt, jede Ebene grün und Software, die etwas anderes tut als von Ihnen beabsichtigt. Jede Stunde, die Sie dadurch sparen, dass Sie den Diff nicht lesen, sollten Sie in das Lesen der SPEC investieren.

Das zweite Problem sind die Prüfprogramme. Das Repository dokumentiert dies in seiner eigenen Nachweisdatei offen. Das unabhängige Verifizierungsprotokoll durchlief sechs Runden. Die sechste Runde gab failed zurück. Nach dieser Runde vorgenommene Korrekturen wurden nie erneut verifiziert. Deshalb wurde der ausgelieferte Stand nicht durchgängig verifiziert. Eine Shell-Lint-Ebene ist als nicht verfügbar und nicht als erfolgreich protokolliert. Frühere Runden fanden echte Verhaltensfehler und einen unsicheren Mutation Runner, obwohl die darüberliegenden Zustände bereits grün gemeldet hatten. Eine grüne Prüfkette weist ihre eigene Korrektheit nicht nach.

Das dritte Problem ist der Umfang. Eine manuell erstellte Mutantenliste deckt nur die Fehler ab, die jemand gezielt einbauen wollte. Jeder äquivalente Mutant, der aus dieser Liste entfernt wurde, beruht auf einer Einschätzung, der Sie vertrauen müssen. Standardtools für Mutationstests (mutmut, cosmic-ray, Stryker, PIT) erzeugen Mutanten systematisch und sind die bessere Voreinstellung, sofern für Ihre Sprache ein solches Tool verfügbar ist.

Den Aufwand am Risiko ausrichten

Das Skill definiert drei Stufen und erwartet, dass der Agent angibt, für welche Stufe er sich entschieden hat.

• Stufe 1, trivial: ein Tippfehler, ein Kommentar oder ein Konfigurationswert. Die vollständige Test-Suite plus Lint ausführen, keine neuen Tests hinzufügen und in einem Satz begründen, warum keine benötigt wurden.
• Stufe 2, normal: eine Fehlerbehebung oder ein kleines Feature. Den vollständigen Ablauf ausführen. Eine Fehlerbehebung muss mit einem fehlschlagenden Test beginnen, der den Fehler reproduziert. So wird aus dem gestrigen Fehler ein Regressionstest für morgen.
• Stufe 3, kritisch: Geld, Authentifizierung, Datenverlust, Nebenläufigkeit oder eine öffentliche API. Mit einem Fehlermodell beginnen, das die möglichen Schadensarten dieser Änderung auflistet. Für jeden Modus eine zusätzliche Testschicht hinzufügen. Danach den vollständigen Ablauf sowie Property-Tests, Mutationstests und einen expliziten Durchlauf mit feindseligen Eingaben ausführen, der die Implementierung angreift.

Zu Stufe 3 gehört außerdem ein experimenteller Schritt. Ein zweiter Agent mit einem frischen Kontext erhält nur den Aufgabenvertrag, die freigegebene SPEC und den Quellcodezustand. Er versucht, die fertige Arbeit zu brechen, bevor EVIDENCE signiert wird. Er behebt nichts, sondern berichtet seine Ergebnisse. Ein Mensch bewertet diese anschließend. Dadurch wird die Korrelation reduziert, die durch einen gemeinsamen Aufgabenkontext entsteht. Die Korrelation durch ein gemeinsames Modell wird dadurch nicht reduziert.

Wenn Sie lieber selbst etwas in dieser Form erstellen möchten, beschreibt Ihr eigenes Agent-Skill schreiben den Dateiaufbau und das Beschreibungsfeld, das festlegt, wann der Agent das Skill lädt.

FAQ

Was erkennt Mutation Testing, was die Codeabdeckung nicht erkennt?

Die Codeabdeckung erfasst, dass eine Zeile ausgeführt wurde. Sie kann nicht erfassen, ob eine Assertion fehlgeschlagen wäre, wenn diese Zeile fehlerhaft wäre. Deshalb meldet auch ein Test, der eine Funktion aufruft und nichts prüft, eine vollständige Abdeckung. Mutation Testing ändert den Code absichtlich, jeweils mit einer Änderung, und führt die Testsuite erneut aus. Ein überlebender Mutant bedeutet, dass die Zeile ausgeführt wurde, aber niemand das Ergebnis überprüft hat. Deshalb führt die Anleitung „nie Abdeckungswerte verfolgen“ als verbindliche Regel auf und nennt Mutation Testing als die Ebene, die das Ausnutzen von Abdeckungswerten erkennt.

Muss ich den Code, den mein Agent schreibt, weiterhin lesen?

In diesem Workflow lesen Sie vor dem Programmieren die SPEC und danach den EVIDENCE-Bericht. Sie prüfen den Bericht stichprobenartig, indem Sie die darin genannten Befehle erneut ausführen. Der Diff ist optional. Der Nachteil ist, dass Ihr gesamtes Urteil nun auf einem Dokument basiert. Eine SPEC mit einer falschen Anforderung erzeugt eine grüne Prüfstrecke für ein Programm, das Sie nicht wollten. Verwenden Sie die eingesparte Zeit für die SPEC.

Kann ich die Old Coder-Prüfstrecke in CI auf meinem eigenen Server ausführen?

Ja. Dort ist sie besser aufgehoben. Installieren Sie die festgelegte Toolchain aus requirements-dev.txt in einem Container und führen Sie das Prüfskript des Projekts als einen Job-Schritt aus. Setzen Sie bei GitHub Actions runs-on: self-hosted und registrieren Sie einen Runner auf Ihrem VPS. Beschränken Sie den Trigger auf Pushes in Branches, die Sie kontrollieren. Ein selbst gehosteter Runner, der Pull Requests aus Forks erstellt, führt nicht vertrauenswürdigen Code mit den Zugangsdaten Ihres Runners aus.

Welche Version der Anleitung sollte ich installieren?

Legen Sie eine Version fest. Das Repository wird aktiv weiterentwickelt. Die Referenzdateien wurden bereits aufgeteilt und verschoben. Daher kann ein im letzten Monat erstellter Bericht nach anderen Regeln bewertet worden sein. Klonen Sie das Repository, wechseln Sie zu einem bestimmten Commit, kopieren Sie skills/old-coder nach ~/.claude/skills/ und speichern Sie den Hash dieses Commits neben Ihrer SPEC. Dann bedeutet eine Änderung Ihrer Nachweise auch eine Änderung Ihres Codes.