refactor(wait-for-job): expliciete sprint-scope types op de claim-mapping #50

Merged
janpeter merged 1 commit from refactor/wait-for-job-sprint-scope-types into main 2026-06-10 22:13:45 +02:00
Owner

Route (b) uit de Docker-build-diagnose (follow-up van #49, dat route (a) — de ontbrekende bash in de deps-stage — fixte).

Wat

De sprint-scope mapping in getFullJobContext (SPRINT_IMPLEMENTATION-claim) leunde volledig op type-inferentie uit de gegenereerde Prisma-client. Zonder client (stille generate-failure) werden de query-resultaten any en regende het TS7006 implicit-any op de map-callbacks (~1240–1332) — de fout waarmee de build op 154 faalde. Deze PR legt het response-contract expliciet vast:

  • Structurele interfaces SprintScopePbi / SprintScopeTask / SprintScopeStory / SprintExecutionRow die de include/select van de sprintRun-query spiegelen (verify_required als VerifyRequired-enum omdat die de createMany-input instroomt; nullability conform schema).
  • Eén getypte bron-binding per keten: scopeStories, een executions-annotatie en Map<string, SprintScopePbi> i.p.v. de typeof-keten die bij afwezige client stil naar any collapsete. Alle downstream callbacks krijgen daarmee contextual typing — geen per-callback annotaties nodig.
  • Geen logica-wijzigingen.

Bewust níet het doel

Volledige "typecheck zonder client" is structureel onhaalbaar én onwenselijk: gemeten resteren er dan 25 TS2305 no exported member '@prisma/client'-fouten door het hele project (o.a. PrismaClient zelf) — terecht, want een image zonder client is stuk. De winst hier: déze datavorm-kritische mapping blijft gecheckt bij een verouderde client, en het afwezige-client-scenario faalt voortaan met leesbare import-errors i.p.v. implicit-any-ruis.

Verificatie

  • npx tsc --noEmit (gegenereerde client): exit 0
  • npx vitest run: 750/750 groen (96 files)
  • Absent-client-experiment (worktree-kopie in /tmp zonder node_modules/.prisma, geen parent-resolution): 84 → 79 fouten; alle 8 TS7006's in deze keten weg (1240/1241/1251×2/1274/1312/1321×2); +3 zelfverklarende TS2305 op de nieuwe type-only import (zelfde klasse als de bestaande regel-6-import)
  • Lokale docker build van de Dockerfile: groen; [build 8/8] RUN npm run typecheck succesvol over deze wijziging, apk add bash (#49) in de deps-stage bevestigd

Follow-up-suggestie (buiten scope)

De postinstall eindigt op || true — elke toekomstige generate-failure blijft daardoor stil tot de typecheck-gate. Overweeg in de Docker-deps-stage een expliciete RUN npm run prisma:generate (zonder || true) ná npm ci, zodat zo'n failure de build direct en op de juiste plek breekt.

🤖 Generated with Claude Code

Route (b) uit de Docker-build-diagnose (follow-up van #49, dat route (a) — de ontbrekende bash in de deps-stage — fixte). ## Wat De sprint-scope mapping in `getFullJobContext` (SPRINT_IMPLEMENTATION-claim) leunde volledig op type-inferentie uit de gegenereerde Prisma-client. Zonder client (stille generate-failure) werden de query-resultaten `any` en regende het TS7006 implicit-any op de map-callbacks (~1240–1332) — de fout waarmee de build op 154 faalde. Deze PR legt het response-contract expliciet vast: - Structurele interfaces `SprintScopePbi` / `SprintScopeTask` / `SprintScopeStory` / `SprintExecutionRow` die de include/select van de sprintRun-query spiegelen (`verify_required` als `VerifyRequired`-enum omdat die de createMany-input instroomt; nullability conform schema). - Eén getypte bron-binding per keten: `scopeStories`, een `executions`-annotatie en `Map<string, SprintScopePbi>` i.p.v. de `typeof`-keten die bij afwezige client stil naar `any` collapsete. Alle downstream callbacks krijgen daarmee contextual typing — geen per-callback annotaties nodig. - Geen logica-wijzigingen. ## Bewust níet het doel Volledige "typecheck zonder client" is structureel onhaalbaar én onwenselijk: gemeten resteren er dan 25 `TS2305 no exported member '@prisma/client'`-fouten door het hele project (o.a. `PrismaClient` zelf) — terecht, want een image zonder client is stuk. De winst hier: déze datavorm-kritische mapping blijft gecheckt bij een verouderde client, en het afwezige-client-scenario faalt voortaan met leesbare import-errors i.p.v. implicit-any-ruis. ## Verificatie - `npx tsc --noEmit` (gegenereerde client): exit 0 - `npx vitest run`: 750/750 groen (96 files) - Absent-client-experiment (worktree-kopie in /tmp zonder `node_modules/.prisma`, geen parent-resolution): 84 → 79 fouten; alle 8 TS7006's in deze keten weg (1240/1241/1251×2/1274/1312/1321×2); +3 zelfverklarende TS2305 op de nieuwe type-only import (zelfde klasse als de bestaande regel-6-import) - Lokale docker build van de Dockerfile: groen; `[build 8/8] RUN npm run typecheck` succesvol over deze wijziging, `apk add bash` (#49) in de deps-stage bevestigd ## Follow-up-suggestie (buiten scope) De postinstall eindigt op `|| true` — elke toekomstige generate-failure blijft daardoor stil tot de typecheck-gate. Overweeg in de Docker-deps-stage een expliciete `RUN npm run prisma:generate` (zonder `|| true`) ná `npm ci`, zodat zo'n failure de build direct en op de juiste plek breekt. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
De mcp-http-imagebuild faalde op de typecheck-gate met TS7006-ruis in de
sprint-scope map-callbacks (~1240-1332) zodra de gegenereerde Prisma-client
ontbrak — query-resultaten werden `any`, callbacks verloren hun contextual
type. Root cause (geen bash in node:22-alpine → stille postinstall-failure)
is gefixt in PR #49; dit is route (b) uit de diagnose: leg het response-
contract vast in structurele interfaces (SprintScopePbi/Task/Story +
SprintExecutionRow) en typeer de bron-bindings (scopeStories, executions,
pbiMap) expliciet. Zo blijft tsc deze shapes bewaken bij een afwezige of
verouderde client, en wordt dat scenario een leesbare import-error i.p.v.
implicit-any-ruis.

Gemeten (absent-client experiment, kopie zonder node_modules/.prisma):
8 TS7006's in deze keten weg. Met client: tsc exit 0, 750 tests groen,
lokale docker build groen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
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-mcp!50
No description provided.