ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
53 lines
1.9 KiB
Markdown
53 lines
1.9 KiB
Markdown
# WP-50 — OpenZaak create-zaak (first write slice)
|
|
|
|
Status: done (de3bff0)
|
|
Phase: 9 — OpenZaak / ZGW integration
|
|
|
|
## Why
|
|
|
|
WP-49 made the cases **read** path source-swappable. The next slice is the first **write**:
|
|
create a Zaak in OpenZaak when an aanvraag is submitted, still behind the config gate, still
|
|
without changing the FE contract.
|
|
|
|
## Read first
|
|
|
|
- [openzaak-integration.md](../reference/openzaak-integration.md) — "How to add the next slice"
|
|
- [ADR-0005](../reference/architecture/0005-openzaak-behind-bff.md), [ADR-0001](../reference/architecture/0001-bff-lite-decision-dtos.md)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- Route the create through the existing submit/mutation seam; keep the FE response DTO identical.
|
|
- A create needs a `zaaktype` **URL** from Catalogi (OpenZaak validates it by fetching) — map
|
|
the aanvraag `type` → a configured zaaktype URL.
|
|
- Follow the create with a `status` + a `rol` (initiator/betrokkene by BSN) as ZGW expects.
|
|
|
|
## Files
|
|
|
|
- Extend `IZaakSource` (or add a write method) + `OpenZaakZaakSource`; `LocalZaakSource` keeps
|
|
the current local submit.
|
|
- `ZgwOptions`: a `type → zaaktype URL` map + `bronorganisatie`/`verantwoordelijkeOrganisatie` (RSIN).
|
|
|
|
## Steps
|
|
|
|
1. Add `CreateZaak` to the source seam; local impl = current submit, OpenZaak impl = POST to ZRC.
|
|
2. Map aanvraag `type` → zaaktype URL; POST zaak, then status + rol.
|
|
3. Map the created Zaak back into the existing submit response DTO.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] Submitting with `Zgw:Enabled=true` creates a Zaak (+ status + rol) in OpenZaak.
|
|
- [ ] FE submit response DTO unchanged; no api-client drift.
|
|
- [ ] Covered by tests (stub handler asserts the POST bodies + type→zaaktype mapping).
|
|
|
|
## Verification
|
|
|
|
`dotnet test`; against a docker OpenZaak if available.
|
|
|
|
## Out of scope
|
|
|
|
Documenten (WP-51), Notificaties (WP-52).
|
|
|
|
## Risks
|
|
|
|
Create needs read scope on Catalogi (type-URL validation) — provision AC scopes accordingly.
|