The status-set integration test hit 400 "resultaat-does-not-exist: Zaak has no
resultaat" — OpenZaak refuses a zaak's eindstatus until the zaak has a resultaat.
Resolve the zaaktype's resultaattype and POST /resultaten before POST /statussen.
Also surface the ZGW response body in the failure exception (EnsureSuccessStatusCode
hid the 400 detail that pinpointed this). Reworked the gateway with shared
GetCatalogusAsync/PostAsync helpers and rewrote the stub-handler tests for the new
4-call flow incl. failure paths. Verified against real OpenZaak (integration test
green) and locally: acl mutation 100%.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
verify-up failed: the event-subscriber and projection-api both migrate the shared
projection DB on start, and EF releases its migrations-history lock between individual
migrations — harmless with one migration, but the new AddNotificationResource made a
second, so a migrator re-applied it in the window between the other's two migrations
("column resource already exists"). Hold a session pg_advisory_lock across the whole
MigrateAsync so the sequence runs exactly once; the second migrator then finds nothing
pending.
Verified by starting both images simultaneously against a fresh Postgres: both reach
health, the resource column is created once, and __EFMigrationsHistory has both rows.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The new gateway/use-case code left surviving mutants (empty NoCoverage on the ACL
gateway status-set, plus unasserted error messages, null-guards, and the persist
call). Add stub-handler tests for SetZaakToEindstatusAsync (eindstatus resolution,
POST framing, failure paths) and assert the approve use case's messages, null
handling and SaveAsync. Local Stryker: acl 100%, domain 98.4%, event-subscriber 100%.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Records the two non-obvious decisions: the ACL resolves the zaaktype eindstatus
(domain stays ZGW-ignorant), and the event-subscriber projects INGESCHREVEN from
the notification alone (hoofdObject + any status-create), never reading OpenZaak.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extend the walking-skeleton happy path: after the entry is publicly visible as
INGEDIEND, approve it via the temporary admin endpoint (waiting for the zaak to be
opened first), then poll the openbaar register until it shows INGESCHREVEN —
covering submit → BFF → domain → ACL → NRC → projection → public visibility.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bind the NRC hoofdObject, recognise a zaken/status/create notification, and key the
projection on the zaak (hoofdObject) so the status updates the existing INGEDIEND row
to INGESCHREVEN — without reading OpenZaak (§8.1). Retain the ZGW resource in the log
(new column + migration) so a rebuild reproduces the approved status. Updates the
acceptance fakes for the new IAclClient/IZaakGateway members.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A zaken/status/create notification (hoofdObject = the zaak) updates the zaak's row to
INGESCHREVEN, and a rebuild reproduces it. Red: Notification has no hoofdObject/
IsZaakStatusSet and RegistrationStatus.Ingeschreven doesn't exist.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The gateway resolves the zaaktype's eindstatus from the catalogus (isEindstatus,
falling back to the highest volgnummer) and POSTs a status against the zaak. Exposed
as POST /statussen for the domain's approve use case. Adds an integration test that
sets the eindstatus against a real OpenZaak and verifies the zaak's current status.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Red: AclService.ApproveZaakAsync and IZaakGateway.SetZaakToEindstatusAsync don't exist yet.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Loads the registration, asks the ACL to set its zaak's final status (new
IAclClient.ApproveZaakAsync → POST /statussen), then advances the aggregate to
INGESCHREVEN. Idempotent: a repeated approval is a no-op. Adds HTTP-adapter tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Approve() advances a submitted registration with an opened zaak to INGESCHREVEN;
re-approval and approval-before-zaak are rejected as invalid transitions.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Guards: an opened zaak is required and only a submitted registration can be
approved. Fails to compile — Registration.Approve() and RegistrationStatus.
Ingeschreven don't exist yet (red).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
