feat(dispatch): kind draait met model en effort uit de jobconfig (M41 W1, T-1957) #99

Merged
janpeter merged 2 commits from feat/m41-child-model into master 2026-10-02 22:33:36 +02:00
Owner

Waarom

M41 increment 5, W1, met daarin T-1957. Het kind (model-codex) draaide altijd op de standaard van de Codex-CLI. Het run-log en Ops Worker Logs noemden intussen het model uit de jobconfig (model=gpt-5.6-sol effort=6000), dus de modelregel was misleidend. Besluit JP (2026-10-02): model en effort komen uit de QUEUE_REVIEW-jobconfig.

Wat

  • lib/dispatch-runtime.ts: childModelFromConfig(modelConfig) maakt van de jobconfig {model, effort}:
    • een numeriek thinking_budget wordt een Codex-effort: tot en met 6000 medium, tot en met 12000 high, daarboven xhigh (max bestaat niet in Codex); 0 of null geeft geen effort;
    • een effort die al low, medium, high of xhigh heet, blijft ongewijzigd;
    • een model dat geen plain token is (^[A-Za-z0-9][A-Za-z0-9._:-]{0,63}$) of een config die niet voor CODEX is, geeft geen childModel. Het kind draait dan de CLI-standaard.
  • Runtime-port: stuurt childModel mee in de broker-create.
  • Broker: createSchema accepteert een optioneel, strikt childModel. buildContainerArgs zet precies DISPATCH_CODEX_MODEL en DISPATCH_CODEX_REASONING_EFFORT in de omgeving van het kind, en weigert elke andere vorm.
  • Run-log: noemt het model en de effort waarmee het kind werkelijk draaide, of cli-default.
  • Operator-doc: bijgewerkt.

Bewijs

  • Eerst rood, dan groen:
    • __tests__/dispatch-child-model.test.ts (4 tests): mapping, validatie, env-argumenten en de create-aanroep van de runtime-port;
    • run-logtest "names the model and mapped effort";
    • brokertest "puts the job config model into the child env and refuses an unsafe one". Die is ook rood gezien met alleen de brokerwijziging teruggedraaid.
  • Aangepaste test: de bestaande sanitize-test in het run-log eist nu cli-default voor een niet-plain model en controleert dat er geen veld in de metaregel komt.
  • Suite: npm test 1047 groen, plus de 2 bekende macOS-failures in transcript-retention. tsc -p tsconfig.dispatch.json groen.

Na merge en uitrol bewijst een echte reviewjob het gekozen model in transcript en run-log (acceptatie van increment 5).

Story ST-1618, taak T-1958 (Scrum4Me).

🤖 Generated with Claude Code

## Waarom M41 increment 5, W1, met daarin T-1957. Het kind (`model-codex`) draaide altijd op de standaard van de Codex-CLI. Het run-log en Ops Worker Logs noemden intussen het model uit de jobconfig (`model=gpt-5.6-sol effort=6000`), dus de modelregel was misleidend. Besluit JP (2026-10-02): model en effort komen uit de `QUEUE_REVIEW`-jobconfig. ## Wat - **`lib/dispatch-runtime.ts`:** `childModelFromConfig(modelConfig)` maakt van de jobconfig `{model, effort}`: - een numeriek `thinking_budget` wordt een Codex-effort: tot en met 6000 `medium`, tot en met 12000 `high`, daarboven `xhigh` (`max` bestaat niet in Codex); 0 of null geeft geen effort; - een effort die al `low`, `medium`, `high` of `xhigh` heet, blijft ongewijzigd; - een model dat geen plain token is (`^[A-Za-z0-9][A-Za-z0-9._:-]{0,63}$`) of een config die niet voor CODEX is, geeft geen `childModel`. Het kind draait dan de CLI-standaard. - **Runtime-port:** stuurt `childModel` mee in de broker-`create`. - **Broker:** `createSchema` accepteert een optioneel, strikt `childModel`. `buildContainerArgs` zet precies `DISPATCH_CODEX_MODEL` en `DISPATCH_CODEX_REASONING_EFFORT` in de omgeving van het kind, en weigert elke andere vorm. - **Run-log:** noemt het model en de effort waarmee het kind werkelijk draaide, of `cli-default`. - **Operator-doc:** bijgewerkt. ## Bewijs - **Eerst rood, dan groen:** - `__tests__/dispatch-child-model.test.ts` (4 tests): mapping, validatie, env-argumenten en de create-aanroep van de runtime-port; - run-logtest "names the model and mapped effort"; - brokertest "puts the job config model into the child env and refuses an unsafe one". Die is ook rood gezien met alleen de brokerwijziging teruggedraaid. - **Aangepaste test:** de bestaande sanitize-test in het run-log eist nu `cli-default` voor een niet-plain model en controleert dat er geen veld in de metaregel komt. - **Suite:** `npm test` 1047 groen, plus de 2 bekende macOS-failures in `transcript-retention`. `tsc -p tsconfig.dispatch.json` groen. Na merge en uitrol bewijst een echte reviewjob het gekozen model in transcript en run-log (acceptatie van increment 5). Story ST-1618, taak T-1958 (Scrum4Me). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
feat(dispatch): kind draait met model en effort uit de jobconfig (M41 W1, T-1957)
All checks were successful
CI / Compose config (pull_request) Successful in 4s
CI / Build-arg coverage (pull_request) Successful in 9s
CI / Docker build (pull_request) Successful in 1m21s
697f9eae90
De supervisor geeft het model en de thinking budget van de QUEUE_REVIEW-
jobconfig als childModel mee in de broker-create (budget naar Codex-effort:
medium tot 6000, high tot 12000, daarboven xhigh). De broker valideert
strikt en zet precies DISPATCH_CODEX_MODEL en DISPATCH_CODEX_REASONING_EFFORT
in de omgeving van het kind. Het run-log noemt nu het model en de effort
waarmee het kind werkelijk draaide, of cli-default.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
s4m-codex-reviewer left a comment

REQUEST_CHANGES

geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

  • error — lib/dispatch-runtime.ts:21: childModelFromConfig kopieert de Claude-mapping (mapBudgetToEffort) terwijl de bestaande Codex-runner mapBudgetToCodexEffort uit vendor/scrum4me-shared/lib/codex-config.ts gebruikt. Reproductie: budget 6000 geeft hier medium versus gedeeld low; 12000 geeft high versus medium; 24000 geeft xhigh versus high. Dezelfde jobconfig draait daardoor met een andere reasoning effort via dispatch dan via de reguliere Codex-runner, met gevolgen voor looptijd en gebruik. Hergebruik de Codex-helper en corrigeer de bijbehorende tests en operator-documentatie; de nieuwe tests leggen nu juist de afwijkende mapping vast.

De modeldoorgifte via runtime → strikt gevalideerde broker → vaste omgevingsvariabelen sluit verder aan op de bestaande grenzen. Het run-log gebruikt dezelfde resolver als de runtime.

Verificatie op commit 697f9eae906bc1eba1a9f21f8d010b790fd8f761: TypeScript-controle (tsconfig.dispatch.json) geslaagd; bovenstaande mappingverschillen rechtstreeks gereproduceerd. Vitest kon niet starten door de uitvoer-/native-librarybeperking van /tmp; geen geslaagde testsuite geclaimd. Docker-integratietests niet uitgevoerd.

# REQUEST_CHANGES geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. - **error — lib/dispatch-runtime.ts:21:** `childModelFromConfig` kopieert de Claude-mapping (`mapBudgetToEffort`) terwijl de bestaande Codex-runner `mapBudgetToCodexEffort` uit `vendor/scrum4me-shared/lib/codex-config.ts` gebruikt. Reproductie: budget 6000 geeft hier `medium` versus gedeeld `low`; 12000 geeft `high` versus `medium`; 24000 geeft `xhigh` versus `high`. Dezelfde jobconfig draait daardoor met een andere reasoning effort via dispatch dan via de reguliere Codex-runner, met gevolgen voor looptijd en gebruik. Hergebruik de Codex-helper en corrigeer de bijbehorende tests en operator-documentatie; de nieuwe tests leggen nu juist de afwijkende mapping vast. De modeldoorgifte via runtime → strikt gevalideerde broker → vaste omgevingsvariabelen sluit verder aan op de bestaande grenzen. Het run-log gebruikt dezelfde resolver als de runtime. Verificatie op commit `697f9eae906bc1eba1a9f21f8d010b790fd8f761`: TypeScript-controle (`tsconfig.dispatch.json`) geslaagd; bovenstaande mappingverschillen rechtstreeks gereproduceerd. Vitest kon niet starten door de uitvoer-/native-librarybeperking van `/tmp`; geen geslaagde testsuite geclaimd. Docker-integratietests niet uitgevoerd.
Author
Owner

BLOCKER verwerkt in 5ed7b11: childModelFromConfig gebruikt nu de gedeelde mapBudgetToCodexEffort uit vendor/scrum4me-shared/lib/codex-config.ts (6000 → low, 12000 → medium, meer → high), dezelfde mapping als de gewone Codex-runner. Een test vergelijkt de waarden 1, 6000, 6001, 12000, 12001, 24000, 99999 en 0 rechtstreeks met de gedeelde helper. Die test faalde tegen de vorige mapping. De run-logtest en de operator-doc zijn bijgewerkt. npm test geeft 1048 groen (plus de 2 bekende macOS-failures), tsc groen.

BLOCKER verwerkt in `5ed7b11`: `childModelFromConfig` gebruikt nu de gedeelde `mapBudgetToCodexEffort` uit `vendor/scrum4me-shared/lib/codex-config.ts` (6000 → low, 12000 → medium, meer → high), dezelfde mapping als de gewone Codex-runner. Een test vergelijkt de waarden 1, 6000, 6001, 12000, 12001, 24000, 99999 en 0 rechtstreeks met de gedeelde helper. Die test faalde tegen de vorige mapping. De run-logtest en de operator-doc zijn bijgewerkt. `npm test` geeft 1048 groen (plus de 2 bekende macOS-failures), tsc groen.
fix(dispatch): effort via de gedeelde codex-mapping (review #99)
All checks were successful
CI / Build-arg coverage (pull_request) Successful in 4s
CI / Compose config (pull_request) Successful in 10s
CI / Docker build (pull_request) Successful in 1m19s
5ed7b1111c
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
s4m-codex-reviewer left a comment

COMMENT

Geen blokkerende codefouten gevonden bij de statische beoordeling van commit 5ed7b1111ce4280b446667e7a734fce9fcc951bf. Model en effort worden vanuit de execution context doorgegeven via een strikt gevalideerd broker-object; de child-runner gebruikt de variabelen als CLI-argumenten. De numerieke mapping hergebruikt de gedeelde Codex-helper. Tests dekken de budgetgrenzen, broker-validatie, transport en run-log; de operator-documentatie is bijgewerkt. De geraadpleegde product-standaarden vragen hergebruik van bestaande utilities en verificatie.

Findings

  • LOW — lib/dispatch-runtime.ts:8 — De comment beweert dat max naar xhigh wordt gemapt. In werkelijkheid levert childModelFromConfig voor max effort:null op en weigert het broker-schema max. Pas de comment aan de werkelijke mapping aan.
  • INFO — tests/dispatch-child-model.test.ts:9 — De tests konden in deze reviewomgeving niet starten: executables/native modules onder /tmp geven Permission denied respectievelijk failed to map segment from shared object. Dit bewijst geen testregressie, maar laat de runtimeverificatie onbevestigd; daarom geen APPROVED.

Verificatie: PR-head via Forgejo Git opgehaald en gecontroleerd; node node_modules/typescript/bin/tsc -p tsconfig.dispatch.json geslaagd. Geen succesvolle test- of Docker-integratierun beschikbaar.

geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

# COMMENT Geen blokkerende codefouten gevonden bij de statische beoordeling van commit `5ed7b1111ce4280b446667e7a734fce9fcc951bf`. Model en effort worden vanuit de execution context doorgegeven via een strikt gevalideerd broker-object; de child-runner gebruikt de variabelen als CLI-argumenten. De numerieke mapping hergebruikt de gedeelde Codex-helper. Tests dekken de budgetgrenzen, broker-validatie, transport en run-log; de operator-documentatie is bijgewerkt. De geraadpleegde product-standaarden vragen hergebruik van bestaande utilities en verificatie. ## Findings - **LOW — lib/dispatch-runtime.ts:8** — De comment beweert dat `max` naar `xhigh` wordt gemapt. In werkelijkheid levert `childModelFromConfig` voor `max` `effort:null` op en weigert het broker-schema `max`. Pas de comment aan de werkelijke mapping aan. - **INFO — __tests__/dispatch-child-model.test.ts:9** — De tests konden in deze reviewomgeving niet starten: executables/native modules onder `/tmp` geven `Permission denied` respectievelijk `failed to map segment from shared object`. Dit bewijst geen testregressie, maar laat de runtimeverificatie onbevestigd; daarom geen APPROVED. Verificatie: PR-head via Forgejo Git opgehaald en gecontroleerd; `node node_modules/typescript/bin/tsc -p tsconfig.dispatch.json` geslaagd. Geen succesvolle test- of Docker-integratierun beschikbaar. geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.
janpeter merged commit ca57581ca7 into master 2026-10-02 22:33:36 +02:00
Sign in to join this conversation.
No reviewers
No labels
severity/s3
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/scrum4me-docker!99
No description provided.