feat(#13): S-12a — beoordeling decision model (domain) #82

Merged
not merged 7 commits from feat/13-behandel-decision-model into main 2026-07-15 07:12:20 +00:00
Contributor

What & why

First sub-slice of S-12 (#13) — the beoordeling decision model in the Domain Service. Foundation for the behandel-portal: it gives the domain a proper decision lifecycle before any UI/Flowable/BFF work.

  • Statuses: add InBehandeling and Afgewezen to RegistrationStatus.
  • Aggregate: TakeIntoBehandeling() (Ingediend → InBehandeling, idempotent, guards terminal states); generalise the behandelaar decision — Approve() (requires a zaak) and new Reject() both act on an Ingediend/InBehandeling registration → Ingeschreven/Afgewezen.
  • Use-case: BeoordeelRegistratie (goedkeuren sets the zaak's final status via the ACL §8.1 → Ingeschreven; afwijzenAfgewezen, domain-only for now). Idempotent.
  • Endpoint: POST /registrations/{id}/decide ({ "besluit": "goedkeuren" | "afwijzen" }), superseding the temporary /approve (retired when the portal lands, S-12d).
  • BDD: EenRegistratieBeoordelen.feature — goedkeuren + afwijzen scenarios (feature-scoped bindings).

Scoped out to later S-12 sub-slices: Flowable user-task claim/complete + BPMN userTask (S-12b), BFF /behandel/* + medewerker authz (S-12c), the Angular behandel-portal + e2e (S-12d), and propagating a rejection to the zaak/projection via the ACL.

Definition of Done

  • Linked issue: #13 (umbrella; this PR refs, does not close)
  • Tests first; red → green per behaviour
  • Unit + acceptance green (make unit): domain 65, acceptance 9
  • Mutation ≥ break(90): domain 98.77%, no survivors in new code (the one unkilled mutant is the pre-existing FlowableWorkflowClient baseline)
  • CI green (pending)

Part of #13.

## What & why First sub-slice of **S-12 (#13)** — the **beoordeling decision model** in the Domain Service. Foundation for the behandel-portal: it gives the domain a proper decision lifecycle before any UI/Flowable/BFF work. - **Statuses:** add `InBehandeling` and `Afgewezen` to `RegistrationStatus`. - **Aggregate:** `TakeIntoBehandeling()` (`Ingediend → InBehandeling`, idempotent, guards terminal states); generalise the behandelaar decision — `Approve()` (requires a zaak) and new `Reject()` both act on an `Ingediend`/`InBehandeling` registration → `Ingeschreven`/`Afgewezen`. - **Use-case:** `BeoordeelRegistratie` (`goedkeuren` sets the zaak's final status via the ACL §8.1 → `Ingeschreven`; `afwijzen` → `Afgewezen`, domain-only for now). Idempotent. - **Endpoint:** `POST /registrations/{id}/decide` (`{ "besluit": "goedkeuren" | "afwijzen" }`), superseding the temporary `/approve` (retired when the portal lands, S-12d). - **BDD:** `EenRegistratieBeoordelen.feature` — goedkeuren + afwijzen scenarios (feature-scoped bindings). **Scoped out** to later S-12 sub-slices: Flowable user-task claim/complete + BPMN `userTask` (S-12b), BFF `/behandel/*` + medewerker authz (S-12c), the Angular behandel-portal + e2e (S-12d), and propagating a *rejection* to the zaak/projection via the ACL. ## Definition of Done - [x] Linked issue: #13 (umbrella; this PR `refs`, does not close) - [x] Tests first; red → green per behaviour - [x] Unit + acceptance green (`make unit`): domain 65, acceptance 9 - [x] Mutation ≥ break(90): domain 98.77%, no survivors in new code (the one unkilled mutant is the pre-existing `FlowableWorkflowClient` baseline) - [x] CI green (pending) Part of #13.
not added 7 commits 2026-07-14 15:26:37 +00:00
First step of S-12a (beoordeling decision model): an INGEDIEND registration moves
to IN_BEHANDELING when a behandelaar picks it up. Red — TakeIntoBehandeling() and
the InBehandeling status do not exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds InBehandeling + Afgewezen statuses and TakeIntoBehandeling(). Generalises the
behandelaar decision: Approve() (requires a zaak) and new Reject() both act on an
INGEDIEND or IN_BEHANDELING registration, moving it to Ingeschreven/Afgewezen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Red — the BeoordeelRegistratie use-case and BeoordelingsBesluit do not exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
BDD scenarios (Gherkin/Reqnroll) driving S-12's decide flow: a behandelaar takes an
INGEDIEND registration into behandeling and decides it goedkeuren (→ INGESCHREVEN,
zaak status via the ACL) or afwijzen (→ AFGEWEZEN, no ACL). Feature-scoped bindings
avoid clashing with the identically-phrased status step in RegistratieIndienen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
feat(domain): expose POST /registrations/{id}/decide for the beoordeling (refs #13)
All checks were successful
CI / lint (pull_request) Successful in 1m20s
CI / build (pull_request) Successful in 1m12s
CI / unit (pull_request) Successful in 1m32s
CI / frontend (pull_request) Successful in 2m47s
CI / mutation (pull_request) Successful in 6m6s
CI / verify-stack (pull_request) Successful in 7m45s
7693a4a85a
The behandel-portal's decision reaches the domain here (via the BFF, later slices):
goedkeuren/afwijzen, idempotent, superseding the temporary /approve endpoint.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
not added the type:slicearea:domain labels 2026-07-14 15:26:41 +00:00
not merged commit d4ed0ffc22 into main 2026-07-15 07:12:20 +00:00
Sign in to join this conversation.