2 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	89ad3490b0	feat(openzaak): idempotent catalogus/zaaktype/zaak provisioning (WP-56) ... bootstrap-catalogus.sh now looks up every resource by its natural key before creating it (catalogus by domein+rsin, zaaktype by catalogus+identificatie, statustype by zaaktype+volgnummer, roltype by zaaktype+omschrijvingGeneriek, zaaktype-publish by checking `concept` first, zaak by identificatie, status/rol by existence-under-the-zaak), so rerunning against an already-seeded instance reuses what's there instead of erroring. The WP's original plan (move this into OpenZaak's `setup_configuration` mechanism) turned out not to be achievable: reading the actual django_setup_configuration steps installed inside the open-zaak image shows no step exists for Catalogi/Zaken content anywhere in this OpenZaak version — only sites/credentials/applicaties/selectielijst. Documented as a deviation; the WP's own Risks section already anticipated this and sanctioned falling back to an idempotent script. Verified live: fresh instance -> full run (all created) -> integration test green -> reran the script twice more against the same instance (all reused, identical URLs, no duplicates) -> integration test still green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 12:57:37 +02:00
ehoandClaude Sonnet 5	5cb3e1a9f0	feat(zgw): docker OpenZaak integration-test harness (WP-54) ... Opt-in docker-compose (postgres+redis+OpenZaak, no celery/nginx) + bootstrap-catalogus.sh seed a real OpenZaak instance; OpenZaakIntegrationTests (Category=Integration, excluded from default dotnet test/CI) proves the ZGW seam against it for the first time. That live run caught a real bug: ZgwHttpClient never sent Content-Crs/Accept-Crs headers, so every write would 412 against a spec-compliant OpenZaak — fixed alongside the harness. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 09:08:35 +02:00