Codex vs. Claude-Code: Welches Codierungswerkzeug passt zu Ihrem Arbeitsablauf?

Bei „Codex vs. Claude“ geht es weniger darum, einen universellen Sieger zu finden, sondern vielmehr darum, den Arbeitsstil zu wählen, auf den Sie sich jeden Tag verlassen können. Beide Produkte können ein Repository überprüfen, mehrere Dateien bearbeiten, Befehle ausführen, Tests durchführen und einen Patch erläutern. Die wesentlichen Unterschiede zeigen sich darin, wie Sie Aufgaben delegieren, wie oft Sie den Agenten steuern, wie viele Daten Sie einsehen können und wie gut sich die jeweiligen Tools in Ihre bestehende Entwicklungsumgebung einfügen.

In unserem kontrollierten Repository-Test mit vier Aufgaben erzielte Codex 98 von 100 Punkten und Claude Code 99 von 100 Punkten. Beide haben die Kernaufgaben bewältigt. Claude Code zeigte eine umfassendere Überprüfung und eine bessere Abdeckung von Randfällen, während Codex in unserem Setup das erforderliche Ergebnis oft mit einem geringeren Umfang erreichte und überzeugendere Nachweise auf Ausführungsebene lieferte. Ein Punkt Unterschied bei einem kleinen Python-Testfall ist kein Grund, einen allgemeinen Sieger zu erklären.

Entwickler, die nicht möchten, dass der Rest ihres Workflows an einen bestimmten Programmier-Agenten gebunden ist, können GlobalGPT als separate multimodale und multimodellfähige Ebene hinzufügen. GlobalGPT integriert über 100 Top-Modelle wie GPT 5.6, Claude Opus 5 und GPT Image 2 in einem Dashboard. Darüber hinaus bietet das GlobalGPT-Befehlszeilenschnittstelle, MCP- und Skill-Routen können aus dem Codex oder dem Claude-Code für Zweitmeinungen, Planung, Dokumentation oder andere unterstützte Modelle genutzt werden, während der native Coding-Host die Kontrolle über Repository-Bearbeitungen und Tests behält.

Probieren Sie über 100 Top-Modelle auf GlobalGPT aus

Der Vergleich vereint offizielle Planinformationen, praktische Erfahrungen mit Repositorys, umfassende, erweiterbare Ergebnisse und klar beschriebene Community-Erfahrungen. Ziel ist es, einem unabhängigen Entwickler bei der Auswahl einer primären Programmierplattform zu helfen, ohne dass er sich durch Abonnementzugänge, zusätzliche Gutschriften und API-Abrechnungen verwirren lässt.

Codex vs. Claude – Der Code auf einen Blick

Die Tabelle beschreibt eine Kaufentscheidung und stellt keine Rangliste der Modelle dar. Eine andere Modelleinstellung, ein anderes Repository, eine andere Berechtigungskonfiguration oder eine andere Aufgabenspezifikation kann das Ergebnis verändern. Wenn Sie bereits ein Produkt verwenden, ist der beste Vergleich eine abgegrenzte Aufgabe aus Ihrer eigenen Codebasis mit demselben Erfolgsbefehl und ohne Qualitätswiederholungen.

Was Codex und der Claude-Code eigentlich sind

„Codex“ und „Claude Code“ sind Produktbezeichnungen und nicht bloß Modellbezeichnungen. Die zugrunde liegenden KI-Modell für die Programmierung Das ist zwar wichtig, aber das umgebende Framework entscheidet auch darüber, welche Dateien der Agent einsehen kann, welche Befehle er ausführen darf, wie Genehmigungen funktionieren, wie der Kontext beibehalten wird und welche Nachweise nach Abschluss der Aufgabe erhalten bleiben. Wenn man nur die Reputation des Modells vergleicht, lässt man einen Großteil der Erfahrung außer Acht, die ein Entwickler damit erwirbt.

Codex deckt Arbeitsabläufe über die Befehlszeile, in der IDE, auf dem Desktop sowie in der Cloud ab. Dank dieser Bandbreite eignet es sich sowohl für die direkte lokale Zusammenarbeit als auch für eine stärker abgegrenzte Aufgabenverteilung. Claude Code basiert auf einem dialogorientierten Terminal-Workflow mit unterstützten Integrationen und umfangreichen Anpassungsmöglichkeiten; dies Anleitung zur Verwendung von Claude für die Programmierung bietet eine umfassendere Einführung in diesen Arbeitsablauf. Für manche Entwickler ist es beruhigend, einem Agenten bei der Arbeit im Terminal zuzusehen. Für andere sind der abschließende Diff, die Tests und der Prüfpfad das wichtige Ergebnis – und nicht der fortlaufende Austausch.

Diese Unterscheidung erklärt auch, warum zwei Tests, bei denen nominell leistungsstarke Modelle zum Einsatz kommen, zu unterschiedlichen Ergebnissen führen können. Der Host entscheidet, wie Anweisungen dargestellt werden, wie Tools aufgerufen werden und wann ein Mensch eine Aktion genehmigen muss. Vergleiche innerhalb der Community, die den Testrahmen außer Acht lassen, können das Verhalten auf Produktebene fälschlicherweise für die Wahrheit auf Modellebene halten.

• Das Modell bietet Denkvermögen und die Fähigkeit zur Ideenfindung.
• Der Agenten-Kabelbaum steuert Dateien, Befehle, den Kontext, Genehmigungen und die Wiederherstellung.
• Der Aufgabenvertrag des Benutzers legt den Umfang, die Erfolgsprüfungen und den Zeitpunkt fest, zu dem der Agent aufhören soll.

Arbeitsablauf und Steuerung: Delegation oder kontinuierliche Steuerung?

Die sinnvollste Frage zum Thema “Codex vs. Claude-Code” lautet oft nicht “Welcher Ansatz führt zu besserem Code?”, sondern „Wie möchte ich damit arbeiten?“ Eine klar definierte, abgegrenzte Aufgabe lässt sich mit einem genauen Ziel, einem festgelegten Umfang und einer Überprüfungsanweisung delegieren. Bei einer mehrdeutigen Refaktorisierung sind Diskussionen, Zwischenprüfungen und die Möglichkeit, den Ausführenden umzulenken, bevor er zu viele Änderungen vornimmt, von Vorteil.

Eine kontinuierliche Steuerung ist sinnvoll, wenn sich die Anforderungen weiterentwickeln oder noch über architektonische Entscheidungen verhandelt wird. Sie wird jedoch zu einem Kostenfaktor, wenn der Agent wiederholt Entscheidungen einfordert, die anhand der Anweisungen aus dem Repository hätten geklärt werden können. Eine autonome Ausführung ist sinnvoll, wenn der Aufgabenvertrag stabil ist. Sie wird jedoch riskant, wenn der Agent unüberprüfte Annahmen trifft oder den Umfang erweitert, ohne dass ein klarer Rollback-Pfad vorhanden ist.

Ein ausführlicher Reddit-Bericht vom 13. April 2026 beschrieb etwa 100 Stunden mit Claude Code und 20 Stunden mit Codex bei einem Python- und TypeScript-Projekt mit rund 80.000 Zeilen und etwa 2.800 Tests. Der Autor charakterisierte Claude als schneller und interaktiver, aber mit höherem Betreuungsaufwand verbunden, und Codex als langsamer und bedächtiger. Dieser Bericht ist ungewöhnlich nützlich, da er den Projekt- und Erfahrungshintergrund einbezieht, spiegelt jedoch nach wie vor den Arbeitsablauf eines einzelnen Entwicklers wider.

Unsere eigenen Zeitmessungen ergaben keinen eindeutigen Sieger. Claude bewältigte die ersten beiden Aufgaben schneller, während Codex die beiden letzteren schneller bewältigte. Claude griff zudem auf einen Subagenten als Ausweichlösung zurück, nachdem sein CLI-Authentifizierungspfad nicht verfügbar war, sodass die Ausführungswege nicht laboräquivalent waren. Die zutreffende Schlussfolgerung lautet, dass die Geschwindigkeit von der Aufgabe, dem gewählten Modell, der Aufwandsstufe, dem Kontext und dem Host abhängt – und nicht davon, dass eines der beiden Produkte immer schneller ist.

Verständnis von Repositorien und Kontextmanagement

Das Verständnis eines Repositorys geht über die bloße Benennung von Ordnern hinaus. Ein nützlicher Agent muss nachverfolgen, wie Daten zwischen Dateien fließen, Verträge identifizieren, die eine Änderung einschränken, Tests ausfindig machen, ein Symptom von seiner wahrscheinlichen Ursache unterscheiden und das Risiko einer Bearbeitung der falschen Ebene erläutern. Eine umfassende Übersicht kann verborgene Inkonsistenzen aufdecken; eine prägnante Übersicht kann einen Entwickler schneller zu einer sicheren Implementierungsentscheidung führen.

In unserer schreibgeschützten T1-Aufgabe erzielten beide Agenten 20 von 20 Punkten und stützten ihre Antworten auf das Repository. Claude Code war umfassender und deckte zusätzliche Vertragsinkonsistenzen auf. Codex war kompakter, identifizierte aber dennoch die relevanten Dateien, Risiken und den Implementierungsplan. Keiner der beiden Stile ist automatisch überlegen. Vollständigkeit ist bei ungewohnten Migrationen und Audits hilfreich; Prägnanz ist von Vorteil, wenn der Entwickler die Architektur bereits kennt und einen fokussierten Änderungsplan wünscht.

Architektur: Modell, Repository, Dienst und ein „Unwired Time“-Dienstprogramm.

Wesentliche Risiken: undefinierte Prioritätssemantik, Kompatibilität, Reihenfolge, Validierung und Bereichsinkongruenz.

Drei Schichten plus ein isoliertes Modul. Keine Zyklen; minimale Abhängigkeitsinjektion.

Außerdem traten Probleme bei der Identifikatorzuweisung, asymmetrische Fehlerverträge und eine geringe Testabdeckung zutage.

##-Architektur

Dies ist ein kleines Python-Paket, das ausschließlich auf der Standardbibliothek basiert und vier funktionale Schichten umfasst:

- **Datenmodell:** [`Job`]() ist eine unveränderliche Dataklasse, die `identifier`, `name` und `owner` enthält. `Job.to_dict()` serialisiert sie über `dataclasses.asdict()`.
- **Repository:** [`JobRepository`]() speichert Jobs in einem In-Memory-Dictionary, dessen Schlüssel die Identifikatoren sind. Es gibt keine Datenbank und keine dauerhafte Persistenz.
- **Dienst:** [`SchedulerService`]() ist zuständig für die Zuweisung von Identifikatoren, die Normalisierung von Eingaben sowie das Anlegen, Auflisten und Löschen von Jobs.
- **Zeit-Hilfsfunktion:** [`next_daily_run()`]() berechnet einen Zeitpunkt für den nächsten Lauf, wird jedoch weder von `Job`, `SchedulerService` noch von `JobRepository` importiert oder mit diesen verbunden.
- **Öffentliche API:** [`scheduler.__init__`]() exportiert ausschließlich `SchedulerService`.

Trotz des Repository-Namens enthalten Jobs derzeit keine Planungsinformationen, und es gibt keine Ausführungswarteschlange. Die Priorität kann daher zwar die gespeicherten Metadaten und die Reihenfolge in der Auflistung beeinflussen, hat jedoch keinen Einfluss auf die tatsächliche Jobausführung, ohne das System erheblich zu erweitern.

## Datenfluss bei der Erstellung und Auflistung

Erstellung über `SchedulerService.create_job(name, owner)`:

1. [`create_job()`]() lehnt einen Namen ab, der ausschließlich aus Leerzeichen besteht.
2. Es kürzt `name` und `owner` und erstellt dann mithilfe des `_next_identifier` des Dienstes ein unveränderliches `Job`-Objekt.
3. [`JobRepository.save()`]() schreibt das Objekt in `_jobs[job.identifier]`.
4. Der Dienst erhöht den Wert von `_next_identifier` und gibt denselben `Job` zurück.

Auflistung über `SchedulerService.list_jobs()`:

1. [`list_jobs()`]() delegiert direkt an `repository.all()`.
2. [`JobRepository.all()`]() sortiert die Schlüssel des Wörterbuchs numerisch.
3. Jobs werden daher in aufsteigender Reihenfolge nach Identifikator bzw. Erstellungsdatum zurückgegeben, nicht nach Zeitplan oder Priorität.

## Wahrscheinlich von Job-Prioritäten betroffene Dateien

Erforderlich:

- [`scheduler/models.py`](): Fügen Sie das Feld "priority" und einen eventuellen Standardwert hinzu. `to_dict()` bezieht es automatisch ein, da es `asdict()` verwendet.
- [`scheduler/service.py`](): Priorität annehmen, validieren und an `Job` übergeben.
- [`tests/test_scheduler.py`](): Testfälle für Standard-, explizite, ungültige, serialisierte und Reihenfolge-Verhalten erstellen.

Bedingt:

- [`scheduler/repository.py`](): Ändere `all()` nur, wenn Prioritäten die Reihenfolge der Auflistung steuern sollen. Ein deterministischer Sekundärschlüssel wie `identifier` sollte Gleichstände behandeln.
- [`scheduler/__init__.py`](): Nur aktualisieren, wenn "priority" zu einer öffentlichen Enumeration oder einem Wert-Objekt wird.
- [`README.md`](): Dokumentieren Sie die zulässigen Werte, den Standardwert und die Semantik der Reihenfolge.

Wahrscheinlich nicht betroffen:

- `scheduler/time_rules.py`, da dessen einziges Symbol auf ein übergegebenes Datums- und Zeitformat angewendet wird und keinen Bezug zu Jobs oder der Auflistung hat.

## Wesentliche Risiken

- **Undefinierte Semantik:** Der Code liefert keinen Anhaltspunkt dafür, ob größere oder kleinere Werte eine höhere Priorität bedeuten, welche Werte gültig sind oder ob die Priorität überhaupt Auswirkungen auf die Auflistung hat.
- **Kompatibilität:** Das Hinzufügen eines obligatorischen Arguments zu `Job` oder `create_job()` würde bestehende Aufrufe wie `create_job("Daily report", "Alex")` im aktuellen Test unbrauchbar machen. Ein Standardwert bewahrt diesen Aufruf.
- **Probleme bei der positionsbasierten Konstruktor-Erstellung:** `Job` wird derzeit in `SchedulerService.create_job()` positionsbasiert instanziiert. Die Anordnung der Felder und zukünftige positionsbasierte Aufrufe könnten stillschweigend falsche Werte zuweisen; eine Schlüsselwort-Konstruktion wäre sicherer.
- **Geänderte Reihenfolge:** Das Ersetzen der Identifikatorreihenfolge in `JobRepository.all()` verändert das etablierte Verhalten. Bei gleichen Prioritäten ist ein stabiler Tie-Breaker erforderlich.
- **Mehrdeutigkeit bei der Validierung:** Ein uneingeschränkter Python-Wert könnte Zeichenketten, Boolesche Werte oder beliebige Ganzzahlen zulassen, die sich nur schwer konsistent vergleichen lassen.
- **Diskrepanz im Ausführungsbereich:** Es gibt keinen Dispatcher und keine Ausführungswarteschlange. Die Behauptung, dass die Priorität bestimmt, welcher Job zuerst ausgeführt wird, würde durch kein derzeitiges Symbol unterstützt.
- **Einschränkungen im Arbeitsspeicher:** Die Priorität verschwindet, wie jedes andere Job-Feld auch, wenn der Prozess endet, da `_jobs` lediglich ein Instanz-Dictionary ist.

## Implementierungs- und Validierungsplan

1. Zunächst den Vertrag definieren: Darstellung, zulässige Werte, Standardwert, Richtung der Priorität, Tie-Breaking und ob die Priorität die Reihenfolge in der Liste verändert.
2. Füge `priority` zu `Job` hinzu, vorzugsweise mit einem abwärtskompatiblen Standardwert.
3. Erweitere `SchedulerService.create_job()` um einen Prioritätsparameter mit Standardwert, validiere ihn und erstelle `Job` mit Schlüsselwortargumenten.
4. Falls die Auflistung prioritätsabhängig ist, `JobRepository.all()` so ändern, dass zuerst nach Priorität und dann nach Kennung sortiert wird. Andernfalls die Reihenfolge im Repository unverändert lassen.
5. Tests hinzufügen für:
   – Bestehende Erstellung mit zwei Argumenten.
   – Explizite Beibehaltung der Priorität.
   – Standardpriorität.
   - Ungültige Typen und Werte außerhalb des zulässigen Bereichs.
   - Ausgabe von `Job.to_dict()`.
   - Sortierreihenfolge bei mehreren Prioritäten.
   - Stabile Reihenfolge bei gleichen Prioritäten.
   - Bestehendes Verhalten bei leeren Namen.
6. Aktualisieren Sie die README-Datei mit dem genauen öffentlichen Vertrag.
7. Die komplette Offline-Testsuite mit `python3 -m unittest discover -s tests -v` ausführen.

## Überprüfung durchgeführt

- Baseline-Testsuite: **2 Tests bestanden**.
- Die repositoryweite Symbolsuche hat bestätigt, dass `next_daily_run()` nicht mehr verknüpft ist und keine Symbole mit Priorität vorhanden sind.
- Geänderte Dateien: **keine**.
- Implementierung der Funktion: **nicht durchgeführt**, wie gefordert.

> **Fazit + Entscheidung**
>
> Die Änderung ist geringfügig, wenn die Priorität lediglich Metadaten oder die Reihenfolge in der Auflistung betrifft: hauptsächlich `models.py`, `service.py`, `repository.py` und Tests. Vor der Implementierung muss entschieden werden, ob die Priorität lediglich einen Job beschreibt oder die Reihenfolge in `list_jobs()` verändert, sowie die Werteskala, den Standardwert, die Richtung und die Regel bei Gleichstand.

# T1-Laufprotokoll – Verständnis eines unbekannten Repositorys

## Ausführungsparameter

| Feld | Wert |
| --- | --- |
| Aufgabe | `T1` |
| Festgelegte Eingabeaufforderung | `01-prompts/T1.md` |
| SHA-256 des eingefrorenen Prompts | `a571ff15c2502ec29b172ae2e77dd9ab0caca2869b91f9468d47571434d16c17` |
| Ausführungseinheit | isolierter Claude-Subagent, `general-purpose`, neuer Kontext |
| Isolationsmethode | **Subagent-Fallback** (dokumentiertes Downgrade – siehe `results/isolation-decision.md`) |
| Zugewiesene saubere Kopie | `runtime/workspaces/T1` |
| Claude-Codeversion | `2.1.220` |
| Modelleinstellung | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:31Z` |
| end_utc | `2026-07-28T10:28:32Z` |
| Dauer | 61 s (gleichzeitig mit T2–T4; keine reine Latenzmessung) |
| Versuchsnummer | 1 |
| Status | `valid` |
| Manuelles Eingreifen | keines |

## Zusammenfassung des Safe-Tools

`date`, `find`, `ls`, `wc`, `stat`, `grep`, `Read` auf 7 Dateien im Arbeitsbereich, `python3 -V`,
`python3 -m unittest discover -s tests -v`. Alle Lesevorgänge beschränken sich auf den zugewiesenen Arbeitsbereich.
Kein Netzwerk, keine Installationen, keine Schreibvorgänge.

## Ergebnis der Offline-Prüfung

`python3 -m unittest discover -s tests -v` → 2 Tests, OK (Beendigungscode 0). Von dem
Koordinator außerhalb des Arbeitsbereichs erneut überprüft: siehe `results/checks/T1-public.txt`.

## Patch

Keine. `results/T1/patch.diff` ist leer, und `diff -ru 02-fixture runtime/workspaces/T1`
liefert keine Unterschiede. Die Aufgabe erforderte eine Überprüfung ohne Änderung von Dateien; dies ist
bestätigt und nicht nur behauptet.

## Bereinigte Fehler

Ein behebbarer Shell-Fehler: Ein anfänglicher `grep`-Befehl verwendete nicht in Anführungszeichen gesetzte `--include=*.py`-Muster, die
die Shell zu verallgemeinern versuchte; die erneute Ausführung mit in Anführungszeichen gesetzten Mustern war erfolgreich. Keine Auswirkungen auf die Ergebnisse.

## Sichtbare Ausgabe (wörtlich)

### 1. Was dieses Repository ist

Eine in sich geschlossene Python-Standardbibliotheks-Fixture namens `local-scheduler-1.0.0` (`fixture-manifest.json`), unter MIT-Lizenz, ohne Netzwerk- oder Produktionsabhängigkeiten (`README.md`, `"network_required": false`). Sie ist sehr klein: 8 Quell- und Dokumentationsdateien plus das Manifest, insgesamt 103 Zeilen. Als Interpreter wird **Python 3.9.6** verwendet. Es gibt keine `pyproject.toml`, keine `setup.py`, keine CI-Konfiguration, keinen Linter und keine Typ-Checker-Konfiguration – der einzige deklarierte Workflow ist `python3 -m unittest discover -s tests -v` (`README.md`).

### 2. Architektur

Drei Schichten plus ein eigenständiges Modul, alle unter `scheduler/`:

| Schicht | Datei | Symbol | Aufgabe |
|---|---|---|---|
| Paket-Fassade | `scheduler/__init__.py` | `__all__ = ["SchedulerService"]` | Exportiert nur `SchedulerService` neu; `Job`, `JobRepository` und `time_rules` sind nicht Teil der öffentlichen Schnittstelle |
| Domänenmodell | `scheduler/models.py` | `Job` (`@dataclass(frozen=True)`) | Unveränderliches Wert-Objekt mit den Feldern `identifier: int`, `name: str`, `owner: str` sowie `to_dict()`, implementiert als `asdict(self)` |
| Persistenz | `scheduler/repository.py` | `JobRepository` | In-Memory-`dict` mit dem Identifikator als Schlüssel; `save`, `get`, `all`, `delete` |
| Anwendungsdienst | `scheduler/service.py` | `SchedulerService` | Validierung, Identifikatorzuweisung, Orchestrierung: `create_job`, `list_jobs`, `delete_job` |
| Orphan | `scheduler/time_rules.py` | `next_daily_run` | Wiederholungsberechnung — **wird von nichts importiert** |

Die Abhängigkeitsrichtung ist klar und einseitig: `service.py` importiert aus `.models` und `.repository`; `repository.py` importiert aus `.models`; `models.py` importiert nur `dataclasses`. Keine Zyklen. Abhängigkeitsinjektion ist vorhanden, aber minimal – `SchedulerService.__init__(self, repository=None)` führt `self.repository = repository or JobRepository()` aus, sodass in Tests ein gefälschtes Repository eingesetzt werden kann.

Beachten Sie, dass `scheduler/time_rules.py` heute toter Code ist. Ich habe den gesamten Baum nach `time_rules` und `next_daily_run` durchsucht; die einzigen Treffer sind die eigene Definition und die Auflistung in `expected_files` von `fixture-manifest.json`. Die Datei ist im Lieferumfang enthalten, wird aber nicht verwendet.

### 3. Datenfluss

**Erstellen eines Jobs** — `SchedulerService.create_job(name, owner)`:
1. Überprüfung: `if not name.strip(): raise ValueError('name is required")`. Dies ist die *einzige* Validierung im System – `owner` wird nie überprüft, daher wird ein leerer Eigentümer akzeptiert.
2. Konstruktion: `Job(self._next_identifier, name.strip(), owner.strip())` – positionelle Konstruktion, wobei beide Zeichenfolgen durch Entfernen der Führungen normalisiert werden.
3. Speichern: `self.repository.save(job)`, was `self._jobs[job.identifier] = job` ausführt und den Job zurückgibt.
4. Zähler erhöhen: `self._next_identifier += 1` – *nach* dem Speichern, sodass bei einer ausgelösten Ausnahme der Zähler unberührt bleibt.
5. Die `Job`-Instanz zurückgeben (der Dienst gibt seinen eigenen lokalen `job` zurück, nicht den Rückgabewert des Repositorys).

Die Zuweisung der Identifikatoren erfolgt im **Dienst**, nicht im Repository (`self._next_identifier = 1` in `SchedulerService.__init__`). Dies ist eine wichtige Schnittstelle: Das Einbinden eines Repositorys, das bereits Jobs enthält, überschreibt diese stillschweigend, da der neue Dienst die Nummerierung bei 1 neu beginnt.

**Auflisten von Jobs** – `SchedulerService.list_jobs()` ist ein direkter Durchlauf durch `JobRepository.all()`, der `[self._jobs[key] for key in sorted(self._jobs)]` zurückgibt. Die Sortierung erfolgt daher **aufsteigend nach ganzzahliger Kennung**, was derzeit mit der Einfügungsreihenfolge übereinstimmt. Bei jedem Aufruf wird eine neue Liste erstellt, aber die `Job`-Objekte sind gemeinsam genutzte Referenzen – was nur deshalb sicher ist, weil `Job` eingefroren ist.

**Löschen** — `SchedulerService.delete_job(identifier)` delegiert an `JobRepository.delete`, was `self._jobs.pop(identifier)` ohne Standardwert ist, sodass bei fehlender ID ein `KeyError` ausgelöst wird. Dies steht im Widerspruch zu `JobRepository.get`, das unter derselben Bedingung `None` zurückgibt.

**Testabdeckung dieser Pfade** — `tests/test_scheduler.py` enthält genau zwei Fälle: `test_create_and_list_jobs` (überprüft `job.identifier == 1` und `[job] == service.list_jobs()`) und `test_blank_name_is_rejected`. Beide Fälle werden im aktuellen Baum bestanden.

### 4. Dateien, die wahrscheinlich vom Hinzufügen von Job-Prioritäten betroffen sind

In absteigender Reihenfolge der Wahrscheinlichkeit:

1. **`scheduler/models.py`** — sicher. `Job` benötigt ein `priority`-Feld. Da die Dataklasse `frozen=True` ist und die Felder positionell sind, muss ein neues Feld einen Standardwert enthalten (z. B. `priority: int = 0`) oder es muss hinter den bestehenden drei Feldern platziert werden, da sonst jede bestehende positionelle Konstruktion nicht mehr funktioniert. `to_dict()` erfordert keine Änderung – `asdict(self)` erkennt das Feld automatisch, was eher eine stillschweigende Änderung des Serialisierungsvertrags als eine Codeänderung darstellt.
2. **`scheduler/service.py`** – auf jeden Fall. `create_job` benötigt einen `priority`-Parameter und muss diesen in Zeile 13 an den positionellen Konstruktor `Job(...)` übergeben. Wenn die Priorität validiert wird (Bereich, Zugehörigkeit zu einer Enumeration), gehört die Überprüfung neben die bestehende `name.strip()`-Prüfung. Wenn die Auflistung nach Priorität sortiert werden muss, wäre `list_jobs` der Ort, an dem eine Sortierregel platziert würde, falls das Repository ein "dummer Speicher' bleiben soll.
3. **`scheduler/repository.py`** — wahrscheinlich. `sorted(self._jobs)` in `JobRepository.all()` sortiert die *Schlüssel* des Dicts, d. h. die Identifikatoren. Eine nach Priorität sortierte Auflistung erfordert eine Änderung, um die Werte nach einem Schlüssel wie `(-job.priority, job.identifier)` zu sortieren, oder das Hinzufügen eines separaten sortierten Accessors. Lass den Tie-Break nicht implizit: Die Einfügungsreihenfolge im Dict ist kein stabiler Vertrag, auf den man sich verlassen kann.
4. **`tests/test_scheduler.py`** — sicher. Neue Testfälle für Standardpriorität, explizite Priorität, Reihenfolge und Ablehnung bei ungültiger Priorität. Beachten Sie, dass das vorhandene `assertEqual([job], service.list_jobs())` das *gleiche* Objekt vergleicht und somit auch nach dem Hinzufügen eines Feldes weiterhin gültig ist; dies wäre nicht der Fall, wenn es ein neu erstelltes `Job`-Literal vergleichen würde.
5. **`README.md`** — wahrscheinlich, falls die Prioritätssemantik (welches Ende des Bereichs Vorrang hat, Standardwert) an irgendeiner Stelle angegeben werden muss.
6. **`scheduler/__init__.py`** — nur, wenn eine Prioritäts-Enumeration oder Konstanten neben `SchedulerService` exportiert werden müssen.
7. **`fixture-manifest.json`** — nur, wenn Sie eine neue Moduldatei hinzufügen; das Array `expected_files` ist eine explizite Bestandsliste und würde sich ändern.
8. **`scheduler/time_rules.py`** — sollte *nicht* verändert werden. Die Priorität steht in keinem Zusammenhang mit der Wiederholung, und dieses Modul ist nicht eingebunden.

### 5. Wesentliche Risiken

- **Die Sortiersemantik stellt eine stillschweigende Verhaltensänderung dar.** `JobRepository.all()` garantiert derzeit eine aufsteigende Reihenfolge der Identifikatoren, und `list_jobs` übernimmt diese Reihenfolge. Jeder Verbraucher, der sich auf diese Garantie verlässt, wird durch eine Neusortierung beeinträchtigt. Entscheiden Sie explizit: Ändert `list_jobs()` seine Bedeutung, oder wird daneben eine neue Funktion `list_jobs_by_priority()` eingeführt? Ersteres ist die risikoreichere Option, und der bestehende Test `test_create_and_list_jobs` ist zu schwach, um eine Regression (Liste mit einem einzigen Element) zu erkennen.
- **Die Sortierrichtung ist tatsächlich mehrdeutig.** "Priorität 1" bedeutet in manchen Systemen üblicherweise *höchste* und in anderen *niedrigste*. In diesem Repo gibt es nichts – weder einen Kommentar, noch einen Docstring, noch eine Zeile in der README-Datei –, was dies eindeutig festlegt. Entscheide dich für eine Konvention, dokumentiere sie in `models.py` und implementiere sie in einem Test mit mindestens drei unterschiedlichen Prioritäten, damit die Sortierrichtung eindeutig festgelegt ist.
- **Instabile Sortierung bei Gleichstand.** Wenn zwei Jobs dieselbe Priorität haben, muss das Ergebnis dennoch deterministisch sein. Pythons `sorted` ist stabil, aber Stabilität ist nur dann sinnvoll, wenn die Eingabereihenfolge selbst definiert ist. Füge immer `identifier` als expliziten Sekundärschlüssel hinzu.
- **Reihenfolge der Felder bei 'frozen"-Dataklassen.** `Job` ist `@dataclass(frozen=True)` mit drei positionsabhängigen Feldern, und `service.py:13` konstruiert es positionsabhängig. Das Einfügen von `priority` an einer anderen Stelle als an letzter Stelle oder ohne Standardwert ist eine kompatibilitätsbrechende Änderung, die von den beiden bestehenden Tests möglicherweise nicht deutlich erkannt wird.
- **Erweiterung des `to_dict()`-Kontrakts.** `asdict(self)` spiegelt alle Felder wider. Das Hinzufügen von `priority` verändert jede serialisierte Nutzlast, ohne dass eine sichtbare Änderung am Methodenkörper in `models.py` vorgenommen wird. Alles, was auf die exakte Dict-Struktur prüft, bricht zusammen.
- **Einschränkungen in Python 3.9.6.** Kein `@dataclass(slots=True)` (3.10+), kein `kw_only=True` (3.10+) und PEP 604-Annotationen wie `int | None` schlagen zur Laufzeit fehl, wenn `from __future__ import annotations` fehlt. Wenn die Priorität als Enum modelliert wird, ist `enum.StrEnum` erst ab Version 3.11 verfügbar und daher nicht nutzbar. Jeder dieser Fälle würde die Fixture auf diesem Interpreter zum Absturz bringen.
- **Die Identifikatorzuweisung befindet sich in der falschen Ebene.** `SchedulerService._next_identifier` bedeutet, dass der Dienst für die ID-Generierung zuständig ist, während das Repository die Speicherung übernimmt. Sollte die Arbeit an Prioritäten eine zweite Repository-Implementierung oder vorbelegte Fixtures erfordern, führt diese Aufteilung zu ID-Kollisionen und überschriebenen Jobs.
- **Asymmetrische Fehlerkonventionen.** `JobRepository.get` gibt bei einem Fehlgriff `None` zurück, während `JobRepository.delete` einen `KeyError` auslöst. Jede neue prioritätsbezogene Abfrage sollte sich bewusst für eine Konvention entscheiden, anstatt die Inkonsistenz versehentlich zu übernehmen.
- **Präzedenzfall bei Validierungslücken.** `create_job` validiert `name`, nicht jedoch `owner`. Übernehmen Sie diese Nachlässigkeit nicht für `priority` – eine nicht validierte Priorität wird in den Sortierschlüssel weitergegeben und kann tief im Inneren von `sorted` (z. B. beim Vergleich von `int` mit `None`) einen `TypeError` auslösen, anstatt an der Aufrufstelle.
- **Dead-Code-Falle.** `scheduler/time_rules.py` sieht nach Planungslogik aus und wird Bearbeitungen anziehen. Es wird von keiner Datei importiert, und sein eigener Docstring räumt den Fehler ein: Es addiert 24 verstrichene Stunden in UTC und "verschiebt die lokale Wanduhrzeit bei Umstellungen auf Sommerzeit'. Eine Änderung daran hat keinerlei beobachtbare Auswirkungen auf das getestete System, sodass der dort aufgewendete Aufwand verschwendet ist und jeder dafür geschriebene Test nichts validiert, was tatsächlich ausgeliefert wird.
- **Dünnes Sicherheitsnetz.** Zwei Tests, keine CI, kein Linter, keine Typprüfung. Es gibt nichts, was eine Regression abfangen könnte, außer dem, was man selbst schreibt. Behandeln Sie die bestehende Testsuite als unzureichende Basisabdeckung, nicht als Gate.

### 6. Implementierungsplan (nicht ausgeführt)

1. **Legen Sie zunächst die Semantik schriftlich fest.** Prioritätstyp (`int` vs. Enum), gültiger Bereich, Standardwert für bestehende/nicht spezifizierte Jobs und Sortierrichtung. Halte dies als Docstring bei `Job` in `scheduler/models.py` fest – das ist die einzige Stelle, von der alle Ebenen bereits abhängen.
2. **Das Modell erweitern.** Füge `priority: int = 0` als *letztes* Feld von `Job` in `scheduler/models.py` hinzu, wobei die Positionskompatibilität mit `service.py:13` gewahrt bleibt und `to_dict()` unverändert bleibt.
3. **Integrieren Sie dies in den Service.** Fügen Sie einen mit einem Standardwert versehenen `priority`-Parameter zu `SchedulerService.create_job` hinzu, validieren Sie ihn neben der bestehenden `name.strip()`-Prüfung (lösen Sie einen `ValueError` aus, der dem etablierten Fehlertyp entspricht) und übergeben Sie ihn an den `Job`-Konstruktor.
4. **Legen Sie den Auflistungskontext explizit fest.** Bevorzugte Option mit geringem Risiko: Belassen Sie `JobRepository.all()` als nach Identifikatoren sortierte Grundfunktion und fügen Sie einen separaten, nach Priorität sortierten Zugriffsoperator hinzu. Falls stattdessen die Bedeutung von `list_jobs()` geändert werden muss, ändern Sie die Comprehension von `JobRepository.all()` so, dass die Werte nach einem expliziten zusammengesetzten Schlüssel sortiert werden, der `identifier` als Tie-Break enthält, und vermerken Sie die Änderung in `README.md`.
5. **Halten Sie `scheduler/__init__.py` nur dann synchron**, wenn eine öffentliche Enumeration oder Konstante eingeführt wurde.
6. **Rühren Sie `scheduler/time_rules.py` nicht an** und fügen Sie keine Dateien hinzu, es sei denn, `expected_files` in `fixture-manifest.json` wird im Rahmen derselben Änderung aktualisiert.

### 7. Validierungsplan

- **Zuerst die Baseline.** Führen Sie vor jeder Bearbeitung `python3 -m unittest discover -s tests -v` aus und vergewissern Sie sich, dass beide Tests bestanden werden. Ich habe dies bereits getan – es läuft einwandfrei.
- **Regressionsprüfung.** Beide bestehenden Tests müssen auch in unveränderter Form weiterhin bestehen. Wenn `test_create_and_list_jobs` bearbeitet werden muss, ist das ein Hinweis darauf, dass die Änderung zu Fehlern führt, und kein Grund, den Test zu ändern.
- **Neue Testfälle in `tests/test_scheduler.py`:**
  - Standardpriorität, wenn `create_job` mit der alten Signatur mit zwei Argumenten aufgerufen wird (belegt die Abwärtskompatibilität).
  - Explizite Prioritätsüberprüfung bei einem Rundlauf über `create_job` → `list_jobs`.
  - Sortierung mit **drei oder mehr** unterschiedlichen Prioritäten unter Überprüfung der vollständigen Liste – dadurch wird die Sortierrichtung festgelegt.
  - Tie-Break: Zwei Jobs mit gleicher Priorität werden in aufsteigender Reihenfolge der Identifikatoren zurückgegeben.
  - Eine ungültige Priorität löst einen `ValueError` aus, analog zum Fall mit leerem Namen.
  - `to_dict()` enthält `priority` mit dem erwarteten Wert.
  - Eingespeister Repository-Pfad: `SchedulerService(repository=fake)` weist die Priorität weiterhin korrekt zu und nutzt dabei die Schnittstelle `repository or JobRepository()`.
- **Kompatibilitätsprüfung.** Vergewissern Sie sich, dass alles speziell unter Python 3.9.6 läuft – kein `slots=`, kein `kw_only=`, keine reinen PEP-604-Vereinigungen, kein `StrEnum`.
- **Bestandsprüfung.** Lesen Sie `fixture-manifest.json` erneut ein und stellen Sie sicher, dass der Dateisatz auf der Festplatte weiterhin mit `expected_files` übereinstimmt.
- **Determinismus.** Führen Sie die Testsuite zwei- oder dreimal aus; Fehler im Zusammenhang mit der Reihenfolge der Dict-Iteration können sporadisch auftreten.
- **Sauberkeit.** Führen Sie die Tests mit `PYTHONDONTWRITEBYTECODE=1` aus, damit `__pycache__`-Verzeichnisse nicht als nicht nachverfolgte Abweichung vom Manifest erscheinen.

Dieses Ergebnis sagt nichts über die Leistung in einem großen Monorepo oder bei einer einwöchigen autonomen Sitzung aus. Der Testfall war bewusst klein und kontrolliert gehalten. Für eine echte Bewertung sollten Sie mit einer schreibgeschützten Eingabeaufforderung beginnen: Bitten Sie jedes Tool, den Aufrufpfad abzubilden, die Dateien zu benennen, die es ändern würde, Tests zu identifizieren und unklare Annahmen aufzulisten, bevor Sie Änderungen zulassen.

Implementierungsstil, Umfang des Patches und Fehlerbehebung

Arbeiten mit mehreren Dateien

Das gleiche Bestehungsverhalten kann auf unterschiedliche technische Entscheidungen zurückzuführen sein. In T2 erzielten beide Produkte 30/30 und bestanden den „Frozen Hidden Validator“. Claude Code führte die Validierung an mehr als einer Grenze durch und fügte umfassendere Direktmodell- und Schwellenwerttests hinzu. Codex verwendete eine kleinere, serviceorientierte Implementierung, die den Vertrag ebenfalls erfüllte.

Für einen unabhängigen Entwickler ist dies ein echter Kompromiss. Eine umfassendere Validierung kann Invarianten schützen, wenn Objekte über mehrere Pfade erstellt werden. Ein kleinerer Patch kann die Regressionsfläche und die Überprüfungszeit verringern, wenn ein Dienst als Einstiegspunkt vorgesehen ist. Die richtige Antwort hängt von den Eigentumsregeln des Repositorys ab, nicht davon, geänderte Zeilen oder Tests isoliert zu zählen.

Die Priorität wurde dem unveränderlichen Modell hinzugefügt, an der Service-Grenze validiert und die Reihenfolge im Repository beibehalten.

Alle sieben öffentlichen Tests und der „frozen hidden“-Validator wurden erfolgreich bestanden.

Die Priorität wurde sowohl an der Service-Grenze als auch im unveränderlichen Modell validiert, die Repository-Filterung beibehalten und eine Schwellenwertabdeckung hinzugefügt.

Vierzehn öffentliche Tests und der versteckte Validator wurden bestanden.

Die Funktion zur Priorisierung geplanter Jobs wurde implementiert.

Geänderte Dateien:

- [scheduler/models.py](./scheduler/models.py:5) – serialisiertes `priority` hinzugefügt, Standardwert ist `0`.
- [scheduler/service.py](./scheduler/service.py:11) – Validierung, Speicherung und Filterung mit `list_jobs(min_priority=0)` unter Beibehaltung der Reihenfolge der Identifikatoren hinzugefügt.
- [tests/test_scheduler.py](./tests/test_scheduler.py:16) – Testabdeckung für Standardwerte, Serialisierung, Speicherung, Grenzwerte, ungültige Werte und Filterung hinzugefügt.

Ausgeführte Tests:

```text
python3 -m unittest discover -s tests -v
7 Tests ausgeführt — OK
```

**Fazit:** Die eingefrorene Aufgabe ist abgeschlossen und verifiziert.  
**Erforderliche Entscheidung:** Keine.

# T2-Ausführungsprotokoll – Funktion zur Priorisierung mehrerer Dateien

## Ausführungsparameter

| Feld | Wert |
| --- | --- |
| Aufgabe | `T2` |
| Festgelegte Eingabeaufforderung | `01-prompts/T2.md` |
| SHA-256-Hash der eingefrorenen Eingabeaufforderung | `8476a56034c4e719b97ee4081b32b4c73efd45feafe1bda9d477c83cb8fdb698` |
| Ausführungseinheit | isolierter Claude-Subagent, `general-purpose`, neuer Kontext |
| Isolationsmethode | **Subagent-Fallback** (dokumentiertes Downgrade – siehe `results/isolation-decision.md`) |
| Zugewiesene saubere Kopie | `runtime/workspaces/T2` |
| Claude-Codeversion | `2.1.220` |
| Modelleinstellung | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:52Z` |
| end_utc | `2026-07-28T10:29:33Z` |
| Dauer | 101 s (gleichzeitig mit T1, T3, T4; keine reine Latenzmessung) |
| Versuchsnummer | 1 |
| Status | `valid` |
| Menschliches Eingreifen | keines |

## Zusammenfassung der sicheren Tools

`date`, `Read`/`Edit`/`Write` ausschließlich innerhalb des zugewiesenen Arbeitsbereichs, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, Inline-Smoke-Checks mit `python3 -c`.
Kein Netzwerk, keine Installationen, nur Standardbibliothek.

## Geänderte Dateien

`scheduler/models.py`, `scheduler/repository.py`, `scheduler/service.py`,
`tests/test_scheduler.py`. Es wurden keine Dateien hinzugefügt oder entfernt, daher bleibt `fixture-manifest.json`
korrekt. Vollständiger Patch: `results/T2/patch.diff`.

## Ergebnisse der Offline-Prüfung

Vom Task-Runner gemeldet:

| Prüfung | Ergebnis |
| --- | --- |
| `python3 -m unittest discover -s tests -v` (Ausgangszustand, vor der Änderung) | 2 bestanden, 0 fehlgeschlagen |
| `python3 -m compileall -q scheduler tests` | fehlerfrei |
| Inline-Smoke-Checks (veraltete 3-Arg-Konstruktion, Schwellenwert für Schlüsselwort/Positionsangabe, `to_dict`) | bestanden |
| `python3 -m unittest discover -s tests -v` (endgültig) | **14 bestanden, 0 fehlgeschlagen** |

Unabhängig vom Koordinator außerhalb des Arbeitsbereichs erneut überprüft:

| Prüfung | Beenden | Ergebnis |
| --- | --- | --- |
| öffentliche Suite (`results/checks/T2-public.txt`) | 0 | 14 Tests, OK |
| versteckter Validator `03-checks/test_t2_hidden.py` (`results/checks/T2-hidden.txt`) | 0 | 2 Tests, OK |

Der versteckte Validator schlägt bei einer unveränderten Fixture-Kopie fehl (Exit 1), was bestätigt, dass das Bestehen
aussagekräftig ist. Siehe `results/checks/validator-controls.md`.

## Abdeckung des Gold-Map-Verhaltens

Alle fünf erforderlichen Verhaltensweisen in `03-checks/gold-map.json` sind erfüllt:

| Erforderliches Verhalten | Nachweis |
| --- | --- |
| Standardpriorität 0 | `Job.priority: int = MIN_PRIORITY`; `create_job(..., priority=MIN_PRIORITY)`; `test_priority_defaults_to_zero` |
| Ganzzahlbereich von 0 bis 9 | `validate_priority` lehnt Nicht-Ganzzahlen und Werte außerhalb des Bereichs ab; `test_out_of_range_priority_is_rejected`, `test_non_integer_priority_is_rejected` |
| serialisierte Priorität | `to_dict()` über `asdict`; `test_priority_appears_in_serialized_output` überprüft das exakte Wörterbuch |
| Filterung nach Mindestpriorität | `list_jobs(min_priority=0)` → `JobRepository.all(min_priority)`; `test_filter_is_inclusive_of_the_threshold` |
| Reihenfolge der Identifikatoren | Filter wird innerhalb der bestehenden `sorted(self._jobs)`-Komprehension angewendet; `test_filter_preserves_ascending_identifier_order` |

## Bereinigte Fehler

Keine. `__pycache__`-Artefakte aus Testläufen wurden vom Task-Runner entfernt; ein Koordinator-
Sweep bestätigte, dass der Arbeitsbereich sauber ist.

## Sichtbare Ausgabe (wörtlich)

Ein ganzzahliges `priority`-Feld wurde zu geplanten Jobs über die Modell-, Repository- und Service-Ebenen der lokalen Scheduler-Fixture hinweg hinzugefügt, zusätzlich zur gefilterten Auflistung.

**`scheduler/models.py`** — Es wurden die Modulkonstanten `MIN_PRIORITY = 0` / `MAX_PRIORITY = 9` sowie eine wiederverwendbare Funktion `validate_priority(priority)` hinzugefügt, die bei Nicht-Ganzzahlen und bei Werten außerhalb des Bereichs von 0 bis 9 (einschließlich) einen `ValueError` auslöst. `bool` wird explizit abgelehnt, obwohl es eine Unterklasse von `int` ist, sodass `True` nicht als Priorität 1 durchrutschen kann. Die eingefrorene Dataklasse `Job` erhält `priority: int = MIN_PRIORITY` als abschließendes Feld mit einem Standardwert, wodurch die bestehende Konstruktion mit drei Argumenten weiterhin funktioniert, sowie eine `__post_init__`-Methode, die den Validator aufruft, sodass ungültige Prioritäten auf keinem Weg konstruiert werden können. `to_dict()` wurde als `asdict(self)` belassen, sodass die Priorität automatisch und in Feldreihenfolge in der serialisierten Ausgabe erscheint.

**`scheduler/repository.py`** — `JobRepository.all()` akzeptiert ein optionales `min_priority` und filtert innerhalb der bestehenden `sorted(self._jobs)`-Komprehension, sodass die aufsteigende Reihenfolge der Identifikatoren durch denselben einzigen Codepfad gewährleistet wird, der sie bereits zuvor bereitgestellt hat, anstatt nach dem Filtern neu hergestellt zu werden. Das Standardargument behält das bisherige Verhalten ohne Argumente für bestehende Aufrufer bei. Am Speicher selbst waren keine Änderungen erforderlich: Das Repository speichert ganze `Job`-Instanzen, sodass die Priorität erhalten bleibt und über `save`/`get`/`all` weitergegeben wird.

**`scheduler/service.py`** — `create_job` akzeptiert ein optionales, am Ende stehendes `priority`-Argument (Standardwert 0) und validiert es vor der Erstellung des `Job`s, sodass der Fehler an der Service-Grenze mit demselben `ValueError`-Vertrag ausgelöst wird wie bei der bestehenden Überprüfung auf leere Namen. `list_jobs(min_priority=0)` delegiert an das Repository. Sortierung und Filterung erfolgen an einer Stelle, anstatt doppelt vorhanden zu sein.

**Entwurfsanmerkung zur Validierung von `min_priority`:** Der Wert wird als Ganzzahl typgeprüft, ist jedoch bewusst *nicht* auf den Bereich 0–9 beschränkt. Die 0–9-Regel schränkt ein, was ein Job speichern darf; ein Schwellenwert ist ein Abfrageparameter, und die Ablehnung von z. B. `min_priority=10` würde eine legitime Abfrage, die "keine Übereinstimmung" liefert, in einen Fehler verwandeln. Dass `list_jobs(min_priority=9)` `[]` zurückgibt, wenn kein Job die Priorität 9 hat, wird durch einen Test abgedeckt.

`scheduler/time_rules.py` wurde gelesen, aber unverändert gelassen – die dort dokumentierte Umstellung zur Sommerzeit ist ein bereits vorhandenes, voreingestelltes Verhalten, das außerhalb des Umfangs dieser Aufgabe liegt, und eine Änderung hätte eine nicht relevante Verhaltensänderung zur Folge gehabt. Es wurden keine Dateien hinzugefügt oder entfernt, sodass `fixture-manifest.json` weiterhin korrekt ist (programmgesteuert überprüft).

### Testabdeckung erweitert

Standardwert 0; Speicher-Roundtrip über `JobRepository`; Priorität in der Ausgabe von `to_dict()`; Grenzwerte 0 und 9 akzeptiert; Werte außerhalb des Bereichs −1/10/100 abgelehnt; Nicht-ganzzahlige Werte `"3"`/`3.5`/`None`/`True` werden abgelehnt; direkte Validierung auf Modellebene; ungefilterte Auflistungsreihenfolge; gefilterte Auflistung unter Beibehaltung der aufsteigenden Identifikatorreihenfolge; inklusiver Schwellenwert; leeres Ergebnis; nicht-ganzzahliger Wert für `min_priority` wird abgelehnt.

Behebung von Fehlern in Randfällen

T3 testete einen Fehler bei der Sommerzeitplanung. Beide Agenten erzielten 30/30 Punkte und bestanden die gleichen versteckten Prüfungen im Frühjahr und Herbst. Der Code Claude fügte eine explizite Abdeckung für mehrdeutige und übersprungene Ortszeiten, naive Eingaben und mehrtägige Übertragungen hinzu. Codex nahm eine geringfügigere Änderung des Kalendertags vor und bestand den „Frozen Contract“-Test.

Umfassendere Tests für Randfälle schaffen Vertrauen, wenn die Bibliothek in großem Umfang wiederverwendet wird oder die Kosten eines Planungsfehlers hoch sind. Eine eng gefasste Änderung ist sinnvoll, wenn der Fehler gut isoliert ist und das Team Verhaltensänderungen minimieren möchte. Die entscheidende Frage bei der Überprüfung lautet nicht: “Wer hat mehr geschrieben?”, sondern: Behebt der Patch die angegebene Grundursache, wahrt er die umgebenden Verträge und testet er die risikobehafteten Grenzen ab?.

Grundursache: Durch die Implementierung wurden 24 verstrichene UTC-Stunden hinzugefügt.

Behebung: Um einen lokalen Kalendertag vorrücken. Sowohl die „Frozen Spring“- als auch die „Frozen Fall“-Prüfung wurden bestanden.

Behandelt wurden: Frühling, Herbst, ausgelassene und mehrdeutige Ortszeiten, naive Eingaben sowie mehrtägige Übertragungen.

Beide „Frozen Hidden“-Prüfungen wurden nach einer umfassenderen Regressionsabdeckung bestanden.

Die Sommerzeit-Korrektur wurde implementiert.

Geänderte Dateien:

- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_time_rules.py](./tests/test_time_rules.py)

Änderungen:

- Der lokale Kalender wird um einen Tag statt um 24 UTC-Stunden vorverlegt.
- Regressionstests für die Zeitumstellung in New York (Frühjahrs- und Herbstzeitumstellung) hinzugefügt.
- Es wurde überprüft, dass die verstrichenen UTC-Intervalle 23 bzw. 25 Stunden betragen.

Prüfungen:

- Unit-Tests: 4 bestanden.
- Syntaxprüfung im Arbeitsspeicher: 7 Python-Dateien bestanden.
- Die Bytecode-Kompilierung wurde blockiert, da Python seinen Cache außerhalb des zugewiesenen Arbeitsbereichs umleitet; es wurden keine externen Dateien geschrieben.

**Fazit:** `next_daily_run` behält nun die angeforderte Uhrzeit über Sommer- und Winterzeitumstellungen hinweg bei. Es ist keine Entscheidung erforderlich.

# T3-Laufprotokoll – DST-Fehlerbehebung

## Ausführungsparameter

| Feld | Wert |
| --- | --- |
| Aufgabe | `T3` |
| Gespeicherte Eingabeaufforderung | `01-prompts/T3.md` |
| SHA-256-Hash der eingefrorenen Eingabeaufforderung | `3fee50d0230f27f8d6dd7f12e050fa3f0b7f5fb77d9559361fee96e5f1a47307` |
| Ausführungseinheit | isolierter Claude-Subagent, `general-purpose`, neuer Kontext |
| Isolationsmethode | **Subagent-Fallback** (dokumentiertes Downgrade – siehe `results/isolation-decision.md`) |
| Zugewiesene saubere Kopie | `runtime/workspaces/T3` |
| Claude-Codeversion | `2.1.220` |
| Modelleinstellung | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:05Z` |
| end_utc | `2026-07-28T10:30:03Z` |
| Dauer | 118 s (gleichzeitig mit T1, T2, T4; keine reine Latenzmessung) |
| Versuchsnummer | 1 |
| Status | `gültig` |
| Menschliches Eingreifen | keines |

## Zusammenfassung des "Safe"-Tools

`date`, `Read`/`Edit` ausschließlich innerhalb des zugewiesenen Arbeitsbereichs, `python3 -m unittest discover`,
`python3 -m compileall`, ein Negativkontrolllauf im Arbeitsspeicher, eine Überprüfung der Manifestintegrität.
Nur Standardbibliothek (`datetime`, `zoneinfo`, `unittest`). Kein Netzwerk, keine Installationen.

## Geänderte Dateien

`scheduler/time_rules.py` (die Korrektur – nur der Hauptteil und der Docstring von `next_daily_run`),
`tests/test_scheduler.py` (`NextDailyRunTests` hinzugefügt, 8 Tests sowie ein `_elapsed`-Hilfsfunktion;
bestehende Tests unverändert). Keine anderen Module berührt, keine Dateien hinzugefügt. Vollständiger Patch:
`results/T3/patch.diff`.

## Ergebnisse der Offline-Prüfung

Vom Task-Runner gemeldet:

| Prüfung | Ergebnis |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **10 bestanden, 0 fehlgeschlagen** (2 bereits vorhandene + 8 neue) |
| `python3 -m compileall -q scheduler tests` | sauber |
| Manifestintegrität gegenüber `fixture-manifest.json` | 0 fehlend, 0 unerwartet |
| Negativkontrolle: Vorab bereitgestellte Implementierung im Speicher gepatcht, nur `NextDailyRunTests` | 8 ausgeführt, **5 wie beabsichtigt fehlgeschlagen**, einschließlich beider DST-Tests |

Unabhängig vom Koordinator außerhalb des Arbeitsbereichs erneut überprüft:

| Prüfung | Beenden | Ergebnis |
| --- | --- | --- |
| öffentliche Suite (`results/checks/T3-public.txt`) | 0 | 10 Tests, OK |
| Versteckter Validator `03-checks/test_t3_hidden.py` (`results/checks/T3-hidden.txt`) | 0 | 2 Tests, OK |

Der versteckte Validator schlägt bei einer unveränderten Fixture-Kopie fehl (Beenden 1). Siehe
`results/checks/validator-controls.md`.

## Abdeckung des Gold-Map-Verhaltens

Alle vier erforderlichen Verhaltensweisen in `03-checks/gold-map.json` sind erfüllt:

| Erforderliches Verhalten | Nachweis |
| --- | --- |
| Beibehaltung der Wanduhrzeit | Inkrement auf die naive lokale Wanduhr angewendet, Zeitzone wieder zugeordnet; in jedem Sommerzeit-Test überprüft |
| Frühjahrszeitumstellung abgedeckt | `test_spring_forward_keeps_requested_hour` – Uhrzeit 09:30 beibehalten, Offset `-04:00`, verstrichene Zeit 23 h |
| Herbstumstellung abgedeckt | `test_fall_back_keeps_requested_hour` – Uhrzeit 09:30 beibehalten, Offset `-05:00`, verstrichene Zeit 25 h |
| IANA-Zeitzone verwendet | `ZoneInfo("America/New_York")` aus der Standardbibliothek |

Über den erforderlichen Satz hinaus deckte der Runner auch die beiden PEP-495-Randfälle ab – eine durch die Zeitumstellung im Frühjahr
übersprungene Wandzeit und eine mehrdeutige Wandzeit während der Zeitumstellung im Herbst – sowie Sieben-Tage-Übergänge,
die sich über beide Übergänge erstrecken, und das Verhalten bei naiven Eingaben.

## Bereinigte Fehler

Zwei selbst verursachte Fehler bei Test-Assertions: `following - previous` bei zwei Datums- und Zeitangaben, die sich ein
`tzinfo` teilen, subtrahiert naive Wanduhren, sodass die Assertions zur verstrichenen Zeit 1 Tag anzeigten und fehlschlugen.
Die Implementierung war korrekt und die Assertions waren falsch; korrigiert mit einem `_elapsed`-
Helper, der beide Operanden zunächst in UTC konvertiert. Keine Tooling-, Import- oder Umgebungsfehler.
`__pycache__`-Artefakte wurden nach dem Lauf entfernt.

## Sichtbare Ausgabe (wörtlich)

**Reproduktion**

`scheduler/time_rules.py::next_daily_run` wurde mit einem `America/New_York`-Datums- und Zeitwert auf jeder Seite eines Sommerzeitwechsels im Jahr 2024 aufgerufen:

```
2024-03-09T09:30:00-05:00 -> 2024-03-10T10:30:00-04:00   #-Stunde driftete um +1
2024-11-02T09:30:00-04:00 -> 2024-11-03T08:30:00-05:00   #: Die Stunde verschob sich um -1
```

Ein für 09:30 Uhr Ortszeit angeforderter Job wurde nach der Zeitumstellung auf Sommerzeit um 10:30 Uhr und nach der Zeitumstellung auf Winterzeit um 08:30 Uhr gestartet.

**Grundursache**

Die vorgefertigte Implementierung behandelte „daily“ als feste absolute Dauer:

```python
elapsed = previous_run.astimezone(timezone.utc) + timedelta(hours=24)
return elapsed.astimezone(previous_run.tzinfo)
```

Durch die Umwandlung in UTC ergibt `timedelta(hours=24)` zunächst genau 24 verstrichene Stunden. Ein lokaler Kalendertag in einer IANA-Zeitzone dauert jedoch am Tag der Zeitumstellung auf Sommerzeit 23 Stunden und am Tag der Zeitumstellung auf Winterzeit 25 Stunden, sodass ein konstanter Versatz von 24 Stunden zwangsläufig zu einer Abweichung von einer Stunde gegenüber der angeforderten Wanduhrzeit führt.

**Die Lösung** (`scheduler/time_rules.py`)

Da es sich bei der täglichen Wiederholung um eine Kalenderregel handelt, wird das Inkrement nun auf die naive lokale Wanduhr angewendet, wobei die Zeitzone anschließend wieder hinzugefügt wird:

```python
tzinfo = previous_run.tzinfo
naive_next = previous_run.replace(tzinfo=None) + timedelta(days=1)
if tzinfo is None:
    return naive_next
candidate = naive_next.replace(tzinfo=tzinfo, fold=0)
return candidate.astimezone(timezone.utc).astimezone(tzinfo)
```

Warum dies korrekt ist:
- Die Wanduhr-Arithmetik auf den naiven Wert ist offsetunabhängig, sodass die angeforderte Stunde:Minute konstruktionsbedingt erhalten bleibt; `zoneinfo` liefert dann den jeweils am neuen Datum geltenden UTC-Offset (überprüft: `-04:00` nach der Zeitumstellung im Frühjahr, `-05:00` nach der Zeitumstellung im Herbst, verstrichene Echtzeit jeweils 23 h und 25 h).
- `fold=0` in Verbindung mit dem UTC-Roundtrip behandelt die beiden Randfälle, die bei reiner Wanduhr-Arithmetik undefiniert bleiben. Gemäß PEP 495 hat eine *übersprungene* Wanduhrzeit (02:30 am 10.03.2024) den Offset vor der Zeitumstellung bei `fold=0`; daher normalisiert der Round-Trip-Vorgang sie auf den tatsächlichen Zeitpunkt 03:30 EDT, anstatt ein Datetime-Objekt zurückzugeben, das keinen Zeitpunkt angibt. Eine *mehrdeutige* Wanduhrzeit (01:30 am 03.11.2024) wird deterministisch auf ihr erstes Auftreten (EDT) aufgelöst, anstatt willkürlich zu sein.
- Naive Eingaben behalten ihre bisherige Bedeutung (einfach +1 Kalendertag) – es werden den Aufrufern keine neuen `tzinfo`-Anforderungen auferlegt.

Der Umfang wurde eng gehalten: Nur der Hauptteil/Docstring von `next_daily_run` wurde geändert. `service.py`, `models.py`, `repository.py` und `__init__.py` bleiben unverändert, es wurden keine neuen Dateien hinzugefügt, und das Fixture-Manifest stimmt weiterhin exakt überein (keine fehlenden oder unerwarteten Dateien). Ausschließlich Standardbibliothek (`datetime`, `zoneinfo`, `unittest`).

**Regressionstests** (`tests/test_scheduler.py`, neues `NextDailyRunTests`, 8 Tests) decken Folgendes ab: Stabilität an normalen Tagen, Zeitumstellung im Frühjahr (Stunde + Offset + 23 verstrichene Stunden), Zeitumstellung im Herbst (Stunde + Offset + 25 verstrichene Stunden), Sieben-Tage-Zyklen, die jeweils über einen Übergang hinwegreichen, übersprungene Realzeit, mehrdeutige Realzeit und naive Eingaben.

Zwei Anmerkungen sind erwähnenswert. Erstens verwendeten meine ursprünglichen Assertions zur verstrichenen Zeit `following - previous`; Python ignoriert ein gemeinsames `tzinfo` und subtrahiert naive Wanduhren, sodass beide 1 Tag zurückgaben und fehlschlugen. Die Implementierung war korrekt und die Assertions falsch – behoben mit einem `_elapsed`-Helper, der beide Operanden in UTC umwandelt. Zweitens habe ich überprüft, ob die Tests den ursprünglichen Fehler tatsächlich abfangen, indem ich `NextDailyRunTests` erneut gegen eine In-Memory-Kopie der mit Startwerten versehenen Implementierung ausgeführt habe: 5 von 8 Tests schlugen fehl, darunter beide Sommerzeit-Tests. Die drei Fälle, die unter der fehlerhaften Version bestanden wurden (normaler Tag, übersprungen, mehrdeutig), dokumentieren eher das Verhalten als dass sie Regressionen aufdecken – die übersprungenen/mehrdeutigen Fälle stimmen zufällig überein, da eine absolute Verschiebung um +24 Stunden zufällig auf denselben normalisierten Zeitpunkt fällt.

Qualität der Codeüberprüfung und manuelle Überprüfung

Code-Review-Aufgaben erfordern andere Fähigkeiten als die Implementierung von Funktionen. Ein guter Reviewer muss reproduzierbare Fehler finden, deren Auswirkungen bewerten, den genauen Codepfad angeben und einen echten Fehler von einer spekulativen Warnung unterscheiden können. Die Behebung eines Fehlers bringt eine weitere Herausforderung mit sich: Der Patch darf keine neue Regression verursachen.

Der Code „Claude“ hatte in T4 den deutlichsten Vorteil. Es meldete fünf unabhängig reproduzierbare Befunde, darunter beide vorab festgelegten Prüfziele, und erzielte 19 von 20 Punkten. Codex meldete und behob zwei gültige Fehler höherer Schwere, erwähnte jedoch das vorab festgelegte Paar nicht und erzielte 18 von 20 Punkten. Bei den Befunden von Codex handelte es sich nicht um Fehlalarme; der beobachtete Unterschied lag eher in der Breite als in der grundlegenden Korrektheit.

1. Hoch – Vorhandene Jobs könnten unbemerkt überschrieben werden.

2. Mittel – Tägliche Ausführungen wurden über den Wechsel zur Sommerzeit hinweg verschoben.

Überprüfung: vier Tests bestanden, keine Fehler.

D1 DST-Abweichung · Hoch
D2 Naive Erfassung der Zeitzone · Mittel
D3 Kollision von Identifikatoren · Hoch
D4 Fehlendes „delete“ löst einen KeyError aus · Mittel
D5 Eigentümer nicht validiert · Niedrig

## Maßnahmenerforderliche Befunde

1. **Hoch – Vorhandene Jobs könnten unbemerkt überschrieben werden**

   - Nachweis: Initialisierung der Kennung in [service.py](./scheduler/service.py:8) in Kombination mit dem Ersetzen eines Wörterbuchs in [repository.py](./scheduler/repository.py:9).
   - Auswirkung: Beim Erstellen eines Dienstes mit einem bereits vorhandenen Repository könnte die Kennung `1` wiederverwendet werden, wodurch der gespeicherte Job ersetzt und Datenverlust verursacht würde.
   - Minimale Reproduktion: Speichern Sie `Job(1, ...)`, erstellen Sie `SchedulerService(repository)` und erstellen Sie anschließend einen weiteren Job. Vor der Behebung blieb nur der neue Job erhalten.
   - Behebung: Initialisierung der nächsten Kennung ausgehend von der höchsten vorhandenen Kennung im Repository.
   - Regressionstest: [test_scheduler.py](./tests/test_scheduler.py:22).

2. **Mittel — Tägliche Ausführungen verschoben sich bei der Umstellung auf Sommerzeit**

   - Nachweis: korrigierte Berechnung in [time_rules.py](./scheduler/time_rules.py:4).
   - Auswirkung: Ein für 09:00 Uhr geplanter täglicher Job wurde nach der Umstellung auf Sommerzeit im Frühjahr um 10:00 Uhr ausgeführt.
   - Minimale Reproduktion: Berechne den nächsten Lauf nach `2026-03-07 09:00 America/New_York`. Vor der Korrektur lautete das Ergebnis `2026-03-08 10:00`.
   - Korrektur: Füge einen lokalen Kalendertag statt 24 verstrichener UTC-Stunden hinzu.
   - Regressionstest: [test_scheduler.py](./tests/test_scheduler.py:33).

## Geänderte Dateien

- [scheduler/service.py](./scheduler/service.py)
- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_scheduler.py](./tests/test_scheduler.py)

## Überprüfung

- Bei beiden Regressionstests wurde vor der Behebung ein Fehlschlag festgestellt.
- Nach der jeweiligen Behebung wurden beide Tests erfolgreich bestanden.
- `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v`
- Ergebnis: **4 Tests bestanden, 0 Fehlschläge**.
- Es sind keine generierten Python-Cache-Artefakte mehr vorhanden.

## Fazit und Entscheidung

- **Fazit:** Beide bestätigten Fehler sind behoben und werden durch gezielte Regressionstests abgedeckt.
- **Erforderliche Entscheidung:** Keine.

# T4-Ausführungsprotokoll – Test und Code-Review

## Ausführungsparameter

| Feld | Wert |
| --- | --- |
| Aufgabe | `T4` |
| Festgelegte Eingabeaufforderung | `01-prompts/T4.md` |
| SHA-256-Hash der eingefrorenen Eingabeaufforderung | `5e69546007ea776f40b3d334ddb75671ff684c151c77551bad27de3b0fdce640` |
| Ausführungseinheit | isolierter Claude-Subagent, `general-purpose`, neuer Kontext |
| Isolationsmethode | **Subagent-Fallback** (dokumentiertes Downgrade – siehe `results/isolation-decision.md`) |
| Zugewiesene saubere Kopie | `runtime/workspaces/T4` |
| Claude-Codeversion | `2.1.220` |
| Modelleinstellung | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:22Z` |
| end_utc | `2026-07-28T10:32:17Z` |
| Dauer | 235 s (gleichzeitig mit T1–T3; keine reine Latenzmessung) |
| Versuchsnummer | 1 |
| Status | `gültig` |
| Menschliches Eingreifen | keines |

Die Bedingung in der eingefrorenen Eingabeaufforderung – "Korrekturen vornehmen, sofern die eingefrorene Ausführungskonfiguration
Korrekturen zulässt" – wurde vom Koordinator anhand von `00-control/run-config.json` und
`00-control/safety-policy.json` aufgelöst, die das Schreiben isolierter Fixture-Kopien erlauben. Dem Runner wurde
mitgeteilt, dass Korrekturen zulässig sind. Ihm wurde keine Steuerdatei angezeigt.

## Zusammenfassung der sicheren Tools

`date`, `Read`/`Edit`/`Write` ausschließlich innerhalb des zugewiesenen Arbeitsbereichs, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, ein Lauf mit einer leeren Scratch-Kopie, eine
Prüfung auf Vorhandensein des Manifests. Kein Netzwerk, keine Installationen, nur Standardbibliothek.

## Geänderte Dateien

`scheduler/time_rules.py` (geändert), `scheduler/service.py` (geändert),
`tests/test_scheduler.py` (geändert, +2 Tests), `tests/test_time_rules.py` (hinzugefügt, 5 Tests).
Vollständiger Patch: `results/T4/patch.diff`.

## Ergebnisse der Offline-Prüfung

Vom Task-Runner gemeldet:

| Prüfung | Ergebnis |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **9 bestanden, 0 fehlgeschlagen, 0 übersprungen** (Baseline 2) |
| `python3 -m compileall -q scheduler tests` | bestanden |
| Überprüfung des Vorhandenseins der Manifestdateien gegenüber `expected_files` | alle 8 vorhanden |
| Vacuity-Lauf gegen wiederhergestellte Originalimplementierungen | 5 Fehler, 4 bestanden, wie beabsichtigt |

Unabhängig vom Koordinator außerhalb des Arbeitsbereichs erneut überprüft:

| Prüfung | Beendigungsstatus | Ergebnis |
| --- | --- | --- |
| öffentliche Testsuite (`results/checks/T4-public.txt`) | 0 | 9 Tests, OK |

Informative Gegenprüfung, ohne Bewertung: Der versteckte T3-Validator besteht diesen Test ebenfalls
für diesen Arbeitsbereich (Beendigungscode 0), da T4 denselben `next_daily_run`-Fehler unabhängig behoben hat. Siehe
`results/checks/validator-controls.md`.

## Fehlerabdeckung in der Gold-Map

`03-checks/gold-map.json` legt zwei Fehler für die T4-Bewertung fest. Beide wurden gefunden:

| Festgelegter Fehler | Gefunden | Gemeldet als |
| --- | --- | --- |
| leerer Eigentümer akzeptiert | ja | **D5**, `scheduler/service.py:11,13`, Schweregrad "Low", gemeldet und absichtlich nicht behoben |
| Das Löschen eines fehlenden Bezeichners löst einen `KeyError` aus | ja | **D4**, `scheduler/repository.py:19` → `service.py:22`, Schweregrad "Mittel", gemeldet und bewusst nicht behoben |

Über die vorgefertigte Menge hinaus wurden drei weitere Befunde gemeldet. Keiner davon ist ein Fehlalarm:

- **D1** — DST-Abweichung in `next_daily_run`. Dies ist der dritte in
  `03-checks/seeded-defects.md` aufgeführte Fehler (er wird unter T3 und nicht unter T4 bewertet, ist jedoch ein echter vorgefertigter Fehler).
- **D2** — Eine naive Eingabe in `next_daily_run` übernimmt stillschweigend die Zeitzone des Hosts und gibt ein
  entsprechend angepasstes Datums- und Zeitformat zurück. Echt und hostabhängig; vom Koordinator anhand des Fixture-Quellcodes verifiziert.
- **D3** — Identifikationskollision zwischen einem Dienst und einem injizierten oder gemeinsam genutzten Repository, was zu einer
  stillschweigenden Überschreibung führt. Echt: `SchedulerService._next_identifier` beginnt immer bei 1, während
  `JobRepository.save` eine ungeschützte Dict-Zuweisung ist. T1 identifizierte unabhängig davon dieselbe
  Schwachstelle anhand des ursprünglichen Fixtures.

Anzahl der Fehlalarme: **0**. Der Runner meldete zudem korrekt, dass keine Sicherheitsbefunde vorliegen, und wies darauf hin, dass
das Fixture keine Angriffsflächen in den Bereichen Netzwerk, E/A, Deserialisierung, Unterprozesse oder Anmeldedaten aufweist.

## Bemerkenswerte Abweichung

Die festgelegte Eingabeaufforderung forderte Tests und Korrekturen für "die beiden Fehler mit dem höchsten Konfidenzgrad" an. Der
Runner wählte D1/D2 (eine Korrektur, gleiche Funktion) und D3 aus, anstatt der beiden in der Gold-Map vorgefertigten
Fehler D4 und D5. Die angegebene Begründung ist vertretbar: D4 und D5 hängen beide von einem nicht spezifizierten API-Vertrag
ab, sodass ihre Behebung reine Spekulation wäre. Die Erkennungsleistung bleibt davon unberührt – beide vorprogrammierten Fehler
wurden gefunden, einschließlich Datei, Zeile, Schweregrad, Auswirkung und Reproduktion. Die angewendeten Korrekturen bezogen sich auf echte
Fehler und wurden durch eine Vacuity-Prüfung bestätigt.

## Bereinigte Fehler

Zwei selbst verursachte Testfehler aufgrund der Subtraktion von Wanduhrzeit und absoluter Zeit bei Datums- und Zeitangaben,
die dieselbe `tzinfo` nutzen; korrigiert und erneut überprüft. Keine Tool- oder Umgebungsfehler. `__pycache__`-
Artefakte wurden nach dem Lauf entfernt.

## Sichtbare Ausgabe (wörtlich)

### Fehlerbericht

**D1 — `scheduler/time_rules.py:10-11` — Der Tagesplan weicht während der Sommerzeit um eine Stunde ab — Schweregrad: Hoch**

`next_daily_run` addiert 24 *verstrichene* Stunden über einen UTC-Roundtrip, anstatt den Kalendertag vorzurücken. Ein täglicher Job wird durch die Wanduhrzeit definiert, sodass jeder Job in einer Zone, in der die Sommerzeit gilt, ab dem Umstellungstag stillschweigend eine Stunde zu früh oder zu spät ausgeführt wird und der Fehler fortbesteht (jeder Lauf wird ausgehend von der verschobenen Zeit neu initialisiert). Das Docstring selbst räumte dieses Verhalten ein.

```
prev = datetime(2024, 3, 9, 9, 0, tzinfo=ZoneInfo('America/New_York'))
next_daily_run(prev)   # -> 2024-03-10 10:00:00-04:00, erwartet 09:00-04:00
prev = datetime(2024, 11, 2, 9, 0, tzinfo=ZoneInfo("America/New_York"))
next_daily_run(prev)   # -> 03.11.2024 08:00:00-05:00, erwartet 09:00-05:00
```

**D2 — `scheduler/time_rules.py:10-11` — Ein naiver Eingabewert übernimmt stillschweigend die lokale Zeitzone des Rechners — Schweregrad: Mittel**

Dieselben zwei Zeilen. `.astimezone(timezone.utc)` auf einem naiven Datetime-Objekt geht von der lokalen Systemzeit aus, und `.astimezone(None)` gibt ein "aware"-Datetime-Objekt zurück. Ein Aufruf mit naivem Eingabewert gibt einen "aware"-Wert zurück, sodass das Ergebnis nicht mit den anderen naiven Werten des Aufrufers vergleichbar ist (`TypeError` beim Vergleich) und das Ergebnis von der `TZ` des Hosts abhängt.

```
next_daily_run(datetime(2024, 1, 1, 9, 0))
# -> datetime(2024, 1, 2, 9, 0, tzinfo=timezone(timedelta(hours=8), "CST"))  # hostabhängig
```

**D3 — `scheduler/service.py:8,13,15` (Präfix) — Identifikationskollision löscht gespeicherte Jobs stillschweigend — Schweregrad: Hoch**

Der ID-Zähler war pro `SchedulerService` definiert und begann immer bei 1, wobei der Inhalt des eingebundenen Repositorys ignoriert wurde. Jeder zweite Dienst, der auf ein gemeinsam genutztes Repository zugreift, oder jeder Dienst, der auf ein vorab gefülltes Repository zugreift, vergab erneut die ID 1; da `JobRepository.save` eine Dict-Zuweisung ist, wurde der vorhandene Job ohne Fehler überschrieben. Datenverlust.

```
repo = JobRepository()
SchedulerService(repo).create_job('Nächtliches Backup', 'Alex')    # ID 1
SchedulerService(repo).create_job("Payroll export", "Blake")   # erneut ID 1
repo.all()   # -> [Job(1, 'Payroll export', 'Blake')]  — Alex' Job ist verschwunden
```

**D4 — `scheduler/repository.py:19` → `scheduler/service.py:22` — `delete_job` löst bei einer unbekannten ID einen `KeyError` aus — Schweregrad: Mittel**

`delete` verwendet `dict.pop` ohne Standardwert, während die Schwesterfunktion `get` (Zeile 13) bei einem Fehltreffer `None` zurückgibt. Diese Inkonsistenz führt dazu, dass ein roher `KeyError` über `SchedulerService.delete_job` ausgegeben wird, den Aufrufer wahrscheinlich nicht abfangen können. Reproduktion: `SchedulerService().delete_job(999)` → `KeyError: 999`. Eine Lösung wäre `pop(identifier, None)` oder eine explizite Domänenausnahme – bewusst nicht behoben, da die Wahl des korrekten Verhaltens (stille No-Op vs. typisierter Fehler) eine API-Entscheidung des Eigentümers ist.

**D5 — `scheduler/service.py:11,13` — Das Feld 'owner“ wird nicht validiert — Schweregrad: Niedrig**

`name` wird auf Leere geprüft, `owner` jedoch nicht: `create_job("ok", "   ")` speichert `owner=''`. Beide Parameter rufen zudem `.strip()` ungeschützt auf, sodass `None` als `AttributeError: 'NoneType'-Objekt hat kein Attribut 'strip'` ausgegeben wird, anstatt des `ValueError`, den die API ansonsten bei fehlerhafter Eingabe verwendet. Unbeheoben belassen – der beabsichtigte „owner“-Vertrag ist an keiner Stelle im Fixture angegeben.

**Sicherheit:** keine Befunde. Die Fixture weist keine Schnittstellen für Netzwerk, E/A, Deserialisierung, Unterprozesse oder Anmeldedaten auf; die Speicherung erfolgt in einem prozessinternen Dict.

**Abdeckungslücke:** `scheduler/time_rules.py` und `scheduler/repository.py` wiesen vor diesem Durchlauf eine Testabdeckung von null auf; die beiden vorab festgelegten Tests deckten lediglich den Happy Path des Dienstes ab.

### Durchgeführte Tests und Korrekturen

Die beiden Fehler mit der höchsten Konfidenz waren **D1/D2** (gleiche Funktion, eine Korrektur) und **D3**.

**Korrektur 1 – `scheduler/time_rules.py`:** Der UTC-Roundtrip wurde durch `previous_run + timedelta(days=1)` ersetzt. Python führt bei „aware“-Datums- und Zeitangaben Wall-Clock-Arithmetik durch, und `zoneinfo` ermittelt den UTC-Offset verzögert anhand der neuen Wall-Clock-Zeit neu – somit bleibt 09:00 Uhr weiterhin 09:00 Uhr, während sich der Offset korrekt von `-05:00 → -04:00` verschiebt. Dadurch werden D1 und D2 gemeinsam behoben: Naive Eingaben bleiben nun naiv, und die lokale Zeitzone wird niemals abgeleitet. Der Fall des Übergangs zwischen „unreichbar“ und „mehrdeutig“ wird so dokumentiert, dass auf die „Fold“-Regeln von `tzinfo` zurückgegriffen wird.

**Korrektur 2 – `scheduler/service.py`:** Der instanzspezifische Zähler `_next_identifier` wurde entfernt; Identifikatoren werden nun bei der Erstellung aus dem Repository-Zustand als `max(vorhandene IDs, default=0) + 1` zugewiesen. Dies ist sowohl für gemeinsam genutzte als auch für vorab gefüllte Repositorys korrekt. Kompromiss: O(n) pro Erstellung statt O(1), akzeptabel für einen auf einem Wörterbuch basierenden Speicher im Arbeitsspeicher, und Korrektheit gegenüber einem Zähler, der den Speicher, in den er schreibt, nicht sehen kann.

**Tests — `tests/test_time_rules.py` (neu, 5 Tests):** Beibehaltung der Wanduhrzeit bei Zeitumstellung (Spring-Forward und Fall-Back), absolute verstrichene Zeit von 23 h/25 h über diese Übergänge hinweg, erneute Auflösung des UTC-Offsets, „Naive-Stays-Naive“ sowie eine einfache UTC-Tagesverschiebung. Wird sauber übersprungen, wenn keine IANA-Datenbank vorhanden ist.

**Tests — `tests/test_scheduler.py` (erweitert, +2 Tests):** Zwei Dienste, die sich ein Repository teilen, müssen unterschiedliche IDs vergeben und beide Jobs beibehalten; ein Dienst, der auf ein Repository zugreift, das bereits mit den IDs 1 und 7 vorbelegt ist, muss die ID 8 vergeben und die bestehenden Jobs unverändert lassen.

**Leerheitsprüfung:** Ich habe beide ursprünglichen Implementierungen in einer temporären Kopie wiederhergestellt und die Testsuite erneut ausgeführt – alle 5 neuen Tests schlugen fehl (`FAILED (failures=5)`), und alle Tests wurden mit dem korrigierten Code erfolgreich bestanden. Die Tests decken die Fehler tatsächlich auf.

Eine Korrektur während des Durchlaufs: In meinem ersten Entwurf wurde die verstrichene DST-Zeit als `result - previous` überprüft, was Python als Realzeit-Arithmetik auswertet, wenn beide Operanden dieselbe `tzinfo`-Einstellung verwenden; daher wurde `24h` gelesen und die Tests schlugen fehl. Die Überprüfungen konvertieren nun vor der Subtraktion auf UTC. Der Fehler lag in meinem Test, nicht in der Korrektur.

### Hinweise für den Verantwortlichen

„fixture-manifest.json“ wurde unverändert gelassen, daher ist „tests/test_time_rules.py“ eine zulässige neue Datei, die nicht in „expected_files“ aufgeführt ist – aktualisiere das Manifest, falls eine Prüfung einen exakten Dateisatz vorschreibt. Und D4/D5 wurden zwar gemeldet, aber bewusst nicht behoben: Beide hängen von einer Entscheidung bezüglich des API-Vertrags ab (Semantik bei „miss-on-delete“, Validierungsregeln des Eigentümers), die nirgendwo in der Fixture spezifiziert ist; sich für eine der beiden zu entscheiden, wäre daher eher eine Vermutung als eine Korrektur gewesen.

Keine der beiden Bewertungen macht eine manuelle Überprüfung überflüssig. Nachdem einer der beiden Agenten eine Reparatur abgeschlossen hat, überprüfen Sie die geänderten Schnittstellen, unerwartete Dateibereiche, fehlende Negativtests, Berechtigungen oder den Befehlsverlauf sowie den Rollback-Pfad. Eine überzeugende Erklärung ist kein Ersatz für einen reproduzierbaren Test.

Berechtigungen, Sandboxing und Betriebssicherheit

Ein Programmieragent kann vertraulichen Code lesen, Shell-Befehle ausführen, zahlreiche Dateien ändern und externe Tools aufrufen. Daher ist die Gestaltung der Berechtigungen ein wesentlicher Bestandteil der Produktqualität. Die entscheidenden Fragen lauten: Welche Vorgänge erfordern eine Genehmigung? Auf welche Daten hat der Agent standardmäßig Zugriff? Wie deutlich werden riskante Aktionen im Voraus angezeigt? Und kann ein Entwickler die daraus resultierenden Änderungen überprüfen?.

Man sollte nicht automatisch davon ausgehen, dass weniger Genehmigungsaufforderungen besser sind. Ein reibungsloser Ablauf ist in einer isolierten Testumgebung ohne Anmeldedaten oder Produktionsverbindungen sinnvoll. Das gleiche Verhalten kann jedoch in einem Repository gefährlich sein, das mit Bereitstellungsskripten, echten Kundendaten oder weitreichenden Cloud-Berechtigungen verbunden ist. Umgekehrt können übermäßige Genehmigungsaufforderungen eine sichere Automatisierung unpraktikabel machen und Benutzer dazu verleiten, Anfragen zu genehmigen, ohne sie zu lesen.

Bei unserem Test kamen frische lokale Kopien zum Einsatz – keine Produktionssysteme, keine Bereitstellung und kein menschliches Eingreifen während der Ausführung. Daher wird die Erledigung der Aufgaben unter sicheren Bedingungen bewertet und nicht die relative Sicherheit der beiden Produkte. Bevor Sie eines der beiden Tools für wichtige Aufgaben einsetzen, beginnen Sie mit einem schreibgeschützten Zugriff, legen Sie zulässige Verzeichnisse und Befehle fest, überprüfen Sie die Unterschiede und führen Sie objektive Überprüfungen in einer wiederherstellbaren Umgebung durch.

• Beginnen Sie mit einer schreibgeschützten Architektur oder einem Risikopass.
• Genehmigen Sie nur Befehle, deren Geltungsbereich und Auswirkungen Sie verstehen.
• Bewahren Sie Anmeldedaten, Produktionsdaten und Zugriffsrechte für die Bereitstellung außerhalb der Testumgebung auf.
• Verlangen Sie einen Diff, Tests und einen klaren Rollback-Pfad, bevor Sie das Ergebnis akzeptieren.

MCP, Fähigkeiten, Projektanweisungen und Anpassung

Beide Ökosysteme lassen sich erweitern, doch sollten die Begriffe „Erweiterung“ und „Erweiterungsbedingungen“ nicht als Synonyme betrachtet werden. Projektanweisungen geben einem Agenten vor, wie er sich in einem Repository verhalten soll. Wiederverwendbare Skills bündeln einen wiederholbaren Arbeitsablauf oder Fachwissen. MCP verbindet einen Host mit externen Tools oder Daten. Hooks und Befehle können bestimmte Schritte in einem Entwicklungszyklus automatisieren. Ein Produkt kann in einer Ebene stark sein, ohne eine andere Funktion eins zu eins abzudecken.

Die entscheidende Frage beim Kauf ist nicht, ob es ein Integrationslogo gibt. Es geht vielmehr darum, ob die Verbindung auf dem von Ihnen tatsächlich genutzten Host eingerichtet, authentifiziert, genehmigt und genutzt werden kann. Außerdem muss ein verständlicher Fehlermodus vorhanden sein. Ein MCP-Server, der interaktiv funktioniert, in einer unbeaufsichtigten Sitzung jedoch auf eine Genehmigung wartet, ist zwar immer noch nützlich, sollte aber nicht als reibungslose Automatisierung bezeichnet werden.

Bei wiederverwendbaren Anweisungen gilt ein ähnlicher Vorbehalt. Lange Anweisungsdateien garantieren keine Einhaltung der Vorschriften, und ein übermäßig kompliziertes Regelwerk kann den Kontext überlagern oder Widersprüche hervorrufen. Halten Sie die Repository-Richtlinien kurz, überprüfbar und nah am Code. Geben Sie erforderliche Überprüfungsbefehle, geschützte Bereiche, Stilregeln und die Fälle an, in denen der Agent anhalten und nachfragen muss.

• Projektanleitung: Repository-spezifische Regeln und Überprüfungsbefehle.
• Fähigkeiten: wiederverwendbare Prozeduren oder Fachwissen-Pakete.
• MCP: Anbindungen an externe Tools und Daten.
• Hooks und Befehle: Automatisierung rund um definierte Workflow-Ereignisse.

Codex vs. Claude – Preisgestaltung und Nutzungsbeschränkungen

Der „Clean Consumer“-Vergleich beginnt bei $20 pro Monat. Der Codex-Zugang ist im entsprechenden $20-ChatGPT-Tarif enthalten, während Claude Pro in den Vereinigten Staaten $20 pro Monat kostet und Claude Code umfasst. Beide bieten Tarife für höhere Nutzungsvolumina zu $100 und $200 an. Ähnliche Listenpreise bedeuten nicht, dass die Kapazitäten identisch sind.

Claude “Max 5x” kostet $100 pro Monat und “Max 20x” kostet $200 pro Monat. Die Bezeichnungen „5x“ und „20x“ beschreiben die Nutzung pro Sitzung im Vergleich zur Pro-Version und stellen keine garantierte Anzahl von Programmieraufgaben dar. Claude und Claude Code teilen sich Sitzungs- und Wochenlimits. Die Länge des Kontexts, angehängte Dateien, die Modellauswahl und die Nutzung von Funktionen können beeinflussen, wie schnell das Kontingent aufgebraucht wird.

Die optionalen Nutzungskredite von Claude ermöglichen bei Aktivierung die Fortsetzung berechtigter Vorgänge über das im Paket enthaltene Kontingent hinaus; diese Kredite werden separat zu den üblichen API-Tarifen abgerechnet. Die Authentifizierung per API-Schlüssel stellt einen weiteren, separat abgerechneten Weg dar. Würde man einen dieser Wege als “unbegrenzt” bezeichnen, würde dies die tatsächlichen Grenzkosten verschleiern.

Codex unterscheidet ebenfalls zwischen der Nutzung im Rahmen des enthaltenen Verbraucher-Tarifs, berechtigten gekauften Guthaben und der API-Abrechnung. Für lokale Nachrichten und Cloud-Chats gilt ein Zeitfenster von fünf Stunden, und es können zudem wöchentliche Limits gelten. Ein Token-Feld in einem CLI-Protokoll lässt sich nicht direkt in einen Prozentsatz für fünf Stunden, einen Abonnement-Guthabenbetrag oder eine API-Rechnung umrechnen.

Für gelegentliches Programmieren im Alleingang ist die Stufe $20 auf beiden Seiten der sinnvolle Ausgangspunkt. Die tägliche Arbeit mit Repositorien in langen Kontexten kann eine Stufe mit höherer Auslastung rechtfertigen, jedoch erst nach Beobachtung der tatsächlichen Rücksetzungen und des Aufgabenverbrauchs. Intensive parallele Arbeit erfordert noch mehr Sorgfalt: Die Bezahlung einer größeren Stufe beseitigt nicht die Notwendigkeit, den Kontext zu kontrollieren, Aufgaben aufzuteilen und aufwendige Schlussfolgerungen für Aufgaben zu reservieren, die ein hohes Maß an Urteilsvermögen erfordern.

Ergebnisse unseres kontrollierten Vergleichstests zwischen Codex und Claude Code

Wir haben vier englische Aufgabenstellungen, eine öffentliche Python-Fixture, objektive Prüfungen, eine Bewertungsrubrik und die „First-Valid-Result“-Regel festgelegten, bevor einer der Agenten gestartet wurde. Die Aufgaben umfassten das Verstehen unbekannter Repositorys, eine Funktion mit mehreren Dateien, die Behebung eines DST-Fehlers und eine Code-Review mit Korrekturen. Gültige Ergebnisse wurden ohne menschliches Eingreifen akzeptiert, und schwache, aber gültige Ausgaben konnten nicht erneut ausgeführt werden, um eine bessere Punktzahl zu erzielen.

Codex führte isolierte CLI-Prozesse mit Roh-JSONL durch, wobei die von der CLI ausgegebenen Token-Felder beibehalten wurden. Die OAuth-Sitzung des Kollegen für die Claude-CLI war abgelaufen, daher verwendete Claude Code einen Koordinator mit neuen Subagent-Kontexten. Wir haben die Patches von Claude in sauberen Audit-Kopien rekonstruiert und die öffentlichen sowie die versteckten Prüfungen erneut durchgeführt. Dies lieferte glaubwürdige praktische Beweise, jedoch keine identischen Isolations- oder Modellsteuerungsflächen.

Der Test ist zu klein, um Aussagen über die Leistung bei großen Repositorien, allen Sprachen, allen Modellstufen oder langen autonomen Sitzungen zu treffen. Die Gesamtdifferenz von einem Punkt sollte am besten so interpretiert werden, dass “beide erfolgreich waren, allerdings mit einem Unterschied hinsichtlich der Überprüfungsreichweite”, und nicht als allgemeingültige Rangliste.

Was echte Nutzer berichten – und inwieweit man darauf vertrauen kann

Feedback aus der Community ist dann wertvoll, wenn es ein Projekt, eine Aufgabe, ein Modell, den Umfang des Aufwands und den Zeithorizont umfasst. Es ist hingegen wenig aussagekräftig, wenn in einem Beitrag lediglich berichtet wird, dass ein Produkt “intelligenter wirkt” oder “viel schneller ist”. Verschiedene Nutzer vergleichen unterschiedliche Repositorys, Abonnementstufen, Prompts, Erweiterungen und den Grad der Überwachung.

Das oben angeführte Beispiel aus dem Reddit-Kontext deutet auf einen Kompromiss bei der Interaktion hin: Ein schneller, dialogorientierter Ansatz kann mehr Aufmerksamkeit erfordern, während eine bedächtige Ausführung zwar langsamer wirken mag, dafür aber weniger Korrekturen erfordert. Unser kontrollierter Test überschneidet sich nur teilweise mit diesem Bericht. Er ergab bei gültigen Durchläufen gemischte Geschwindigkeiten und keine menschlichen Eingriffe, sodass die Behauptung bezüglich der „Betreuung“ nicht bestätigt werden kann. Genau aus diesem Grund sollten Community-Befunde und kontrollierte Befunde gemeinsam dargestellt werden, ohne sie miteinander zu vermischen.

Der Kommentar zum X-Harness bringt einen zweiten wichtigen Punkt auf den Punkt: Ein Ergebnis der Codierung bezieht sich auf das gesamte System und nicht nur auf die Modellbezeichnung. Keiner der beiden Beiträge sollte als Umfragedaten betrachtet werden. Nutzen Sie sie, um Fragen für Ihre eigene Studie zu identifizieren – Anzahl der Interventionen, Größenordnung der Abweichung, Testqualität und Erholung von einer falschen Annahme.

Erweiterung von Codex und Claude-Code um GlobalGPT

GlobalGPT ist ein multimodeller, multimodaler Arbeitsbereich, kein Ersatz für native Repository-Agenten. Seine praktische Aufgabe besteht darin, einen bestehenden Host zu erweitern: ein anderes verfügbares Agentenmodell für eine Zweitmeinung, eine Planprüfung, einen Dokumentationsdurchlauf oder spezielle Ausgabedaten zu nutzen, während Codex oder Claude Code weiterhin für den Repository-Zugriff, Shell-Befehle, Tests und Freigaben zuständig bleibt.

GlobalGPT veröffentlicht eigene CLI-Anleitungen für Codex und Claude-Code, sowie Cursor. In unserem sicheren T5-Integrationstest führte die CLI dieselbe „frozen“-Aufgabe in beiden verglichenen Umgebungen aus. In Codex haben wir außerdem einen schreibgeschützten Aufruf der MCP-Modellliste überprüft und den GlobalGPT-Skill installiert, geladen und verwendet.

# GlobalGPT Zusammenfassung des Integrationstests

## Umfang

T5 misst die GlobalGPT-Integration und wird bei der Berechnung der nativen Codex-Codierungsbewertung nicht berücksichtigt. Yukie wurde nicht verwendet.

## Modellsperre und Bereitschaft

- Modell A: `gpt-5.6-sol`
- Modell B: `gpt-5.6-luna`
- Beide Modelle erschienen in der Liste der Live-Modelle.
- Beide Lightweight-Bereitschaftsprüfungen lieferten gültigen, analysierbaren Text.
- Die Modelle wurden vor den formalen T5A- und T5B-Ausgaberufen gesperrt.

## Formale CLI-Ergebnisse

| Aufgabe | Modell | Status | Dauer | Prompt-Token | Fertigstellungs-Token | Erforderliche Überschriften |
|---|---|---|---:|---:|---:|---:|
| T5A | gpt-5.6-sol | Gültig | 27 s | 2.116 | 1.207 | 6/6 |
| T5B | gpt-5.6-luna | Gültig | 14 s | 2.116 | 1.441 | 6/6 |

Beide formalen Aufrufe verwendeten über `glbgpt exec` dieselbe eingefrorene englische Produktplanungsaufgabe, lieferten ausschließlich auf Englisch sichtbare Ausgaben und legten keine Anmeldedaten offen. Es erfolgte keine Qualitätswiederholung.

## MCP-Ergebnis

- `codex mcp list` zeigte an, dass `globalgpt` aktiviert war.
- Eine nicht-interaktive Codex-Sitzung erkannte `mcp__globalgpt__glbgpt_list_models` und versuchte, diesen Aufruf auszuführen, doch der Aufruf wurde abgebrochen, da keine unbeaufsichtigte MCP-Genehmigung verfügbar war. Es wurden keine Sicherheitseinstellungen gelockert.
- Die aktive interaktive Codex-Sitzung rief erfolgreich dasselbe schreibgeschützte GlobalGPT-MCP-Tool auf und erhielt neun Chat-Modelle.
- Ergebnis: Interaktiver MCP-Zugriff verifiziert; die unbeaufsichtigte, nicht-interaktive MCP-Ausführung unterliegt weiterhin einer Genehmigungsbeschränkung.

##-Skill-Ergebnis

- Die GlobalGPT- und GlobalGPT-Coding-Skills wurden über Verknüpfungen zum mitgelieferten CLI-Skill-Paket im Codex-Skill-Verzeichnis installiert.
- Die GlobalGPT-Skill wurde geladen und hinsichtlich der Überprüfung der konfigurierten Sitzung, der Auswahl von Live-Modellen, der Betriebsbereitschaft, der kreditsicheren Optionen und der Fehlerbehandlung getestet.
- Ergebnis: Im aktiven Codex-Workflow installiert und getestet.

## Eingeschränkte Schlussfolgerung

Dieser Durchlauf verifiziert funktionierende GlobalGPT-CLI-Aufrufe, einen interaktiven GlobalGPT-MCP-Aufruf (nur Lesezugriff) aus Codex sowie einen installierten und verwendeten GlobalGPT-Skill-Pfad. Er beweist nicht, dass jedes Modell, jedes Medientool, jeder Host, jedes Konto oder jede unbeaufsichtigte MCP-Konfiguration funktioniert. Er testet weder Yukie noch stützt er die Behauptung, dass GlobalGPT Codex oder Claude Code ersetzt.

Die Abgrenzung ist entscheidend. Der Claude-Lauf des Kollegen hat den CLI-Pfad überprüft, nicht den MCP auf der Claude-Seite. Das Skill war dort installiert, wurde aber für die eingefrorenen Anrufe nicht verwendet. Ein unbeaufsichtigter Codex-MCP-Versuch erforderte weiterhin eine manuelle Genehmigung. Die Verfügbarkeit von Modellen und Guthaben hängt zudem vom aktuellen GlobalGPT-Tarif ab, daher sollten Entwickler die Live-Liste überprüfen, anstatt davon auszugehen, dass jedes Modell enthalten ist.

GlobalGPT deckt außerdem Bild-, Video-, Audio- und geführte Agent-Workflows ab. Yukies Einträge zu Folien, Dokumenten und Bildern bilden eine eigene Kategorie: Sie bieten konkrete Vorlagen und eine Schritt-für-Schritt-Anleitung im Browser für Aufgaben, die keine Programmierung erfordern. Das kann einfacher sein, als eine Programmier-CLI zu öffnen, um eine Präsentation oder ein strukturiertes Dokument zu erstellen, ersetzt jedoch nicht das Lesen des Repositorys, die Durchführung von Tests oder die Codeüberprüfung.

Welches Programmierwerkzeug sollte ein unabhängiger Entwickler wählen?

• Wählen Sie „Codex“ wenn die kompakte, begrenzte Ausführung, die Kombination der verfügbaren Oberflächen oder die in Ihrer Konfiguration verfügbaren Ausführungsdaten zu Ihrer Arbeitsweise passen.
• Wählen Sie den Code Claude wenn eine Dialog-Terminal-Schleife, die von Ihnen überprüften Anpassungsfunktionen oder ein umfassenderes Überprüfungsverhalten, wie es in unserem Testfall zu beobachten ist, eine größere Rolle spielen.
• Verwenden Sie eine der beiden Optionen für ein unbekanntes Repository erst nach einer Überprüfung der schreibgeschützten Architektur und einer Risikobewertung. Beide Tools haben diese Aufgabe gut gemeistert.
• Verwende beide gezielt wann sich die Überprüfung durch einen zweiten Bearbeiter trotz der zusätzlichen Abonnement- und Koordinationskosten lohnt. Bitten Sie das zweite Tool, einen Diff oder Plan zu hinterfragen, anstatt die Aufgabe blind zu wiederholen.
• GlobalGPT hinzufügen wenn die Routing-Funktionalität für mehrere Modelle oder multimodale Aufgaben die fehlende Ebene darstellt. Behalten Sie native Repository-Operationen im Programmierhost bei.

Eine siebentägige Testphase ist aussagekräftiger als eine Rangliste. Wählen Sie eine reale, aber nicht produktive Funktion oder einen Fehler aus und überprüfen Sie diese. Sperren Sie die Eingabeaufforderung und den Befehl „success“. Zeichnen Sie den ersten gültigen Diff, die bestandenen Tests, die verstrichene Zeit, menschliche Eingriffe, unerwarteten Umfang und die Auswirkungen der Arbeit auf Ihre verfügbare Nutzung auf. Das bessere Produkt ist dasjenige, dessen Fehler Sie erkennen und dessen Arbeitsablauf Sie aufrechterhalten können.

FAQ zu Codex vs. Claude-Code

Ist Codex besser als der Claude-Code?

Nicht in allen Fällen. Beide haben die vier Aufgaben in unserem Testablauf erfüllt. Claude Code war hinsichtlich des Umfangs der Überprüfung führend, während Codex bei Teilen der Implementierung und der Fehlerbehebung kompakter war.

Was eignet sich besser für große Repositorys?

Unser kleines Tool kann diese Frage nicht beantworten. Testen Sie beide Varianten zunächst in einer schreibgeschützten Architekturumgebung aus Ihrem eigenen Repository, bevor Sie Änderungen zulassen.

Welches Codierungsmittel erfordert weniger Überwachung?

Das hängt von der Klarheit der Aufgabe, den Modelleinstellungen, den Anweisungen im Repository und dem gewünschten Interaktionsstil ab. Ein Reddit-Nutzer berichtete von unterschiedlichen Überwachungsmustern, doch diese individuelle Erfahrung stellt keine produktweite Regel dar.

Was ist günstiger?

Die wichtigsten Verbrauchstufen liegen bei $20, $100 und $200 pro Monat, unterscheiden sich jedoch hinsichtlich der enthaltenen Kapazität und der Limitmechanismen. Optionale Gutschriften und die API-Abrechnung werden separat behandelt.

Gibt es bei den Tarifen Claude und Claude Nutzungsbeschränkungen für Code-Sharing?

Ja. Bei den Tarifen „Claude“ und „Claude Code“ gelten bei den verbundenen Pro- oder Max-Tarifen gemeinsame Sitzungs- und Wochenlimits.

Gelten für lokale und Cloud-Aufgaben in Codex dieselben Beschränkungen?

Für lokale Nachrichten und Cloud-Chats gilt ein Zeitfenster von fünf Stunden; außerdem können wöchentliche Obergrenzen gelten.

Kann GlobalGPT den Codex oder den Claude-Code ersetzen?

Nein. Es kann zwar beide Workflows um zusätzliche Modelle, CLI, MCP, Skills und multimodale Tools erweitern, doch der Zugriff auf das Repository und das Verhalten der Programmier-Agenten verbleiben auf dem Host.

Kann ich GlobalGPT aus beiden Produkten verwenden?

GlobalGPT bietet für beide offizielle CLI-Tutorials an. Wir haben die CLI-Nutzung in beiden Umgebungen sowie die Nutzung von MCP und Skill in Codex überprüft, wobei für den unbeaufsichtigten MCP-Einsatz eine Genehmigungsbeschränkung gilt.

Preise, Tarifbedingungen, Integrationen und Quellenangaben wurden im Juli 2026 überprüft. Produktdetails können sich ändern.

Geöffnet GlobalGPT wenn Sie Ihren bestehenden Kodierungs-Workflow um eine modellübergreifende und multimodale Ebene erweitern möchten.