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 Skill-Datei verlangt, dass jedes spezifizierte Verhalten dem Test zugeordnet wird, der es überprüft, dass für jede ausgeführte Gauntlet-Ebene der verwendete Befehl und das tatsächliche Ergebnis angegeben werden, dass jede Zahl aus einem neuen Lauf nach der letzten Codeänderung stammt und dass jede übersprungene Ebene mit ihrer Begründung aufgeführt wird. Adjektive sind keine Belege. „Alle 41 Tests bestanden, Abdeckung 49/49 Anweisungen“ ist ein Ergebnis. „Gut getestet“ ist es nicht.

Der Demo-Bericht im Repository, demo-rate-limiter/evidence.md, kennzeichnet seinen Quellstand durch einen Commit und einen sha256-Tree-Hash. Diese Zeile ist wichtiger, als es zunächst scheint, denn sie zeigt, welche exakten Bytes diese Zahlen erzeugt haben. Ohne diese Angabe kann ein Bericht unbemerkt einen Arbeitsstand beschreiben, den es nicht mehr gibt.

Drei Regeln gegen Manipulation halten den Bericht belastbar, und die Skill-Datei formuliert sie absolut. Schwächen Sie niemals einen Test, damit er besteht: keine erweiterten Assertions und keine erhöhten Toleranzen. Ändern Sie niemals in demselben Schritt einen Test und die Implementierung, um den grünen Status zu erreichen, denn eine gleichzeitige Änderung verbirgt, welcher Teil falsch war. Berichten Sie niemals über eine Ebene, die nicht ausgeführt wurde: „übersprungen, kein Tool verfügbar, stattdessen manuelle Mutation“ erhält das Vertrauen, während ein erfundenes Ergebnis das gesamte Verfahren unbrauchbar macht.

Installieren Sie das Skill und pinnen Sie den installierten Commit

Das Repository ist AmazingAng/old-coder und unter der MIT-Lizenz veröffentlicht. Die README enthält eine einzeilige Installation über die skills CLI:

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

Damit wird die Version installiert, die main zum Ausführungszeitpunkt enthält. Auch die CLI selbst kann sich ändern. Prüfen Sie, wo die Dateien abgelegt wurden, bevor Sie davon ausgehen, dass das Skill aktiv ist:

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

Sie sollten SKILL.md und ein Verzeichnis references/ sehen. Wenn dort nichts vorhanden ist, befindet sich das Skill nicht an dem Ort, an dem Claude Code danach sucht. Ältere Versionen der skills CLI schrieben nach ~/.agents/skills/, ohne das Ergebnis mit ~/.claude/skills/ zu verknüpfen. Die Dateien waren dann zwar auf der Festplatte vorhanden, aber der Agent lud sie nicht. Mit npx skills@latest add ... vermeiden Sie den Fall einer veralteten 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. Wählen Sie einen eigenen Commit und notieren Sie ihn. Das Repository wird aktiv weiterentwickelt. Die Referenz für die Gauntlet-Prüfung, die Vorlagen und das Verifier-Protokoll wurden bereits zwischen Dateien verschoben. Wenn Ihre EVIDENCE-Berichte nicht angeben, welche Version des Skills sie bewertet hat, können Sie eine Änderung in Ihrem Code nicht von einer Änderung der Regeln unterscheiden. Speichern Sie den Commit-Hash neben der SPEC im selben Repository wie den Code, für den sie gilt.

Wenn ein Agent ~/.claude/skills nicht liest, fügen Sie skills/old-coder/SKILL.md und skills/old-coder/references/gauntlet.md seiner Systemaufforderung oder Regeldatei hinzu. Das ist die vollständige Integration.

Was innerhalb des Gauntlets ausgeführt wird

Der Gauntlet besteht aus mehreren Schichten und wird einmal ausgeführt, sobald jedes Spec-Verhalten erfolgreich ist. Das Skill bezeichnet diese Schichten wie folgt:

• Die vollständige Testsuite zur Erkennung von Regressionen. Es dürfen keine neuen Fehler auftreten. Bereits vorhandene Fehler müssen zuvor als Baseline erfasst werden.
• 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 Befehl mit einem Fehlercode ungleich 0 beendet werden.
• Mutation Testing für Tests, die nichts prüfen.
• Property-based Tests für Grenzfälle, die niemand vorhergesehen hat.
• Ein Komplexitätsbudget, eine echte Ausführung des tatsächlichen Programms, ein Scan der Software-Lieferkette und von Secrets sowie ein Lauf zur Prüfung der Suite-Gesundheit in zufälliger Reihenfolge.
• Domänenspezifische Schichten, die anhand des Risikos der Aufgabe ausgewählt werden: Stresstests für Nebenläufigkeit, API-Kompatibilität, eine Rollback-Probe und Latenz-Benchmarks.

Die Demo führt diese Prüfungen in einem Skript, demo-rate-limiter/tools/gauntlet.sh, zusammen und verwendet dafür eine in requirements-dev.txt festgelegte Toolchain: pytest, pytest-cov, coverage, hypothesis, mypy, ruff, pip-audit und pytest-randomly. Jedes Tool ist auf eine exakte Version festgelegt (pytest 9.1.1, ruff 0.16.0, Stand August 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 für jede Schicht ein Banner aus, beispielsweise === tests + coverage === und === mutation ===, und endet mit === gauntlet: all layers green ===. Es läuft unter set -e. Daher wird es beim ersten fehlerhaften Layer beendet, und das abschließende Banner wird nicht ausgegeben. Das abschließende Banner ist die Prüfung: Es bedeutet, dass jede darüberliegende Schicht mit dem Exit-Code 0 beendet wurde.

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

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

Ohne --cov-fail-under gibt pytest --cov einen Prozentsatz aus und wird mit dem Exit-Code 0 beendet, unabhängig davon, wie stark die Coverage gefallen 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 nur 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 lässt sich nur prüfen, wenn jemand anderes dieselben Zahlen erzeugen kann. Ein Laptop ist dafür der ungünstigste Ort. Ihre Python-Version ist ein anderes Patch-Release, und Ihr PATH enthält Werkzeuge, die auf dem nächsten Rechner möglicherweise fehlen. Mutation Testing verschärft das Problem, weil die gesamte Testsuite für jeden Mutanten erneut ausgeführt wird. Schon die Liste der Demo bedeutet daher 22 zusätzliche Durchläufe der Testsuite.

Führen Sie die Prüfung in einem Container auf einem VPS aus. Der Container legt das Betriebssystem und den Interpreter fest. Das gepinnte 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 ===. Für zwei Schritte ist eine ausgehende Netzwerkverbindung erforderlich: für die Installation der gepinnten Werkzeuge mit pip und für die Ebene pip-audit, die Ihre Abhängigkeiten anhand eines Dienstes zur Prüfung auf Schwachstellen kontrolliert. Bei einem Offline-Lauf wird diese Ebene nicht stillschweigend übersprungen. Der Lauf schlägt fehl. Genau dieses Verhalten soll ein Gate zeigen.

Für einen Lauf bei jedem Push wird dasselbe Skript zu einem CI-Job-Schritt. Das Repository führt seine eigene vollständige Prüfung mit GitHub Actions auf ubuntu-latest und mit Python 3.12 aus. Verweisen Sie runs-on auf einen selbst gehosteten Runner. Dann wird der Job stattdessen auf Ihrem VPS ausgeführt:

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

Beschränken Sie den Trigger auf Pushes in Branches, die Sie kontrollieren. Ein selbst gehosteter Runner, der zusätzlich Pull Requests aus Forks erstellt, führt fremden Code mit den Zugangsdaten Ihres Runners auf Ihrem Server aus. Dasselbe gilt für den Agent selbst: Geben Sie ihm eine temporäre VM, die Sie löschen können, statt Ihrer Arbeitsstation. Wenn das Ergebnis der Prüfung dort erscheinen 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.