feat(#13): S-12b — Workflow Client user-tasks + Beoordelen userTask #83

Merged

not merged 7 commits from feat/13-workflow-user-tasks into main 2026-07-15 08:53:35 +00:00

Conversation 0 Commits 7 Files Changed 6

+279 -14

7 Commits

Author	SHA1	Message	Date
notandClaude Opus 4.8	94a506cbfc	fix(workflow): read task query variables from 'variables', not 'processVariables' (refs #13) ... Flowable's POST query/tasks returns the included process variables under the key 'variables' (the request opts in via includeProcessVariables). The client DTO, its unit test, and the live-check parser all looked for 'processVariables', so the werkbak never matched a task's registrationId and verify-domain timed out. Verified by driving a real Flowable instance end-to-end locally: start -> complete external job -> the Beoordelen task carries registrationId under 'variables'. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 10:29:43 +02:00
notandClaude Opus 4.8	c53354cd22	fix(workflow): query Flowable tasks at service/query/tasks, not runtime/tasks/query (refs #13) ... The task-query endpoint is service/query/tasks; the wrong path 404'd, so verify-domain's werkbak poll got an empty body and the JSON parser aborted the check. Correct the path in the Workflow Client (and its unit test) and make the live-check parser tolerant of a transient empty/non-JSON body so the poll retries instead of crashing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:57:11 +02:00
notandClaude Opus 4.8	57b8755f9d	test(workflow): cover the besluit variable type + start empty-body throw (refs #13) ... Kills two mutation survivors: assert the complete besluit variable's type, and add the missing start empty-response case (the pre-existing baseline survivor). Domain mutation score reaches 100%. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:24:53 +02:00
notandClaude Opus 4.8	3d561deb05	test(workflow): verify-domain exercises the Beoordelen user task end-to-end (refs #13) ... After the worker opens the zaak, the process parks at Beoordelen. The live check now polls Flowable for the task (werkbak), claims it as merel-behandelaar, completes it with besluit=goedkeuren, and asserts the process finishes — proving the exact REST contract (query/claim/complete) the Workflow Client depends on against a real engine. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:21:35 +02:00
notandClaude Opus 4.8	5db55eebf4	feat(workflow): add the Beoordelen behandelaar user task to registratie.bpmn (refs #13) ... After OpenZaakAanmaken the process now parks at a Beoordelen user task (candidate group behandelaar) until the behandelaar claims and completes it. registrationId rides along as a process variable so the werkbak correlates each task to its aggregate. The walking skeleton is unaffected: the temporary /approve path sets the zaak status directly; wiring the decision to complete this task lands in S-12c/d. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:19:19 +02:00
notandClaude Opus 4.8	efd1c06b99	feat(workflow): user-task client for beoordeling — werkbak, claim, complete (refs #13) ... Adds the IUserTaskClient port and implements it on the Workflow Client (the only code that talks to Flowable, §8.2): query open Beoordelen tasks (werkbak) with their registrationId, claim a task for a behandelaar, and complete it carrying the besluit into the process. Registered in DI for later wiring (S-12c). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:18:03 +02:00
notandClaude Opus 4.8	57cc3637c9	test(workflow): user-task client — werkbak query, claim, complete beoordeling (refs #13) ... Red — GetOpenBeoordelingenAsync/ClaimAsync/CompleteBeoordelingAsync do not exist yet. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-15 09:16:46 +02:00