feat(dispatch): usage ook via de herstelroute (T-1972) #180

Merged

janpeter merged 1 commit from feat/t1972-recovery-usage into main

2026-10-03 17:21:12 +02:00

janpeter commented

2026-10-03 17:12:19 +02:00

Owner

Waarom (T-1972, review scrum4me-docker#103)

De supervisor legt de usage van een poging vast in zijn journal, maar herstelt een poging die zijn submit verloor via POST /attempts/recovery/result. Die route kende usage niet, waardoor de usage op dat pad verloren ging (de blokkerende bevinding op scrum4me-docker#103).

Wat

POST /attempts/recovery/result accepteert een optioneel usage ({binding,result,usage?}), net als /attempts/result. De route parseert het niet zelf.
nonLaunchRecovery().submitResult(binding,result,usage) geeft het door via acceptHistoricalResult. Daarna geldt dezelfde domeinlogica als in scrum4me-mcp#179:
- een vers resultaat schrijft de usage in de afrondende transactie;
- een laat resultaat van dezelfde poging schrijft hem eenmalig, en het canonieke resultaat blijft ongemoeid.
README: de herstelroute staat erin, en het bredere late-result-gedrag is beschreven: annulering bij de stop (ook tussen de twee transacties) en operatorherstel met close_failed of close_cancelled. Dit pakt de WARNING uit de review van #179 op met documentatie en tests, in plaats van het gedrag te beperken. Een supervisor dient alleen zijn ene vastgelegde resultaat opnieuw in, dus de late usage is altijd die van de run zelf.

Verificatie

RED: de nieuwe tests voor de herstelroute (vers resultaat, en laat resultaat na annulering) faalden met lege usagekolommen.
vitest.dispatch.config.ts op een wegwerp-Postgres: 288 van 288 (recovery-suite 19 van 19, waarvan 3 nieuw, onder meer late result na close_failed).
npx vitest run: 2032 geslaagd; tsc --noEmit is schoon.

Uitrolvolgorde: deze service gaat live vóór een supervisor die usage via de herstelroute meestuurt (scrum4me-docker#103).

🤖 Generated with Claude Code

## Waarom (T-1972, review scrum4me-docker#103) De supervisor legt de usage van een poging vast in zijn journal, maar herstelt een poging die zijn submit verloor via `POST /attempts/recovery/result`. Die route kende `usage` niet, waardoor de usage op dat pad verloren ging (de blokkerende bevinding op scrum4me-docker#103). ## Wat - `POST /attempts/recovery/result` accepteert een optioneel `usage` (`{binding,result,usage?}`), net als `/attempts/result`. De route parseert het niet zelf. - `nonLaunchRecovery().submitResult(binding,result,usage)` geeft het door via `acceptHistoricalResult`. Daarna geldt dezelfde domeinlogica als in scrum4me-mcp#179: - een vers resultaat schrijft de usage in de afrondende transactie; - een laat resultaat van dezelfde poging schrijft hem eenmalig, en het canonieke resultaat blijft ongemoeid. - README: de herstelroute staat erin, en het bredere late-result-gedrag is beschreven: annulering bij de stop (ook tussen de twee transacties) en operatorherstel met `close_failed` of `close_cancelled`. Dit pakt de WARNING uit de review van #179 op met documentatie en tests, in plaats van het gedrag te beperken. Een supervisor dient alleen zijn ene vastgelegde resultaat opnieuw in, dus de late usage is altijd die van de run zelf. ## Verificatie - RED: de nieuwe tests voor de herstelroute (vers resultaat, en laat resultaat na annulering) faalden met lege usagekolommen. - `vitest.dispatch.config.ts` op een wegwerp-Postgres: **288 van 288** (recovery-suite 19 van 19, waarvan 3 nieuw, onder meer late result na `close_failed`). - `npx vitest run`: 2032 geslaagd; `tsc --noEmit` is schoon. **Uitrolvolgorde:** deze service gaat live vóór een supervisor die `usage` via de herstelroute meestuurt (scrum4me-docker#103). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

janpeter added 1 commit

2026-10-03 17:12:19 +02:00

feat(dispatch): usage ook via de herstelroute (T-1972, review scrum4me-docker#103)

CI / Final merge attestation and immutable publication (pull_request) Has been skipped

Details

CI / PR candidate (never published) (pull_request) Successful in 8m49s

Details

f12c06e41d

POST /attempts/recovery/result accepteert hetzelfde optionele usage-veld als
/attempts/result en geeft het via acceptHistoricalResult aan dezelfde
domeinlogica: vers resultaat schrijft usage in de afrondende transactie, een
laat resultaat van dezelfde poging eenmalig. Zo gaat de journalled usage van
een supervisor die via authority:'none' herstelt niet verloren.

README: de herstelroute en het bredere late-result-gedrag (annulering, ook
tussen de twee transacties, en operator close_failed/close_cancelled) zijn
gedocumenteerd en getest (review #179 WARNING).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

s4m-codex-reviewer reviewed

2026-10-03 17:18:00 +02:00

s4m-codex-reviewer left a comment

COMMENT

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

Findings

LOW — tests/dispatch/recovery.integration.test.ts:142: De nieuwe tests roepen submitResult rechtstreeks aan. Voeg een HTTP-regressietest toe voor POST /attempts/recovery/result met usage; de oorspronkelijke strict-parser zou deze tests ook passeren terwijl hij dat veld weigert.

De diff hergebruikt de bestaande authenticatie, historische binding en transactionele usage-opslag. Tests beschrijven normale afronding, eenmalige late usage na annulering en operator close_failed; de README werkt het HTTP-contract bij. Geen blokkerende codefout vastgesteld.

Beoordeeld op commit f12c06e41d793fa44877115458f192b73ae8b2c3. Uitvoeringsbewijs blijft beperkt: npm ci faalde op esbuild (EACCES, /tmp is noexec); installatie zonder scripts slaagde, maar beide typechecks konden zonder gegenereerde Prisma-client niet groen worden. De dispatch-integratiegate stopt op DISPATCH_TEST_SCHEMA_ROOT_REQUIRED; de vereiste testdatabaseconfiguratie ontbreekt. Deze omgevingsproblemen zijn geen bewezen PR-regressies. Vanwege ontbrekend uitvoeringsbewijs en de HTTP-testlacune kies ik conform safe-default COMMENT.

# COMMENT geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings - **LOW — __tests__/dispatch/recovery.integration.test.ts:142**: De nieuwe tests roepen `submitResult` rechtstreeks aan. Voeg een HTTP-regressietest toe voor `POST /attempts/recovery/result` met `usage`; de oorspronkelijke strict-parser zou deze tests ook passeren terwijl hij dat veld weigert. De diff hergebruikt de bestaande authenticatie, historische binding en transactionele usage-opslag. Tests beschrijven normale afronding, eenmalige late usage na annulering en operator `close_failed`; de README werkt het HTTP-contract bij. Geen blokkerende codefout vastgesteld. Beoordeeld op commit `f12c06e41d793fa44877115458f192b73ae8b2c3`. Uitvoeringsbewijs blijft beperkt: `npm ci` faalde op esbuild (`EACCES`, `/tmp` is `noexec`); installatie zonder scripts slaagde, maar beide typechecks konden zonder gegenereerde Prisma-client niet groen worden. De dispatch-integratiegate stopt op `DISPATCH_TEST_SCHEMA_ROOT_REQUIRED`; de vereiste testdatabaseconfiguratie ontbreekt. Deze omgevingsproblemen zijn geen bewezen PR-regressies. Vanwege ontbrekend uitvoeringsbewijs en de HTTP-testlacune kies ik conform safe-default `COMMENT`.

janpeter merged commit 6b2a7a384d into main

2026-10-03 17:21:12 +02:00

janpeter referenced this pull request from a commit

2026-10-03 17:21:13 +02:00

Merge pull request 'feat(dispatch): usage ook via de herstelroute (T-1972)' (#180)

janpeter referenced this pull request from a commit

2026-10-03 18:07:56 +02:00

test(dispatch): HTTP-regressietest voor usage op /attempts/recovery/result (review #180)