fix(queue): leid de 'as'-enum af uit QUEUE_MODELS in plaats van hem over te typen #107

Merged

janpeter merged 1 commit from feat/queue-kimi-enums into main 2026-07-26 23:15:31 +02:00

Conversation 0 Commits 1 Files changed 9 +97 -7

janpeter commented 2026-07-26 22:35:15 +02:00

Owner

Copy link

T-125: de vier as-enums in de queue-tools afleiden uit QUEUE_MODELS, plus de submodule-bump die kimi binnenhaalt.

Het gat dat dit dicht. src/queue/identity.ts valideerde al netjes tegen de runtime-array, maar de vier tool-schema's hadden de lijst overgetypt. Gevolg: S4M_MODEL=kimi werkte, terwijl as: 'kimi' door Zod geweigerd werd vóórdat identity-code ooit draaide. En omdat src/queue/types.ts alleen het type importeert en niet de array, bleef de typecheck bij die drift gewoon groen — de stille faalmodus die dit vocabulaire kenmerkt.

Zod 4 doet dit uit zichzelf. Ik verwachtte de mutable-tuple-cast ([...QUEUE_MODELS] as [...]) nodig te hebben; dat is de Zod-3-workaround. Deze repo draait Zod 4.3.6, waar _enum een readonly string[] accepteert, dus z.enum(QUEUE_MODELS) volstaat. Beide vormen zijn langs tsc gehaald en leveren hetzelfde outputtype; de cast is weggelaten omdat hij zou suggereren dat er iets te repareren viel.

Vier losse imports in plaats van één gedeelde constante — src/queue/types.ts legt in zijn header expliciet vast dat het gedeelde vocabulaire daar bewust niet opnieuw ge-exporteerd wordt, zodat de herkomst per bestand leesbaar blijft, en queue-next.ts deed dit al zo voor QUEUE_REQUEST_TYPES.

Een vijfde plek die de greps niet vonden. De description van queue_push somde de modellen met de hand op ("models: claude, codex, jp"). Geen quotes rond de losse waarden, dus onvindbaar met de voorgeschreven zoekopdracht — en juist die tekst is wat een agent leest om te weten welke waarden bestaan. Nu afgeleid uit QUEUE_SERVERS/QUEUE_MODELS.

De tests bewijzen iets, en dat was niet vanzelfsprekend. Het mock-serverpatroon in deze repo roept handlers rechtstreeks aan en slaat Zod dus over; een test die enkel server.call({as:'kimi'}) doet was óók onder de oude hardcoded lijst groen geweest. De nieuwe tests trekken daarom het inputSchema uit de gecaptureerde registerTool-meta en parsen daar tegenaan, plus een negatieve assertie op as:'gpt' zodat een sluipende z.string() ze niet groen houdt. Mutatie bevestigd: enums terugdraaien naar de oude lijst laat exact vier tests vallen, één per tool.

Verificatie. 1339 passed (was 1335), 29 skipped, typecheck exit 0. Submodule op 9812ae5; git diff --stat prisma/schema.prisma leeg en 39 modellen — de generatie-val uit eerdere uitrollen is gecontroleerd, niet aangenomen.

Nog open, bewust buiten scope: queue-push.ts:14 heeft type: z.enum(['task','info','review_request']) terwijl QUEUE_REQUEST_TYPES bestaat — dezelfde klasse drift, ander vocabulaire. Belegd in T-129, samen met de pariteitsgate.

🤖 Generated with Claude Code

T-125: de vier `as`-enums in de queue-tools afleiden uit `QUEUE_MODELS`, plus de submodule-bump die `kimi` binnenhaalt. **Het gat dat dit dicht.** `src/queue/identity.ts` valideerde al netjes tegen de runtime-array, maar de vier tool-schema's hadden de lijst overgetypt. Gevolg: `S4M_MODEL=kimi` werkte, terwijl `as: 'kimi'` door Zod geweigerd werd vóórdat identity-code ooit draaide. En omdat `src/queue/types.ts` alleen het *type* importeert en niet de array, bleef de typecheck bij die drift gewoon groen — de stille faalmodus die dit vocabulaire kenmerkt. **Zod 4 doet dit uit zichzelf.** Ik verwachtte de mutable-tuple-cast (`[...QUEUE_MODELS] as [...]`) nodig te hebben; dat is de Zod-3-workaround. Deze repo draait Zod 4.3.6, waar `_enum` een `readonly string[]` accepteert, dus `z.enum(QUEUE_MODELS)` volstaat. Beide vormen zijn langs `tsc` gehaald en leveren hetzelfde outputtype; de cast is weggelaten omdat hij zou suggereren dat er iets te repareren viel. Vier losse imports in plaats van één gedeelde constante — `src/queue/types.ts` legt in zijn header expliciet vast dat het gedeelde vocabulaire daar bewust niet opnieuw ge-exporteerd wordt, zodat de herkomst per bestand leesbaar blijft, en `queue-next.ts` deed dit al zo voor `QUEUE_REQUEST_TYPES`. **Een vijfde plek die de greps niet vonden.** De `description` van `queue_push` somde de modellen met de hand op ("models: claude, codex, jp"). Geen quotes rond de losse waarden, dus onvindbaar met de voorgeschreven zoekopdracht — en juist die tekst is wat een agent leest om te weten welke waarden bestaan. Nu afgeleid uit `QUEUE_SERVERS`/`QUEUE_MODELS`. **De tests bewijzen iets, en dat was niet vanzelfsprekend.** Het mock-serverpatroon in deze repo roept handlers rechtstreeks aan en slaat Zod dus over; een test die enkel `server.call({as:'kimi'})` doet was óók onder de oude hardcoded lijst groen geweest. De nieuwe tests trekken daarom het `inputSchema` uit de gecaptureerde `registerTool`-meta en parsen daar tegenaan, plus een negatieve assertie op `as:'gpt'` zodat een sluipende `z.string()` ze niet groen houdt. Mutatie bevestigd: enums terugdraaien naar de oude lijst laat exact vier tests vallen, één per tool. **Verificatie.** 1339 passed (was 1335), 29 skipped, typecheck exit 0. Submodule op `9812ae5`; `git diff --stat prisma/schema.prisma` leeg en 39 modellen — de generatie-val uit eerdere uitrollen is gecontroleerd, niet aangenomen. Nog open, bewust buiten scope: `queue-push.ts:14` heeft `type: z.enum(['task','info','review_request'])` terwijl `QUEUE_REQUEST_TYPES` bestaat — dezelfde klasse drift, ander vocabulaire. Belegd in T-129, samen met de pariteitsgate. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

janpeter added 1 commit 2026-07-26 22:35:17 +02:00

fix(queue): leid de 'as'-enum af uit QUEUE_MODELS in plaats van hem over te typen ... 7677b447bc

De vier queue-tools typten het modelvocabulaire over als
z.enum(['claude','codex','jp']). Sinds 'kimi' erbij kwam weigerde Zod
`as: 'kimi'` vóórdat resolveQueueIdentity — dat wél tegen QUEUE_MODELS
toetst — ooit draaide, terwijl S4M_MODEL=kimi gewoon werkte.

De drift kon niet rood worden: src/queue/types.ts importeert alleen het
*type* QueueModel, niet de runtime-array, dus tsc zag geen verschil.

Nu: z.enum(QUEUE_MODELS) in queue-push, queue-next, queue-list en
queue-wait-reply. Zod 4 accepteert readonly const-tuples rechtstreeks, dus
de cast naar een mutable tuple is niet nodig. Elk bestand importeert
QUEUE_MODELS zelf uit @shared/queue-identity.js — dezelfde afspraak als de
header van src/queue/types.ts beschrijft en als queue-next al deed voor
QUEUE_REQUEST_TYPES.

Ook de queue_push-description somde de modellen met de hand op; die komt nu
uit QUEUE_SERVERS/QUEUE_MODELS, zodat de tool-omschrijving niet over kimi
kan liegen.

Bevat de submodule-bump van vendor/scrum4me-shared naar 9812ae5, waar
QUEUE_MODELS 'kimi' toevoegt.

janpeter merged commit 352b5d25cb into main 2026-07-26 23:15:31 +02:00

janpeter referenced this pull request from a commit 2026-07-26 23:15:33 +02:00

Merge pull request 'fix(queue): leid de 'as'-enum af uit QUEUE_MODELS in plaats van hem over te typen' (#107) from feat/queue-kimi-enums into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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-mcp!107

No description provided.