Codex versus Claude-code: welk coderingsprogramma past bij uw workflow?

Bij Codex versus Claude gaat het niet zozeer om het vinden van één universele winnaar, maar meer om het kiezen van de werkwijze waarop je elke dag kunt vertrouwen. Beide producten kunnen een repository doorzoeken, meerdere bestanden bewerken, opdrachten uitvoeren, tests uitvoeren en een patch toelichten. De wezenlijke verschillen zitten in de manier waarop je taken delegeert, hoe vaak je de agent aanstuurt, hoeveel gegevens je kunt bekijken en hoe elk hulpmiddel aansluit bij je bestaande ontwikkelomgeving.

In onze gecontroleerde test met vier taken scoorde Codex 98/100 en Claude Code 99/100. Beide voltooiden de kerntaak. Claude Code liet een bredere dekking van de beoordeling en randgevallen zien, terwijl Codex in onze opstelling vaak met een kleinere reikwijdte het vereiste resultaat bereikte en sterker bewijs op uitvoeringsniveau leverde. Een verschil van één punt bij een kleine Python-testcase is geen reden om een algemene winnaar aan te wijzen.

Ontwikkelaars die niet willen dat de rest van hun workflow aan één programmeeragent gebonden is, kunnen GlobalGPT toevoegen als een afzonderlijke multi-model- en multimodale laag. GlobalGPT integreert meer dan 100 topmodellen, zoals GPT 5.6, Claude Opus 5 en GPT Image 2, in één dashboard. Bovendien, de GlobalGPT CLI, MCP- en Skill-routes kunnen vanuit Codex of Claude Code worden gebruikt voor second opinions, planning, documentatie of andere ondersteunde modellen, terwijl de eigen codeeromgeving de controle behoudt over wijzigingen in de repository en tests.

Probeer meer dan 100 topmodellen op GlobalGPT

De vergelijking combineert officiële informatie over de platformen, praktische ervaring met de repositories, volledige en uitbreidbare output en duidelijk beschreven ervaringen van de community. Het doel is om een onafhankelijke ontwikkelaar te helpen bij het kiezen van een primair programmeerplatform, zonder verwarring te veroorzaken over abonnementstoegang, extra credits en API-facturering.

Codex versus Claude-code in één oogopslag

De tabel geeft een aankoopbeslissing weer, geen ranglijst van modellen. Een andere modelinstelling, repository, machtigingsconfiguratie of taakspecificatie kan het resultaat beïnvloeden. Als je al een product gebruikt, kun je het beste een afgebakende taak uit je eigen codebase vergelijken met hetzelfde succescommando en zonder herhalingen op basis van kwaliteit.

Wat Codex en de Claude-code eigenlijk zijn

Codex en Claude Code zijn productnamen, niet louter modelnamen. De onderliggende AI-model voor codering is belangrijk, maar de bijbehorende infrastructuur bepaalt ook welke bestanden de agent kan inzien, welke commando’s hij mag uitvoeren, hoe goedkeuringen werken, hoe de context wordt behouden en welke gegevens na afloop van de taak bewaard blijven. Als je alleen de reputatie van het model vergelijkt, laat je een groot deel van de ervaring die een ontwikkelaar koopt buiten beschouwing.

Codex ondersteunt zowel command-line-, IDE-, desktop- als cloudgerichte workflows. Dankzij dit brede scala is het geschikt voor zowel directe lokale samenwerking als meer afgebakende delegatie. Claude Code is gericht op een conversatiegerichte terminal-workflow met ondersteunde integraties en uitgebreide aanpassingsmogelijkheden; dit handleiding voor het gebruik van Claude bij het coderen biedt een uitgebreidere inleiding tot die workflow. Voor sommige ontwikkelaars is het geruststellend om een agent in de terminal aan het werk te zien. Voor anderen zijn de uiteindelijke diff, de tests en het audittraject belangrijker dan een voortdurende dialoog.

Dit onderscheid verklaart ook waarom twee tests die gebruikmaken van modellen die op papier sterk zijn, zich anders kunnen gedragen. De host bepaalt hoe instructies worden gepresenteerd, hoe tools worden aangeroepen en wanneer een mens een actie moet goedkeuren. Vergelijkingen binnen de gemeenschap die geen rekening houden met het testraamwerk, kunnen gedrag op productniveau verwarren met de waarheid op modelniveau.

• Het model biedt redeneervermogen en generatievermogen.
• De bedrading van de agent bestanden, opdrachten, context, goedkeuringen en herstel.
• Het taakcontract van de gebruiker bepaalt de reikwijdte, de succescontroles en wanneer de agent moet stoppen.

Werkproces en aansturing: delegeren of voortdurende sturing?

De meest nuttige vraag bij de afweging tussen Codex en Claude is vaak niet “Welke levert betere code op?”, maar “Hoe wil ik ermee werken?” Een duidelijke, afgebakende taak kan worden gedelegeerd met een exacte doelstelling, een toegestane reikwijdte en een verificatieopdracht. Bij een dubbelzinnige refactor is het nuttig om te overleggen, tussentijds te controleren en de uitvoerder bij te sturen voordat er te veel verandert.

Continu sturen is waardevol wanneer de vereisten veranderen of er nog onderhandeld wordt over architecturale keuzes. Het wordt een kostenpost wanneer de agent herhaaldelijk om beslissingen vraagt die op basis van instructies uit de repository hadden kunnen worden opgelost. Autonome uitvoering is waardevol wanneer de taakomschrijving stabiel is. Het wordt riskant wanneer de agent ongecontroleerde aannames doet of de reikwijdte uitbreidt zonder een duidelijk terugdraaipad.

In een uitgebreid Reddit-verslag van 13 april 2026 werd beschreven dat er ongeveer 100 uur met Claude Code en 20 uur met Codex was besteed aan een Python- en TypeScript-project van ongeveer 80.000 regels met zo’n 2.800 tests. De auteur omschreef Claude als sneller en interactiever, maar met meer begeleiding, en Codex als langzamer en bedachtzamer. Dat verslag is buitengewoon nuttig omdat het de context van het project en de ervaring bevat, maar het geeft nog steeds de workflow van één ontwikkelaar weer.

Onze eigen tijdmetingen leverden geen eenduidige winnaar op. Claude voltooide de eerste twee taken sneller, terwijl Codex de laatste twee sneller afwerkte. Claude maakte bovendien gebruik van een uitwijkoplossing via een subagent toen het CLI-authenticatiepad niet beschikbaar was, waardoor de uitvoeringsroutes niet volledig vergelijkbaar waren. De verantwoordelijke conclusie is dat de snelheid afhangt van de taak, het gekozen model, de instelling voor de inspanningsgraad, de context en de host – en niet dat één van beide producten altijd sneller is.

Inzicht in de repository en contextbeheer

Inzicht in de repository gaat verder dan het benoemen van mappen. Een bruikbare tool moet kunnen traceren hoe gegevens tussen bestanden worden uitgewisseld, afspraken identificeren die een wijziging beperken, tests lokaliseren, een symptoom onderscheiden van de waarschijnlijke oorzaak ervan, en het risico uitleggen van het bewerken van de verkeerde laag. Een uitgebreide kaart kan verborgen inconsistenties aan het licht brengen; een beknopte kaart kan een ontwikkelaar sneller naar een veilige implementatiebeslissing leiden.

In onze T1-taak (alleen lezen) scoorden beide agents 20/20 en baseerden ze hun antwoorden op de repository. Claude Code was grondiger en bracht extra inconsistenties in de contracten aan het licht. Codex was compacter, maar identificeerde toch de relevante bestanden, risico’s en het implementatieplan. Geen van beide stijlen is per definitie superieur. Uitputtendheid helpt bij onbekende migraties en audits; beknoptheid helpt wanneer de ontwikkelaar de architectuur al kent en een gericht wijzigingsplan wil.

Architectuur: model, opslagplaats, service en een ‘unwired time’-hulpprogramma.

Belangrijkste risico’s: onduidelijke prioriteitssemantiek, compatibiliteit, volgorde, validatie en afwijkingen in het toepassingsgebied.

Drie lagen plus één losstaande module. Geen cycli; minimale afhankelijkheidsinjectie.

Daarnaast kwamen ook de toewijzing van identificatiecodes, asymmetrische foutcontracten en een beperkte testdekking aan het licht.

##-architectuur

Dit is een klein Python-pakket dat uitsluitend gebruikmaakt van de standaardbibliotheek en vier functionele lagen bevat:

- **Datamodel:** [`Job`]() is een onveranderlijke dataclass die `identifier`, `name` en `owner` bevat. `Job.to_dict()` serialiseert deze via `dataclasses.asdict()`.
- **Repository:** [`JobRepository`]() slaat taken op in een woordenboek in het geheugen, met `identifier` als sleutel. Er is geen database of duurzame opslag.
- **Service:** [`SchedulerService`]() is verantwoordelijk voor de toewijzing van identifiers, het normaliseren van invoer, het aanmaken, weergeven en verwijderen van taken.
- **Tijdfunctie:** [`next_daily_run()`]() berekent een volgend uitvoeringstijdstip, maar er is geen import of koppeling met `Job`, `SchedulerService` of `JobRepository`.
- **Openbare API:** [`scheduler.__init__`]() exporteert alleen `SchedulerService`.

Ondanks de naam van de repository bevatten jobs momenteel geen planningsinformatie en is er geen uitvoeringswachtrij. Prioriteit kan daarom van invloed zijn op opgeslagen metadata en de volgorde in de lijst, maar heeft geen invloed op de daadwerkelijke uitvoering van de taak zonder het systeem aanzienlijk uit te breiden.

## Gegevensstroom bij het aanmaken en weergeven

Aanmaken via `SchedulerService.create_job(name, owner)`:

1. [`create_job()`]() weigert een naam die uitsluitend uit witruimte bestaat.
2. Het verwijdert overbodige witruimte uit `name` en `owner` en construeert vervolgens een onveranderlijk `Job`-object met behulp van de `_next_identifier` van de service.
3. [`JobRepository.save()`]() schrijft het object naar `_jobs[job.identifier]`.
4. De service verhoogt de waarde van `_next_identifier` en retourneert hetzelfde `Job`-object.

Lijst weergeven via `SchedulerService.list_jobs()`:

1. [`list_jobs()`]() delegeert rechtstreeks naar `repository.all()`.
2. [`JobRepository.all()`]() sorteert de sleutels van het woordenboek op numerieke waarde.
3. Taken worden daarom geretourneerd in oplopende volgorde van identifier/aanmaakdatum, niet op basis van planning of prioriteit.

## Bestanden die waarschijnlijk worden beïnvloed door taakprioriteiten

Vereist:

- [`scheduler/models.py`](): voeg het veld `priority` toe, evenals een eventuele standaardwaarde. `to_dict()` neemt dit automatisch op omdat het gebruikmaakt van `asdict()`.
- [`scheduler/service.py`](): accepteer, valideer en geef de prioriteit door aan `Job`.
- [`tests/test_scheduler.py`](): test het gedrag bij standaardwaarden, expliciete waarden, ongeldige waarden, geserialiseerde waarden en de volgorde.

Voorwaardelijk:

- [`scheduler/repository.py`](): wijzig `all()` alleen als prioriteiten bedoeld zijn om de volgorde in de lijst te bepalen. Een deterministische secundaire sleutel zoals `identifier` moet gelijke standen afhandelen.
- [`scheduler/__init__.py`](): alleen bijwerken als prioriteit een openbare enum of een waardeobject wordt.
- [`README.md`](): documenteer de toegestane waarden, de standaardwaarde en de volgorderegels.

Waarschijnlijk niet betrokken:

- `scheduler/time_rules.py`, omdat het enige symbool daarin werkt op een opgegeven datum-tijd en geen verband houdt met taken of de weergave.

## Belangrijke risico’s

- **Ongedefinieerde semantiek:** De code biedt geen houvast voor de vraag of grotere of kleinere waarden een hogere prioriteit betekenen, welke waarden geldig zijn, of dat prioriteit überhaupt invloed heeft op de weergave in de lijst.
- **Compatibiliteit:** Het toevoegen van een verplicht argument aan `Job` of `create_job()` zou bestaande aanroepen, zoals `create_job("Daily report", "Alex")` in de huidige test, onbruikbaar maken. Een standaardwaarde zorgt ervoor dat die aanroep behouden blijft.
- **Problemen met positionele constructie:** `Job` wordt momenteel positioneel geconstrueerd in `SchedulerService.create_job()`. De plaatsing van velden en toekomstige positionele aanroepen zouden stilletjes de verkeerde waarden kunnen toewijzen; constructie met trefwoorden zou veiliger zijn.
- **Gewijzigde volgorde:** Het vervangen van de volgorde van identificatoren in `JobRepository.all()` verandert het vastgestelde gedrag. Bij gelijke prioriteiten is een stabiele beslissingsfactor nodig.
- **Dubbelzinnigheid bij validatie:** Een onbeperkte Python-waarde zou strings, booleaanse waarden of willekeurige gehele getallen kunnen toestaan die moeilijk consistent te vergelijken zijn.
- **Discrepantie in uitvoeringsbereik:** Er is geen dispatcher of uitvoeringswachtrij. De bewering dat prioriteit bepaalt welke taak als eerste wordt uitgevoerd, wordt door geen enkel huidig symbool ondersteund.
- **Beperkingen in het geheugen:** Prioriteit verdwijnt, net als elk ander taakveld, wanneer het proces eindigt, omdat `_jobs` slechts een instantie-woordenboek is.

## Implementatie- en validatieplan

1. Definieer eerst het contract: representatie, toegestane waarden, standaardwaarde, richting van de prioriteit, beslissingsregels bij gelijke waarden en of het de volgorde in de lijst wijzigt.
2. Voeg `priority` toe aan `Job`, bij voorkeur met een achterwaarts compatibele standaardwaarde.
3. Breid `SchedulerService.create_job()` uit met een prioriteitsparameter met standaardwaarde, valideer deze en construeer `Job` met trefwoordargumenten.
4. Als de weergave rekening houdt met prioriteit, pas dan `JobRepository.all()` aan om eerst op prioriteit en vervolgens op identificatiecode te sorteren. Laat de volgorde in de repository anders ongewijzigd.
5. Voeg tests toe voor:
   - Bestaande aanmaak met twee argumenten.
   - Expliciete behoud van prioriteit.
   - Standaardprioriteit.
   - Ongeldige typen en waarden buiten het bereik.
   - Uitvoer van `Job.to_dict()`.
   - Weergavevolgorde bij meerdere prioriteiten.
   - Stabiele volgorde bij gelijke prioriteiten.
   - Bestaand gedrag bij lege namen.
6. Werk de README bij met het exacte openbare contract.
7. Voer de volledige offline testsuite uit met `python3 -m unittest discover -s tests -v`.

## Verificatie uitgevoerd

- Baseline-testsuite: **2 tests geslaagd**.
- Symboolzoekopdracht in de gehele repository bevestigt dat `next_daily_run()` is losgekoppeld en dat er geen bestaande prioriteitssymbolen zijn.
- Gewijzigde bestanden: **geen**.
- Implementatie van de functie: **niet uitgevoerd**, zoals vereist.

> **Conclusie + besluit**
>
> De wijziging is klein als prioriteit alleen betrekking heeft op metagegevens of de volgorde in de lijst: voornamelijk `models.py`, `service.py`, `repository.py` en tests. Vóór de implementatie moet worden besloten of prioriteit louter een taak beschrijft of de volgorde van `list_jobs()` wijzigt, plus de waardeschaal, standaardwaarde, richting en regel voor het doorbreken van gelijke standen.

# T1-uitvoeringsverslag — Inzicht in onbekende repository

## Uitvoeringsparameters

| Veld | Waarde |
| --- | --- |
| Taak | `T1` |
| Bevroren prompt | `01-prompts/T1.md` |
| SHA-256 van bevroren prompt | `a571ff15c2502ec29b172ae2e77dd9ab0caca2869b91f9468d47571434d16c17` |
| Uitvoeringseenheid | geïsoleerde Claude-subagent, `general-purpose`, nieuwe context |
| Isolatiemethode | **subagent-fallback** (gedocumenteerde downgrade — zie `results/isolation-decision.md`) |
| Toegewezen schone kopie | `runtime/workspaces/T1` |
| Claude-codeversie | `2.1.220` |
| Modelinstelling | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:31Z` |
| end_utc | `2026-07-28T10:28:32Z` |
| Duur | 61 s (gelijktijdig met T2–T4; geen zuivere latentietijdmeting) |
| Pogingnummer | 1 |
| Status | `geldig` |
| Menselijke tussenkomst | geen |

## Samenvatting veilige tool

`date`, `find`, `ls`, `wc`, `stat`, `grep`, `Read` op 7 werkruimtebestanden, `python3 -V`,
`python3 -m unittest discover -s tests -v`. Alle leesbewerkingen beperkt tot de toegewezen werkruimte.
Geen netwerk, geen installaties, geen schrijfbewerkingen.

## Resultaat van de offline controle

`python3 -m unittest discover -s tests -v` → 2 tests, OK (exit 0). Opnieuw geverifieerd door de
coördinator van buiten de werkruimte: zie `results/checks/T1-public.txt`.

## Patch

Geen. `results/T1/patch.diff` is leeg en `diff -ru 02-fixture runtime/workspaces/T1`
levert geen verschillen op. De taak vereiste inspectie zonder bestanden te wijzigen; dit is
bevestigd in plaats van beweerd.

## Opgeschoonde fouten

Eén herstelbare shell-fout: een eerste `grep` gebruikte patronen `--include=*.py` zonder aanhalingstekens, die
de shell probeerde te globben; bij herhaling met patronen tussen aanhalingstekens lukte het wel. Geen invloed op de bevindingen.

## Zichtbare uitvoer (letterlijk)

### 1. Wat deze repository is

Een op zichzelf staande Python-standaardbibliotheek-fixture met de naam `local-scheduler-1.0.0` (`fixture-manifest.json`), onder MIT-licentie, zonder netwerk- of productieafhankelijkheid (`README.md`, `"network_required": false`). Het is erg klein: 8 bron- en documentatiebestanden plus het manifest, in totaal 103 regels. De gebruikte interpreter is **Python 3.9.6**. Er is geen `pyproject.toml`, `setup.py`, CI-configuratie, linter of type-checker-configuratie — de enige gedeclareerde workflow is `python3 -m unittest discover -s tests -v` (`README.md`).

### 2. Architectuur

Drie lagen plus één losstaande module, allemaal onder `scheduler/`:

| Laag | Bestand | Symbool | Verantwoordelijkheid |
|---|---|---|---|
| Pakketfaçade | `scheduler/__init__.py` | `__all__ = ["SchedulerService"]` | Exporteert alleen `SchedulerService` opnieuw; `Job`, `JobRepository` en `time_rules` maken geen deel uit van het openbare oppervlak |
| Domeinmodel | `scheduler/models.py` | `Job` (`@dataclass(frozen=True)`) | Onveranderlijk waardeobject met velden `identifier: int`, `name: str`, `owner: str`, plus `to_dict()` geïmplementeerd als `asdict(self)` |
| Persistentie | `scheduler/repository.py` | `JobRepository` | In-memory `dict` met `identifier` als sleutel; `save`, `get`, `all`, `delete` |
| Applicatieservice | `scheduler/service.py` | `SchedulerService` | Validatie, toewijzing van identificatiecodes, coördinatie: `create_job`, `list_jobs`, `delete_job` |
| Orphan | `scheduler/time_rules.py` | `next_daily_run` | Rekenregels voor herhaling — **wordt door niets geïmporteerd** |

De afhankelijkheid is duidelijk en eenrichtingsverkeer: `service.py` importeert uit `.models` en `.repository`; `repository.py` importeert uit `.models`; `models.py` importeert alleen `dataclasses`. Geen cycli. Afhankelijkheidsinjectie is aanwezig maar minimaal — `SchedulerService.__init__(self, repository=None)` voert `self.repository = repository or JobRepository()` uit, zodat in tests een nep-repository kan worden ingezet.

Merk op dat `scheduler/time_rules.py` op dit moment dode code is. Ik heb de hele boomstructuur doorzocht op `time_rules` en `next_daily_run`; de enige treffers zijn de eigen definitie ervan en de vermelding in `expected_files` van `fixture-manifest.json`. Het wordt meegeleverd, maar is niet aangesloten.

### 3. Gegevensstroom

**Een taak aanmaken** — `SchedulerService.create_job(name, owner)`:
1. Controle: `if not name.strip(): raise ValueError('name is required")`. Dit is de *enige* validatie in het systeem — `owner` wordt nooit gecontroleerd, dus een lege eigenaar wordt geaccepteerd.
2. Constructie: `Job(self._next_identifier, name.strip(), owner.strip())` — positionele constructie, waarbij beide strings worden genormaliseerd door het verwijderen van de leiders.
3. Opslaan: `self.repository.save(job)`, wat `self._jobs[job.identifier] = job` uitvoert en de taak retourneert.
4. De teller verhogen: `self._next_identifier += 1` — *na* het opslaan, zodat bij een gegenereerde uitzondering de teller ongebruikt blijft.
5. De `Job`-instantie retourneren (de service retourneert zijn eigen lokale `job`, niet de retourwaarde van de repository).

De toewijzing van identificatiecodes vindt plaats in de **service**, niet in de repository (`self._next_identifier = 1` in `SchedulerService.__init__`). Dit is een belangrijk aandachtspunt: het injecteren van een repository die al taken bevat, zal deze stilzwijgend overschrijven, omdat de nieuwe service de nummering opnieuw begint bij 1.

**Taken weergeven** — `SchedulerService.list_jobs()` is een rechtstreekse doorverwijzing naar `JobRepository.all()`, die `[self._jobs[key] for key in sorted(self._jobs)]` retourneert. De volgorde is daarom **oplopend op basis van de gehele getal-identificatie**, wat momenteel samenvalt met de invoegvolgorde. Bij elke aanroep wordt een nieuwe lijst opgebouwd, maar de `Job`-objecten zijn gedeelde verwijzingen — dit is alleen veilig omdat `Job` bevroren is.

**Verwijderen** — `SchedulerService.delete_job(identifier)` delegeert naar `JobRepository.delete`, wat neerkomt op `self._jobs.pop(identifier)` zonder standaardwaarde, waardoor er een `KeyError` wordt gegenereerd bij een ontbrekende id. Dit is niet consistent met `JobRepository.get`, dat onder dezelfde voorwaarde `None` retourneert.

**Testdekking van deze paden** — `tests/test_scheduler.py` bevat precies twee gevallen: `test_create_and_list_jobs` (controleert of `job.identifier == 1` en `[job] == service.list_jobs()`) en `test_blank_name_is_rejected`. Beide slagen in de huidige boomstructuur.

### 4. Bestanden die waarschijnlijk worden beïnvloed door het toevoegen van taakprioriteiten

In aflopende volgorde van zekerheid:

1. **`scheduler/models.py`** — zeker. `Job` heeft een `priority`-veld nodig. Omdat de dataclass `frozen=True` is en velden positioneel zijn, moet een nieuw veld een standaardwaarde hebben (bijv. `priority: int = 0`) of het moet na de bestaande drie worden geplaatst, anders gaat elke bestaande positionele constructie kapot. `to_dict()` hoeft niet te worden aangepast — `asdict(self)` pikt het veld automatisch op, wat een stille wijziging in het serialisatiecontract is in plaats van een codewijziging.
2. **`scheduler/service.py`** — zeker. `create_job` heeft een `priority`-parameter nodig en moet deze doorgeven aan de positionele constructor `Job(...)` op regel 13. Als de prioriteit wordt gevalideerd (bereik, lidmaatschap van een enum), hoort de guard naast de bestaande `name.strip()`-controle te staan. Als de lijst op prioriteit moet worden gesorteerd, is `list_jobs` de plek waar een sorteerbeleid zou moeten staan als je wilt dat de repository een "domme' opslag blijft.
3. **`scheduler/repository.py`** — waarschijnlijk. `sorted(self._jobs)` van `JobRepository.all()` sorteert de *sleutels* van het dict, d.w.z. de identificatiecodes. Voor een op prioriteit gesorteerde lijst moet dit worden aangepast om de waarden te sorteren op een sleutel zoals `(-job.priority, job.identifier)`, of moet er een aparte geordende accessor worden toegevoegd. Laat de tie-break niet impliciet: de invoegvolgorde in het dict is geen stabiele garantie waarop je kunt vertrouwen.
4. **`tests/test_scheduler.py`** — zeker. Nieuwe testgevallen voor standaardprioriteit, expliciete prioriteit, rangschikking en afwijzing bij ongeldige prioriteit. Merk op dat de bestaande `assertEqual([job], service.list_jobs())` *hetzelfde* object vergelijkt, zodat deze test een toevoeging van een veld doorstaat; dit zou niet het geval zijn als er een pas aangemaakte `Job`-literaal zou worden vergeleken.
5. **`README.md`** — waarschijnlijk, als de prioriteitssemantiek (welk uiteinde van het bereik wint, standaardwaarde) ergens moet worden vermeld.
6. **`scheduler/__init__.py`** — alleen als een prioriteitsenumeratie of constanten samen met `SchedulerService` moeten worden geëxporteerd.
7. **`fixture-manifest.json`** — alleen als je een nieuw modulebestand toevoegt; de `expected_files`-array is een expliciete inventaris en zou afwijken.
8. **`scheduler/time_rules.py`** — mag *niet* worden aangepast. Prioriteit staat los van herhaling, en deze module is niet gekoppeld.

### 5. Belangrijke risico’s

- **De volgordesemantiek is een stille gedragswijziging.** `JobRepository.all()` garandeert momenteel een oplopende volgorde op basis van de identifier en `list_jobs` neemt dit over. Elke gebruiker die op die garantie vertrouwt, ondervindt problemen door het opnieuw sorteren. Beslis expliciet: verandert de betekenis van `list_jobs()`, of verschijnt er naast deze functie een nieuwe `list_jobs_by_priority()`? De eerste optie brengt het grootste risico met zich mee en de bestaande test `test_create_and_list_jobs` is te zwak om een regressie op te sporen (lijst met één element).
- **De sorteerrichting is echt dubbelzinnig.** "Prioriteit 1" betekent in sommige systemen gewoonlijk *hoogste* en in andere *laagste*. Er staat niets in deze repository — geen opmerking, geen docstring, geen regel in de README — dat hierover duidelijkheid verschaft. Kies een conventie, documenteer deze in `models.py` en codeer deze in een test met ten minste drie verschillende prioriteiten, zodat de richting vastligt.
- **Onstabiele gelijke standen bij sorteren.** Als twee taken dezelfde prioriteit hebben, moet het resultaat toch deterministisch zijn. Python’s `sorted` is stabiel, maar stabiliteit is alleen nuttig als de invoervolgorde zelf gedefinieerd is. Neem altijd `identifier` op als expliciete secundaire sleutel.
- **Volgorde van velden in `frozen-dataclass`.** `Job` is `@dataclass(frozen=True)` met drie positionele velden, en `service.py:13` construeert het op basis van positie. Het invoegen van `priority` op een andere plaats dan als laatste, of zonder een standaardwaarde, is een brekende wijziging die de twee bestaande tests mogelijk niet duidelijk aan het licht brengen.
- **Uitbreiding van het `to_dict()`-contract.** `asdict(self)` geeft alle velden weer. Het toevoegen van `priority` verandert elke geserialiseerde payload zonder zichtbare wijziging in de methodebody van `models.py`. Alles wat controleert op de exacte structuur van het dict, werkt niet meer.
- **Beperkingen van Python 3.9.6.** Geen `@dataclass(slots=True)` (3.10+), geen `kw_only=True` (3.10+), en PEP 604 `int | None`-annotaties mislukken tijdens runtime zonder `from __future__ import annotations`. Als prioriteit wordt gemodelleerd als een enum, is `enum.StrEnum` pas beschikbaar vanaf versie 3.11 en dus niet beschikbaar. Elk van deze gevallen zou de fixture op deze interpreter doen mislukken.
- **De toewijzing van identificatiecodes vindt plaats in de verkeerde laag.** `SchedulerService._next_identifier` betekent dat de service verantwoordelijk is voor het genereren van id’s, terwijl de repository verantwoordelijk is voor de opslag. Als prioriteitswerk aanleiding geeft tot een tweede repository-implementatie of vooraf geladen fixtures, zal deze scheiding leiden tot id-conflicten en overschreven taken.
- **Asymmetrische foutcontracten.** `JobRepository.get` retourneert `None` bij een misser, terwijl `JobRepository.delete` een `KeyError` genereert. Elke nieuwe prioriteitsgerelateerde opzoekactie moet bewust één conventie kiezen in plaats van per ongeluk de inconsistentie over te nemen.
- **Precedent voor validatiegat.** `create_job` valideert `name` maar niet `owner`. Kopieer die lakse aanpak niet voor `priority` — een niet-gevalideerde prioriteit wordt doorgegeven aan de sorteersleutel en kan diep in `sorted` een `TypeError` veroorzaken (bijv. bij het vergelijken van `int` met `None`) in plaats van op de plaats waar de functie wordt aangeroepen.
- **Valkuil van dode code.** `scheduler/time_rules.py` lijkt op planningslogica en zal bewerkingen aantrekken. Het wordt door niets geïmporteerd, en de eigen docstring geeft de fout toe: het voegt 24 verstreken uren in UTC toe en 'verschuift de lokale kloktijd bij overgangen naar zomertijd." Het wijzigen ervan heeft geen waarneembaar effect op het geteste systeem, dus de inspanning die hieraan wordt besteed is verspild en elke test die hiervoor wordt geschreven, valideert niets van wat wordt uitgebracht.
- **Dun vangnet.** Twee tests, geen CI, geen linter, geen typecontrole. Er is niets om een regressie op te vangen, behalve wat je zelf schrijft. Beschouw de bestaande testsuite als onvoldoende basisdekking, niet als een poort.

### 6. Implementatieplan (niet uitgevoerd)

1. **Leg eerst de semantiek vast, op papier.** Prioriteitstype (`int` versus enum), geldig bereik, standaardwaarde voor bestaande/niet-gespecificeerde taken en sorteerrichting. Leg dit vast als een docstring bij `Job` in `scheduler/models.py` — dat is de enige plek waar alle lagen al van afhankelijk zijn.
2. **Breid het model uit.** Voeg `priority: int = 0` toe als het *laatste* veld van `Job` in `scheduler/models.py`, waarbij de positionele compatibiliteit met `service.py:13` behouden blijft en `to_dict()` ongewijzigd blijft.
3. **Verwerk het in de service.** Voeg een `priority`-parameter met standaardwaarde toe aan `SchedulerService.create_job`, valideer deze naast de bestaande `name.strip()`-controle (genereer een `ValueError`, in overeenstemming met het vastgestelde fouttype), en geef deze door aan de `Job`-constructor.
4. **Leg het weergavecontract expliciet vast.** Voorkeursoptie met laag risico: laat `JobRepository.all()` ongewijzigd als de op identificatie gesorteerde basisweergave, en voeg een aparte, op prioriteit gesorteerde accessor toe. Als `list_jobs()` daarentegen van betekenis moet veranderen, pas dan de comprehensie van `JobRepository.all()` aan om waarden te sorteren op een expliciete samengestelde sleutel, inclusief `identifier` als doorslaggevende factor, en noteer de wijziging in `README.md`.
5. **Houd `scheduler/__init__.py` alleen gesynchroniseerd** als er een openbare enum of constante is geïntroduceerd.
6. **Raak `scheduler/time_rules.py` niet aan**, en voeg geen bestanden toe tenzij `expected_files` in `fixture-manifest.json` in dezelfde wijziging wordt bijgewerkt.

### 7. Validatieplan

- **Eerst de baseline.** Voer `python3 -m unittest discover -s tests -v` uit vóór elke bewerking en controleer of beide tests slagen. Ik heb dit al gedaan — het slaagt zonder problemen.
- **Regressietest.** Beide bestaande tests moeten nog steeds slagen zonder aanpassingen. Als `test_create_and_list_jobs` moet worden aangepast, is dat een teken dat de wijziging een fout veroorzaakt, niet een reden om de test aan te passen.
- **Nieuwe testgevallen in `tests/test_scheduler.py`:**
  - Standaardprioriteit wanneer `create_job` wordt aangeroepen met de oude signatuur met twee argumenten (bewijst achterwaartse compatibiliteit).
  - Expliciete prioriteit bij heen-en-terug-processen via `create_job` → `list_jobs`.
  - Sorteren met **drie of meer** verschillende prioriteiten, waarbij de volledige lijst wordt gecontroleerd — dit bepaalt de sorteerrichting.
  - Bij gelijke prioriteit: twee taken met gelijke prioriteit worden weergegeven in oplopende volgorde van identificatiecode.
  - Een ongeldige prioriteit genereert een `ValueError`, net als bij het geval met een lege naam.
  - `to_dict()` neemt `priority` op met de verwachte waarde.
  - Ingevoegd repository-pad: `SchedulerService(repository=fake)` wijst prioriteit nog steeds correct toe, waarbij de `repository or JobRepository()`-koppeling wordt getest.
- **Compatibiliteitscontrole.** Controleer of alles specifiek op Python 3.9.6 draait — geen `slots=`, geen `kw_only=`, geen naakte PEP 604-unions, geen `StrEnum`.
- **Inventarisatiecontrole.** Lees `fixture-manifest.json` opnieuw door en controleer of de set bestanden op de schijf nog steeds overeenkomt met `expected_files`.
- **Determinisme.** Voer de testsuite twee of drie keer uit; sorteerfouten die te maken hebben met de iteratievolgorde van dictionaries kunnen met tussenpozen optreden.
- **Netheid.** Voer de testsuite uit met `PYTHONDONTWRITEBYTECODE=1`, zodat `__pycache__`-mappen niet als niet-bijgehouden afwijking ten opzichte van het manifest verschijnen.

Dit resultaat zegt niets over de prestaties in een grote monorepo of tijdens een autonome sessie van een week. De testomgeving was bewust klein en gecontroleerd gehouden. Voor een echte evaluatie begin je met een ‘alleen-lezen’-prompt: vraag elke tool om het aanroeppad in kaart te brengen, de bestanden te benoemen die zouden worden gewijzigd, tests te identificeren en onopgeloste aannames op te sommen, voordat je bewerkingen toestaat.

Implementatiestijl, reikwijdte van patches en het verhelpen van fouten

Werken met meerdere bestanden

Hetzelfde gedrag bij het doorlopen van de tests kan het gevolg zijn van verschillende technische keuzes. In T2 scoorden beide producten 30/30 en doorstonden ze de ‘frozen hidden validator’. Claude Code plaatste validatie op meer dan één grens en voegde uitgebreidere directe model- en drempeltests toe. Codex maakte gebruik van een kleinere, servicegerichte implementatie die eveneens aan het contract voldeed.

Voor een onafhankelijke ontwikkelaar is dit een echte afweging. Een bredere validatie kan invarianten beschermen wanneer objecten via meerdere paden worden aangemaakt. Een kleinere patch kan het risico op regressies en de tijd die nodig is voor het beoordelen ervan verminderen wanneer één service het beoogde toegangspunt is. Het juiste antwoord hangt af van de eigendomsregels van de repository, en niet van het afzonderlijk tellen van gewijzigde regels of tests.

Er is prioriteit toegevoegd aan het onveranderlijke model, dit is gevalideerd op de servicegrens en de volgorde in de repository is behouden.

Alle zeven openbare tests en de ‘frozen’ verborgen validator zijn geslaagd.

Prioriteit gevalideerd op zowel de servicegrens als het onveranderlijke model, filtering in de repository behouden en drempeldekking toegevoegd.

Veertien openbare tests en de verborgen validator zijn geslaagd.

De functie voor prioriteit van geplande taken is geïmplementeerd.

Gewijzigde bestanden:

- [scheduler/models.py](./scheduler/models.py:5) — geserialiseerde `priority` toegevoegd, standaard ingesteld op `0`.
- [scheduler/service.py](./scheduler/service.py:11) — validatie, opslag en filtering met `list_jobs(min_priority=0)` toegevoegd, waarbij de volgorde van de identificatiecodes behouden blijft.
- [tests/test_scheduler.py](./tests/test_scheduler.py:16) — dekking toegevoegd voor standaardwaarden, serialisatie, opslag, grenzen, ongeldige waarden en filtering.

Uitgevoerde tests:

```text
python3 -m unittest discover -s tests -v
7 tests uitgevoerd — OK
```

**Conclusie:** De bevroren taak is voltooid en geverifieerd.  
**Benodigde beslissing:** Geen.

# T2-uitvoeringsverslag — Functie voor prioriteit van meerdere bestanden

## Uitvoeringsparameters

| Veld | Waarde |
| --- | --- |
| Taak | `T2` |
| Bevroren prompt | `01-prompts/T2.md` |
| SHA-256 van bevroren prompt | `8476a56034c4e719b97ee4081b32b4c73efd45feafe1bda9d477c83cb8fdb698` |
| Uitvoeringseenheid | geïsoleerde Claude-subagent, `general-purpose`, nieuwe context |
| Isolatiemethode | **subagent-fallback** (gedocumenteerde downgrade — zie `results/isolation-decision.md`) |
| Toegewezen schone kopie | `runtime/workspaces/T2` |
| Claude-codeversie | `2.1.220` |
| Modelinstelling | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:52Z` |
| end_utc | `2026-07-28T10:29:33Z` |
| Duur | 101 s (gelijktijdig met T1, T3, T4; geen zuivere latentie-meting) |
| Poging nummer | 1 |
| Status | `geldig` |
| Menselijke tussenkomst | geen |

## Overzicht veilige tools

`date`, `Read`/`Edit`/`Write` uitsluitend binnen de toegewezen werkruimte, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, inline `python3 -c` smoke checks.
Geen netwerk, geen installaties, alleen standaardbibliotheek.

## Gewijzigde bestanden

`scheduler/models.py`, `scheduler/repository.py`, `scheduler/service.py`,
`tests/test_scheduler.py`. Er zijn geen bestanden toegevoegd of verwijderd, dus `fixture-manifest.json` blijft
correct. Volledige patch: `results/T2/patch.diff`.

## Resultaten van offline controle

Gerapporteerd door de taakuitvoerder:

| Controle | Resultaat |
| --- | --- |
| `python3 -m unittest discover -s tests -v` (uitgangssituatie, vóór wijziging) | 2 geslaagd, 0 mislukt |
| `python3 -m compileall -q scheduler tests` | foutloos |
| inline smoke-controles (verouderde constructie met 3 argumenten, drempelwaarde voor trefwoord/positie, `to_dict`) | geslaagd |
| `python3 -m unittest discover -s tests -v` (eindresultaat) | **14 geslaagd, 0 mislukt** |

Onafhankelijk opnieuw geverifieerd door de coördinator van buiten de werkruimte:

| Controle | Afsluiten | Resultaat |
| --- | --- | --- |
| openbare suite (`results/checks/T2-public.txt`) | 0 | 14 tests, OK |
| verborgen validator `03-checks/test_t2_hidden.py` (`results/checks/T2-hidden.txt`) | 0 | 2 tests, OK |

De verborgen validator faalt (exit 1) bij een ongewijzigde kopie van de fixture, wat bevestigt dat het slagen
zinvol is. Zie `results/checks/validator-controls.md`.

## Gedragsdekking van de gold-map

Aan alle vijf vereiste gedragingen in `03-checks/gold-map.json` is voldaan:

| Vereist gedrag | Bewijs |
| --- | --- |
| prioriteit standaard 0 | `Job.priority: int = MIN_PRIORITY`; `create_job(..., priority=MIN_PRIORITY)`; `test_priority_defaults_to_zero` |
| geheel getalbereik 0 tot en met 9 | `validate_priority` wijst niet-gehele getallen en waarden buiten het bereik af; `test_out_of_range_priority_is_rejected`, `test_non_integer_priority_is_rejected` |
| geserialiseerde prioriteit | `to_dict()` via `asdict`; `test_priority_appears_in_serialized_output` controleert of de exacte dict aanwezig is |
| filteren op minimale prioriteit | `list_jobs(min_priority=0)` → `JobRepository.all(min_priority)`; `test_filter_is_inclusive_of_the_threshold` |
| volgorde van identificatiecodes | filter toegepast binnen de bestaande `sorted(self._jobs)`-comprehension; `test_filter_preserves_ascending_identifier_order` |

## Opgeschoonde fouten

Geen. `__pycache__`-artefacten van testruns zijn verwijderd door de taakuitvoerder; een coördinator-
sweep heeft bevestigd dat de werkruimte schoon is.

## Zichtbare uitvoer (letterlijk)

Er is een integer `priority`-veld toegevoegd aan geplande taken in de model-, repository- en servicelagen van de lokale scheduler-fixture, plus een gefilterde lijst.

**`scheduler/models.py`** — Moduleconstanten `MIN_PRIORITY = 0` / `MAX_PRIORITY = 9` toegevoegd, evenals een herbruikbare functie `validate_priority(priority)` die een `ValueError` genereert bij niet-gehele getallen en bij waarden buiten het bereik van 0 tot en met 9. `bool` wordt expliciet afgewezen, ondanks dat het een subklasse van `int` is, zodat `True` niet als prioriteit 1 kan worden doorlaten. De bevroren dataklasse `Job` krijgt `priority: int = MIN_PRIORITY` als een achtervoegselveld met een standaardwaarde, waardoor de bestaande constructie met drie argumenten blijft werken, en een `__post_init__` die de validator aanroept, zodat er via geen enkel pad ongeldige prioriteiten kunnen worden geconstrueerd. `to_dict()` is gelaten als `asdict(self)`, zodat de prioriteit automatisch en in veldvolgorde in de geserialiseerde uitvoer verschijnt.

**`scheduler/repository.py`** — `JobRepository.all()` accepteert een optioneel `min_priority` en filtert binnen de bestaande `sorted(self._jobs)`-comprehension, zodat de oplopende volgorde van de identifiers wordt gegarandeerd door hetzelfde enkele codepad dat dit al verzorgde, in plaats van dat deze na het filteren opnieuw moet worden vastgesteld. Het standaardargument behoudt het eerdere gedrag zonder argumenten voor bestaande aanroepers. De opslag zelf hoefde niet te worden gewijzigd: de repository slaat volledige `Job`-instanties op, zodat de prioriteit behouden blijft en door `save`/`get`/`all` wordt doorgegeven.

**`scheduler/service.py`** — `create_job` accepteert een optioneel achteraf opgegeven `priority`-argument (standaard 0) en valideert dit voordat de `Job` wordt aangemaakt, zodat de foutmelding wordt gegenereerd op de servicegrens met hetzelfde `ValueError`-contract als de bestaande controle op lege namen. `list_jobs(min_priority=0)` delegeert naar de repository. Sorteren en filteren vinden op één plek plaats in plaats van dat ze worden gedupliceerd.

**Ontwerpopmerking over de validatie van `min_priority`:** het wordt getypeerd als een geheel getal, maar is bewust *niet* beperkt tot het bereik 0–9. De 0–9-regel beperkt wat een taak mag opslaan; een drempelwaarde is een queryparameter, en het afwijzen van bijvoorbeeld `min_priority=10` zou een legitieme query die "niets vindt" in een fout veranderen. Dat `list_jobs(min_priority=9)` `[]` retourneert wanneer geen enkele taak prioriteit 9 heeft, wordt gedekt door een test.

`scheduler/time_rules.py` is gelezen maar ongewijzigd gelaten — de gedocumenteerde aanpassing voor zomertijd is reeds bestaand standaardgedrag, valt buiten het bereik van deze taak en het wijzigen ervan zou een niet-gerelateerde gedragswijziging zijn geweest. Er zijn geen bestanden toegevoegd of verwijderd, dus `fixture-manifest.json` blijft correct (programmatisch geverifieerd).

### Testdekking toegevoegd

Standaardwaarde 0; opslag-roundtrip via `JobRepository`; prioriteit in de uitvoer van `to_dict()`; grenswaarden 0 en 9 geaccepteerd; waarden buiten het bereik −1/10/100 afgewezen; niet-gehele getallen `"3"`/`3.5`/`None`/`True` afgewezen; directe validatie op modelniveau; ongefilterde volgorde van de lijst; gefilterde lijst met behoud van oplopende volgorde van identificatiecodes; inclusieve drempelwaarde; leeg resultaat; niet-geheel getal `min_priority` afgewezen.

Fouten verhelpen in uitzonderlijke gevallen

T3 heeft een fout in de planning van de zomertijd getest. Beide agents scoorden 30/30 en slaagden voor dezelfde verborgen controles in het voor- en najaar. De Claude-code voegde expliciete dekking toe voor dubbelzinnige en overgeslagen lokale tijden, naïeve invoer en meerdaagse doorrollen. Codex voerde een beperktere wijziging van de kalenderdag door en slaagde voor het ‘frozen contract’.

Uitgebreidere tests voor randgevallen zorgen voor zekerheid wanneer de bibliotheek op grote schaal wordt hergebruikt of wanneer de kosten van een planningsfout hoog zijn. Een beperkte wijziging is aantrekkelijk wanneer het defect goed geïsoleerd is en het team gedragsveranderingen tot een minimum wil beperken. De praktische beoordelingsvraag is niet “Wie heeft er meer geschreven?”, maar of de patch de aangegeven hoofdoorzaak verhelpt, de omliggende afspraken in stand houdt en de risicovolle grenzen aantoont.

Oorzaak: door de implementatie zijn er 24 verstreken UTC-uren bijgeteld.

Oplossing: één lokale kalenderdag vooruitgaan. Zowel de 'frozen spring'- als de 'fall'-controles zijn geslaagd.

Er is aandacht besteed aan spring- en fall-condities, ontbrekende en onduidelijke lokale tijden, onjuiste invoer en meerdaagse roll-overs.

Beide ‘frozen hidden checks’ zijn geslaagd na een uitgebreidere regressietest.

De zomertijd-fix is geïmplementeerd.

Gewijzigde bestanden:

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

Wijzigingen:

- De lokale kalenderdag wordt met één dag vooruitgezet in plaats van 24 UTC-uren.
- Regressietests toegevoegd voor de zomertijd- en wintertijdwijzigingen in New York.
- Gecontroleerd dat de verstreken UTC-intervallen respectievelijk 23 en 25 uur bedragen.

Controles:

- Unit-tests: 4 geslaagd.
- Syntaxiscontrole in het geheugen: 7 Python-bestanden geslaagd.
- De bytecode-compilatie werd geblokkeerd omdat Python zijn cache omleidt naar buiten de toegewezen werkruimte; er werden geen externe bestanden geschreven.

**Conclusie:** `next_daily_run` behoudt nu het gevraagde uur van de wandklok tijdens zomertijd- en wintertijdovergangen. Er hoeft geen beslissing te worden genomen.

# T3-uitvoeringsverslag — DST-bugfix

## Uitvoeringsparameters

| Veld | Waarde |
| --- | --- |
| Taak | `T3` |
| Bevroren prompt | `01-prompts/T3.md` |
| SHA-256 van bevroren prompt | `3fee50d0230f27f8d6dd7f12e050fa3f0b7f5fb77d9559361fee96e5f1a47307` |
| Uitvoeringseenheid | geïsoleerde Claude-subagent, `general-purpose`, nieuwe context |
| Isolatiemethode | **subagent-fallback** (gedocumenteerde downgrade — zie `results/isolation-decision.md`) |
| Toegewezen schone kopie | `runtime/workspaces/T3` |
| Claude-codeversie | `2.1.220` |
| Modelinstelling | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:05Z` |
| end_utc | `2026-07-28T10:30:03Z` |
| Duur | 118 s (gelijktijdig met T1, T2, T4; geen zuivere latentie-meting) |
| Poging nummer | 1 |
| Status | `geldig` |
| Menselijke tussenkomst | geen |

## Samenvatting van de Safe-tool

`date`, `Read`/`Edit` uitsluitend binnen de toegewezen werkruimte, `python3 -m unittest discover`,
`python3 -m compileall`, een negatieve controle in het geheugen, een integriteitscontrole van het manifest.
Alleen standaardbibliotheek (`datetime`, `zoneinfo`, `unittest`). Geen netwerk, geen installaties.

## Gewijzigde bestanden

`scheduler/time_rules.py` (de correctie — alleen de body en docstring van `next_daily_run`),
`tests/test_scheduler.py` (`NextDailyRunTests` toegevoegd, 8 tests, plus een `_elapsed`-helper;
bestaande tests ongewijzigd). Geen andere modules aangepast, geen bestanden toegevoegd. Volledige patch:
`results/T3/patch.diff`.

## Resultaten van offline controle

Gerapporteerd door de taakuitvoerder:

| Controle | Resultaat |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **10 geslaagd, 0 mislukt** (2 reeds bestaande + 8 nieuwe) |
| `python3 -m compileall -q scheduler tests` | clean |
| integriteit van het manifest ten opzichte van `fixture-manifest.json` | 0 ontbrekend, 0 onverwacht |
| negatieve controle: gepatchte implementatie in het geheugen, alleen `NextDailyRunTests` | 8 uitgevoerd, **5 mislukt zoals bedoeld**, inclusief beide DST-tests |

Onafhankelijk opnieuw geverifieerd door de coördinator van buiten de werkruimte:

| Controle | Afsluiting | Resultaat |
| --- | --- | --- |
| openbare suite (`results/checks/T3-public.txt`) | 0 | 10 tests, OK |
| verborgen validator `03-checks/test_t3_hidden.py` (`results/checks/T3-hidden.txt`) | 0 | 2 tests, OK |

De verborgen validator faalt (exit 1) bij een ongewijzigde kopie van de fixture. Zie
`results/checks/validator-controls.md`.

## Dekking van het gedrag in de gold-map

Aan alle vier de vereiste gedragingen in `03-checks/gold-map.json` is voldaan:

| Vereist gedrag | Bewijs |
| --- | --- |
| wall-clock-uur behouden | increment toegepast op de naïeve lokale wall-clock, zone opnieuw gekoppeld; gecontroleerd in elke DST-test |
| overgang naar zomertijd gedekt | `test_spring_forward_keeps_requested_hour` — uur 09:30 behouden, offset `-04:00`, verstreken tijd 23 uur |
| herfstovergang getest | `test_fall_back_keeps_requested_hour` — uur 09:30 behouden, offset `-05:00`, verstreken tijd 25 uur |
| IANA-tijdzone gebruikt | `ZoneInfo("America/New_York")` uit de standaardbibliotheek |

Naast de vereiste set heeft de runner ook de twee PEP 495-randgevallen getest — een kloktijd
die door de zomertijdomschakeling wordt overgeslagen en een ambigue kloktijd tijdens de herfsttijdomschakeling — plus zevendaagse overschrijvingen
die elk van de overgangen overspannen en naïef invoergedrag.

## Opgeschoonde fouten

Twee zelfveroorzaakte fouten in testasserties: `following - previous` op twee datetimes die een
`tzinfo` delen, trekt naïeve kloktijden van elkaar af, waardoor de asserties voor verstreken tijd 1 dag aangaven en faalden.
De implementatie was correct en de asserties waren fout; gecorrigeerd met een `_elapsed`
helper die beide operanden eerst naar UTC converteert. Geen fouten in tooling, import of omgeving.
`__pycache__`-artefacten werden na de run verwijderd.

## Zichtbare uitvoer (letterlijk)

**Reproductie**

`scheduler/time_rules.py::next_daily_run` werd aangeroepen met een `America/New_York`-tijdstip aan weerszijden van een zomertijdwisseling in 2024:

```
2024-03-09T09:30:00-05:00 -> 2024-03-10T10:30:00-04:00   # uur verschoven +1
2024-11-02T09:30:00-04:00 -> 2024-11-03T08:30:00-05:00   # uurverschuiving -1
```

Een taak die was ingepland voor 09:30 lokale tijd, werd om 10:30 gestart na de zomertijdomschakeling en om 08:30 na de wintertijdomschakeling.

**Oorzaak**

De standaardimplementatie behandelde "daily" als een vaste, absolute duur:

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

Door eerst naar UTC om te rekenen, wordt `timedelta(hours=24)` precies 24 verstreken uren. Maar een lokale kalenderdag in een IANA-tijdzone duurt 23 uur op de dag dat de klok vooruit wordt gezet en 25 uur op de dag dat de klok terug wordt gezet, dus een constante verschuiving van 24 uur leidt noodzakelijkerwijs tot een afwijking van één uur ten opzichte van de gevraagde wandkloktijd.

**De oplossing** (`scheduler/time_rules.py`)

Dagelijkse herhaling is een kalenderregel, dus de toename wordt nu toegepast op de ‘naïeve’ lokale kloktijd, waarna de tijdzone er achteraf weer aan wordt gekoppeld:

```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)
```

Waarom dit correct is:
- De klokberekening op de naïeve waarde is onafhankelijk van de tijdzone-offset, dus het gevraagde uur:minuut blijft per definitie behouden; `zoneinfo` levert vervolgens de UTC-offset die op de nieuwe datum van kracht is (gecontroleerd: `-04:00` na de zomertijd, `-05:00` na de wintertijd, met een verstreken reële tijd van respectievelijk 23 uur en 25 uur).
- `fold=0` in combinatie met de UTC-round-trip verwerkt de twee randgevallen die bij pure kloktijdberekening onduidelijk blijven. Volgens PEP 495 heeft een *overgeslagen* kloktijd (02:30 op 10-03-2024) de offset van vóór de overgang bij `fold=0`, dus de round-trip normaliseert deze naar het werkelijke tijdstip 03:30 EDT in plaats van een datetime te retourneren die geen specifiek tijdstip aangeeft. Een *dubbelzinnige* kloktijd (01:30 op 03-11-2024) wordt deterministisch omgezet naar de eerste keer dat deze voorkomt (EDT) in plaats van willekeurig te zijn.
- Naïeve invoer behoudt zijn eerdere betekenis (gewoon +1 kalenderdag) — er worden geen nieuwe `tzinfo`-vereisten opgelegd aan aanroepers.

De reikwijdte is beperkt gehouden: alleen de body/docstring van `next_daily_run` is gewijzigd. `service.py`, `models.py`, `repository.py` en `__init__.py` zijn ongewijzigd gebleven, er zijn geen nieuwe bestanden toegevoegd en het fixture-manifest komt nog steeds exact overeen (geen ontbrekende of onverwachte bestanden). Alleen standaardbibliotheken (`datetime`, `zoneinfo`, `unittest`).

**Regressietests** (`tests/test_scheduler.py`, nieuwe `NextDailyRunTests`, 8 tests) omvatten: stabiliteit op gewone dagen, zomertijd + offset + 23 uur verstreken, wintertijd + offset + 25 uur verstreken, zevendaagse cycli die elke overgang overspannen, overgeslagen kloktijd, dubbelzinnige kloktijd en naïeve invoer.

Twee opmerkingen die het vermelden waard zijn. Ten eerste gebruikten mijn oorspronkelijke beweringen over verstreken tijd `following - previous`; Python negeert een gedeelde `tzinfo` en trekt naïeve kloktijden van elkaar af, waardoor beide 1 dag opleverden en faalden. De implementatie was correct en de beweringen waren onjuist — opgelost met een `_elapsed`-helper die beide operanden naar UTC converteert. Ten tweede heb ik gecontroleerd of de tests het oorspronkelijke defect daadwerkelijk opsporen door `NextDailyRunTests` opnieuw uit te voeren op een kopie in het geheugen van de geïnitieerde implementatie: 5 van de 8 faalden, waaronder beide zomertijd-tests. De drie die slagen onder de buggy-versie (gewone dag, overgeslagen, ambigu) documenteren eerder het gedrag dan dat ze regressies opsporen — de overgeslagen/ambigue gevallen komen toevallig overeen omdat een absolute verschuiving van +24 uur toevallig op hetzelfde genormaliseerde tijdstip uitkomt.

Kwaliteit van codebeoordeling en handmatige controle

Code-reviewtaken vereisen andere vaardigheden dan het implementeren van nieuwe functies. Een goede reviewer moet reproduceerbare fouten opsporen, de ernst ervan inschatten, het exacte codepad aangeven en een echt defect kunnen onderscheiden van een speculatieve waarschuwing. Het verhelpen van een fout brengt nog een extra test met zich mee: de patch mag geen nieuwe regressie veroorzaken.

Claude Code had het duidelijkste voordeel in T4. Het rapporteerde vijf onafhankelijk reproduceerbare bevindingen, waaronder beide vooraf geplaatste beoordelingsdoelen, en behaalde 19/20. Codex rapporteerde en verholpen twee geldige defecten met een hogere ernstgraad, maar maakte geen melding van het vooraf geplaatste paar, waardoor het 18/20 behaalde. De bevindingen van Codex waren geen valse positieven; het waargenomen verschil betrof de breedte van de dekking in plaats van de fundamentele juistheid.

1. Hoog — Bestaande taken zouden ongemerkt kunnen worden overschreven.

2. Gemiddeld — Dagelijkse taken liepen niet synchroon met de overgang naar zomertijd.

Verificatie: vier tests geslaagd, nul mislukkingen.

D1 DST-afwijking · Hoog
D2 Naïeve tijdzone-detectie · Gemiddeld
D3 Conflicten tussen identificatiecodes · Hoog
D4 Ontbrekende verwijdering leidt tot KeyError · Gemiddeld
D5 Eigenaar niet gevalideerd · Laag

## Actiepunten

1. **Hoog — Bestaande taken kunnen onopgemerkt worden overschreven**

   - Bewijs: initialisatie van de identificatiecode in [service.py](./scheduler/service.py:8), in combinatie met het vervangen van het woordenboek in [repository.py](./scheduler/repository.py:9).
   - Gevolgen: bij het aanmaken van een service met een bestaande repository zou identifier `1` opnieuw kunnen worden gebruikt, waardoor de opgeslagen taak wordt vervangen en gegevensverlies ontstaat.
   - Minimale reproductie: sla `Job(1, ...)` op, maak een `SchedulerService(repository)` aan en maak vervolgens een andere taak aan. Vóór de correctie bleef alleen de nieuwe taak over.
   - Oplossing: initialiseer de volgende identificatiecode op basis van de hoogste bestaande identificatiecode in de repository.
   - Regressietest: [test_scheduler.py](./tests/test_scheduler.py:22).

2. **Gemiddeld — Dagelijkse uitvoeringen verschoofden bij de overgang naar zomertijd**

   - Bewijs: gecorrigeerde berekening in [time_rules.py](./scheduler/time_rules.py:4).
   - Gevolgen: een dagelijkse taak die was gepland voor 09:00 uur, werd na de overgang naar de zomertijd in het voorjaar om 10:00 uur uitgevoerd.
   - Minimale reproductie: bereken de volgende uitvoering na `2026-03-07 09:00 America/New_York`. Vóór de correctie was het resultaat `2026-03-08 10:00`.
   - Oplossing: voeg één lokale kalenderdag toe in plaats van 24 verstreken UTC-uren.
   - Regressietest: [test_scheduler.py](./tests/test_scheduler.py:33).

## Gewijzigde bestanden

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

## Verificatie

- Beide regressietests faalden vóór de reparaties.
- Ze zijn allemaal geslaagd na de bijbehorende reparatie.
- `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v`
- Resultaat: **4 tests geslaagd, 0 mislukkingen**.
- Er zijn geen gegenereerde Python-cache-artefacten meer aanwezig.

## Conclusie en besluit

- **Conclusie:** Beide bevestigde defecten zijn verholpen en worden gedekt door gerichte regressietests.
- **Vereist besluit:** Geen.

# T4-uitvoeringsrapport — Test en codebeoordeling

## Uitvoeringsparameters

| Veld | Waarde |
| --- | --- |
| Taak | `T4` |
| Bevroren prompt | `01-prompts/T4.md` |
| SHA-256 van bevroren prompt | `5e69546007ea776f40b3d334ddb75671ff684c151c77551bad27de3b0fdce640` |
| Uitvoeringseenheid | geïsoleerde Claude-subagent, `general-purpose`, nieuwe context |
| Isolatiemethode | **subagent-fallback** (gedocumenteerde downgrade — zie `results/isolation-decision.md`) |
| Toegewezen schone kopie | `runtime/workspaces/T4` |
| Claude-codeversie | `2.1.220` |
| Modelinstelling | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:22Z` |
| end_utc | `2026-07-28T10:32:17Z` |
| Duur | 235 s (gelijktijdig met T1–T3; geen zuivere latentie-meting) |
| Pogingsnummer | 1 |
| Status | `geldig` |
| Menselijke tussenkomst | geen |

De voorwaarde in de bevroren prompt — "corrigeer ze als de bevroren uitvoerconfiguratie
correcties toestaat" — werd door de coördinator opgelost aan de hand van `00-control/run-config.json` en
`00-control/safety-policy.json`, die het schrijven van geïsoleerde kopieën van fixtures toestaan. De runner kreeg
te horen dat aanpassingen zijn toegestaan. Er werd geen controlebestand getoond.

## Overzicht veilige tools

`date`, `Read`/`Edit`/`Write` uitsluitend binnen de toegewezen werkruimte, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, een vacuity-run met een tijdelijke kopie, een
controle op de aanwezigheid van het manifest. Geen netwerk, geen installaties, uitsluitend standaardbibliotheek.

## Gewijzigde bestanden

`scheduler/time_rules.py` (gewijzigd), `scheduler/service.py` (gewijzigd),
`tests/test_scheduler.py` (gewijzigd, +2 tests), `tests/test_time_rules.py` (toegevoegd, 5 tests).
Volledige patch: `results/T4/patch.diff`.

## Resultaten van de offline controle

Gerapporteerd door de taakuitvoerder:

| Controle | Resultaat |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **9 geslaagd, 0 mislukt, 0 overgeslagen** (baseline 2) |
| `python3 -m compileall -q scheduler tests` | geslaagd |
| Controle op aanwezigheid van manifest ten opzichte van `expected_files` | alle 8 aanwezig |
| Vacuity-run tegen herstelde originele implementaties | 5 mislukkingen, 4 geslaagd, zoals bedoeld |

Onafhankelijk opnieuw geverifieerd door de coördinator van buiten de werkruimte:

| Controle | Uitgang | Resultaat |
| --- | --- | --- |
| openbare suite (`results/checks/T4-public.txt`) | 0 | 9 tests, OK |

Informatieve kruiscontrole, niet beoordeeld: de verborgen T3-validator slaagt ook voor deze
werkruimte (uitgang 0), omdat T4 onafhankelijk hetzelfde `next_daily_run`-defect heeft verholpen. Zie
`results/checks/validator-controls.md`.

## Defectdekking in de gold-map

`03-checks/gold-map.json` zet twee defecten in voor de T4-beoordeling. Beide zijn gevonden:

| Ingezette defecten | Gevonden | Gerapporteerd als |
| --- | --- | --- |
| lege eigenaar geaccepteerd | ja | **D5**, `scheduler/service.py:11,13`, ernst Laag, gerapporteerd en opzettelijk niet verholpen |
| het verwijderen van een ontbrekende identificatiecode veroorzaakt een `KeyError` | ja | **D4**, `scheduler/repository.py:19` → `service.py:22`, ernst: gemiddeld, gerapporteerd en opzettelijk niet verholpen |

Er werden drie extra bevindingen gerapporteerd buiten de aangebrachte set. Geen enkele is een vals-positief:

- **D1** — DST-afwijking in `next_daily_run`. Dit is het derde defect dat wordt vermeld in
  `03-checks/seeded-defects.md` (het is gescoord onder T3, niet onder T4, maar het is een echte vooraf geplaatste bug).
- **D2** — naïeve invoer in `next_daily_run` haalt stilzwijgend de tijdzone van de host op en retourneert een
  daarvan op de hoogte zijnde datum-tijd. Echt en host-afhankelijk; geverifieerd door de coördinator aan de hand van de fixture-broncode.
- **D3** — Identificatieconflict tussen een service en een geïnjecteerde of gedeelde repository, wat leidt tot
  stille overschrijving. Echt: `SchedulerService._next_identifier` begint altijd bij 1, terwijl
  `JobRepository.save` een onbeveiligde dict-toewijzing is. T1 identificeerde onafhankelijk dezelfde
  naad vanuit de ongewijzigde fixture.

Aantal valse positieven: **0**. De runner meldde ook correct dat er geen beveiligingsbevindingen waren, waarbij werd opgemerkt
dat de fixture geen netwerk-, I/O-, deserialisatie-, subproces- of inloggegevens-oppervlak heeft.

## Afwijking die het vermelden waard is

De vaste opdracht vroeg om tests en oplossingen voor "de twee defecten met de hoogste betrouwbaarheid". De
runner selecteerde D1/D2 (één oplossing, dezelfde functie) en D3, in plaats van de twee in de gold-map ingebouwde
defecten D4 en D5. De opgegeven reden is verdedigbaar: D4 en D5 hangen beide af van een niet-gespecificeerd API-
contract, dus het verhelpen ervan zou giswerk zijn. De detectiescore blijft ongewijzigd — beide vooraf geplaatste defecten
werden gevonden, met vermelding van bestand, regel, ernst, impact en reproduceerbaarheid. De toegepaste oplossingen hadden betrekking op echte
fouten en worden ondersteund door een vacuity-controle.

## Opgeschoonde fouten

Twee zelfveroorzaakte testfouten door aftrekking van wall-clock-tijd versus absolute tijd bij datetimes
die een `tzinfo` delen; gecorrigeerd en opnieuw geverifieerd. Geen fouten in tools of omgeving. `__pycache__`-
artefacten zijn na de run verwijderd.

## Zichtbare uitvoer (letterlijk)

### Foutrapport

**D1 — `scheduler/time_rules.py:10-11` — Dagelijkse planning wijkt tijdens zomertijd één uur af — Ernst: Hoog**

`next_daily_run` voegt 24 *verstreken* uren toe via een UTC-roundtrip in plaats van de kalenderdag vooruit te zetten. Een dagelijkse taak wordt bepaald door de kloktijd, dus elke taak in een zone waar zomertijd geldt, wordt vanaf de overgangsdag stilzwijgend een uur te vroeg of te laat uitgevoerd, en de fout blijft bestaan (elke run begint opnieuw vanaf de verschoven tijd). In de docstring zelf werd dit gedrag toegegeven.

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

**D2 — `scheduler/time_rules.py:10-11` — Naïeve invoer neemt stilzwijgend de lokale tijdzone van de machine over — Ernst: Gemiddeld**

Dezelfde twee regels. `.astimezone(timezone.utc)` op een naïeve datetime gaat uit van de lokale systeemtijd, en `.astimezone(None)` retourneert een 'aware' datetime. Een aanroep met een naïeve invoer retourneert een "aware" uitvoer, waardoor het resultaat niet vergelijkbaar is met de andere naïeve waarden van de aanroeper (`TypeError` bij vergelijking) en het antwoord afhankelijk is van de `TZ` van de host.

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

**D3 — `scheduler/service.py:8,13,15` (prefix) — Conflicten tussen identificatiecodes vernietigen opgeslagen taken zonder waarschuwing — Ernst: Hoog**

De id-teller was per `SchedulerService` en begon altijd bij 1, waarbij de inhoud van de geïnjecteerde repository werd genegeerd. Elke tweede service die gebruikmaakte van een gedeelde repository, of elke service die gebruikmaakte van een vooraf gevulde repository, kende opnieuw id 1 toe; `JobRepository.save` is een dict-toewijzing, dus de bestaande taak werd zonder foutmelding overschreven. Gegevensverlies.

```
repo = JobRepository()
SchedulerService(repo).create_job("Nightly backup", "Alex")    # id 1
SchedulerService(repo).create_job('Payroll export', 'Blake')   # id 1 opnieuw
repo.all()   # -> [Job(1, "Payroll export", "Blake")]  — De taak van Alex is verdwenen
```

**D4 — `scheduler/repository.py:19` → `scheduler/service.py:22` — `delete_job` genereert een `KeyError` voor een onbekende id — Ernst: Gemiddeld**

`delete` gebruikt `dict.pop` zonder standaardwaarde, terwijl de verwante methode `get` (regel 13) `None` retourneert als er niets wordt gevonden. Door deze inconsistentie lekt er een onbewerkte `KeyError` door `SchedulerService.delete_job`, die aanroepers waarschijnlijk niet zullen opvangen. Repro: `SchedulerService().delete_job(999)` → `KeyError: 999`. Een oplossing zou `pop(identifier, None)` of een expliciete domeinuitzondering zijn — dit is bewust niet verholpen, aangezien de juiste afsprake (stille no-op versus getypeerde fout) een API-beslissing is voor de eigenaar.

**D5 — `scheduler/service.py:11,13` — Het veld `owner` wordt niet gevalideerd — Ernst: Laag**

`name` wordt gecontroleerd op leegheid, maar `owner` niet: `create_job('ok', '   ')` slaat `owner=''` op. Beide parameters roepen ook `.strip()` onbeveiligd aan, waardoor `None` wordt weergegeven als `AttributeError: 'NoneType'-object heeft geen attribuut 'strip'` in plaats van de `ValueError` die de API anders gebruikt bij ongeldige invoer. Niet verholpen — het beoogde contract voor `owner` wordt nergens in de fixture vermeld.

**Beveiliging:** geen bevindingen. De fixture heeft geen netwerk-, I/O-, deserialisatie-, subproces- of inloggegevens-kwetsbaarheden; de opslag is een in-process dict.

**Dekkingtekort:** `scheduler/time_rules.py` en `scheduler/repository.py` hadden vóór deze testrun geen testdekking; de twee vooraf ingestelde tests doorliepen alleen het ‘happy path’ van de service.

### Toegepaste tests en oplossingen

De twee defecten met de hoogste betrouwbaarheidsscore waren **D1/D2** (dezelfde functie, één oplossing) en **D3**.

**Oplossing 1 — `scheduler/time_rules.py`:** de UTC-round-trip vervangen door `previous_run + timedelta(days=1)`. Python voert wall-clock-berekeningen uit op ‘aware’ datetimes, en `zoneinfo` berekent de UTC-offset pas achteraf op basis van de nieuwe wall-time — dus 09:00 blijft 09:00 terwijl de offset correct verschuift van `-05:00 → -04:00`. Dit lost D1 en D2 tegelijkertijd op: naïeve invoer blijft nu naïef en de lokale tijdzone wordt nooit afgeleid. Het geval van een onbereikbaar versus dubbelzinnig overgangsuur wordt gedocumenteerd als een verwijzing naar de fold-regels van tzinfo.

**Oplossing 2 — `scheduler/service.py`:** de per instantie geldende `_next_identifier`-teller is verwijderd; identificatiecodes worden nu bij het aanmaken toegewezen vanuit de repositorystatus als `max(bestaande id’s, standaard=0) + 1`. Dit is correct voor zowel gedeelde als vooraf gevulde repositories. Afweging: O(n) per aanmaak in plaats van O(1), aanvaardbaar voor een op een dict gebaseerde opslag in het geheugen, en correctheid ten opzichte van een teller die de opslag waarnaar hij schrijft niet kan zien.

**Tests — `tests/test_time_rules.py` (nieuw, 5 tests):** behoud van de wandklok bij spring-forward en fall-back, absolute verstreken tijd van 23 uur/25 uur tijdens die overgangen, herberekening van de UTC-offset, ‘naïef blijft naïef’, en een gewone UTC-dagverschuiving. Slaat de tests netjes over als er geen IANA-database aanwezig is.

**Tests — `tests/test_scheduler.py` (uitgebreid, +2 tests):** twee services die één repository delen, moeten verschillende id’s toekennen en beide taken behouden; een service die gebruikmaakt van een repository die vooraf is gevuld met id’s 1 en 7, moet id 8 toekennen en de bestaande taken intact laten.

**Vacuümcontrole:** ik heb beide oorspronkelijke implementaties in een tijdelijke kopie hersteld en de testsuite opnieuw uitgevoerd — alle 5 nieuwe tests faalden (`FAILED (failures=5)`), en ze slagen allemaal met de gecorrigeerde code. De tests leggen de defecten daadwerkelijk bloot.

Eén correctie tijdens de testrun: in mijn eerste concept werd de verstreken DST-tijd vastgesteld als `result - previous`, wat Python interpreteert als rekenkundige bewerking op basis van de kloktijd wanneer beide operanden dezelfde `tzinfo` delen, waardoor de waarde als `24h` werd gelezen en de tests mislukten. De beweringen worden nu omgezet naar UTC voordat er wordt afgetrokken. De fout zat in mijn test, niet in de oplossing.

### Opmerkingen voor de eigenaar

`fixture-manifest.json` is ongewijzigd gelaten, dus `tests/test_time_rules.py` is een legitiem nieuw bestand dat niet in `expected_files` staat vermeld — werk het manifest bij als een controle een exacte set bestanden vereist. En D4/D5 zijn gemeld maar bewust niet verholpen: beide hangen af van een beslissing over het API-contract (semantiek bij verwijdering, validatieregels voor eigenaren) die nergens in de fixture is gespecificeerd, dus het kiezen van één ervan zou eerder een gok dan een oplossing zijn geweest.

Geen van beide scores maakt menselijke controle overbodig. Nadat een van beide agents een reparatie heeft voltooid, moet u de gewijzigde interfaces, onverwachte bestandsbereiken, ontbrekende negatieve tests, de geschiedenis van machtigingen of opdrachten en het terugdraaipad controleren. Een overtuigende uitleg is geen vervanging voor een reproduceerbare test.

Toegangsrechten, sandboxing en operationele veiligheid

Een codeeragent kan vertrouwelijke code lezen, shell-opdrachten uitvoeren, talrijke bestanden wijzigen en externe tools aanroepen. Daardoor maakt het ontwerp van de machtigingen deel uit van de productkwaliteit. De relevante vragen zijn: welke bewerkingen vereisen goedkeuring, waartoe heeft de agent standaard toegang, hoe duidelijk worden risicovolle acties vooraf weergegeven en kan een ontwikkelaar de resulterende wijzigingen controleren?.

Ga er niet automatisch vanuit dat minder goedkeuringsverzoeken beter zijn. Een soepel proces is nuttig in een op zichzelf staande omgeving zonder inloggegevens of productieverbindingen. Hetzelfde gedrag kan echter gevaarlijk zijn in een repository die is gekoppeld aan implementatiescripts, echte klantgegevens of uitgebreide cloudtoegangsrechten. Omgekeerd kunnen te veel goedkeuringen veilige automatisering onpraktisch maken en gebruikers ertoe aanzetten verzoeken goed te keuren zonder ze te lezen.

Bij onze test is gebruikgemaakt van nieuwe lokale kopieën, zonder productiesystemen, zonder implementatie en zonder menselijke tussenkomst tijdens de testrun. De test beoordeelt dus de voltooiing van taken onder veilige omstandigheden, en niet de relatieve veiligheid van de twee producten. Voordat u een van beide tools voor belangrijk werk gebruikt, moet u beginnen met alleen-lezen-toegang, de toegestane mappen en commando’s definiëren, de diff controleren en objectieve controles uitvoeren in een herstelbare omgeving.

• Begin met een alleen-lezen-architectuur of neem het risico.
• Keur alleen commando’s goed waarvan je de reikwijdte en de gevolgen begrijpt.
• Bewaar inloggegevens, productiegegevens en toegang tot de implementatie buiten de proefperiode.
• Vraag om een diff, tests en een duidelijk terugdraaipad voordat je het resultaat accepteert.

MCP, vaardigheden, projectinstructies en aanpassing

Beide ecosystemen kunnen worden uitgebreid, maar de termen ‘uitbreiding’ en ‘extensie’ mogen niet als synoniemen worden beschouwd. Projectinstructies geven een agent aan hoe hij zich in een repository moet gedragen. Herbruikbare vaardigheden (Reusable Skills) bundelen een herhaalbare workflow of expertise. MCP koppelt een host aan externe tools of gegevens. Hooks en commando’s kunnen bepaalde momenten in een ontwikkelingscyclus automatiseren. Een product kan in één laag sterk zijn zonder dat het een andere functie één-op-één evenaart.

De vraag bij de aankoop is niet of er een integratielogo bestaat. Het gaat erom of de verbinding kan worden geïnstalleerd, geauthenticeerd, goedgekeurd en gebruikt in de host die je daadwerkelijk gebruikt. Ook moet er een begrijpelijke storingsmodus zijn. Een MCP-server die interactief werkt maar in een onbemande sessie op goedkeuring wacht, is nog steeds bruikbaar, maar mag niet worden omschreven als soepele automatisering.

Voor hergebruikbare instructies geldt een soortgelijk voorbehoud. Lange instructiebestanden bieden geen garantie voor naleving, en een te ingewikkelde set regels kan de context verdoezelen of tegenstrijdigheden veroorzaken. Zorg ervoor dat de richtlijnen in de repository kort, toetsbaar en nauw aansluitend bij de code zijn. Geef aan welke verificatiecommando’s vereist zijn, welke gebieden beschermd zijn, welke stijlregels gelden en wanneer de agent moet stoppen om om toestemming te vragen.

• Projectinstructies: repository-specifieke regels en verificatiecommando's.
• Vaardigheden: herbruikbare procedures of expertise-pakketten.
• MCP: koppelingen met externe tools en gegevens.
• Haken en commando's: automatisering rond vastgestelde workflow-gebeurtenissen.

Codex versus Claude: prijzen en gebruikslimieten

De vergelijking van de basisabonnementen begint bij $20 per maand. Toegang tot Codex is inbegrepen bij het betreffende $20 ChatGPT-abonnement, terwijl Claude Pro in de Verenigde Staten $20 per maand kost en Claude Code omvat. Beide bieden consumententarieven voor intensiever gebruik aan, namelijk $100 en $200. Vergelijkbare catalogusprijzen betekenen niet dat de capaciteit identiek is.

Claude Max 5x kost $100 per maand en Max 20x kost $200 per maand. De benamingen “5x” en “20x” verwijzen naar het gebruik per sessie in vergelijking met Pro, en niet naar een gegarandeerd aantal codeertaken. Claude en Claude Code delen dezelfde sessie- en wekelijkse limieten. De lengte van de context, bijgevoegde bestanden, modelkeuze en het gebruik van functies kunnen invloed hebben op hoe snel de toegewezen hoeveelheid wordt verbruikt.

De optionele gebruikskredieten van Claude maken het mogelijk om, indien ingeschakeld, na het opgenomen verbruik door te gaan met in aanmerking komend werk; deze kredieten worden apart gefactureerd tegen de standaard API-tarieven. Authenticatie via een API-sleutel is een andere, afzonderlijke factureringsroute. Als een van beide routes als “onbeperkt” zou worden aangeduid, zou dit de werkelijke marginale kosten verhullen.

Codex maakt eveneens onderscheid tussen het gebruik binnen het consumentenabonnement, in aanmerking komende aangekochte credits en API-facturering. Voor lokale berichten en cloudchats geldt een tijdsvenster van vijf uur, en er kunnen ook wekelijkse limieten van toepassing zijn. Een tokenveld in een CLI-logboek kan niet rechtstreeks worden omgezet in een percentage van vijf uur, een bedrag aan abonnementskrediet of een API-factuur.

Voor af en toe wat solo-programmeren is het $20-niveau aan beide kanten een verstandig startpunt. Dagelijks werk met repositories en lange contexten kan een hogere tier rechtvaardigen, maar alleen na observatie van daadwerkelijke resets en taakverbruik. Zwaar parallel werk vereist nog meer zorg: betalen voor een grotere tier neemt niet de noodzaak weg om de context te beheren, taken op te splitsen en kostbare redeneringen te reserveren voor werk dat veel beoordelingsvermogen vereist.

Wat onze vergelijkende test tussen de Codex- en de Claude-code aan het licht bracht

We hebben vier Engelse opdrachten, een openbare Python-testomgeving, objectieve controles, een beoordelingsschema en een ‘eerste geldige resultaat’-regel vastgelegd voordat een van beide agents werd gestart. De taken hadden betrekking op het begrijpen van onbekende repositories, een functie met meerdere bestanden, het verhelpen van een DST-bug en codereview met correcties. Bij geldige resultaten vond er geen menselijke tussenkomst plaats, en zwakke maar geldige uitvoer kon niet opnieuw worden uitgevoerd om een betere score te behalen.

Codex voerde de test uit via afzonderlijke CLI-processen, waarbij de onbewerkte JSONL-gegevens en de door de CLI gegenereerde tokenvelden behouden bleven. De OAuth-sessie van de collega voor de Claude CLI was verlopen, dus maakte Claude Code gebruik van een coördinator met nieuwe subagent-contexten. We hebben de patches van Claude gereconstrueerd in schone auditkopieën en de openbare en verborgen controles opnieuw uitgevoerd. Dit leverde geloofwaardig praktisch bewijs op, maar niet identieke isolatie- of modelcontroleoppervlakken.

De testopstelling is te beperkt om de prestaties te beoordelen bij grote datasets, alle talen, alle modelniveaus of lange autonome sessies. Het totale verschil van één punt kan het best worden geïnterpreteerd als “beide waren succesvol, maar met een verschil in de reikwijdte van de beoordeling”, en niet als een algemene ranglijst.

Wat echte gebruikers melden – en in hoeverre je daar vertrouwen in kunt hebben

Feedback van de community is waardevol wanneer daarin een project, taak, model, inzetniveau en tijdshorizon zijn opgenomen. De feedback is minder waardevol wanneer in een bericht alleen wordt vermeld dat een bepaald product “slimmer aanvoelt” of “veel sneller is”. Verschillende gebruikers vergelijken verschillende repositories, abonnementsniveaus, prompts, extensies en mate van begeleiding.

Het bovenstaande contextuele voorbeeld van Reddit wijst op een afweging tussen interactie en snelheid: een snelle, conversatieachtige aanpak kan meer aandacht vergen, terwijl een weloverwogen uitvoering misschien trager aanvoelt, maar minder correcties vereist. Onze gecontroleerde test overlapt slechts gedeeltelijk met dat verslag. Er werd een gemengd beeld van de snelheid vastgesteld en er was geen menselijke tussenkomst bij geldige runs, dus de bewering over ‘babysitting’ kan hiermee niet worden bevestigd. Dit is precies de reden waarom bewijs uit de community en gecontroleerd bewijs samen moeten worden getoond, zonder ze met elkaar te vermengen.

De opmerking over de X-harnas brengt nog een tweede nuttig punt naar voren: een programmeerresultaat hoort bij het hele systeem, niet alleen bij het modellabel. Geen van beide afzonderlijke berichten mag als enquêtegegevens worden beschouwd. Gebruik ze om vragen te formuleren voor je eigen proef: het aantal interventies, de omvang van de verschillen, de kwaliteit van de tests en het herstel na een verkeerde aanname.

Uitbreiding van Codex en Claude-code met GlobalGPT

GlobalGPT is een multimodale werkruimte, en is geen vervanging voor de standaard repository-agents. De praktische functie ervan is om een bestaande host uit te breiden: gebruik een ander beschikbaar agentmodel voor een second opinion, het beoordelen van plannen, het controleren van documentatie of gespecialiseerde uitvoer, terwijl Codex of Claude Code verantwoordelijk blijft voor de toegang tot de repository, shell-opdrachten, tests en goedkeuringen.

GlobalGPT publiceert officiële CLI-handleidingen voor Codex en Claude Code, evenals Cursor. In onze veilige T5-integratietest voltooide de CLI dezelfde ‘bevroren’ taak in beide vergeleken omgevingen. In Codex hebben we ook een alleen-lezen MCP-model-list-aanroep geverifieerd en de GlobalGPT-skill geïnstalleerd, geladen en gebruikt.

# GlobalGPT Samenvatting integratietest

## Reikwijdte

T5 meet de integratie van GlobalGPT en wordt niet meegenomen in de score voor native Codex-codering. Yukie werd niet gebruikt.

## Modelvergrendeling en gereedheid

- Model A: `gpt-5.6-sol`
- Model B: `gpt-5.6-luna`
- Beide modellen stonden in de lijst met live-modellen.
- Beide lichtgewicht gereedheidstests leverden geldige, parseerbare tekst op.
- De modellen werden vergrendeld vóór de formele T5A- en T5B-uitvoeraanroepen.

## Formele CLI-resultaten

| Taak | Model | Status | Duur | Prompt-tokens | Voltooide tokens | Vereiste kopteksten |
|---|---|---|---:|---:|---:|---:|
| T5A | gpt-5.6-sol | Geldig | 27 s | 2.116 | 1.207 | 6/6 |
| T5B | gpt-5.6-luna | Geldig | 14 s | 2.116 | 1.441 | 6/6 |

Beide formele aanroepen maakten gebruik van dezelfde bevroren Engelse productplanningstaak via `glbgpt exec`, leverden uitsluitend in het Engels zichtbare uitvoer op en legden geen inloggegevens bloot. Er vond geen kwaliteitsherhaling plaats.

## MCP-resultaat

- `codex mcp list` toonde aan dat `globalgpt` was ingeschakeld.
- Een niet-interactieve Codex-sessie ontdekte en probeerde `mcp__globalgpt__glbgpt_list_models` uit te voeren, maar de aanroep werd geannuleerd omdat er geen onbemande MCP-goedkeuring beschikbaar was. Er werden geen veiligheidsinstellingen versoepeld.
- De actieve interactieve Codex-sessie riep met succes dezelfde alleen-lezen GlobalGPT MCP-tool aan en ontving negen chatmodellen.
- Resultaat: interactieve MCP-toegang geverifieerd; voor onbeheerde, niet-interactieve MCP-uitvoering geldt nog steeds een goedkeuringsbeperking.

##-skillresultaat

- De GlobalGPT- en GlobalGPT-coderingsskills zijn geïnstalleerd in de Codex-skillmap via koppelingen naar het meegeleverde CLI-skillpakket.
- De GlobalGPT-skill werd geladen en doorlopen voor het controleren van de geconfigureerde sessie, het selecteren van live-modellen, gereedheid, kredietveilige opties en foutafhandeling.
- Resultaat: geïnstalleerd en getest in de actieve Codex-workflow.

## Beperkte conclusie

Deze run verifieert werkende GlobalGPT CLI-aanroepen, een interactieve GlobalGPT MCP-aanroep (alleen-lezen) vanuit Codex en een geïnstalleerd/gebruikt GlobalGPT-vaardigheidspad. Het bewijst niet dat elk model, elke mediatool, elke host, elk account of elke onbemande MCP-configuratie werkt. Het test Yukie niet en ondersteunt geen bewering dat GlobalGPT Codex of Claude Code vervangt.

De afbakening is van belang. De Claude-run van de collega heeft het CLI-pad geverifieerd, niet de MCP aan de Claude-zijde. De Skill was daar wel geïnstalleerd, maar werd niet gebruikt voor de bevroren gesprekken. Een onbemande Codex MCP-poging moest nog steeds handmatig worden goedgekeurd. De beschikbaarheid van modellen en credits hangt ook af van het huidige GlobalGPT-abonnement, dus ontwikkelaars moeten de actuele lijst raadplegen in plaats van ervan uit te gaan dat elk model is inbegrepen.

GlobalGPT omvat ook afbeeldingen, video’s, audio en begeleide Agent-workflows. Yukie’s Slides-, Document- en Image-items vormen een aparte categorie: ze bieden kant-en-klare sjablonen en stapsgewijze begeleiding in de browser voor taken waarbij geen code nodig is. Dat kan gemakkelijker zijn dan een programmeer-CLI openen om een presentatie of gestructureerd document te maken, maar het is geen vervanging voor het doorlezen van de repository, het uitvoeren van tests of het beoordelen van code.

Welk programmeerplatform moet een onafhankelijke ontwikkelaar kiezen?

• Kies Codex wanneer compacte, begrensde uitvoering, de combinatie van beschikbare oppervlakken of de uitvoeringsgegevens die in je opstelling beschikbaar zijn, aansluiten bij jouw manier van werken.
• Kies de code Claude wanneer een conversatieterminallus, de aanpassingsmogelijkheden die je hebt gecontroleerd, of algemener beoordelingsgedrag zoals dat in onze testopstelling is waargenomen, van groter belang zijn.
• Gebruik een van beide voor een onbekende repository pas na een controle op de read-only-architectuur en een risicobeoordeling. Beide tools hebben die taak goed uitgevoerd.
• Gebruik beide op een doordachte manier wanneer een beoordeling door een tweede medewerker de extra kosten voor het abonnement en de coördinatie waard is. Vraag de tweede medewerker om een verschil of plan ter discussie te stellen in plaats van de taak blindelings te herhalen.
• Voeg GlobalGPT toe wanneer multi-model routing of multimodaal werk de ontbrekende schakel is. Houd de native repository-bewerkingen in de codeeromgeving.

Een proefperiode van zeven dagen geeft meer inzicht dan een ranglijst. Kies één echte, maar niet-productiegerelateerde functie of bug en evalueer deze. Bevries de prompt en het succescommando. Leg de eerste geldige diff vast, evenals de geslaagde tests, de verstreken tijd, menselijke interventies, onverwachte reikwijdte en hoe het werk je beschikbare gebruik beïnvloedde. Het betere product is het product waarvan je de fouten kunt opsporen en waarvan je de workflow kunt volhouden.

Veelgestelde vragen over Codex versus Claude-code

Is Codex beter dan de Claude-code?

Niet in alle opzichten. Beide hebben de vier taken in onze testcase voltooid. Claude Code scoorde beter op het gebied van de reikwijdte van de controle, terwijl Codex op bepaalde punten van de implementatie en het verhelpen van fouten compacter was.

Wat is beter voor grote repositories?

Ons kleine programma kan daar geen antwoord op geven. Test beide opties eerst in een alleen-lezen omgeving vanuit je eigen repository voordat je wijzigingen toestaat.

Welk coderingsmiddel vereist minder toezicht?

Dat hangt af van de duidelijkheid van de taak, de modelinstellingen, de instructies in de repository en de gewenste interactiestijl. Een Reddit-gebruiker meldde verschillende supervisiepatronen, maar die individuele ervaring geldt niet als algemene regel voor het hele product.

Wat is goedkoper?

De belangrijkste consumentenniveaus komen overeen met $20, $100 en $200 per maand, maar de inbegrepen capaciteit en de limietregels verschillen. Optionele credits en API-facturering worden apart behandeld.

Gelden er gebruikslimieten voor Claude en Claude Code Share?

Ja. Voor Claude en Claude Code gelden gedeelde sessie- en wekelijkse limieten bij gekoppelde Pro- of Max-abonnementen.

Gelden er gemeenschappelijke limieten voor lokale en cloudtaken in Codex?

Lokale berichten en cloudchats vallen binnen een tijdsbestek van vijf uur, en er kunnen ook wekelijkse limieten gelden.

Kan GlobalGPT Codex of Claude Code vervangen?

Nee. Beide workflows kunnen worden uitgebreid met extra modellen, CLI, MCP, Skills en multimodale tools, maar de toegang tot de repository en het gedrag van de codeeragent blijven bij de host.

Kan ik GlobalGPT uit beide producten gebruiken?

GlobalGPT biedt officiële CLI-handleidingen voor beide. We hebben het gebruik van de CLI in beide omgevingen getest, evenals het gebruik van MCP en Skill in Codex, waarbij voor onbeheerde MCP een goedkeuringsbeperking geldt.

De prijzen, voorwaarden van de abonnementen, integraties en bronvermeldingen zijn in juli 2026 gecontroleerd. Productgegevens kunnen veranderen.

Open GlobalGPT als u een multi-model- en multimodale laag wilt toevoegen aan uw bestaande coderingsworkflow.